6 ms·

Are-we-fast-yet implementations in Oberon, C++, C, Pascal, Micron and Luon

91 points by luismedel 11mo ago

rpcope1 11mo ago
Micron seems like a bad naming choice...maybe it predates the manufacturer?
- Rochus 11mo 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.
  - kragen 11mo ago
    Wouldn't be surprising if the computer/RAM company had registered the trademark in some countries for the field of software.
    - Rochus 11mo ago
      They surely have better things to do than worry about what I call my programming language.
      - kragen 11mo ago
        If they have a trademark they don't defend, they can lose it.
        Rochus 11mo ago
        I think we can skip this discussion.
        kragen 11mo ago
        Okay.
        nine_k 11mo ago
        The word "micron" is a common unit of measurement (μm). The trademark Micron™ only applies to microelectronic hardware, I suppose.
        kragen 11mo ago
        I hope you are correct, but probably continuing the discussion usefully would require doing a trademark search.
        achierius 11mo ago
        They also have a Micron trademark for software, as they sell some software packages. So it's really just a question of whether or not they notice and decide to go after you.
        tialaramex 11mo ago
        No. This is a common misconception. I know, you asked an LLM and it said you were very right and it cited a bunch of legal cases which prove you correct. You didn't check any of those citations, because they looked right, because it's an LLM and generating plausible nonsense is exactly what it's good at. Or worse, you just relied on a vague memory that other people said the reason they have to do something reprehensible was because it's legally required, and even though you've heard that bullshit from a dozen US politicians in the last week and know it's bullshit you thought they must be correct.
        kragen 11mo ago
        No, I've been interested in "intellectual property" restrictions since last millennium, so I've been familiar with the outlines of US trademark law for a while. You evidently are not. Aside from the reductions in scope resulting from laches and equitable estoppel, demonstrating a clear record of enforcement efforts is crucial to preventing genericization, which can befall even the most inherently distinctive marks such as "heroin". Nowadays it can indeed be difficult to avoid getting taken in by LLM bullshit even if you don't ask an LLM yourself, but it is still possible. https://simmonsattorney.com/generic-trademarks/ https://simmonsattorney.com/generic-trademarks/
        jecel 11mo ago
        You are correct about the US in relation to trademarks. The situation there is rather complex, with it being possible for people to just add TM to their texts and ask other people to do the same and it is considered legally binding. They can take the extra step of registering and then they add (R) to their texts and that gets them an even stronger legal case. Because of the case law nature of the US legal system and the informality of TM, if other people start using the term in other ways (for example using "xerox" as a verb meaning "copy") and you don't show an effort to curb that then you can lose your trademark. In other countries things are different. Brazil, for example, uses a Latin legal system which is more formal. So the only thing that matters is whether you have registered the trademark with INPI (National Institute for Intellectual Property) or not. Which is why Gradiente owned the iPhone trademark in Brazil even though they were not using it anymore (it was from a product from around 2000) and if you asked anybody on the streets in Brazil they would associate the name with Apple.
  - willrshansen 11mo ago
    MicrOberon
- oneshtein 11mo 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.»
Hannah203 11mo ago
[dead]
nmeofthestate 11mo ago
I'd be more interested in the results, relative to the languages from the main repository.
- Rochus 11mo 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/Luau/Results.pdf https://github.com/rochus-keller/Are-we-fast-yet/blob/main/L... Or here: https://github.com/rochus-keller/Oberon/blob/master/testcases/Are-we-fast-yet/Are-we-fast-yet_results_linux.pdf 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 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.
- eska 11mo 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.
  - Rochus 11mo 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.
dardeaup 11mo ago
I'd like to hear more about the Oberon languages and compilers used.
- Rochus 11mo ago
  See e.g. https://github.com/rochus-keller/Oberon https://github.com/rochus-keller/Oberon or https://github.com/rochus-keller/Are-we-fast-yet/blob/main/Oberon90/Results/Summary.md https://github.com/rochus-keller/Are-we-fast-yet/blob/main/O....

91 points by luismedel 11mo ago

rpcope1 11mo ago

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

Rochus 11mo 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.
- kragen 11mo ago
  Wouldn't be surprising if the computer/RAM company had registered the trademark in some countries for the field of software.
  - Rochus 11mo ago
    They surely have better things to do than worry about what I call my programming language.
    - kragen 11mo ago
      If they have a trademark they don't defend, they can lose it.
      - Rochus 11mo ago
        I think we can skip this discussion.
        kragen 11mo ago
        Okay.
      - nine_k 11mo ago
        The word "micron" is a common unit of measurement (μm). The trademark Micron™ only applies to microelectronic hardware, I suppose.
        kragen 11mo ago
        I hope you are correct, but probably continuing the discussion usefully would require doing a trademark search.
        achierius 11mo ago
        They also have a Micron trademark for software, as they sell some software packages. So it's really just a question of whether or not they notice and decide to go after you.
      - tialaramex 11mo ago
        No. This is a common misconception. I know, you asked an LLM and it said you were very right and it cited a bunch of legal cases which prove you correct. You didn't check any of those citations, because they looked right, because it's an LLM and generating plausible nonsense is exactly what it's good at. Or worse, you just relied on a vague memory that other people said the reason they have to do something reprehensible was because it's legally required, and even though you've heard that bullshit from a dozen US politicians in the last week and know it's bullshit you thought they must be correct.
        kragen 11mo ago
        No, I've been interested in "intellectual property" restrictions since last millennium, so I've been familiar with the outlines of US trademark law for a while. You evidently are not. Aside from the reductions in scope resulting from laches and equitable estoppel, demonstrating a clear record of enforcement efforts is crucial to preventing genericization, which can befall even the most inherently distinctive marks such as "heroin". Nowadays it can indeed be difficult to avoid getting taken in by LLM bullshit even if you don't ask an LLM yourself, but it is still possible. https://simmonsattorney.com/generic-trademarks/ https://simmonsattorney.com/generic-trademarks/
        jecel 11mo ago
        You are correct about the US in relation to trademarks. The situation there is rather complex, with it being possible for people to just add TM to their texts and ask other people to do the same and it is considered legally binding. They can take the extra step of registering and then they add (R) to their texts and that gets them an even stronger legal case. Because of the case law nature of the US legal system and the informality of TM, if other people start using the term in other ways (for example using "xerox" as a verb meaning "copy") and you don't show an effort to curb that then you can lose your trademark. In other countries things are different. Brazil, for example, uses a Latin legal system which is more formal. So the only thing that matters is whether you have registered the trademark with INPI (National Institute for Intellectual Property) or not. Which is why Gradiente owned the iPhone trademark in Brazil even though they were not using it anymore (it was from a product from around 2000) and if you asked anybody on the streets in Brazil they would associate the name with Apple.
- willrshansen 11mo ago
  MicrOberon
oneshtein 11mo 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.»

Hannah203 11mo ago

[dead]

nmeofthestate 11mo ago

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

Rochus 11mo 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/Luau/Results.pdf https://github.com/rochus-keller/Are-we-fast-yet/blob/main/L... Or here: https://github.com/rochus-keller/Oberon/blob/master/testcases/Are-we-fast-yet/Are-we-fast-yet_results_linux.pdf 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 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.
eska 11mo 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.
- Rochus 11mo 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.

dardeaup 11mo ago

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

Rochus 11mo ago
See e.g. https://github.com/rochus-keller/Oberon https://github.com/rochus-keller/Oberon or https://github.com/rochus-keller/Are-we-fast-yet/blob/main/Oberon90/Results/Summary.md https://github.com/rochus-keller/Are-we-fast-yet/blob/main/O....