3 ms·
Sorry, I wasn’t clear. On shootout they have multiple implementation of each benchmark in the same language. The fastest implementations are always fast languag
by Skunkleton 7y ago
Sorry, I wasn’t clear. On shootout they have multiple implementation of each benchmark in the same language. The fastest implementations are always fast languages, but there are lots of implementations in fast languages that are bested by better implementations in slow languages[1]. The point I was trying to make is that picking a fast language isn’t enough to write truly fast programs.
1. https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/mandelbrot.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
- acqq 7y agoBut even that doesn't follow from the link you give: the slowest C++ entry is taking 54 seconds there. But I don't see any, for example, Python code which is faster. There is node.js code which is fast, but we know that node.js depends on really, really, good JIT, which doesn't make it "slow language" in my view. The node.js implementation also uses all CPU cores, so we should at least compare among the implementations which also use all CPU cores. So in this case it's less "an algorithm" in the narrow sense and more "is it written to use all CPU cores effectively" and is it using the JIT to run the code compiled to the native. Other languages with good scores are also all that can do a good JIT and use all the CPU cores, which yes, confirms that good JITs are really good. Which still also doesn't mean that I don't know (or have happened to know) enough incompetent programmers who would, indeed, make even worse performing C++ than any entry that we see in the Benchmarks game. I could write a whole article about all the things they would or could do wrong. I only wanted to see the examples in "the Benchmarks game" specifically.
- Skunkleton 7y agoIts really hard to be slower than python, unless you are using ruby. Considering that the parent was asking about node, that is what I was looking at. While V8's performance is hugely impressive, it is still significantly slower than other languages. I'm not sure what you are trying to say though? My point was that you have to develop expertise before you can create high performance programs. If you are considering dropping node because you need more performance, be careful.
- acqq 7y ago> If you are considering dropping node because you need more performance, be careful. That's what is surely not surprising to me, as I've measured the performance of V8 even before node.js existed, and already knew of enough examples that resulted in the code executed with the speed comparable to C. I don't consider any modern JavaScript JIT implementation to be "slow", neither V8, nor the one in Safari or in Firefox. Moreover, all of them have more than one level of achieving the speed -- they adapt to the needs of the code executed, they are really the works of art, and not an accidental development.