Message-ID: <31FF20C9.5B02@itv.se>
Date: Wed, 31 Jul 1996 11:00:57 +0200
From: Mikael Sker <sicher@itv.se>
Organization: IT verkstaden, Sweden
X-Mailer: Mozilla 2.02 (Win95; I)
MIME-Version: 1.0
Newsgroups: comp.lang.java.programmer,comp.lang.java,comp.lang.functional,comp.lang.misc,comp.lang.smalltalk,comp.lang.c,comp.lang.c++
Subject: Re: Three languages: A performance comparison
References: <4te7rg$287o@piglet.cc.uic.edu> <4tg1i3$20p@mag3.magmacom.com>
		<4th72n$38v8@piglet.cc.uic.edu> <rqcg26brsvo.fsf@knase.it.kth.se>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
NNTP-Posting-Host: blom.itv.se
Lines: 50
Path: cantaloupe.srv.cs.cmu.edu!rochester!cornellcs!newsstand.cit.cornell.edu!portc01.blue.aol.com!news-res.gsl.net!news.gsl.net!swrinde!howland.reston.ans.net!spool.mu.edu!munnari.OZ.AU!news.ecn.uoknor.edu!solace!xinit!newsfeed.tip.net!katla.itv.se!
Xref: glinda.oz.cs.cmu.edu comp.lang.java.programmer:2603 comp.lang.java:72813 comp.lang.functional:7705 comp.lang.misc:26416 comp.lang.smalltalk:41640 comp.lang.c:199169 comp.lang.c++:203247

Rasmus Kaj wrote:
> 
> >>>>> "DJH" == David James Hanley <dhanle2@icarus.cc.uic.edu> writes:
> 
>  DJH> :  To code large integer
>  DJH> : calculations explicitly in Smalltalk is like saying that you enter a
>  DJH> : race with a Concord so long as you keep the wheels on the ground the
>  DJH> : whole time.
> 
>  DJH>   No, it's the only way to get a valid comparison in this
>  DJH> case.  It has to do with computer science.
> 
> Since we are comparing languages, we should use whatever optimization
> feels usefull and is availible in any language.
> 
> If you feel that the test is unfair, I agree... I guess (note; only a
> guess, dont flame me!) that C++ would be *much* faster, booth
> development and excuting, than java in a larger project. For ml and
> smalltalk, I'm clueless and I admit it...
> 
> // Rasmus

As far as execution speed is concerned, I am convinced that Java *will* be slower than any average C++ 
program. However, this is due to Java's lack of Virtual Machines implemented for speed (i.e silicon 
VM). If we are talking development speed the situation is probably the other way around. Java do have 
stronger typing and a much neater way of handling memory. It's, for example, easy to overrun an array 
in C++ without further notice. 

OK, there are environments that helps a lot. VC++ has nice tools to detect memory-leaks which is fine, 
but that is not in the language design as the situation with Java is.

But when I think about it.. Maybe you're right about development time under sme circumstances. Java 
forces you to do better design to a farther extent than C++ which will cost time in the *design* phase 
of a project. However, this is by most people considered a good thing. I agree with them.

On the subject of benchmarking optimized language there are different approaches I thing one should 
consider. First. If we are testing the sole function of the language itself - that is, how well the 
language is designed to cope with practical situations and various environments, I believe optimization 
will ruin the test. On the other hand. If you are testing to see the over-all practical impact of the 
language, not considering any language-disigns, you should switch on all the optimization options 
possible and rock-n-roll. The drawback on this kind of test is that you are most likely to be able to 
design a lagnuage that out-performs most other languages in speed, but lacks the design that is needed 
to do well in any larger-scale project. Look at Forth, for example. It's really fast and is probably 
rather easy to optimize further, but I don't think of the language as really well-suited for 
programming seriously (I know some people disagree on this).
  
About Smalltalk and ML, I'm in the same boat as you, Rasmus. I don't have a clue... :-)


/Mikael

P.S.    Hur str det till med dig d, Rasmus? Det var ett tag sedan sist... 
D.S

-- 
Mikael Saker <sicher@itv.se>
IT verkstaden, Harnosand - SWEDEN
