Re: For performance, write it in C - Part 2, comparing C, Ruby and Java

Sorry to jump into discussion, but I am wondering once again (I cannot
remember the real number) what is the purpose of this "benchmark"?

Showing that your special algorithm is better implemented/run in a
native executable? I could have told you so from the beginning. Have
you tried also with compiled Pascal? (or I don't know what else).

Or is it the fact that after working in Java since '92 (???) you have
find out about the JVM startup penalty and that any decent benchmark
would not account for that (only in case you are compairing JVM
startup times)? Should I also tell you that the JVM can be configured?
Or that you must run the code a couple of times before, because the
JVM will optimize the bytecode?

However, I must agree, I may have sound rude. Way too rude, for this
completely unuseful thread. Sorry.

/alex
--
w( the_mindstorm )p.


On 7/28/06, Charles O Nutter <headius@xxxxxxxxxxx> wrote:
On 7/28/06, Peter Hickman <peter@xxxxxxxxxxxxx> wrote:
>
> Isak Hansen wrote:
> > When people want 'speed' they care about how fast the code runs, not
> > JVM startup time..
> Interesting, so just how to you run a Java program without the JVM
> start-up time?
>
> And if you can't run a Java program without the JVM start-up then your
> point is
> what exactly?


The problem is that you're not controlling for that startup time. If you
want to do a comparison of raw number-crunching performance, you can't
include processing time that's unrelated. A short list of what's wrong with
your benchmark:

- You include Ruby parse, startup, and init time
- You include Java startup and init time
- You include C startup and init time, however insignificant
- You do not post your code, system configuration, Java, Ruby, GCC, and
related library versions, Java and Ruby startup parameters, C compiler
settings, ......
- You expect us to trust that your knowledge of writing efficient code in
Java is without question (although if you've been doing it since 1992, maybe
you're right)
- You do not take into consideration the delay before runtime JIT happens in
the JVM

Every reputable benchmark or scientific study must provide full access to
not only test results but to the tests themselves, along with complete
documentation of methodology and process. To hide the mechanism and the
means behind these tests allows you to impose your own handicaps on each of
the platforms in question to further your point. To allow no rebuttal via
submissions of "better" Java code implies an obvious bias against that
platform, and your lack of knowlege about how that platform works taints
your results severely.

It's certainly possible that Java is slower for this particular algorithm,
even with an optimized version. However your means of benchmarking and
method of communicating results calls the entirety of your email into
question.

--
Contribute to RubySpec! @ www.headius.com/rubyspec
Charles Oliver Nutter @ headius.blogspot.com
Ruby User @ ruby.mn
JRuby Developer @ www.jruby.org
Application Architect @ www.ventera.com



.