Article View: comp.lang.java
Article #300Re: Will Java kill C++?
From: Alan L. Lovejoy
Date: Wed, 17 Apr 1996 20:15
Date: Wed, 17 Apr 1996 20:15
56 lines
3635 bytes
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!newsReferences:
<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)