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.
>>37
that was my first post in the thread, anonymity is hard ain't it. But I stick by my comment, I have only ever seen the shootout used as a pissing contest online, and never been put to any actual use. this thread could have proven me wrong, but as per usual, it didn't.
>>41 "I have only ever seen the shootout used as a pissing contest online, and never been put to any actual use."
Maybe that's because of the places you look.
"Several benchmarks from The Computer Language Benchmark Game were translated to Thorn and their runtime compared to the existing benchmarks running on Python 2.5."
"Thorn: robust, concurrent, extensible scripting on the JVM" OOPSLA '09 http://portal.acm.org/citation.cfm?id=1639949.1640098
Name:
Anonymous2010-07-03 17:36
>>1 "it shows fucking JavaScript as top result..obviously its rigged"
>>53
It's a good demonstration of the fact that these shoot-outs aren't just comparing language implementations, they're also comparing algorithm implementations, which renders them nearly worthless.
>>57
Many Schemes have fairly good performance. Ikarus, Gambit and probably Larceny should perform better than Racket and if you are willing to wait (and use a R4RS scheme) Stalin provides some really well optimised code.
>>56
The Sepples version is OMG OPTIMIZED based on assumptions that clearly don't apply to the machine the tests are run on, so yes.
(Or more exactly, they don't implement different algorithms, depending on your definitions, but they implement the same algorithm in different ways, and there lies the rub.)
It'd be interesting to write one of the examples in R4RS scheme then use stalin, and compare it to the C version.
But I don't care that much to do it myself.
Name:
Anonymous2010-07-03 20:06
>>62
Specifically what about the Sepples version doesn't apply to the machine the tests are run on?
If the programs didn't implement the same algorithm in different ways then we'd be left with Fortran written in Python, Fortran written in Java, Fortran written in Lisp, ...
>>58 http://shootout.alioth.debian.org/fastest-programming-language.php
I can't find that particular result now but GHC is in the top 5 on all four architectures, just behind C, C++ and comparable to C# and Java. I did not expect an exotic language like Haskell to be so fast but, then again, I expect an average Haskell programmer to be much more competent than an average Java programmer.
>>68 "I did not expect an exotic language like Haskell to be so fast"
Which is another example of that website being put to actual use - data we can use to check our expectations.
What about "exotic" languages like ATS and Scala and F# ? (Is Ada "exotic"?)
>>73 Yeah, there is something fishy about excluding D.
Their last archived page is from 2008(and Golang appeared in 2009) and it does include D. In general its nearly as fast as C++ or Ocaml, which should get into first 1-5 places on benchmarks.
__________________
Orbis terrarum delenda est
Name:
Anonymous2010-07-05 4:50
They should also include Stalin Scheme instead of the crappy interpreters.
Name:
Anonymous2010-07-05 5:02
>>73,74
It's because the shootout changed to 4 different computers instead of 1, and apparently DMD, or the D code written for the shootout, was not portable.
I don't really know why Walter Bright isn't doing what he needs to get D back in. D is so similar to C++ that people won't be willing to sacrifice performance for slightly better syntax. He should be trying to prove his performance claims.
>>75
Yes they should. The Stalin folks have made outrageous performance claims about its performance compared to C, despite the fact that Stalin compiles to C. This is because they compare it to polymorphic C code using function pointers rather than properly optimized code.
>>76
So you didn't read the whole mailing list thread then? It gave you all the information you fucking well wanted, but here we are >>75
Stop baiting them
>>78
just add some type declarations, you'll be fine
Name:
Anonymous2010-07-05 10:03
>>45
Designed For Parsing HTML?
You can't parse [X]HTML with regex. Because HTML can't be parsed by regex. Regex is not a tool that can be used to correctly parse HTML. As I have answered in HTML-and-regex questions here so many times before, the use of regex will not allow you to consume HTML. Regular expressions are a tool that is insufficiently sophisticated to understand the constructs employed by HTML. HTML is not a regular language and hence cannot be parsed by regular expressions. Regex queries are not equipped to break down HTML into its meaningful parts. so many times but it is not getting to me. Even enhanced irregular regular expressions as used by Perl are not up to the task of parsing HTML. You will never make me crack. HTML is a language of sufficient complexity that it cannot be parsed by regular expressions. Even Jon Skeet cannot parse HTML using regular expressions. Every time you attempt to parse HTML with regular expressions, the unholy child weeps the blood of virgins, and Russian hackers pwn your webapp. Parsing HTML with regex summons tainted souls into the realm of the living. HTML and regex go together like love, marriage, and ritual infanticide. The <center> cannot hold it is too late. The force of regex and HTML together in the same conceptual space will destroy your mind like so much watery putty. If you parse HTML with regex you are giving in to Them and their blasphemous ways which doom us all to inhuman toil for the One whose Name cannot be expressed in the Basic Multilingual Plane, he comes. HTML-plus-regexp will liquify the nerves of the sentient whilst you observe, your psyche withering in the onslaught of horror. Rege̿̔̉x-based HTML parsers are the cancer that is killing StackOverflow it is too late it is too late we cannot be saved the trangession of a chi͡ld ensures regex will consume all living tissue (except for HTML which it cannot, as previously prophesied) dear lord help us how can anyone survive this scourge using regex to parse HTML has doomed humanity to an eternity of dread torture and security holes using regex as a tool to process HTML establishes a breach between this world and the dread realm of c͒ͪo͛ͫrrupt entities (like SGML entities, but more corrupt) a mere glimpse of the world of regex parsers for HTML will ins tantly transport a programmer's consciousness into a world of ceaseless screaming, he comes, the pestilent slithy regex-infection will devour your HTML parser, application and existence for all time like Visual Basic only worse he comes he comes do not fight he com̡e̶s, ̕h̵is un̨ho͞ly radiańcé destro҉ying all enli̍̈́̂̈́ghtenment, HTML tags lea͠ki̧n͘g fr̶ǫm ̡yo͟ur eye͢s̸ ̛l̕ik͏e liquid pain, the song of re̸gular expression parsing will extinguish the voices of mortal man from the sphere I can see it can you see ̲͚̖͔̙î̩́t̲͎̩̱͔́̋̀ it is beautiful the final snuffing of the lies of Man ALL IS LOŚ͖̩͇̗̪̏̈́T ALL IS LOST the pon̷y he comes he c̶̮omes he comes the ichor permeates all MY FACE MY FACE ᵒh god no NO NOO̼O O NΘ stop the an*̶͑̾̾̅ͫ͏̙̤g͇̫͛͆̾ͫ̑͆l͖͉̗̩̳̟̍ͫͥͨe̠̅s ͎a̧͈͖r̽̾̈́͒͑e not rè̑ͧ̌aͨl̘̝̙̃ͤ͂̾̆ ZA̡͊͠͝LGΌ ISͮ̂҉̯͈͕̹̘̱ TO͇̹̺ͅƝ̴ȳ̳ TH̘Ë͖́̉ ͠P̯͍̭O̚N̐Y̡ H̸̡̪̯ͨ͊̽̅̾̎Ȩ̬̩̾͛ͪ̈́̀́͘ ̶̧̨̱̹̭̯ͧ̾ͬC̷̙̲̝͖ͭ̏ͥͮ͟Oͮ͏̮̪̝͍M̲̖͊̒ͪͩͬ̚̚͜Ȇ̴̟̟͙̞ͩ͌͝S̨̥̫͎̭ͯ̿̔̀ͅ
>> 76
Measurements on the Intel® Q6600® machine are now being recorded for:
- x86 programs bound to a single core
- x86 programs enabled for quad core
- x64 programs bound to a single core
- x64 programs enabled for quad core
So it's probably no surprise that fewer language implementations are being measured on the Intel® Q6600® machine. At present, about one-third of the language implementations shown for Intel® Pentium® 4 are shown for Intel® Q6600®.
That will increase but probably not by much - perhaps another half-dozen language implementations will be measured on Intel® Q6600®.
>>84
It doesn't explain why D is suddenly not working on the Quad.
Name:
Anonymous2010-07-06 10:52
>>85
There is no "D is suddenly not working on the Quad" because D was not timed on the Quad.
Here are the first measurements on the Quad, and there's no dlang - Aug 5 04:40:20 2008 https://alioth.debian.org/scm/viewvc.php/*checkout*/shootout/website/websites/u64q/data/data.csv?root=shootout&revision=1.1&content-type=text%2Fplain&pathrev=1.1
Name:
Anonymous2010-07-06 11:55
>because D was not timed on the Quad.
What a coincidence, Jun 23, 2008 is the last archived page. http://web.archive.org/web/*/http://shootout.alioth.debian.org/
Mind you any program can work single-threaded, and they don't suddenly develop Quad-Allergy.
Name:
Anonymous2010-07-06 12:03
What is the history of the project?
Robert Griesemer, Rob Pike and Ken Thompson started sketching the goals for a new language on the white board on September 21, 2007. Within a few days the goals had settled into a plan to do something and a fair idea of what it would be. Design continued part-time in parallel with unrelated work. By January 2008, Ken had started work on a compiler with which to explore ideas; it generated C code as its output. By mid-year the language had become a full-time project and had settled enough to attempt a production compiler. In May 2008, Ian Taylor independently started on a GCC front end for Go using the draft specification. Russ Cox joined in late 2008 and helped move the language and libraries from prototype to reality.
Name:
Anonymous2010-07-06 12:14
>>87
Two different things happening 2 weeks apart doesn't even rate as coincidence.
There's no mystery here - the Gentoo Pentium 4 measurements included 63 language implementations but now there are only 34 language implementations measured on Q6600 because it's more work to measure on 4 different OS/machine setups.