tex-oberon VS Oberon

Direct link to the current release of pdf, generated from his work so far:

https://github.com/guidoism/tex-oberon/releases/download/v0....

I re-typeset the text in TeX and have a nicer looking PDF for those that care: https://github.com/guidoism/tex-oberon

Ok, I see, thanks; so it's the same version as implemented in OBNC posted above. It's the last version Wirth specified, and quite different from the versions used for the Oberon systems 2, 3 and 4 in the nineties. Personally I consider Oberon-2 the most useful version, but I still had to get rid of a lot of orthodoxies to really use it in my projects (see https://github.com/rochus-keller/Oberon).

> LuaJITted Lua code runs at 80% (on average, sometimes faster!) of the compiled C version of the same algorithm, typically

Cannot confirm this. It might be true on selected micro benchmarks. Here are the results of the Are-we-fast-yet benchmark suite, which includes a decent set of benchmarks challenging CPU, cache and memory access: https://github.com/rochus-keller/Oberon/blob/master/testcase....

On average, the C and C++ implementations are five times faster than LuaJIT.

> Oberon also doesn't seem to be actively developed anymore as far as I can tell

See https://github.com/rochus-keller/Oberon, and derived languages such as https://github.com/rochus-keller/Luon or https://github.com/rochus-keller/Micron, which inherit the "spirit of Oberon", but specialize for other use-cases than the original.

> Since Oberon is as much a compiler as it's a complete system,

The system and the language are two different things (even if they unfortunately share the same name); the language itself doesn't depend on the system. Instead there is a standard library defined in the Oakwood guidelines; the guidelines even define a (primitive) drawing window (XYPlane). The Oberon+ compiler (see https://github.com/rochus-keller/oberon/) includes a foreign function interface and a binding to e.g. the NAppGUI library which is a powerfull cross-platform user interface framework, but also an SDL binding, which is e.g. used by https://github.com/rochus-keller/OberonSystem3/.

My major system programming languages are C and C++, but I did some projects in Oberon (which turned out to be not particularly suited for systems programming), and then created a modified, better suited version of it called Oberon+ (https://github.com/rochus-keller/Oberon), which I e.g. used to create platform-independend versions of different Oberon System generations.

But Oberon+ is still too high-level for many system programming tasks. So I'm designing a new system programming language called Micron (for Micro Oberon, see https://github.com/micron-language/specification) which has the full power of C without its disadvantages. You can even use it for the OS bootstrapping when there is no stack and no heap, but also for higher-level application development, due to its selectable language levels.

It's not about a "final conclusion", just about a summary of the measurement results at hand. Instead of letting the user to trawl through a lot of documents and figures and make geomean and factors calculations him/herself, the author who publishes measurement results should do this. Here is an example how this could look: https://github.com/rochus-keller/Oberon/blob/master/testcase.... It is immediately recognizable how much less time on average the C++ implementation used compared to the reference (LuaJIT in this case).

You can e.g. use Node.js as a reference and compare with these results: https://github.com/rochus-keller/Oberon/blob/master/testcase.... LuaJIT with JIT on is usually factor two slower than Node.js and factor five slower than C/C++ in my measurements.

Pallene unfortunately is only a subset of Lua, i.e. you cannot simply take a Lua program and compile it with Pallene. The use case of this language is not obvious to me, since if I have to re-implement the performance-critical parts of the Lua program anyway, I can just as good implement it in C using the Lua C API. Thus the claim of the Pallene authors is a bit misleading.

Concerning LuaJIT performance, I have done a lot of measurements over the years (see e.g. https://github.com/rochus-keller/Oberon/blob/master/testcase...) and would rather say that its performance is about factor four worse on average than an equivalent C++ -O2 compiled program. For some exceptional use cases it might perform as good as C, but not in general (one reason is the missing tracing JIT support for closures).

> Sure there's a small overhead to smart pointers

Not so small, and it has the potential to significantly speed down an application when not used wisely. Here are e.g. some measurements where the programmer used C++11 and did everything with smart pointers: https://github.com/smarr/are-we-fast-yet/issues/80#issuecomm.... There was a speed down between factor 2 and 10 compared with the C++98 implementation. Also remember that smart pointers create memory leaks when used with circular references, and there is an additional memory allocation involved with each smart pointer.

> Garbage collection has an overhead too of course

The Boehm GC is surprisingly efficient. See e.g. these measurements: https://github.com/rochus-keller/Oberon/blob/master/testcase.... The same benchmark suite as above is compared with different versions of Mono (using the generational GC) and the C code (using Boehm GC) generated with my Oberon compiler. The latter only is 20% slower than the native C++98 version, and still twice as fast as Mono 5.