Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
[Caml-list] speed
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2003-01-05 (20:17)
From: Michael Vanier <mvanier@c...>
Subject: Re: [Caml-list] speed

> Date: Sat, 4 Jan 2003 19:13:11 -0600 (CST)
> From: Brian Hurt <>
> Startup costs dominate in Bagley's shootout.  Look at matrix 
> multiplication- the fastest tests (C, C++, and Ocaml) are running in 
> 70-110 milliseconds.  Most timers are accurate only to ~10 milliseconds, 
> which means the time for the C program to run could be anything from 
> 600 millisecond to 800 milliseconds, for an error of +/-14.3%.
> Java has huge start up costs.  First off, you have the JIT.  Then, there 
> is a time delay before hotspot kicks in an actually starts optimizing the 
> code to any signifigant extent.  Notice that the pro-Java benchmarks run 
> the code to be benchmarked a few thousands or tens of thousands of times 
> before starting the timer, so that the hotspot optimizer has already been 
> over the code a couple of times.  Or at least once, to bypass JIT time.   
> Is this a legitimate tactic?  Lies, damned lies, and cross-language 
> benchmarks.

I think it is a legitimate tactic.  If your code can run in 100
milliseconds, I could care less about performance.  I want high performance
for programs that are going to run for hours, days, or weeks.  For these,
startup costs should hardly matter.

> Note that I, personally, think that performance should be the last reason 
> used to pick a language.  Things like correctness of the code, available 
> libraries and environments, and existing talents and skills of the 
> workforce, should instead take precedence.
> Brian

True, but it depends a lot on the application.  If you're doing heavy
graphics or big simulations, you simply can't ignore performance.

To unsubscribe, mail Archives:
Bug reports: FAQ:
Beginner's list: