I'm not really sure if I understand your question. People have runtime speed demands for their applications and when they start a project they get to choose a language. Runtime speed is one of several pertinent pieces of information that is relevant when choosing which language to use.
Not that this benchmark is actually indicating anything about which language to use in any of those circumstances (Java has a bad startup but pretty good during runtime, and startup time on these orders is generally irrelevant for any nontrivial application), but that isn't to say that language benchmarks in general are irrelevant.
from as little coding experience i have i can say that I have seen blazingly fast V1.0 of applications which doomed to sluggish responses because of poor maintenance. So, i really don't buy the speed thing. I'll always design with a note that "There will be no awesome-coders to maintain this". A well-maintained version of Java app will beat a struggling C app anyday. So, i differ. And, ofcourse if you know what you are doing, these graphs do make sense and its worth an effort to dig out the flipping bits on registers.
"A well-maintained version of Java app will beat a struggling C app anyday."
And a poorly maintained C program will outperform an equally poorly maintained Java program...
The things that make programs dramatically slower is poor algorithmic complexity (and often a poor understanding of the architecture, be it the JVM or the metal). That's not what we're talking about here though, this discussion is pretty explicitly about start-up times. We're talking constant-time issues.
Comments
when will people stop comparing languages based on their runtime speeds?
When computers are infinitely fast.
For some people we're already there, just read this today: http://prog21.dadgum.com/101.html
I'm not really sure if I understand your question. People have runtime speed demands for their applications and when they start a project they get to choose a language. Runtime speed is one of several pertinent pieces of information that is relevant when choosing which language to use.
Not that this benchmark is actually indicating anything about which language to use in any of those circumstances (Java has a bad startup but pretty good during runtime, and startup time on these orders is generally irrelevant for any nontrivial application), but that isn't to say that language benchmarks in general are irrelevant.
"startup time on these orders is generally irrelevant for any nontrivial" [or trivial] "application" ;-)
from as little coding experience i have i can say that I have seen blazingly fast V1.0 of applications which doomed to sluggish responses because of poor maintenance. So, i really don't buy the speed thing. I'll always design with a note that "There will be no awesome-coders to maintain this". A well-maintained version of Java app will beat a struggling C app anyday. So, i differ. And, ofcourse if you know what you are doing, these graphs do make sense and its worth an effort to dig out the flipping bits on registers.
"A well-maintained version of Java app will beat a struggling C app anyday."
And a poorly maintained C program will outperform an equally poorly maintained Java program...
The things that make programs dramatically slower is poor algorithmic complexity (and often a poor understanding of the architecture, be it the JVM or the metal). That's not what we're talking about here though, this discussion is pretty explicitly about start-up times. We're talking constant-time issues.
And luckily the crappy java programmers will never even get a C program of any complexity to start up.