Oberon VS are-we-fast-yet

Compare Oberon vs are-we-fast-yet and see what are their differences.

Oberon

Oberon parser, code model & browser, compiler and IDE with debugger (by rochus-keller)

are-we-fast-yet

Are We Fast Yet? Comparing Language Implementations with Objects, Closures, and Arrays (by smarr)
Our great sponsors
  • InfluxDB - Power Real-Time Data Analytics at Scale
  • WorkOS - The modern identity platform for B2B SaaS
  • SaaSHub - Software Alternatives and Reviews
Oberon are-we-fast-yet
76 18
415 315
- -
7.4 8.8
15 days ago about 1 month ago
C++ Java
GNU General Public License v3.0 only GNU General Public License v3.0 or later
The number of mentions indicates the total number of mentions that we've tracked plus the number of user suggested alternatives.
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.

Oberon

Posts with mentions or reviews of Oberon. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2024-01-21.

are-we-fast-yet

Posts with mentions or reviews of are-we-fast-yet. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2024-01-21.
  • Boehm Garbage Collector
    9 projects | news.ycombinator.com | 21 Jan 2024
    > 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.

  • A C++ version of the Are-we-fast-yet benchmark suite
    2 projects | /r/cpp | 26 Jun 2023
    See https://github.com/smarr/are-we-fast-yet/blob/master/docs/guidelines.md.
  • Are We Fast Yet? Comparing Language Implementations with Objects, Closures, and Arrays
    2 projects | /r/programming | 20 Mar 2022
  • .NET 6 vs. .NET 5: up to 40% speedup
    15 projects | news.ycombinator.com | 21 Nov 2021
    > Software benchmarks are super subjective.

    No, they are not, but they are just a measurement tool, not a source of absolute thruth. When I studied engineering at ETH we learned "Who measures measures rubbish!" ("Wer misst misst Mist!" in German). Every measurement has errors and being aware of these errors and coping with it is part of the engineering profession. The problem with programming language benchmarks is often that the goal is to win by all means; to compare as fairly and objectively as possible instead, there must be a set of suitable rules adhered to by all benchmark implementations. Such a set of rules is e.g. given for the Are-we-fast-yet suite (https://github.com/smarr/are-we-fast-yet).

  • Is CoreCLR that much faster than Mono?
    2 projects | news.ycombinator.com | 29 Aug 2021
    I am aware of the various published test results where CoreCLR shows fantastic speed-ups compared to Mono, e.g. when calculating MD5 or SHA hash sums.

    But my measurements based on the Are-we-fast-yet benchmark suite (see https://github.com/smarr/are-we-fast-yet and https://github.com/rochus-keller/Oberon/tree/master/testcases/Are-we-fast-yet) show a completely different picture. Here the difference between Mono and CoreCLR (both versions 3 and 5) is within +/- 10%, so nothing earth shattering.

    Here are my measurement results:

    https://github.com/rochus-keller/Oberon/blob/master/testcases/Are-we-fast-yet/Are-we-fast-yet_results_linux.pdf comparing the same benchmark on the same machine run under LuaJIT, Mono, Node.js and Crystal.

    https://github.com/rochus-keller/Oberon/blob/master/testcases/Are-we-fast-yet/Are-we-fast-yet_results_windows.pdf comparing Mono, .Net 4 and CoreCLR 3 and 5 on the same machine.

    Here are the assemblies of the Are-we-fast-yet benchmark suite used for the measurements, in case you want to reproduce my results: http://software.rochus-keller.ch/Are-we-fast-yet_CLI_2021-08-28.zip.

    I was very surprised by the results. Perhaps it has to do with the fact that I measured on x86, or that the benchmark suite used includes somewhat larger (i.e. more representative) applications than just micro benchmarks.

    What are your opinions? Do others have similar results?

  • Is CoreCLR really that much faster than Mono?
    6 projects | /r/dotnet | 29 Aug 2021
    But my measurements based on the Are-we-fast-yet benchmark suite (see https://github.com/smarr/are-we-fast-yet and https://github.com/rochus-keller/Oberon/tree/master/testcases/Are-we-fast-yet) show a completely different picture. Here the difference between Mono and CoreCLR (both versions 3 and 5) is within +/- 10%, so nothing earth shattering.
    6 projects | /r/dotnet | 29 Aug 2021
    There is a good reason for this; have a look at e.g. https://github.com/smarr/are-we-fast-yet/blob/master/docs/guidelines.md.
  • Ranking programming languages by energy efficiency (scientific paper, 2021)
    5 projects | /r/ProgrammingLanguages | 7 Feb 2021
    If you want to compare different language implementations, you have to somehow control what you compare; the implementations must do the same thing with the same quantity, and especially for VMs and interpreters you want to make sure that you're not comparing a native library call with an interpreted version of the same function. The Are-we-fast-yet has a decent set of rules from by point of view to enable fair comparisons, and even though it's still possible to use ideomatic paradigms supported by the language. Have you seen this document: https://github.com/smarr/are-we-fast-yet/blob/master/docs/guidelines.md?
    5 projects | /r/ProgrammingLanguages | 7 Feb 2021
    Personally, I like this benchmark suite better, but unfortunately the number of implementations is still quite small: https://github.com/smarr/are-we-fast-yet
    5 projects | /r/ProgrammingLanguages | 7 Feb 2021
    See the publication (https://stefan-marr.de/papers/dls-marr-et-al-cross-language-compiler-benchmarking-are-we-fast-yet/) about what rules they apply. The code is ideomatic, but they require that all implementations use the same data structure implementations to make it comparable. Here is a discussion in the pull request: https://github.com/smarr/are-we-fast-yet/pull/30.

What are some alternatives?

When comparing Oberon and are-we-fast-yet you can also consider the following projects:

gleam - ⭐️ A friendly language for building type-safe, scalable systems!

oberon-riscv - Oberon RISC-V port, based on Samuel Falvo's RISC-V compiler and Peter de Wachter's Project Norebo. Part of an academic project to evaluate Project Oberon on RISC-V.

crystal - The Crystal Programming Language

MoarVM - A VM with adaptive optimization and JIT compilation, built for Rakudo

Smalltalk - Parser, code model, interpreter and navigable browser for the original Xerox Smalltalk-80 v2 sources and virtual image file

tectonic - A modernized, complete, self-contained TeX/LaTeX engine, powered by XeTeX and TeXLive.

fast-ruby - :dash: Writing Fast Ruby :heart_eyes: -- Collect Common Ruby idioms.

aws-lambda-rust-runtime - A Rust runtime for AWS Lambda

nappgui - Cross-Platform C SDK (precompiled)

atldotnet - Fully managed, portable and easy-to-use C# library to read and edit audio data and metadata (tags) from various audio formats, playlists and CUE sheets

core - .NET news, announcements, release notes, and more!

PyCall.jl - Package to call Python functions from the Julia language