HREF Considered Harmful

Chrome, V8 and Strongtalk

There's lots to like about Google's new web browser, Chrome, which was released today.  When I read the awesome comic strip introduction yesterday, however, the thing that stood out most for me was in very small type: the name Lars Bak attached to the V8 JavaScript engine.  I know of Lars from his work on Self, Strongtalk, HotSpot and OOVM, and his involvement in V8 says a lot about the kind of language implementation it will be.  David Griswold has posted some more information on the Strongtalk list:

The V8 development team has multiple members of the original Animorphic team; it is headed by Lars Bak, who was the technical lead for both Strongtalk and the HotSpot Java VM (as well as a huge contributor to the original Self VM).   I think that you will find that V8 has a lot of the creamy goodness of the Strongtalk and Self VMs, with many big architectural improvements

I'll post more on this later, but things are getting interesting...

Update: the V8 code is already available, and builds and runs fine on Mac OS X.  From the design docs, it's pretty clear that this is indeed what I was hoping for: a mainstream, open source dynamic language implementation that learned and applies the lessons from Smalltalk, Self and Strongtalk.  Most telling are that the only two papers cited in that document are titled "An Efficient Implementation of Self" and "An Efficient Implementation of the Smalltalk-80 System".

The "classes as nodes in a state machine" trick for expando properties is especially neat.

The bad news: V8 is over 100,000 lines of C++.

 

MagLev recap

There has been a huge response to the MagLev demo I gave on Friday, most of it enthusiastic, though not without the inevitable skepticism that comes with any announcement.

For those who weren't at RailsConf, here's a quick summary of how the demo went.

I started off by describing MagLev as a "full stack Ruby implementation", in the same way that Rails is a full stack web framework. To understand what I mean by that, see my earlier post on the Gemstone architecture: not only does MagLev provide a new (and fast) VM for Ruby, but it also provides an integrated shared memory object cache, and integrated transparent persistence. This fully replaces the typical Rails stack of many mongrel instances + several memcached instances + MySQL.

As a first demo, I showed a "magic trick" with two maglev instances running an irb-like shell in side by side terminal windows. A $hat global was defined in each, which just wraps an array and lets you put things in it. In the left window, I put a Rabbit into the $hat. I then looked at the $hat on the right and showed that the Rabbit had magically been transported there.

>> $hat
=> #<Hat:0x0c184bfd01 @contents=[
 () ()
( '.' )
(")_(")
]>

How is this possible? Because they're the same hat. The integrated VMs, cache, and storage conspire to create an illusion that global state is shared across all instances: no matter how many VMs you add, over however many machines, they all see and work with the same set of Ruby objects.

There's no limit to what kinds of objects can be shared this way: procs and classes work just as well as arrays and strings. This isn't RPC - the objects are copied into a shared cache when they're created or modified, and if (but only if) another VM needs the object, it will pull it out of the cache and work on the local copy. All of these copies are kept in sync, and any changes are also written to disk by the storage engine so that the entire model is persistent.

This only applies to globally reachable objects - local variables, method arguments and so on aren't generally shared.

Obviously, with this kind of synchronization there has to be some concern for concurrency. MagLev handles this with transactions. Each VM has its own transaction state. When a VM enters a transaction, all of its changes are only locally visible until it is asked to commit. At that point, all of its changes get recorded to the cache and to disk and are available to every other VM.

A transaction can be aborted, in which case *everything* that has happened in that VM since the last commit (object modifications, creation, method or class definition, etc) will get rolled back. A transaction commit can also fail if it conflicts with concurrent changes elsewhere (for example, two VMs modifying the same instance variable of the same object at once).

Because these shared objects are stored on disk, and are lazily loaded into the VMs only when needed, it means you can work with datasets that have many, many more objects than would fit into available RAM. I showed a dataset that I had loaded in which contained 100 million movie reviews, and took up somewhere around 10GB. I could instantly pull in a single movie, modify it, and commit that change, without needing to load the other couple hundred million objects into RAM.

As a final demo, I showed how far MagLev has currently gotten with compatibility by running a simple WEBrick servlet.

At this point, Bob Walker took over. He gave some company background on Gemstone (they've been working on multi-user persistent dynamic language VMs since 1982), and some technical details on MagLev (the VM is a modified version of their Gemstone/S Smalltalk VM, with some Ruby-specific bytecodes; the bytecode is JITted to native code before execution). Then he showed some micro-benchmarks: for what it's worth, MagLev is anywhere from 6 times to (in the extreme case) 111 times faster than the standard 1.8.6 Ruby interpreter on things like fibonacci, block execution, method dispatch, and so on.

Bob then talked about scale. Gemstone has many customers running things like commodities exchanges, derivatives trading, container shipping, and so on that operate at very large scale on top of the same underlying technology as MagLev. Here are a couple of recent unsolicited quotes from a thread on the Joel on Software forums:

"I work for a major shipping company. We have a massive OODB and Smalltalk Application (500 gig range) with 3 million lines of code. We have 2000 plus daily users. We can do 700 transactions a second before slowing down. We also have a Java + SQL +EMS system. On a good day they can do 70 transactions a second, with three times the hardware." --Timo (Saturday, February 16, 2008)

"Along side with the major shipping company, we are a major
commodities exchange using GS and ST and while our operational DB is
small (about 5 GB at the start of the trading day to less than 75 GB
and the end) we are probably one of the fastest. We easily handle
transaction rates approaching 6000/sec with about 8000+ daily
users. Our average data center round trip times are in the 2-3 ms
range." --GemStone Weenie (Monday, February 18, 2008)

It's worth noting that that's 6000 writes per second, sustained, and that this application peaks at about 3x that. By comparison, Twitter was once reported as having 600 requests/s (read and write).

Bob then moved onto the vision for MagLev going forward. A few important points:

• It doesn't run Rails yet, but it will.
  
• It will be RubySpec compliant.
  
• The Ruby source will be released. The C source code for the VM most likely will remain closed (but anything is possible).
  
• There will be a free version which will work for most uses, and a paid version for large-scale deployment.
  
• Look for another announcement/demo at RailsConf Europe in September.
  

After that we retired to the DoubleTree for a keg of Ruby ale.

MagLev

People have by now probably gotten a little sick of me saying that we really need to take Smalltalk technology and apply it to Ruby - see, for example, pretty much anything I wrote in November 2006, or my RailsConf keynote from last year.

This year, I'm going back to RailsConf, but with some concrete good news: we've finally done it, and it rocks.

If you're want to see the first real demo* of Ruby running on Gemstone's very cool originally-for-Smalltalk platform, drop by on Friday afternoon. I'm excited to see what everyone thinks.

(* I did do a teaser at MeshU)

Those who misremember history...

In Dynamic Languages Strike Back, Steve Yegge says

StrongTalk was really interesting. They added a static type system, an optional static type system on top of Smalltalk that sped it up like 20x, or maybe it was 12x.

Why do people make this stuff up? The following two statements are true:

1. Strongtalk has an optional static type system.
2. Strongtalk is 15-20x faster than most other Smalltalk systems.

What's false is the causal link Steve is claiming between them. They are entirely independent. Strongtalk was that much faster whether you used the optional static type system or not. Strongtalk's optimizing compiler completely ignored the types, and it made your program run not one iota faster to add them.

Update: see also Dave Griswold onStrongtalk's history:

... we had a type system and a compilation technology, which together were perfectly suited for a great production Smalltalk system, since they were independent of each other. This independence was critical, since the system would need to accept untyped as well as typed code, so that people could use the type system as much or as little as they wanted to, without impacting performance.

Ruby and other gems

I've had a number of conversations recently about Gemstone Smalltalk, largely in the wake of their announcement of support for my web framework, Seaside. It's complicated to explain Gemstone to people. It's not just an object database (though it is that), and it's not just a Smalltalk implementation (though it's that, too). The best thing I can compare it to is a Ruby on Rails deployment: not the framework, but the entire cluster of servers and software that goes into a large scale Rails app. Which is to say, perhaps, that Gemstone is best understood not as a piece of software but as an architecture.

At a high level, a typical Rails deployment looks like this: a cluster of servers supports one storage engine, several memory caches, and many worker processes. In Rails, the storage engine is always a relational database (usually MySQL), and sits on an especially hefty server by itself. Any number of other smaller, identical servers are each configured to run one memory cache (memcached) and 8-12 or so worker processes (Ruby interpreters running Rails and the Mongrel web server, generally just referred to as "mongrels").

The mongrels accept the web requests and run the actual application code. The objects inside these worker processes are live objects: they're sending and receiving messages, executing methods, changing state, and so on. They exist only inside the memory of a particular mongrel, for the duration of a single request that the mongrel is processing.

Many objects need to be persisted for longer than that, and these get written to and read from the storage engine - in Rails, using ActiveRecord. The storage engine is centralized (though it may be replicated to protect against failure), so that all of the worker processes see a consistent view of the data: if one of the mongrels modifies an object and commits that change to MySQL, the others will see that change the next time they need to load that object. The objects inside the storage engine are dead - they don't do anything until they're loaded into a worker process - but they're well preserved: they're kept on disk, not memory, so they'll survive a server reboot or other catastrophe.

Loading from and saving to the storage engine is relatively slow, and keeping objects there eats disk space, so the memory cache is an important third player in this game. A mongrel that's gone to the work of retrieving an object from MySQL might stash a copy in memcached for the other mongrels to retrieve, more quickly, if and when they need the same one. An object that's expensive to build - like a piece of complex HTML - but not important enough to save to disk might also be placed there for the convenience of the other workers on the same server. In Rails, the cache has to be managed carefully, so that you don't get out of sync with the consistent view of data maintained by the storage engine, but the work pays off with lower loads and faster response times. Objects in the cache are dead - usually marshalled into a meaningless string - and also transient, since the cache is purely in memory.

What about Gemstone? As it happens, the architecture is exactly the same: there's a single storage engine (called a "stone"), a memory cache on each server (the "shared page cache"), and any number of Smalltalk VM worker processes ("gems"). The gems handle the requests and run the code, and they stash objects in the page cache for speed and in the stone for persistence. The difference is, in Gemstone, these have all been designed from the ground up to work together as quickly and seamlessly as possible. In particular, this means two things:

1. Each part of the architecture uses exactly the same format to store the objects: whether it's a live object running in a gem, a cached object in the page cache, or a stored object on disk, the sequence of bytes is exactly the same. Unlike in Rails, where you have to be mapping and marshalling at every step, in Gemstone copying objects from storage to cache to worker process is pretty much just that - a simple byte copy. This makes it fast.

2. Objects are automatically kept in sync between each part of the system. The worker processes always load objects from the memory cache, because they can trust it to grab a recent copy from storage if needed. They also always save to the cache, because it will write the same change through to the storage without being asked. The gems also keep track of which objects have changed so that you don't have to, and will update the cache - and get updates from other gems back - automatically and transparently. The effect is as if all of your worker processes were running their objects inside a single, consistent and impossibly large chunk of persistent memory. This makes it easy.

To be extra clear, here's the mapping I'm trying to describe:

	Rails		Gemstone
	Provided By	Stores	Provided By	Stores
Storage Engine	MySQL	objects mapped to relational tables	"Stone" object store	Smalltalk objects
Memory Cache	memcached	objects marshalled to strings	Shared page cache	Smalltalk objects
Worker Process	MRI/Mongrel	Ruby objects	"Gem" Smalltalk VM	Smalltalk objects

So there you have it: Gemstone, it's like Rails, but faster and easier. If only it ran Ruby...

Don't Panic

So what happened was, I was at my house on Galiano Island with my shiny new iPhone and without, at the time, either high speed internet or EDGE coverage, and I thought "gee, wouldn't it be nice if...". And I did some hacking, and then I mentioned it to Patrick Collison who was sharing office space with us and he ignored my hacking and did a ton of his own, and even though I now have DSL and EDGE out there it *is* nice: all of Wikipedia, stored and searchable in 2GB of your iPhone's flash drive. Get it here.

It's not perfect yet - there's no images, just text, and the parser is pretty basic and doesn't know about tables and stuff, and clicking on links can be flaky and slow, and if you do happen to have a network around it's probably a better experience to just go to wikipedia.org, but: there's really nothing quite like holding the sum of human knowledge in the palm of your hand. Patrick, I owe you many drams of whiskey whenever you're back in town.

DNA as Code

Over the holidays I was chatting with my brother the biophysicist about his research. Roughly speaking, he is trying to create DNA sequences that encode molecular motors. I was trying to understand what it meant to hack DNA from a programmer's perspective. Today I read this, which is in a very similar spirit. Two interesting data points from our conversation: one, the code my brother is "writing" is a few kilobase long, and could be represented in well under one kB of binary data. Two, his edit/compile/run cycle is about three weeks long, although he can do a dozen or so in parallel.

I thought these numbers were impressively small, especially that you could produce a working motor from a few hundred bytes of information (try that in Autocad...). He thought of them as huge, because they made it infeasible to brute-force the design by generating all the random variations and seeing which ones worked.

I'm certainly glad it doesn't take me three weeks to do a new build...

Code as Screenplay

Giles Bowkett writes

Debugger support is like nail-biting support, or farting-in-public support. Its absence is a feature. You want to avoid supporting bad habits. If programmers have to break their bad habits, that's a good thing.

I have a confession to make: I bite my nails. That's a bad habit, and I readily admit it. I also use a debugger. That's not.

Let me explain. Giles' argument seems to rest on this point:

Debuggers are based on the idea that the code base has enough places bugs could happen that the work of locating the bug is involved enough to justify machine assistance. This is not true of well-tested code. It is not true of code you understand, either.

What Giles glosses over is how you come to understand the code in the first place. Nothing helps you understand code - whether you wrote it or someone else did - better than stepping through it in a debugger. Since Giles is a sometime screenwriter, maybe this analogy is appropriate: reading the code is like reading a screenplay. Writing tests is maybe like drawing storyboards (they help you visualize the final product). Using a debugger is like actually watching the damn movie. With a jog wheel so you can slow it down. And no matter how good a screenwriter you are, no matter how good your director's storyboards are, when it comes time to cut the film you're going to find out that you didn't understand the movie as well as you thought you did, and you're going to need to watch the footage, sometimes frame by frame, and modify the movie accordingly.

Programs are the same way. Writing tests and reading code show you your program the way you want it to be, but only a debugger shows you the way your program is. Maybe screenwriters sit around in bars in LA and talk about how real filmmakers just read scripts, and the movies themselves are a crutch - me, I guess I like crutches.

See also: Patrick Collison, Ben Matasar, and Slava Pestov.

Code generation in Smalltalk and Ruby

Neal Ford had a recent post about the difference between code-generation (he calls it "meta-programming", but that's an overloaded and ambiguous term) in Ruby and Smalltalk. The core of his point is this: in Ruby, code generation is done at runtime, which means that what gets checked into your source code repository is a high level statement like "has_many :foo", which then generates the code when it is executed. In Smalltalk, code generation is done at development time (triggered by some custom wizard-like extension to the IDE), and so the generated code itself is checked in and the intent, according to Neal, is lost (as a trade-off for other benefits, like the ability to take the generated code into consideration when doing refactorings and so on, whereas in Ruby that code is invisible to any static analysis).

This is a straw man: Smalltalkers understand the need to capture (and later modify) the intent as well as anyone else does. The solution is to make the generated code round-trippable. If you look at any real Smalltalk tools that generate code based on a custom tool (the SmaCC parser generator is a good example), it will preserve the settings from that tool, for example in a class comment, and the tool will let you inspect the intent, modify the intent, and regenerate the code.

To be concrete: any self-respecting Smalltalk tool that let you generate all the code associated with a "has_many" expression would annotate those methods with the "has_many" intent, in a way that the tools could understand, present to the user, and modify.

(James Robertson points out that ORM tools in Smalltalk tend not to use code generation anyway, but I don't think that really answers Neal's point.)

Moving

Just a quick note that I've moved this blog to a new platform (typepad) and a new URL (www.avibryant.com). If you were subscribed to the old one, you shouldn't have to do anything, because the feeds are redirected. However, although all of the old posts are imported, the old permalinks are currently broken. When I find the time over the next week I'll set up the mapping for them but for now, if you came here from a link to a specific post, I apologize.