[self-interest] Performance?

Jakob Praher jpraher at yahoo.de
Sun Jul 4 11:08:47 UTC 2004


hi Michael, Jecel, David, and everybody,

I very much enjoy the threads here.

from a vm design point of view, I, as a self interested person, would
have some questions:
* how would you design a self vm from scratch these days?
* what are the things, learned?
  -> for instance the heap word structure, with the two bit tag fields,
were they big problems when introducing 64 bit support?

* self-in-self would be interesting (I know the jikes rmv design, which
is a java vm in java, they use some kind of runtime image, which must be
created with a java vm once and then gets dumped to a file. they use a
simple image loader, which produces all the runtime data structures for
the vm to launch it).
  -> what are design issues here


I could imagine that a self vm could lay the ground for a vm that is
capable of different language/runtime systems, like the paper that
implemented java on top of the self vm. This would especially be
valuable, given the soup of different languages/runtimes we have today
(java,python,.net, ... )

Are you serious about relaunching a self project again? It could be
rather interesting...

have a nice weekend.
-- Jakob

Am Sam, den 03.07.2004 schrieb Michael Latta um 2:15:
> As Jecel pointed out, we are not trying to find out how "good" self is. 
>   The VM technology is clearly newer/better.
> 
> It all started when I did some bad math in my head and thought that 
> Squeak was running 1000 cycles / bytecode.  The actual
> numbers are much more reasonable (8 / bytecode or so).  Then I asked if 
> the same benchmarks could be run in Self to compare
> them on my machine.
> 
> Having just got back from JavaOne I have a related question.  Is the 
> HotSpot VM faster than Self?  I will probably try recoding it in java 
> just
> for curiosity sake.  It sure is hard to look at the success of Java and 
> hold out for the Smalltalk/Self language and environment.  It is 
> however the things
> that Java left out from these languages and environments that make them 
> so much more productive and enjoyable to work in.  Even the best Java 
> IDEs
> with some code replacement features, are no where close to the fluidity 
> of the "older" environments.  The Java VMs only allow live replacement 
> if you are
> not adding/removing methods or fields!  Talk about user visible 
> discontinuity.  What we need is a commercially usable VM that runs 
> Self/Smalltalk and can
> interoperate with Java (through SOAP?).

> 
> Michael
> 
> 
> 
> On Jul 2, 2004, at 3:01 PM, David Ungar wrote:
> 
> > What benchmarks are you running?
> > I believe that bytecodes/sec can be a meaningless figure.
> > Remember that in Smalltalk bitblt is one bytecode, and local variable
> > access is one bytecode.
> >
> > When we did our benchmarking work, we took a (then) medium-sized
> > program, Richards,
> > and wrote it in optimized C++, and in several different styles in Self,
> > varying in amount
> > of object-orientedness.
> >
> > Remember, that in a Self-style VM, sends to self of messages whose
> > method bodies are small are free.
> > Also, custom control structures you build run just as fast as ifTrue:
> > while:, etc.
> > Last time I looked, this was not true in Smalltalk VMs. So, if your
> > benchmark uses a control structure
> > that the ST compiler happens to replace with branch bytecodes, you do
> > OK.
> > But if not, you lose. I don't know if it is still true, but in ST-80,
> > folks used to distort their code
> > to use the "good" control structures.
> >
> > - David
> >
> >
> >
> >
> > On Jul 2, 2004, at 10:28 AM, Jecel Assumpcao Jr wrote:
> >
> >> On Thursday 01 July 2004 23:11, Michael Latta wrote:
> >>> It looks like the compiler on the Mac is not as good as that for the
> >>> Sparc.  On my 1Ghz powerbook I got the following:
> >>>
> >>> 47,058,823 bytecodes/sec and 17,247,597 sends/sec
> >>>
> >>> which is a lot less than the 277Mhz sparc for bytecodes, but
> >>> competitive on sends.  Still not what you want when comparing to
> >>> hardware with 1/4 the clock rate.
> >>
> >> Is this a G4? I'll see what numbers I get on 1GHz G4 eMac the next 
> >> time
> >> I get to use that machine. I suppose you are using the latest version 
> >> -
> >> Self on the Mac didn't have the SIC (simple inlining compiler) before
> >> 4.2 and didn't even have PICs (polymorphic inline caches) before 
> >> 4.1.6.
> >>
> >> <http://research.sun.com/self/release_4.2/Self-4.2.1/Self-4.2.1-
> >> Release-Notes.pdf>
> >>
> >> It seems that the compilers have been improved for the Sparc. Here are
> >> more numbers on that same machine:
> >>
> >> Self 4.0 =>  60,150,375 bytecodes/sec; 5,845,070 sends/sec
> >> Self 4.1 =>  78,527,607 bytecodes/sec; 15,404,782 sends/sec
> >>
> >> You might also want to run the benchmarks several times. Here are the
> >> first ten runs in Self 4.1.1 on the Ultra:
> >>
> >>   75,029,308 bytecodes/sec; 16,746,759 sends/sec
> >>   74,116,965 bytecodes/sec; 16,915,608 sends/sec
> >>   69,678,824 bytecodes/sec; 16,492,340 sends/sec
> >>   72,480,181 bytecodes/sec; 16,946,674 sends/sec
> >>   97,116,843 bytecodes/sec; 16,962,250 sends/sec
> >>  100,078,186 bytecodes/sec; 16,993,488 sends/sec
> >>  101,910,858 bytecodes/sec; 16,962,250 sends/sec
> >>  101,185,770 bytecodes/sec; 16,977,855 sends/sec
> >>  101,105,845 bytecodes/sec; 17,024,842 sends/sec
> >>   85,106,382 bytecodes/sec; 17,087,897 sends/sec
> >>
> >> Please note that these are bad benchmarks for Squeak, and even worse
> >> for
> >> Self (the moral equivalent of BogoMIPS in Linux). For a serious
> >> comparison we should be using DeltaBlue, Richards and so on.
> >>
> >>> Now I need to run the same thing on Squeak to compare on the same
> >>> hardware.  Could you point me at the squeak expression?
> >>
> >>    0 tinyBenchmarks
> >>
> >> -- Jecel
> >>
> >>
> >>
> >> Yahoo! Groups Links
> >>
> >>
> >>
> >>
> >>
> >
> >
> >
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
> 
> 
> 
>  
> Yahoo! Groups Links
> 
> 
> 
>  
> 





More information about the Self-interest mailing list