71–80 of 209 posts
simplicity source brain load Rust 95% Go 23%
Also, in readability Go wins. Because you don't have to put single quotes and HTML tags after every variable.
Why is Java faster than Go?
Earlier quoted context omitted.
> I guess because its not in the stdlib in Go? It's a game, and the sources are available. Nobody is stopping Golang enthusiasts from posting the results with a slab allocator or some other third-party packages.
Yes the maintainer is. People have tried.
These benchmarks have many flaws. Consider this thread: https://www.reddit.com/r/golang/comments/51mhzv/on_the_binar... The binary-trees benchmark would fare significantly better in Go if it were allowed to use an arena allocator like other implementations. But its not. This despite the fact that the Rust version literally uses one: https://benchmarksgame-team.pages.debian.net/benchmarksgame/... . I guess because its…
There are many predictable things in life: the tendency of up-and-comer languages to blitz these benchmarks due to careful optimization, and the tendency of people whose pet language has lost on a benchmark or two to get on here and write off the idea that anyone should ever benchmark cross-language. Some of the benchmarks are pretty ridiculous and flawed. Others look pretty straightforwardly comparable. I have troub…
Also they tend to focus on the developer who optimizes code, not the journeyman developer in your company who actually writes code. C or Fortran looks fantastic on benchmarks, but if you forced all your developers to use C I doubt you'd see a similar outcome.
They seem to push developers in the direction of coming up with simple rules of thumb like "Go is 2x slower than C" or "Python is 10x slower than C" which is complete nonsense. It really matters what the code is doing.
In particular for server programs developers come to these conclusions without considering the multi-core environment they're working in. ie, redis is a really fast key-value store that will use 1 core on a 32 core machine.
And as it turns out all the tips and tricks to improving performance in these cases works in all the other languages too. So just what are we to conclude from them?
I suppose a nice simple math benchmark can demonstrate that LLVM or GCC is better at optimizing code than Go?
Anyone has tried modifying the go regex benchmark to use https://github.com/BurntSushi/rure-go ? It seems to use a library that isn't even on github anymore.
"Go bindings to Rust's regex engine." - I't would not be in the spirit of the comparison. - Even though most scripting languages also have native regex implementations.
I expect Rust to be faster than Go as a rule because of its somewhat lower level nature and cost-less "unmanaged" abstractions but I didn't expect it to be a full order of magnitude faster than Go for some benchmarks. Are the Go snippets not properly optimized or is there something else going on? I think pitting Go against Rust is somewhat inflammatory but if you look at the Rust vs. C++ benchmark the results are muc…
Explanations for the few largest offenders: 1. regex-redux Rust has it's own regexp engine, that lacks a few of the bells and whistles of PCRE, but is much faster than it. (And has no sheer perfomance cliffs where a carefully crafted target string or search expression can DOS the app.) Also, I think the rust implementation can do less copying. GO just uses PCRE. (Which is weird, isn't RE2 a google project?) 2. binary…
I believe that there is an optimization that allows this to be completely avoided for types with only trivial or no destructors.
I expect Rust to be faster than Go as a rule because of its somewhat lower level nature and cost-less "unmanaged" abstractions but I didn't expect it to be a full order of magnitude faster than Go for some benchmarks. Are the Go snippets not properly optimized or is there something else going on? I think pitting Go against Rust is somewhat inflammatory but if you look at the Rust vs. C++ benchmark the results are muc…
Explanations for the few largest offenders: 1. regex-redux Rust has it's own regexp engine, that lacks a few of the bells and whistles of PCRE, but is much faster than it. (And has no sheer perfomance cliffs where a carefully crafted target string or search expression can DOS the app.) Also, I think the rust implementation can do less copying. GO just uses PCRE. (Which is weird, isn't RE2 a google project?) 2. binary…
So does the Java implementation, and still it fares much (3x) better than Go.
Not really that surprising. I spent a good chunk of time trying to make a Go program as fast as a well written Rust one (tokei) which I wrote about here https://boyter.org/posts/sloc-cloc-code/ and in the end the GC was what held me back. I suspect its possible to get Go programs for the most part close to the performance of Rust but in the end the lower level and fewer abstractions mean a well written Rust or C/C++…
simplicity source brain load Rust 95% Go 23%
Why is Java faster than Go?
Similarly Go and Rust are faster than Java in many cases, because the developers have been able to learn for past language like Java, and avoid the same performance pit falls. Or simply because they didn't have to deal with legacy support.