Re: [Caml-list] speed

Re: [Caml-list] speed

[isaac gouy]

>> Java has huge start up costs... 
>> 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. 

You're both right.
Benchmarks give invaluable insight into specific
problems.

If the specific problem involves long-running
processes then that's what we should be benchmarking:
it doesn't matter what happened in the first second.

If the specific problem involves starting a program
hundreds-of-times a day to do a small computation then
that's what we should be benchmarking: it doesn't
matter what the performance was after millions of
iterations.

best wishes, Isaac

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
-------------------
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

[Caml-list] speed

[onlyclimb]

Is it normal that my ocaml program is only 2 times faster than the java 
counterpart ?(using the same method and complied into native. jdk is 1.4.1



-------------------
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

Re: [Caml-list] speed

[Noel Welsh]

--- onlyclimb <onlyclimb@163.com> wrote:
> Is it normal that my ocaml program is only 2 times
> faster than the java 
> counterpart ?(using the same method and complied
> into native. jdk is 1.4.1

It depends entirely on the program.  I wouldn't expect
a huge difference in speed in, say, an HTTP server
where most of the time is spent waiting for the disk. 
In numeric applications I would expect O'Caml to be
significantly faster than Java.

Noel

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
-------------------
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

Re: [Caml-list] speed

[Chet Murthy]

[I work for IBM.  Notwithstanding, I'm really not a Java shill.  But,
well, try whatever you do on the IBM JDKs, or the _Sunsoft_ _Solaris_
JDKs.]

Actually, I think you'll find that for tight integer loops and
floating-point stuff, Java is already as fast as good C++.  After all,
that's what the JIT guys optimized first and best.  That said, I've
found that in fact, you can get as good performance from Java, as from
Perl or Caml.  You just gotta really optimize your Java code in
strange (non-JDK-compliant) ways.

--chet--

>>>>> "NW" == Noel Welsh <noelwelsh@yahoo.com> writes:

    NW> --- onlyclimb <onlyclimb@163.com> wrote:

    >> Is it normal that my ocaml program is only 2 times faster than
    >> the java counterpart ?(using the same method and complied into
    >> native. jdk is 1.4.1

    NW> It depends entirely on the program.  I wouldn't expect a huge
    NW> difference in speed in, say, an HTTP server where most of the
    NW> time is spent waiting for the disk. In numeric applications I
    NW> would expect O'Caml to be significantly faster than Java.
-------------------
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

Re: [Caml-list] speed

[Xavier Leroy]

> Is it normal that my ocaml program is only 2 times faster than the java 
> counterpart ?(using the same method and complied into native. jdk is 1.4.1

You know, many compiler researchers would kill their whole families to
get speedups by a factor of 2 :-)

James Gosling gave a talk at INRIA recently where he repeated the
party line that JDK 1.4 runs as fast, or even faster, than C++.
So, by transitivity, you're implying that OCaml is twice as fast as C++.
Yippee! 

More seriously: Java is nowhere as fast as a good C++ compiler (see
e.g. http://www.coyotegulch.com/reviews/almabench.html for an
independent, cross-language benchmark in numerical computing),
but it's not that slow either.  A factor of 2 slower than ocamlopt
sounds broadly reasonable, especially if the program doesn't stress
the GC too much.  Bagley's shootout (http://www.bagley.org/~doug/shootout/)
seems to suggest a larger factor (JDK 1.3 slightly slower than OCaml
bytecode), but his figures may be lowered by Java's slow start-up times.

- Xavier Leroy
-------------------
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

Re: [Caml-list] speed

[Chet Murthy]

Not to contradict Xavier, because in essence, he is right -- Caml is
indeed far faster than Java on any realistic applications in almost
any area I have ever bothered to try -- but the story as to Java is
actually rather complicated.

(1) different JDKs exhibit remarkably different results on real-world
examples, as their implementors have different backgrounds.  I
remember that the first JITs all did great on integer and
floating-point loops, and that was _it_ -- the rest of the time, they
were often slower than just a hack like inlining interpreter
code-segments.  This is just a human thing.

(2) different JDKs from different manufacturers exhibit different
behaviours.  E.g., I find that the Sunsoft JDKs on Solaris are a lot
faster than the Javasoft JDKs on Solaris.  I also find (no, I'm not
shilling for IBM) that IBM's JDK on Linux is a lot faster than
Javasoft's.  There are, again, social issues involved here, which I am
not sure I am at liberty to discuss.

That said, by and large I find that when you don't go near issues of
allocation and interprocedural optimization, Java is and can be as
fast as Caml.  *However*, when you _do_ go near those things, e.g. if
you do anything I/O or string-processing-intensive, well,

  go get a rocking chair, 'cos you're gonna have a looong wait.

--chet--

P.S. Or get thee to a caml and get it done.  *grin*
-------------------
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

Re: [Caml-list] speed

[Sven Luther]

On Thu, Jan 02, 2003 at 12:52:25PM -0500, Chet Murthy wrote:
> 
> Not to contradict Xavier, because in essence, he is right -- Caml is
> indeed far faster than Java on any realistic applications in almost
> any area I have ever bothered to try -- but the story as to Java is
> actually rather complicated.
> 
> (1) different JDKs exhibit remarkably different results on real-world
> examples, as their implementors have different backgrounds.  I
> remember that the first JITs all did great on integer and
> floating-point loops, and that was _it_ -- the rest of the time, they
> were often slower than just a hack like inlining interpreter
> code-segments.  This is just a human thing.

Do you have any idea how gcj does, compared to ocamlopt maybe ? After
all, if i am not wrong, both generate native code.

Friendly,

Sven Luther
-------------------
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

Re: [Caml-list] speed

[Erol Akarsu]

Hi All,

What is the best way to access to huge Java libraries created so far from ocaml?
I am looking for efficient way, easy-to-write wrappers. I am actually intersted in
accessing to Web services utilities , RDF parsers and some multiagent libraries
all written java.

Thanks

Erol Akarsu

Sven Luther wrote:

> On Thu, Jan 02, 2003 at 12:52:25PM -0500, Chet Murthy wrote:
> >
> > Not to contradict Xavier, because in essence, he is right -- Caml is
> > indeed far faster than Java on any realistic applications in almost
> > any area I have ever bothered to try -- but the story as to Java is
> > actually rather complicated.
> >
> > (1) different JDKs exhibit remarkably different results on real-world
> > examples, as their implementors have different backgrounds.  I
> > remember that the first JITs all did great on integer and
> > floating-point loops, and that was _it_ -- the rest of the time, they
> > were often slower than just a hack like inlining interpreter
> > code-segments.  This is just a human thing.
>
> Do you have any idea how gcj does, compared to ocamlopt maybe ? After
> all, if i am not wrong, both generate native code.
>
> Friendly,
>
> Sven Luther
> -------------------
> 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

-------------------
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

Re: [Caml-list] speed

[Brian Hurt]

Woo hoo.  Language advocacy with benchmarks again.

Feel free to replace this whole post with a comment about "lies, damned 
lies, and cross language benchmarks".  It amounts to the same thing.

On Fri, 3 Jan 2003, Xavier Leroy wrote:

> > Is it normal that my ocaml program is only 2 times faster than the java 
> > counterpart ?(using the same method and complied into native. jdk is 1.4.1
> 
> You know, many compiler researchers would kill their whole families to
> get speedups by a factor of 2 :-)
> 
> James Gosling gave a talk at INRIA recently where he repeated the
> party line that JDK 1.4 runs as fast, or even faster, than C++.

Quibble #1: *what* C++?  Most of the time, when I see C++ benchmarked,
what's really being benchmarked is C compiled with a C++ compiler, or at
most C with classes.  My experience with C++ tells me that if you actually
use the features of C++- RTTI, templates, STL, exceptions, operator
overloading, etc- the code you produce is often much *slower* than Java.  
With a language as feature rich/bloated as C++, which subset of the
language you use makes a huge difference in your performance.  Ocaml has
the same problem in a lot of ways.

Quibble #2: define "equivelent program".

> So, by transitivity, you're implying that OCaml is twice as fast as C++.
> Yippee! 
> 
> More seriously: Java is nowhere as fast as a good C++ compiler (see
> e.g. http://www.coyotegulch.com/reviews/almabench.html for an
> independent, cross-language benchmark in numerical computing),

I note the coyote gulch benchmark shows IBM's Java to be more-or-less on
par with GCC 3.2.  I note, btw, that GCC 3.2 is signifigantly better at
optimization than GCC 2.9x, producing code about 10% faster on average
IIRC according to the GCC maintainers themselves.  Which tells me that
IBM's Java *is* better than GCC 2.9x.  Which is still the most commonly
used compiler on Linux systems.  Ditto for Windows.  My own experience and
tests show me that MS VC++ 6.0 is no better than, and in many cases worse
than, GCC 2.9x for optimization.

> but it's not that slow either.  A factor of 2 slower than ocamlopt
> sounds broadly reasonable, especially if the program doesn't stress
> the GC too much.  Bagley's shootout (http://www.bagley.org/~doug/shootout/)
> seems to suggest a larger factor (JDK 1.3 slightly slower than OCaml
> bytecode), but his figures may be lowered by Java's slow start-up times.

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.

Note that I can also claim, with a straight face, that Ocaml is 5x 
*slower* than Java.  Take a look at Bagley's shootout on matrix 
multiplication, comparing byte-code interpreted Java with byte-code 
intepreted Ocaml.  Which is a much more apples to apples comparison.

Then there is the question of *future* performance of the languages.  In 
the pro-Java camp, I direct your attention to HP's Dynamo project:
http://www.arstechnica.com/reviews/1q00/dynamo/dynamo-1.html
http://www.hpl.hp.com/cambridge/projects/Dynamo/
which showed that a virtual PA-RISC emulator could run the code up to 20%
faster than running the same code native.  In the pro-Ocaml camp, Caml's
innate ease of reasoning about code open up, I think, a much larger array
of potiental optimizations for the compiler.

Of course, Java, Ocaml, and C++ all pale in comparison to the performance 
of hand-tuned assembly language.  Ergo, anyone who is using performance of 
the generated code as the primary reason for picking a language should, by 
all logic, be coding in assembly language.

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


-------------------
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

Re: [Caml-list] speed

[Michael Vanier]

> 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