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
have a nice weekend.
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
> 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
> 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?).
> 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