jpraher at yahoo.de
Sun Jul 4 17:38:15 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
* 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
* 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
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
> 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
> 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
> > Remember that in Smalltalk bitblt is one bytecode,
and local variable
> > access is one bytecode.
> > When we did our benchmarking work, we took a
> > 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
> >> On Thursday 01 July 2004 23:11, Michael Latta
> >>> It looks like the compiler on the Mac is not as
good as that for the
> >>> Sparc. On my 1Ghz powerbook I got the
> >>> 47,058,823 bytecodes/sec and 17,247,597
> >>> which is a lot less than the 277Mhz sparc for
> >>> 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
> >> 4.1.6.
> >> 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
> >> Self 4.1 => 78,527,607 bytecodes/sec; 15,404,782
> >> 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
> >> 0 tinyBenchmarks
> >> -- Jecel
> >> Yahoo! Groups Links
> > Yahoo! Groups Links
> Yahoo! Groups Links
> self-interest-unsubscribe at yahoogroups.com
Gesendet von Yahoo! Mail - Jetzt mit 100MB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de
More information about the Self-interest