5 ms·

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 fa

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-trees The benchmark needs to build a massive binary tree. The Rust implementation allocates it's tree in a TypedArena, which is basically a bump allocator for objects that are all dropped simultaneously. It requires very minimal metadata or work per allocation. (Not zero, because it does properly call all destructors.) The GO implementation has to use the platform allocator. The results shouldn't be very surprising... 3. Manderbrot Not sure, but I think the Rust version is designed for autovectorization while the Go one is scalar. After that the Go runtimes are within 2.5x of the Rust ones.

Jweb_Guru 8y ago
> Not zero, because it does properly call all destructors. I believe that there is an optimization that allows this to be completely avoided for types with only trivial or no destructors.
pron 8y ago
> The GO implementation has to use the platform allocator. So does the Java implementation, and still it fares much (3x) better than Go.
- deleted 8y ago
  [deleted]
- pcwalton 8y ago
  Because the Java GC has better throughput than the Go GC. The Go GC makes enormous throughput sacrifices by prioritizing latency above all else.
burntsushi 8y ago
With respect to your comments about regex, could you please share with me where you got your information? I would love to know so that I can go bug whoever it is to correct it. > 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/ 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/performance/regexredux.html 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.
flavio81 8y ago
binary-trees source secs Go 28.80 Lisp 8.49 You know what I would choose if I needed a garbage collected language. Btw,the lisp version uses no fancy tree allocator, just plain standard lisp lists.
- Thaxll 8y ago
  And yet Go is much faster than Lisp, you shouldn't look at that specific Benchmark.
  - igouy 8y ago
    You should look where the time goes in your app.
- PopsiclePete 8y ago
  Before you do that, you might want to research GC 'throughput' vs GC 'latency'. Go chose to optimize for latency, not throughput. And for very good reasons.
igouy 8y ago
>> GO just uses PCRE Currently, there are 4 Go regex-redux programs and 2 use PCRE. https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/regexredux.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... >> The GO implementation has to use the platform allocator … because there doesn't seem to be a Go third-party or stdlib arena allocator.

Jweb_Guru 8y ago

> Not zero, because it does properly call all destructors. I believe that there is an optimization that allows this to be completely avoided for types with only trivial or no destructors.

pron 8y ago

> The GO implementation has to use the platform allocator. So does the Java implementation, and still it fares much (3x) better than Go.

deleted 8y ago
[deleted]
pcwalton 8y ago
Because the Java GC has better throughput than the Go GC. The Go GC makes enormous throughput sacrifices by prioritizing latency above all else.

burntsushi 8y ago

With respect to your comments about regex, could you please share with me where you got your information? I would love to know so that I can go bug whoever it is to correct it. > 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/ 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/performance/regexredux.html 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.

flavio81 8y ago

binary-trees source secs Go 28.80 Lisp 8.49 You know what I would choose if I needed a garbage collected language. Btw,the lisp version uses no fancy tree allocator, just plain standard lisp lists.

Thaxll 8y ago
And yet Go is much faster than Lisp, you shouldn't look at that specific Benchmark.
- igouy 8y ago
  You should look where the time goes in your app.
PopsiclePete 8y ago
Before you do that, you might want to research GC 'throughput' vs GC 'latency'. Go chose to optimize for latency, not throughput. And for very good reasons.

igouy 8y ago

>> GO just uses PCRE Currently, there are 4 Go regex-redux programs and 2 use PCRE. https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/regexredux.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... >> The GO implementation has to use the platform allocator … because there doesn't seem to be a Go third-party or stdlib arena allocator.