Morphic, Dynapad, and Squeak performance

Tommy Thorn tt1729 at yahoo.com
Fri May 24 22:05:28 UTC 2002


> Welcome to the debate....




Thank you.




First let me refrase my main point: before
dropping
Morphic, let's see how much performance 
we can
get back from tuning Squeak on StrongArm.

> Huh? I don't think it would be properly called a
>
jitter if it didn't.







I apologize.  I'm _am_ a Squeak newbie and I
hadn't
yet looked closely at jitter, but this is 
good
news.




> But yes, there is a jitter for Squeak that has 

>
some good performance benefits but it doesn't 


>
seem t get a great deal of use in practice. I



>
haven't yet made an ARM version for example.







Is jitter a seperate package or is it part of



VMMaker?  Why isn't it getting use?




> > Even simple minded template



> > based instantiation can improve performance



> >
by a factor of four and more can be had with


> >
varing degree of runtime optimization.



> I think you're over simplifying a bit there; 



>
there are a huge number of other areas that need >
improvements to get fourtimes speedups. As 



> another (even more) simplistic statement it is 

>
generally considered that Smalltalk spends 



> around half its time in primitives and thus even
> an infinitely fast jit engine that produced 



> infinitely fast code would only double aggregate
> performance. 







You're absolutely right.  What I _meant_ to say



is
speed up the execution mechanism by factor of


four. 
This number is based on experience with



functional languages, it might not be exactly 



right for Smalltalk.  Clearly, time spent in 



primitives and GC won't be affected, so the
overall speed up would be less.

> It's perfectly sensible in an interpreter world,
>
which is what we're living in now. You can't 



>
really do inline caching in a practical sense.

I didn't claimed you could, but for the sake of 
the argument, what stops your from doing 
send-site caching, even in an interpreter?
Is the space overhead too big?

> We've been doing this in the Smalltalk worl for,
>
ooh, twenty years or so. I think the earlist 



>
paper I can think of would the the



> Deutsch/Schiffman paper from '84 POPL.







Thanks for reinforcing my point.  This is all



well-know stuff.







> I'm fairly sure we could potentially get maybe


>
four-five times faster from a strongARM than we 
> do
right now. It just so happens that I have a


> few
years experience doing this sort of thing on
> ARMs
(all the way back to helping in the 



> original cpu design) as well as an ARM 



> VisualWorks implementation. It's around five 



>
times faster than squeak.







Excellent.  Is there anywhere I could learn about

the
details of the VM implementation on StrongArm?
Are
there any great tricks that I'm missing?

> The chief obstacle to speed for Smalltalk on ARM
>
is the tiny cache size.  This severely restricts >
effective bandwidth, and as everybody knows I



>
keep saying you need three things for Smalltalk

>
performance memory bandwidth, memory banhdwidth,
> and
err, oh, yes, memory bandwidth :-)







Amen - the same is true for most high-level 



languages, although increasingly you also have



to worry about branch penalties.

But, in spite of the poor memory bandwidth on
the StrongArm, do you think we can speed up
Morphic enough to make it tolerable?

Thanks,







  Tommy

PS: I live in Menlo Park, CA and would be happy to 
meet other Squeakers.



__________________________________________________
Do You Yahoo!?
LAUNCH - Your Yahoo! Music Experience
http://launch.yahoo.com



More information about the Squeak-dev mailing list