This post originated from an RSS feed registered with Ruby Buzz
by Christopher Cyll.
Original Post: If You Can't Make It Fast, Make It Parallel
Feed Title: Topher Cyll
Feed URL: http://feeds.feedburner.com/cyll
Feed Description: I'm not too worried about it. Ruby and programming languages.
Building your own programming language is a lot of work, and you can’t do everything at once. Sometimes you know exactly how to make your language better, but other considerations take priority.
We know how to make our programming language Spin1 a heck of a lot faster, but working on its first killer app Skynet, is more important. Which brings me to a confession…
We’re no faster than Ruby 1.8
I love Ruby, but I consider it an established low water mark for language performance. Ruby is just fast enough to use for real work, but developers can and will complain about performance. As a language designer you really want to be at least a little faster than Ruby 1.8.2
Fear not! We built Spin for distributed programming. And once we had applications talking to applications over asynchronous messages, we started to want modules within those applications to communicate the same way.3
Instead of building objects that have methods, sometimes we built threads that respond to messages. Before we knew it our language was designed around lightweight threads and shared-nothing message passing.
Spin could be faster, but in the meantime, it’s got a saving grace.
An idle Skynet has 160 green threads
It spikes way higher than that while doing active work.4 All of those green threads are mapped to a smaller number of native threads. Unlike some other languages, Spin actually get faster every time Intel or AMD releases on new multi-core monster… if you run it on that new computer.
So our language isn’t a speed demon, but software written in it scales beautifully.5 It’s an interesting position to be in. Skynet completely pegs both cores of my Macbook Pro when starting, but it boots twice as fast as if we’d gone with a more conventional language design.
I can’t wait for Spin to be faster, but in the meantime it’s good enough that it’s parallel. When we improve our language performance, the threads running on every core get faster. And if numbers of cores grows faster than megahertz, well, then I’ll really be glad we went parallel.6
Spin is a horribly confusing codename for our language since there are so many other projects already using that name. We promise to rename it as soon as we have a million developers (or sooner ;-). ↩
Ever since Ruby 1.9, Ruby itself is now faster than Ruby 1.8. Go Ruby! ↩
More on our slide into distributed programming later. ↩
Virtually all of the 160 steady state green threads are in a wait state, so CPU consumption is minimal. And since green threads are relatively cheap, spinning up more isn’t a big deal either. ↩
Not to mention that IO is performed in specially allocated native threads, so you never accidentally block a UI update or working thread just because you’re reading a large file. ↩
Today, even a decent desktop has four cores. Starting in August you’ll be able to order a Mac Pro with twelve cores and SMT for 24 threads of execution. Imagine how much faster Spin would be on one of those! ↩
Previous Topic
