Browse thread
[Caml-list] speed
-
onlyclimb
- Clemens Hintze
- Noel Welsh
-
Xavier Leroy
- Chet Murthy
- Chet Murthy
-
Brian Hurt
- Michael Vanier
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| 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. Mike ------------------- 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