[VM] NCM performance report

Dan Ingalls DanI at wdi.disney.com
Thu Mar 25 06:14:59 UTC 1999


Helga -

>I've been running Tim Rowledge's NCM VM and image (see
><http://sumeru.stanford.edu/tim>) on win32 successfully for a while now.
>I'd like to offer a short performance report, because I think (and feel)
>that I get appreciable results.

<figures snipped>

>All in all, I'd vote for merging Tim's improvements into mainline Squeak
>(2.5?). Not only does NCM enhance the malleability of the VM, it's faster
>too. How much more could we probably want?

Thanks for your performance report.  We have been considering th NCM changes since Tim first got them working.  Simplicity and malleability are certainly positive features.  Performance, if it's real, is as well.

The main reason I have balked at this change so far is the cost in space for small implementations  I believe the current design, even if it makes maximum use of compact headers requires two extra pointer fields and two extra objects, each with a one-word header.  This is 16 bytes per method.  Taking the 2.2 Mini image as a benchmark (4615 CMs), this would add 73k to an image that is only 530k -- or subtract 73k from what you could do with it on a PDA.  I consider this to be material.

A competing change we have been weighing for a long time is to do away with compact headers.  This would add about the same amount of space (70k) to the mini image, but would yield greater simplifications and speedups in the virtual machine (IMO).  Moreover if we decide to drop compact headers, suddenly the penalty for NCMs increases to 110k.  At that point we would have added 180k to the 530k mini image.  This is why I am being conservative.

Since you have published the numbers (and since I am certainly curious about them), I have to ask if they represent an apples-to-apples comparison.  Are the VMs generated from the same compiler, and are the only differences in the handling of methods?  I would be surprized to find more than a nominal increase in speed due to this change, since there is very little difference once a method is in the cache.

Finally, and I am glad you raise the point, I am interested in how this all will appear when seen through the eyes of Jitter.  One of the beauties of Jitter is that it affords an opportunity to lay a completely different set of speed/space tradeoffs on top of the existing system.  While it has consumed a lot of Ian's brain cells (fortunately there are plenty ;-), it is exhibiting remarkable freedom from the apparent costs of our current CompiledMethods.  Ian may want to say more this and about compact classes which are somewhat more of an issue.

I know Tim has probably been frustrated at our apparent recalcitrance in not immediately adopting NCMs, so I'm glad you have induced me to articulate the issues.

	- Dan





More information about the Squeak-dev mailing list