https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

I don't find the code complexity obviously worse for the Rust version, yet it runs a full order of magnitude faster in this benchmark.

https://benchmarksgame-team.pages.debian.net/benchmarksgame/... https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Does Go just suck with it's regex performance? Would this be easy to fix by just pulling in a C regex library?

The exception is the regex benchmark, which has little to do with the languages and everything to do with the regex library used by the language. If the dynamic scripting languages were required to use regex engines implemented in pure Python/Perl/PHP/JS, their performance in the game would collapse on the regex benchmark.

Go's standard library provides a regex library that provides certain O() guarantees, but has a significantly larger constant factor than PCRE-like regexs. Benchmarks tend to hit cases where PRCE is faster, but it's not hard to construct a benchmark where the Go standard library will be arbitrarily faster than some of the other languages, because that's a characteristic of big-O differences.

(In general, one should always be careful of claims that some block of code is X times faster or slower than another; the comparison only has meaning if they're in the same big-O class, or at least de facto in the same big-O class, e.g., O(n logn) and O(n logn logn) are basically the same class in practice. It's also important to make sure the problem being benchmarked is large enough to get past the constant factors that may be involved. I'm not saying those aren't important, but if you want an "X-times faster" sort of comparison you need to shrink the constant factors into irrelevance first. I've seen cases where people blithely claim some bit of code is 100,000 faster than some other, but really, it's a big-O difference.)

While that is true, Rust's regex library makes the same guarantees.

I'd also like to push back on the idea that perf comparisons are meaningless if one implementation has degenerate cases. Pathological behavior in a backtracking engine happens very rarely, and backtrackers typically come with features that are not supplied by O(n) engines. Someone in the PCRE camp might complain that the benchmark isn't fair because go's engine can't handle backreferences. The different approaches come with different features (backreferences vs garenteed O(n) running time), but they do have a place where their problem domains overlap. It is not useless to examine how they perform in that area.

That's not what I said. I said, you can't use "X times faster" comparisons if the O() of the two algorithms in question are not more-or-less the same. That does not prevent you from still characterizing performance differences. You just can't do it via "X times faster" statements, because those are only well-defined for things separated by linear factors, and practically defined for things separated by practically linear factors. f(x) = x^2 is not "2 times bigger" than g(x) = x, or any number of "times bigger", whereas h(x) = 3x + 5 can be reasonably said to be "3 times bigger" than i(x) = x + 50, even though it is not the case that h(x) = 3i(x).

Perhaps that's "a truth" about regex :-)

>> If the dynamic scripting languages were required to…

Then we wouldn't be using them as scripting languages!

I think it can only tell you about the performance cieling, and even then it can't tell you that for languages like Go where fairly obvious optimizations (like arenas) are prohibited while all manner of clever tricks are permitted for other languages.

Your remarks on performance comparisons were really insightful.

No, not prohibited.

Which widely-used third-party Go library do you suggest people use to implement Go binary-trees programs?

Yes, prohibited

> Which widely-used third-party Go library do you suggest people use to implement Go binary-trees programs?

What does this have to do with my post?

You falsely claim that Go arenas are prohibited.

Show that there is a widely-used third-party Go library that provides arenas, which could be used to implement Go binary-trees programs, to support your claim.

No, it's because PCRE is faster than Go's standard library regex engine on this particular benchmark. There is another entry for Go (called just `Go` I believe) that uses Go's "regexp" package.

The regexredux benchmark itself does not require any "fancy" features. It can be satisfied by pure regular expressions.

Today, it is faster: https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

As far as I can tell, the source code of the benchmark didn't change at all. The only difference between them is that former uses PHP 7.1 and the latter uses PHP 7.2.

So... I would start at the differences between PHP 7.1 and PHP 7.2. I would also first attempt to reproduce the result locally, to rule out changes in environment in the benchmark game (speculatively speaking).

I actually use it in parallel with C/C++ legacy code, and I just trying to avoid C/C++ as much as I can, because I newer saw segfault in safe Rust code so far.

  more benchmarks

  source    generics
  Rust      100%
  Go        0%

  source    if err!=nil return { nil, err };
  Rust      0%
  Go        100%

  source    undeserved hype
  Rust      100%
  Go        100%

Haskell: 100%

All Other Languages: 0%

source: flawed generics implementations

Haskell: 0%

All Other Languages: 100%

Coq: 142%

Haskell: 91%

All Other Languages: 0%

Funnily, in some scenarios, I find Rust to be less of a brain load than Go. In others, Rust is way way worse. As I mentioned in another post, we use Go to get shit done. I hope Rust can take that mantel some day.