That shootout is laughable, they couldn't even compile the Haskell version.
Name:
Anonymous2010-07-03 10:23
>>1
Ah yeah, pretty sure V8 JITs a parser for the regex. Makes sense. C can only really be made faster if you actually hand-roll a parser for your regex (or generate the code with an external script, or integrate a runtime compiler such as LLVM).
Name:
Anonymous2010-07-03 10:41
I want to run the benchmarks.
Where can i download a windows compiler for this V8?
>>5
I'm talking specifically about the shootout, not any other benchmark. And if any language did add in optimizations solely to improve performance on the shootout, then the implementer should be taken round back and shot.
Name:
Anonymous2010-07-03 13:49
>>9
Do you know of any other high-profile benchmark?
Name:
Anonymous2010-07-03 14:04
>>8
There is no compiler. You have to build it yourself. With VisualC++.
Multi language benchmarks are extremely stupid for obvious reasons; namely it measures implementation efficiency, not language efficiency (which is extremely hard to quantify). You also have to write a different implementation for each language- something that is rather hard to do objectively (If Java is faster than C, just write a JVM in C and run the Java program through your C execution engine.) Actually, any language which allows assembly statements will necessarily be "faster" than any other language, because we can just tell it to do the chain of instructions the other language was doing- then hand optimize.
Name:
Anonymous2010-07-03 14:23
>>12
>namely it measures implementation efficiency
Whats so stupid about that? You don't use some "Abstract Language" you use GCC
>just write a JVM in C
It took many years to be competitive with C++ with many thousands of person-hours poured over optimizing and extending the JVM. It isn't as trivial as it seems.
>, any language which allows assembly statements will necessarily be "faster"
The shooout forbids assembly, but why a language should be "not faster" just because some scripter thinks its "Unfair, TOO FAST!" or "You CAN'T copy my code"?
>>13 Whats so stupid about that? You don't use some "Abstract Language" you use GCC
Then it isn't a multi-language benchmark. It's a multi-implementation benchmark; completely different. A true language benchmark would, in some ideal world, analyze all properties of the formal language specification and compute some ordinal speed properties for it. It took many years to be competitive with C++ with many thousands of person-hours poured over optimizing and extending the JVM. It isn't as trivial as it seems.
No, it's not. The very idea that an interpreted/JIT'd language can be faster than the language hosting it is paradoxical. Regardless of how trivial it is to implement Java in C, you can never say that Java is faster than C. The shooout forbids assembly, but why a language should be "not faster" just because some scripter thinks its "Unfair, TOO FAST!" or "You CAN'T copy my code"?
You are reinforcing what I said; is English not your native language?
Then it isn't a multi-language benchmark. It's a multi-implementation benchmark; completely different.
And that's exactly what it claims to be -
"How can we benchmark a programming language?
We can't - we benchmark programming language implementations.
How can we benchmark language implementations?
We can't - we measure particular programs."
>>16 No, it's not. The very idea that an interpreted/JIT'd language can be faster than the language hosting it is paradoxical.
This is some smelly bait.
>>18
The criticisms are still valid. There are countless ways to attack the methodology they use- but it is quite easy to see the underlying idea is completely flawed, this is what I was trying to show.
Name:
Anonymous2010-07-03 15:01
>>20
The underlying idea that the performance of programs can be measured and compared?
A true language benchmark would, in some ideal world, analyze all properties of the formal language specification and compute some ordinal speed properties for it.
Which would yield the rather uninteresting result that for any given program specification, the optimal compiled binary is the same no matter what language you represent the problem in.
Name:
Anonymous2010-07-03 15:12
DO you seriously think you can add a 100MB JVM inside a benchmark file?
Name:
Anonymous2010-07-03 15:19
>>22
Not only can the performance of programs be measured and compared across language implementations - but that (rather than - a true language benchmark in some ideal world) has value.
>you can never say that Java is faster than C.
Seems like a deep seated bias against Java here.
Name:
Anonymous2010-07-03 15:59
Every programming language is eventually executed on the CPU, but they differ in the amount of "behind-the-scenes" code their implementations provide. No-one wanting to develop a performance-critical application would look at a performance comparison and say "oh, I know, I'll use JavaScript!", but such comparison lets you see roughly how much performance you're trading for ease of use.
There are countless ways to learn from the measurements and programs
Indeed, and no-one is arguing that all benchmarks are useless. Benchmarking is extremely useful, but taking your measurements from some generic online benchmark rather than making appropriate measurements for the specific problem at hand is stupid, and the only people who actually give any credence to the shootout are language fanboys trying to get one over on each other.
Name:
Anonymous2010-07-03 16:20
>>33
I concur. However I never saw a benchmark where Java beat C or C++ (which in some cases is faster than C) in performance.
I'm curious if, in that case, Java could beat a C program compiled with guided optimization.
the only people who actually give any credence to the shootout
There are countless ways to learn from the measurements and programs shown on that website - but it's far less effort to dismiss them.