Are-we-fast-yet implementations in Oberon, C++, C, Pascal, Micron and Luon (opens in new tab)

(github.com)

91 pointsluismedel5mo ago25 comments

25 comments

Micron seems like a bad naming choice...maybe it predates the manufacturer?

It's the abbreviation of Micro Oberon, therefore a quite obvious naming choice; there is no real risk of confusion with commercial offers under this name; it's also a common name in science.

kragen5mo ago

Wouldn't be surprising if the computer/RAM company had registered the trademark in some countries for the field of software.

1 more reply

willrshansen4mo ago

MicrOberon

oneshtein5mo ago

«The term micron and the symbol μ were officially accepted for use in isolation to denote the micrometre in 1879, but officially revoked by the International System of Units (SI) in 1967.»

nmeofthestate4mo ago

I'd be more interested in the results, relative to the languages from the main repository.

Rochus4mo ago

There are some results in the repository, e.g. one I published recently: https://github.com/rochus-keller/Are-we-fast-yet/blob/main/L...

Or here: https://github.com/rochus-keller/Oberon/blob/master/testcase...

The main repository only recently added a C++ implementation, but it was significantly slower than mine when I check last time (see https://github.com/smarr/are-we-fast-yet/issues/80).

I mostly use the benchmarks to check how my compilers do compared to the big ones, or how the technologies I'm interested in evolve.

eska4mo ago

The original repo is about using a subset of a language to compare language implementations. I can see the point in that. But language benchmarks like this are incredibly useless and very easy to get wrong anyway. For example it you actually cared about performance for the bounce example you would never write it like this in C. Bouncing 100 balls in a loop 50 times with 4 ifs just tests the branch predictor. There is nothing to learn from this in practice.

Rochus4mo ago

Respectfully disagree. This is a compiler engineering tool backed by peer-reviewed research (DLS'16, 112+ citations) and used in 30+ academic publications across PLDI, OOPSLA, and ECOOP. It requires understanding controlled experimental methodology and compiler optimization theory to interpret correctly. Perhaps that context clarifies its purpose. The goal is to assess compiler effectiveness for a common set of core language abstractions (objects, closures, arrays), not to represent application-level performance or claim that production C code would be written this way. Your "branch predictor" criticism actually validates the benchmark's design: if different language implementations handle the same branching patterns with dramatically different performance, that reveals genuine differences in compiler designs.

dardeaup4mo ago

I'd like to hear more about the Oberon languages and compilers used.

Rochus4mo ago

See e.g. https://github.com/rochus-keller/Oberon or https://github.com/rochus-keller/Are-we-fast-yet/blob/main/O....

j / k navigate · click thread line to collapse

25 comments

rpcope15mo ago

Micron seems like a bad naming choice...maybe it predates the manufacturer?

Rochus5mo ago

It's the abbreviation of Micro Oberon, therefore a quite obvious naming choice; there is no real risk of confusion with commercial offers under this name; it's also a common name in science.

kragen5mo ago

Wouldn't be surprising if the computer/RAM company had registered the trademark in some countries for the field of software.

1 more reply

willrshansen4mo ago

MicrOberon

oneshtein5mo ago

«The term micron and the symbol μ were officially accepted for use in isolation to denote the micrometre in 1879, but officially revoked by the International System of Units (SI) in 1967.»

nmeofthestate4mo ago

I'd be more interested in the results, relative to the languages from the main repository.

Rochus4mo ago

There are some results in the repository, e.g. one I published recently: https://github.com/rochus-keller/Are-we-fast-yet/blob/main/L...

Or here: https://github.com/rochus-keller/Oberon/blob/master/testcase...

The main repository only recently added a C++ implementation, but it was significantly slower than mine when I check last time (see https://github.com/smarr/are-we-fast-yet/issues/80).

I mostly use the benchmarks to check how my compilers do compared to the big ones, or how the technologies I'm interested in evolve.

eska4mo ago

Rochus4mo ago

dardeaup4mo ago

I'd like to hear more about the Oberon languages and compilers used.

Rochus4mo ago

See e.g. https://github.com/rochus-keller/Oberon or https://github.com/rochus-keller/Are-we-fast-yet/blob/main/O....

j / k navigate · click thread line to collapse