fast-ruby
are-we-fast-yet
Our great sponsors
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 |
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
-
Sorry for this noobest question
In this perspective, maybe the compilation of approaches by Fast Ruby provides a similar point of entry.
-
Super readable String operations with `delete_prefix` and `delete_suffix`
Stylistically, chomp has a bit more of the whimsy that you might expect from Ruby, while delete_suffix is a nice mirroring of delete_prefix and more explicitly named. Both have similar performance benchmarks and are faster than sub.
-
Ruby 3.0.0 Released
If you’re interested in speed, check this repo: even among Ruby idioms there are big speed differences.
are-we-fast-yet
-
Boehm Garbage Collector
> 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
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
-
.NET 6 vs. .NET 5: up to 40% speedup
> 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?
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?
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.
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)
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?
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
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?
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