81–90 of 209 posts
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.
> Nobody is stopping Golang enthusiasts from posting the results with a slab allocator or some other third-party packages. You've never witnessed the "game"'s maintainer interacting with people have you?
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…
Earlier quoted context omitted.
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…
I find microbenchmarks mostly useless. There are just too many variables in play. 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 o…
However, I think the fairly simple benchmarks where there looks to be a rough 1:1 correspondence between the structures of some similar Rust, Fortran, C/C++, Go code might demonstrate exactly the point you suggested (facetiously? I'm not quite sure how you are suggesting we compare compiler frameworks to a language, especially a language that can use both frameworks with alternate backends...)
I don't know why this is controversial. The Go optimizer wasn't written primarily with utmost code quality in mind (it's pretty much a lift of the Plan 9 C compiler, which I worked with in 1994). It's designed to produce code quickly. It's also not rocket science that GC can be expensive despite years of claims to the contrary (it's been 'about to be the same or faster as manual memory management' since the mid-90s at least). Leaving aside the wacky benchmarks (binary trees and regex) the results seem pretty consistent with this.
These rules of thumb are OK for what they are worth (not very much). Eventually we do have to think about how much performance can be extracted from a language if we really need it. The irritating thing about this whole benchmarking problem is that there is no natural population of programs to draw from, and there is constant thumb-on-the-scale cheating (who can intrinsic the hardest for Grandpa's ancient Core 2 duo, but no later?) - agreed. Essentially we're seeing a real-life version of the saying "the plural of anecdote is not 'data'". Nonetheless... it feels like we can say some programming languages are faster than others.
Earlier quoted context omitted.
"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.
The fastest Go benchmark for regex-redux is using PCRE, which is not a native Go regex engine. It's written in C.
It's the compiler error messages, memory safety and the lack of a Garbage Collector that speak to me more than raw performance.
Earlier quoted context omitted.
Which, at least for hash tables, seems completely reasonable and representative of most actual experiences with both languages?
No. Standard libraries are a good thing, but if you want to write performant code, you definitely should consider a more specific implementation which is tuned to your actual problem. This is good practise in any programming language. But the rules of this benchmark page explicitly prohibit that, so languages, which don't have hash tables in their "standard" library have a strong advantage, which isn't a good represe…
Earlier quoted context omitted.
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…
> The GO implementation has to use the platform allocator. So does the Java implementation, and still it fares much (3x) better than Go.
Even though Rust apparently "won" here(does anybody really win in such comparisons?) I don't care that much about it, because I don't consider this the main appeal of the language. It's the compiler error messages, memory safety and the lack of a Garbage Collector that speak to me more than raw performance.
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…
> Rust has it's own regexp engine, that lacks a few of the bells and whistles of PCRE, but is much faster than it.
The only true part of this is that Rust's regex engine lacks many features found in PCRE. Mostly, these features revolve around things that are either impossible or not-known/difficult to add to a linear time implementation in an efficient way. The most popular features among these are backreferences and various types of lookaround.
However, it is completely unsubstantiated to say that Rust's regex engine is faster than PCRE. At best, you can say that they are competitive with each other, where one regex engine will do better than the other on various types of workloads. Many such cases are not at all related to the feature sets of regex engines, and probably more related to missed optimization opportunities. (Anyone who has implemented a regex engine knows that the size of the set of missed optimization opportunities is unbounded.)
There are of course some of those cases where it comes down to pathological differences. For example, since PCRE uses a backtracking engine even when it isn't necessary (they do have a so-called "DFA" matcher, but it must be invoked explicitly), that means it is susceptible to exponential behavior when Rust's regex engine isn't. But Rust's regex engine has pathological behavior too. The only difference is that Rust's pathological behavior takes the form of large constants, where as PCREs takes the form of exponential growth in the size of the text being searched.
> (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.
If you're talking about PCRE vs Rust's regex, then I see no reason to claim that one does more or less copying than the other. I suspect both do exactly as little as possible. Certainly, neither of them will copy the search text.
> GO just uses PCRE. (Which is weird, isn't RE2 a google project?)
No. Go has its own regexp engine: https://golang.org/pkg/regexp/
The benchmark showcased in the OP for Go uses PCRE, and that's presumably because Go's PCRE variant is faster than Go's native regex engine. See https://benchmarksgame-team.pages.debian.net/benchmarksgame/... and compare `Go #2` (PCRE) with `Go` (Go implemented regex engine).
Go's regex engine in the standard library is written in pure Go, and was written by the same person that wrote RE2. (I wrote Rust's regex engine, but it was heavily inspired by RE2.) Go's regex engine does not have all the same optimizations as RE2, and in particular, it suffers from some very high constant factors in many more cases than what RE2 and Rust's regex engine. While Go's regex engine doesn't exhibit pathological behavior in the form of exponential runtime in the size of the search text, it also can be handily beaten by PCRE in a number of non-pathological cases.
Nothing in these results should really surprise anyone. Go is a good tool for writing networking services, but it is not (and does not intend to be) a systems language. For another perspective, look at Go versus Python: https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
to be fair, it was explicitly designed to be a systems language, and its specification says "Go is a general-purpose language designed with systems programming in mind." This should be removed, and I would say that it gave up on its design goal of being a systems language.