🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.lang.java
Article #300

Re: Will Java kill C++?

#300
From: Alan L. Lovejoy
Date: Wed, 17 Apr 1996 20:15
56 lines
3635 bytes
Tom Payne wrote:
> 
> Alan L. Lovejoy (alovejoy@concentric.net) wrote:
> : Tom Payne wrote:
> : >
> : > Alan L. Lovejoy (alovejoy@concentric.net) wrote:
> : > :
> : > : I did those benchmars to prove that Smalltalk message sends are faster
> : > : than c function calls.  To do that, I needed a benchmark that consisted
> : >
> : > How is that possible, given that the message has to find the entry
> : > point of the method and has to communicate parameters by mechanisms
> : > not unavailable to C.
> :
> : It's a fact.  It's possible because full method lookup only needs to
> : occur the first time a message is sent to a receiver of a particular
> : class, not each time a message is sent--and because message sends do not
> : use "JSR/BSR" machine instructions, but just use simple jumps or
> : branches.  Remember, method contexts are allocated on the heap, not on
> : the stack.
> 
> This shows that a particular implementation of Smalltalk message sends
> is faster than a particular implementation of C function calls, which
> is both surprising and interesting, but does not show message sends to
> be inherently faster.  (Perhaps, all you are claiming is the relative
> performance in a particular case.)

Exactly.  This benchmark was done for a client whose platform was Sun
workstations.  VisualWorks versus C on the SPARC was what mattered.
I realize full well that results may be different on other hardware.

But the mere fact that this result could be obtained on any platform
is very informative, I think.

> As I recall, the standard trick for eliminating most of the overhead
> of method lookups on message sends is to cache the method on each send
> and next time check for correctness.  Of course, this correctness
> check is overhead that is unnecessary in C.  The fact that in this
> implementation method contexts are allocate on the heap, not the
> stack, leaves me even more puzzled; heap allocation is no faster, in
> fact almost always slower, than stack allocation, which merely
> involves incrementing a pointer.
> 
> Tom Payne (thp@cs.ucr.edu)

Smalltalk gets little or no benefit from the work done by a subroutine 
call instruction.  It doesn't need to pass arguments in registers, and it 
doesn't need register windows.  There is no need to save and restore
register values on the stack each time a method is called, because 
the method arguments and temporaries are heap-allocated--this could
account for a significant portion of the surprising speed difference.
C compiled code is optimized for relatively infrequent function calls.
Smalltalk is optimized for dense message sending--just about everything
is done by message send.

--Alan
Technical Details
Message-ID: <31755164.79F8@concentric.net>
Path: arc1-ca.pugleaf.net!newsfeed.concentric.net!news
References: <3134D499.653E@ix.netcom.com> <313613B2.136E@ksopk.sprint.com> <4i7qhl$ik6@cronkite.seas.gwu.edu> <4iuhi7$fmf@sundog.tiac.net> <4iumap$mn5@hustle.rahul.net> <31582A45.3742@vmark.com> <3163C031.4FB1@esec.ch> <3164888D.2B01@concentric.net> <4kbfn8$1bu@news1.is.net> <4kqjf6$kh0@kaiwan009.kaiwan.com> <317173F1.5790@concentric.net> <4l194e$q11@galaxy.ucr.edu> <31743669.62A1@concentric.net> <4l3432$ebu@galaxy.ucr.edu>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!newsfeed.concentric.net!news
From: "Alan L. Lovejoy" <alovejoy@concentric.net>
Newsgroups: comp.lang.java,comp.lang.c++,comp.lang.smalltalk
Subject: Re: Will Java kill C++?
Date: Wed, 17 Apr 1996 13:15:32 -0700
Organization: Modulation
Message-ID: <31755164.79F8@concentric.net>
References: <3134D499.653E@ix.netcom.com> <313613B2.136E@ksopk.sprint.com> <4i7qhl$ik6@cronkite.seas.gwu.edu> <4iuhi7$fmf@sundog.tiac.net> <4iumap$mn5@hustle.rahul.net> <31582A45.3742@vmark.com> <3163C031.4FB1@esec.ch> <3164888D.2B01@concentric.net> <4kbfn8$1bu@news1.is.net> <4kqjf6$kh0@kaiwan009.kaiwan.com> <317173F1.5790@concentric.net> <4l194e$q11@galaxy.ucr.edu> <31743669.62A1@concentric.net> <4l3432$ebu@galaxy.ucr.edu>
NNTP-Posting-Host: cnc009039.concentric.net
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 2.01Gold (Win95; U)