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 / headius.com> wrote:
> On 7/28/06, Peter Hickman <peter / semantico.com> 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
>
>