4 ms·
To decide on a language for a math research project, I implemented a toy problem in many languages: What is the distribution of cycle counts for signed permutat
by Syzygies 11mo ago
To decide on a language for a math research project, I implemented a toy problem in many languages: What is the distribution of cycle counts for signed permutations on n letters? Use all cores in parallel.
C++ 100 19.57s
Rust 96 20.40s
F# 95 20.52s
Nim 75 26.04s
Julia 64 30.40s
Ocaml 48 41.07s
Haskell 41 47.64s
Chez 39 49.53s
Swift 33 58.46s
Lean 7 278.88s
Tarjan, n = 10
Nyx - Apple M4 Max - 12 performance and 4 efficiency cores
n! * 2^n = 3,715,891,200 signed permutations
score = gops normalized so best language averages 100
time = running time in seconds
This had me briefly smitten with F#, till I realized the extent that rusty .NET bed springs were poking through. Same as the JVM and Clojure, or Erlang and Elixir. The F# JIT compiler is nevertheless pretty amazing.
I nearly settled on OCaml. After AI warning me that proper work-stealing parallelism is a massive, sophisticated project to code properly, the 40 lines of OCaml code I wrote that beat available libraries is my favorite code file in years.
Nevertheless, once one understands lazy evaluation in Haskell, it's hard to use any other language. The log slowdown for conventional use of a functional data structure becomes a linear speedup once one exploits persistence.
- fud101 11mo agoInteresting, would be a good blog post to read.
- delta_p_delta_x 11mo agoI would really like to read more about this!
- fithisux 11mo agoNo Fortran?
- jibal 11mo agoWhat about D? Can you post any of the 10 source codes?
- davidwritesbugs 11mo agoF# would be awesome but for the dogs*t .Net backend that made the tiniest error insoluble
- thw_9a83c 11mo agoF# is a nice language, but it depends on .NET, so a direct comparison to OCaml is not possible. The .NET runtime dependency often makes things unnecessarily complex and fragile. There must be a reason why Golang (no VM runtime) is successful despite entering the market very late after Java and C# had already established clear dominance.
- neonsunset 11mo ago[dead]
- dontlaugh 11mo agoEasier deployment helped, but nowadays it’s common to put a single Go executable in a container anyway. .net core doesn’t have much if any disadvantage there. Go was made by Google flawed, but with clarity of purpose and consistently usable libraries. .NET spent years forked into framework and core and unclear open source future. Java struggled to scale down and Oracle caused similar distrust as Microsoft.
- thw_9a83c 11mo agoWhile I agree with most points, .NET or JRE introduce additional complexity that may not be welcome in every setting. I've worked for several companies where upgrading to a newer version of .NET was always a major pain point, especially for applications that weren't very actively developed. There is limited security support for each major .NET version, so at some point, you and your customers need to upgrade. Such problems are non-existent if you don't have a separate VM runtime dependency.
- dontlaugh 11mo agoI don’t think that has anything to do with VMs, the same happens with C++ runtime libraries. The difference is Go really focused on continuity and compatibility, while .NET didn’t.
- 11mo ago