Newsgroups: comp.lang.java.programmer,comp.lang.java,comp.lang.functional,comp.lang.misc,comp.lang.smalltalk,comp.lang.c,comp.lang.c++
Path: cantaloupe.srv.cs.cmu.edu!rochester!cornellcs!newsstand.cit.cornell.edu!news.tc.cornell.edu!caen!hookup!usenet.eel.ufl.edu!spool.mu.edu!agate!ihnp4.ucsd.edu!swrinde!newsfeed.internetmci.com!eanews1!rsvl_ns!unirsvl!news
From: charles loboz <charles@syacus.acus.oz.au>
Subject: Re: Three languages: A performance comparison
Sender: news@unirsvl.rsvl.unisys.com (News Administration)
Message-ID: <31FC2514.31F9@syacus.acus.oz.au>
Date: Mon, 29 Jul 1996 02:42:28 GMT
X-Nntp-Posting-Host: 192.146.252.217
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
References: <4te7rg$287o@piglet.cc.uic.edu> <4tg1i3$20p@mag3.magmacom.com>
Mime-Version: 1.0
X-Mailer: Mozilla 2.0 (WinNT; I)
Organization: Australian Centre for UNISYS Software
Lines: 105
Xref: glinda.oz.cs.cmu.edu comp.lang.java.programmer:2365 comp.lang.java:71968 comp.lang.functional:7649 comp.lang.misc:26358 comp.lang.smalltalk:41494 comp.lang.c:198764 comp.lang.c++:202705

I have to be a total killjoy on this one. Apologies for butting in like this, but 
several years ago I had to do a PhD on benchmarking and 'benchmarks' like that were 
one of the (sub)topics. 

The main points are:
	0) The experiment was well done and well meant. Because of the design flaw 
it's results cannot and should not be overinterpreted nor extrapolated - and most of 
the participants of this thread are doing just that. 
	1) Taking any small(ish) program we benchmark - whether we realise it or not - 
a small subset of the total environment of the language. Very frequently this subset 
is randomly chosen and is not what it seems at the first sight. I did not analyse the 
original programs but further posting were suggesting that in this case garbage 
collection was the issue. [So it wasn't even the language]
	2) For small(ish) programs the differences in speed - due to the compiler, 
system environment, processor architecture etc - can be twenty times or more 
[references available upon request]. This still says _nothing_ about _language_ speed. 
This is a multidimensional space which the 'benchmark' tries to flatten - you lose all 
the important info in other dimensions.
	3) To properly benchmark something we need a set a well chosen (and 
understood) programs. They can be small, but we must understand what each one of them 
is trying ot achieve and which are the language issues and which are 
architectural/environmental issues.

Personally - and performance analysis is my profession - I do not see off-hand any 
reasons why Java should be significantly slower (or faster) than C++ because of 
_language_ issues. 
	1) It is slower now, but this is the compiler-implementation and 
virtual-machine implementation issue. You can take JVM code, write a very good machine 
code generator (with plenty of optimization) and be as good as C/C++/whatever
	2) The advantage Java has is that heavy use of built-in classes (and their 
number) moves many performance problems to the proper implementation of these classes 
(like standard C library did - to smaller extent - to C).
	3) Additional advantage is that the Java compiler can probably do better job 
of code optimization as it does not have to deal with pointer aliasing and other 
unpleasant stuff. A JIT compiler can also do some optimization using _dynamic_ info on 
path probability. [Whether current compilers are doing that or not is another issue - 
but this is eminently doable].
	4) Java's disadvantage is that some specific problems cannot be programmed in 
Java in such a low level like in C/C++, therefore their expression in Java will result 
in (possibly much) slower execution speed - regardless of the compiler. Examples of 
such problems are regular expressions, programs like 'compress' on UNIX, etc. Please 
note that such programs belong really to the 'system library' for each platform (like 
in WinNT, for example). They should be accessible from Java and most such stuff will 
probably became a part of its standard class/utilities library sooner or later.
	5) 


_______________________________________
David Buck wrote:
> 
> dhanle2@icarus.cc.uic.edu (David James Hanley) wrote:
> 
> >       The languages I used were C++, Java, and SML.  I used these
> >because I both know them, and they were available to me.  I encourage
> >others to try to translate to other languages.  The sources will
> >follow this posting.
> 
> >       The C compiler was borland C++ 4.0 for windows.
> >       the java compiler was symantic cafe 1.2 with JIT enabled.
> >        The sml compiler was sml/nj 1.05 for windows.
> 
> >       The computer was a pentium-90, with 24mb of ram, running win'95.
> 
> >Finally, here are the results:
> >(in seconds)
> >                   Taking large       summing
> >                   powers of 2        large numbers.
> >----------------------------------------------------
> >       java :       15.32             3.89
> >        C++  :       22.79            51.3
> >        SML  :        7.0              2.2
> >       (Times are the average of 3 runs, on an unloaded machine
> >         the times match almost identically, so I feel confident of them)
> 
> Here are the VisualWorks Smalltalk results (Pentium 90, 40 Meg RAM,
> Windows 95):
> 
> Taking large powers of 2:        800 microseconds
> (Note - I had to test 10000 loops to perform an accurate timing)
> 
> Summing large numbers:    1.5 seconds
> 
> The code took approximately 30 seconds to write and is included below:
> 
> Time millisecondsToRun: [
>         10000 timesRepeat: [
>         2 raisedToInteger: 8000.
>         2 raisedToInteger: 800]]
> 
> | a b |
> a := 2 raisedToInteger: 8000.
> b := 2 raisedToInteger: 800.
> Time millisecondsToRun: [
>         10000 timesRepeat: [a+b]]
> 
> The point is that this benchmark is one that no Smalltalk programmer
> would ever consider implementing the way you did with linked lists of
> digits separately allocated.  Smalltalk supports large integers and we
> would simply take advantage of that fact.  To code large integer
> calculations explicitly in Smalltalk is like saying that you enter a
> race with a Concord so long as you keep the wheels on the ground the
> whole time.
> 
> David Buck
> dbuck@magmacom.com
