Lambda the Ultimate

See also last month's LtU post about the Sun/IBM/Cray initiative to develop a highly concurrent intermediate language.

I bet they have great success with it :-)

PVR - I assume you refer to the Sun/IBM/Cray VM project? If so have you contacted anyone over there, such as Guy Steele? Do they know about SEAM?

The problem really is preemption and real parallelism, where cache effects like preemption in the middle of a cache-sensitive operation or invalidation of cache lines dues to cache coherency issues often reduce the effectiveness of fully shared address space execution context (threads). There is a rise in popularity in the use of thread-local storage, for this very reason, and many results show that an hybrid architecture employing partially shared address space execution contexts (threads using TLS or Unix-style processes using shared memory), often one or two maximum per available CPU, each running an event-driven processing, provide the highest throughput.

Again, nothing prevents you in such an architecture of using continuations in your event handlers. There isn't very many advantages of putting the state either in explicit variables or on the stack, for either approach.

The last paragraph of section 5 is particularly misguided, IMHO. SEDA is well known to have rather severe design defects, for example using too many queuing operations and context switching. They say that the event model is "deeply tied" to creating many temporary objects and relying heavily on garbage collection, which is blatantly false. The main product of the company where I work (http://open.nit.ca/) is event driven and has no such requirements, being written in C++ with explicit memory management. If you think a CPU pipeline stall is a problem, consider the effect that having your thread preempted has on the cache. With the ever larger gap between CPU speeds and memory speed, I'd rather stall a pipeline than do a cold cache memory load!

In section 6, they misguide the reader, mentioning Ousterhout recommends threads for true concurrency and saying that this is the case for their target space, but they used cooperative multithreading that is specifically not true concurrency (it cannot use multiple processors).

Their conclusion saying that threads can have similar or better performance is simply not true. If they would have picked a better event driven system, this would have been very different. For example, http://www.cs.princeton.edu/~yruan/debox/debox.pdf shows further improvements on Flash, and Haboob is mentioned, while not incorporated in the graphed results, as having a mean latency 70-500 times greater than that of their version of Flash (last paragraph of section 8).

Where threads break down is when trying to apply quality of service to incomming request/event streams. This is really only an issue under load and then it really matters. Under lite load you can do almost anything you want and it will work. But quality of service requires very smart logic be applied to queues and threading priorities and limiting CPU usage. I don't think QOS can be addressed with threads and our very simple OS schedulers. If thread scheduling could be pluggable, maybe you could do better.

One model doesn't really fit all. I think threading is more general because it allows synchronous code, preemption, and priority. Yet events are necessary for some applications as well.

I am working to combine them both in the system i am working on. After going all threads and all events in the past, it's not so easy.

Can you provide a couple of references?

Works for us.

Sorry for the confusion, I was referring to the beginning of the discussion (although it's probably true of the Sun/IBM/Cray project as well).

I don't know if preemption is documented anywhere in particular, but it is fundamental.

That's right, real men program in Emacs Lisp!

http://www.cs.princeton.edu/~vivek/flash/

It's somewhat old, and I remember some other papers describing further improvements (of rather low-level scope, like switching from mincore() to a non-blocking variant of sendfile(), or something like that), but it's still much faster than Haboob, SEDA's web server. While they both use an event-driven architecture, they are still rather different and perform at very different levels too.

I find it rather "handy" for the "Why Events Are a Bad Idea" paper to mention Flash as a similar design (which it isn't that much) and then use the "equivalent" Haboob, which has much more shoddy performance, making it not that equivalent after all!

I will give this to todd, event-driven system are easily prone to latency problems, making them a not-so-great idea for many realtime systems. Basically, it's a matter of latency vs throughput, threads providing lower latency and events providing higher throughput.

I think that in CS, too often absolutist statements are made, attempting to distill some ultimate abstraction ("pure this" and "pure that", for example "purely object-oriented" or "pure functional"). Every so often, you see CS persons demonstrate how every single computing problem can be transformed into a caching problem, or an indexing problem or a sorting problem, depending of the field of interest of the author.

This isn't necessarily bad, but you have to realise that this does not apply 1:1 to reality! Academics were clamoring the superiority of microkernels before, saying that the then-current monolithic kernels were a big mistake. The implementers of monolithic kernel claimed in return that microkernels had poor performance and wouldn't really be usable. They were both right! Nowaday, we have modular kernels, that have the performance of monolithic kernels, but with the adaptability and reconfigurability of microkernels. I remember older versions of Windows NT, when some academics were seeing confirmation of their ideas in it (it had a more or less pure microkernel), and their dismay when NT 4.0 moved graphic drivers into the kernel. It wasn't "pure" anymore, but it was now "usable", which has a bit more value in the real world, IMHO.

You see also the phenomenon at an ideological level. For example, RMS (Richard Stallman) and the free software and open source movements. He's quite extremist about his ideas, and they are good ideas, but he's horrible to work with, he's too "pure". But it gives others, more sensible people, some exposure to the idea, and it turns out to change the world in a good way. You probably wouldn't absolutely want RMS to have his full way, but you want some balance between the old oppression of closed source and the nirvana of free software.

Equilibrium, that's the key.

http://www.cs.nyu.edu/rgrimm/teaching/fa03-web/091603.pdf http://www.cs.nyu.edu/rgrimm/teaching/readings/events-threads.pdf

From a hobbyist or academic point of view however, it can be fun to run with a particular ideology or framework with as far as it can go. I think this is why Haskell, and other similar "pure" languages are not really popular in the industry, because they are not watered down enough for general consumption. But maybe I'm wrong.

Maybe not for webservers and similar highly concurrent applications, but I've come to love cooperative threads for other types of applications. In video games, for example, you have a lot of things going on at once, but you need them all to sync up, so cooperative multitasking is a spectacular win.

James Hague: of course! I do a bit of video games myself (http://quadra.sourceforge.net for a particularly bad example), but when I hear "concurrent", I don't want to see "non-blocking", I want "concurrent".

I felt this clarification was important, because often, you'll see thread proponents saying that events are not concurrent, so if you have an SMP system, it cannot take advantage of it. But saying that, then saying that you can make everything just right by using cooperative threads like GNU Pth (that cannot take advantage of SMP system, precisely because they are not concurrent) is weaseling. Particularly as concurrency is what can make threads really difficult and why they picked cooperative threads.