Mailing list for all users of the OCaml language and system.
 help / color / mirror / Atom feed
From: Michael Vanier <mvanier@cs.caltech.edu>
To: brian.hurt@qlogic.com
Cc: xavier.leroy@inria.fr, onlyclimb@163.com, caml-list@inria.fr
Subject: Re: [Caml-list] speed
Date: Sat, 4 Jan 2003 17:48:24 -0800	[thread overview]
Message-ID: <200301050148.h051mOl26189@orchestra.cs.caltech.edu> (raw)
In-Reply-To: <Pine.LNX.4.33.0301041808020.2036-100000@eagle.ancor.com> (message from Brian Hurt on Sat, 4 Jan 2003 19:13:11 -0600 (CST))


> 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


  reply	other threads:[~2003-01-05 20:17 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-01-03 16:00 onlyclimb
2003-01-03 11:38 ` [Caml-list] speed Clemens Hintze
2003-01-03 11:47 ` [Caml-list] speed Noel Welsh
2003-01-02 16:45   ` Chet Murthy
2003-01-03 13:32 ` Xavier Leroy
2003-01-02 17:52   ` Chet Murthy
2003-01-03 14:53     ` Sven Luther
2003-01-03 15:28       ` Erol Akarsu
2003-01-02 17:53   ` Coyote Gulch test in Caml (was Re: [Caml-list] speed ) Chet Murthy
2003-01-03 15:10     ` Shawn Wagner
2003-01-03 15:56       ` Oleg
2003-01-04 18:31       ` Xavier Leroy
2003-01-18 22:49         ` Oleg
2003-01-18 23:50           ` Shawn Wagner
2003-01-20 21:23             ` David Chase
2003-01-20 21:39               ` Nickolay Semyonov-Kolchin
2003-01-21  0:54                 ` Brian Hurt
2003-01-21 13:09                 ` David Chase
2003-01-21 13:15                   ` Daniel Andor
2003-01-21 20:26                   ` Nickolay Semyonov-Kolchin
2003-01-19 10:33           ` Siegfried Gonzi
2003-01-19 10:34           ` Siegfried Gonzi
2003-01-21  9:56           ` [Caml-list] Re: Coyote Gulch test in Caml Xavier Leroy
2003-01-21 15:57             ` Brian Hurt
2003-01-27 16:58             ` Daniel Andor
2003-01-28  8:27               ` Christian Lindig
2003-01-05  1:13   ` [Caml-list] speed Brian Hurt
2003-01-05  1:48     ` Michael Vanier [this message]
2003-01-07 16:03 isaac gouy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200301050148.h051mOl26189@orchestra.cs.caltech.edu \
    --to=mvanier@cs.caltech.edu \
    --cc=brian.hurt@qlogic.com \
    --cc=caml-list@inria.fr \
    --cc=onlyclimb@163.com \
    --cc=xavier.leroy@inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox