English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

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 <brian.hurt@qlogic.com>
> 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 caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners