From: Peter Suk Date: 2005-04-08T15:13:14+09:00 Subject: Re: Seven new VMs, all in a row On Apr 7, 2005, at 9:14 PM, Phil Tomson wrote: > This "20x to 30x speed increase" stuff is interesting. I would have > thought it would be closer to something like 5x. Can anyone elaborate > on > how those increases are being acheived in the SmallTalk VMs? I'm > wondering > if it might also be worthwhile to incorporate some of these ideas into > YARV - > parhaps that would get us to high-speed Ruby even faster than trying to > put Ruby on top of a SmallTalk VM? Phil, 30X speed increase is for "Real World Applications" and is highly dependent on Garbage Collection. I have seen many dozens of Smalltalk business programs in my time as a consultant. One of the things they do a lot of is create objects and garbage collect them. In fact, memory management is probably the biggest single factor that comes up in the performance of business apps after IO and DB access. The Generational GC in VisualWorks is truly fantastic. I can sit around all day with an infinite loop that allocates copies of some random string like "Doo-Dah, Doo-Dah, All the live long day" running in the Smalltalk image I am developing in, and there's no obvious effect. (Yes, I did this earlier this week!) I can crank up this loop until it is producing a billion new objects in several minutes, and my image is fine, until I try to do something serious like have the Refactoring Browser rename all implementors of the method #add: in the image, and even then, it;s fine, it just does it slowly. Another thing you should know in terms of anecdotes. A fellow Smalltalker implemented a bunch of Encryption algorithms a few years back in VisualWorks Smalltalk. (So we're talking lots of low-level bit & byte slewing.) He benchmarked them against the reference DLLs from RSA Data Security, which were written in C. The Smalltalk algorithms ran at a comparable speed. One of them ran 3% faster! Again, this was partly due to memory management. The DLLs naively malloc'd & free'd everything immediately, while the Generational GC in Smalltalk provided what amounted to a buffer cache optimization for free! (The other part was he had our VM guys implement some bit & byte slewing primitive ops.) And lastly, please remember that VisualWorks and most of the commercial Smalltalk implementations are actually JIT compilers. Most of the time, we're running native machine language instructions. If YARV out does Smalltalk VMs for speed of Ruby execution, then all the better. The competitive pressure will ultimately be good for the Ruby community. We'll just settle for providing all of the other great benefits I've mentioned. (Like the fastest Ruby-In-Ruby!) --Peter -- There's neither heaven nor hell, save what we grant ourselves. There's neither fairness nor justice, save what we grant each other.