Earlier quoted context omitted.
Node uses V8, which does JIT compilation, while CPython is a straight bytecode interpreter. A better point of comparison would be PyPy
Are there any CPython vs PyPy benchmarks?
Rust is now overall faster than C in benchmarks
391–400 of 445 posts
Re: Rust is now overall faster than C in benchmarks
#392Earlier quoted context omitted.
> Those things are never going to be inlined across library boundaries. What prevents this? I trust you on on this, but where is the remaining work? Language semantics, compiler, third choice?
It's prevented by good sense. The functions are likely multiple KB in size. Inlining them would seriously bloat the binary and would be unlikely to help due to how much work most regex engines do on each search. The remaining work _on this particular benchmark_ is the regex algorithm itself. I'm on mobile so I can't do a deep dive, but I haven't yet figured out how to easily improve on this particular case. It has to…
> … doesn't really do much to alleviate this … It's easy to criticize.
Indeed.
Especially easy if it's just fault-finding without any suggestion as to what might be done to "alleviate this" :-)
Re: Rust is now overall faster than C in benchmarks
#393Because Rust does alloca for all locals, and this if course faster. Everyone else avoids it for security reasons. Just search the Rust bugtracker for stack overflows.
You are confusing the llvm instruction “alloca” with the C feature “alloca.” llvm will use its alloca instruction for C and C++ local variables the same way as Rust does. You are correct that the C feature is often banned. Rust doesn’t even support it at all.
No, you are still confusing it.
llvm alloca reserves a stack allocation slot. The number of slots is unchecked that's why rust has so many stack overflows. Esp with varargs. Check your issue tracker or source code.
Re: Rust is now overall faster than C in benchmarks
#394There are 2 charts on the page, both using the same title: "How many times slower?" I don't get those. What's the difference?
The different charts show different programming language implementations.
Re: Rust is now overall faster than C in benchmarks
#395Earlier quoted context omitted.
Don't know why you're downvoted, this is a great comment. By the way, YARV has been "ruby" since 2007; these benchmarks were run with ruby 3.0.0preview1. The name has probably just never been changed.
Ah, thanks. It's been a while since I've used Ruby seriously. Still not quite sure why "Matz's ruby" is separate on the Benchmark Game rankings, while all other languages are grouped based on the best implementation of the language. Anyhow, that's pretty much irrelevant to my overall point. Thanks for the kind words, not sure why it's getting downvoted other than that I called someone out on their lazy dismissal. But…
> Still not quite sure why "Matz's ruby" is separate…
As a marker of where Ruby used to be.
Re: Rust is now overall faster than C in benchmarks
#396Earlier quoted context omitted.
It's prevented by good sense. The functions are likely multiple KB in size. Inlining them would seriously bloat the binary and would be unlikely to help due to how much work most regex engines do on each search. The remaining work _on this particular benchmark_ is the regex algorithm itself. I'm on mobile so I can't do a deep dive, but I haven't yet figured out how to easily improve on this particular case. It has to…
> … doesn't really do much to alleviate this … It's easy to criticize. Indeed. Especially easy if it's just fault-finding without any suggestion as to what might be done to "alleviate this" :-)
You can do better than that, but I suppose I don't expect more than an insubstantial pithy quip from you.
Add analysis to each benchmark. Require submissions to come with analysis. Or more minimally, make the existing disclaimers on the web site more discoverable through one of any number of means, up to taste.
Re: Rust is now overall faster than C in benchmarks
#397Earlier quoted context omitted.
That kind of tit-for-tat in benchmarks seems like it's counter to the goal of benchmarks: what kind of performance could I expect to see using technology $FOO? Crucially, that question depends on how someone will realistically implement $FOO. I like PyPy as an example: on the surface, implementing a Python runtime in Python and expecting performance gains seems crazy. PyPy manages to outperform CPython because althou…
> That kind of tit-for-tat in benchmarks seems like it's counter to the goal of benchmarks Yep. There are good reasons why this set of benchmarks is called The Computer Language Benchmarks Game .
Re: Rust is now overall faster than C in benchmarks
#398Earlier quoted context omitted.
You are confusing the llvm instruction “alloca” with the C feature “alloca.” llvm will use its alloca instruction for C and C++ local variables the same way as Rust does. You are correct that the C feature is often banned. Rust doesn’t even support it at all.
No, you are still confusing it. llvm alloca reserves a stack allocation slot. The number of slots is unchecked that's why rust has so many stack overflows. Esp with varargs. Check your issue tracker or source code.
Rust doesn't support varargs. It also supports stack probes on x86, guard pages, all that stuff. It is runtime checked because it is not possible to compile-time check.
Re: Rust is now overall faster than C in benchmarks
#399Earlier quoted context omitted.
Are there any CPython vs PyPy benchmarks?
https://pybenchmarks.org/
Okay according to their results: https://pybenchmarks.org/u64q/chartbox.php?s=eNptUtttAzEMW0l... PyPy seems to be twice as fast as CPython in these benchmarks. While this is indeed a noticeable achievement, it is still much slower than Node.
Re: Rust is now overall faster than C in benchmarks
#400Earlier quoted context omitted.
> … doesn't really do much to alleviate this … It's easy to criticize. Indeed. Especially easy if it's just fault-finding without any suggestion as to what might be done to "alleviate this" :-)
You can do better than that, but I suppose I don't expect more than an insubstantial pithy quip from you. Add analysis to each benchmark. Require submissions to come with analysis. Or more minimally, make the existing disclaimers on the web site more discoverable through one of any number of means, up to taste.
> Add analysis to each benchmark.
Perhaps you'd like to take on that task?
> Require submissions to come with analysis.
Which raises the barrier for program contributors and presumably would require me to judge whether their analysis was acceptable? Me? Really? ;-)
> disclaimers on the web site more discoverable
The problem is that no one wants to "discover" disclaimers.
We want to see something that supports whatever it is we already believe — and we're very good at ignoring anything else.