fast-ruby VS are-we-fast-yet

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

fast-ruby

:dash: Writing Fast Ruby :heart_eyes: -- Collect Common Ruby idioms. (by fastruby)

are-we-fast-yet

Are We Fast Yet? Comparing Language Implementations with Objects, Closures, and Arrays (by smarr)
Our great sponsors
  • PopRuby - Clothing and Accessories for Ruby Developers
  • InfluxDB - Power Real-Time Data Analytics at Scale
  • WorkOS - The modern identity platform for B2B SaaS
fast-ruby are-we-fast-yet
4 18
5,641 315
0.2% -
4.6 8.8
4 months ago about 1 month ago
Ruby Java
- 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.

fast-ruby

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

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 fast-ruby and are-we-fast-yet you can also consider the following projects:

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

Rails style guide - A community-driven Ruby on Rails style guide

Ruby style guide - A community-driven Ruby coding style guide

RSpec style guide - RSpec Best Practices

Fundamental Ruby - :books: Fundamental programming with ruby examples and references. It covers threads, SOLID principles, design patterns, data structures, algorithms. Books for reading. Repo for website https://github.com/khusnetdinov/betterdocs

crystal - The Crystal Programming Language

Best-Ruby - Ruby Tricks, Idiomatic Ruby, Refactoring and Best Practices

contracts.ruby - Contracts for Ruby.

Functional Ruby

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

Oberon - Oberon parser, code model & browser, compiler and IDE with debugger