Now, this is a niche case. For “heavy lifting” applications (like most business batch applications, and even moderately un-thin clients), the performance limitations are in the way data is managed and handled. That’s where multithreaded applications are huge, and getting multithreaded capability for cheap is a major win.

This is also known as the mainframe model- dumb terminals connecting to a central server where all storage and most computation occurs. All that’s happened is that we’ve change the names (to protect the guilty) and slapped a layer of graphical gloss over the whole thing to obscure the outlines. That, and a steaming pile of hype.

Having been around this merry-go-round at least once already, let me tell you what comes next. People will discover, to their shock and horror, that centralized servers are single points of failure. They won’t go down often, but when they do go down, the outages will be system-wide. Some backhoe will cut the trunk lines to Google, and suddenly no one will be able to read their email, check their calendars, or (comming soon) use their office suite. Google has an extraordinary reliability and huge amount of redundency- so did the mainframes.

The other thing people will realize is that there is more storage, and more processing power, on the edges of the network than there is in the center. This has been true for at least 25 years (since the introduction of the PC), and arguably longer. The resources at the center are more efficiently used, it’s true. Which raises the question of wether these resources can be utilized, even if less efficiently? Can we push processing, or storage, out to the client?

Back in the eighties, this was called the “fat client” solution.

In either case, the problem of parallel execution remains. The CPU companies have, if effect, given up on single threaded performance. There will be clock speed improvements, but (unless and until we solve the power leakage problem) they’re be fewer and farther between than we’ve come to expect. Moores law never gaurenteed that clock speeds would double every two years. Just that the number of transistors on a chip would double.

Which means that if you want to improve the response time of a single process- of a single transaction, in web terms- you have to go multithreaded.

You also run into a problem when you have more processors than programs to run on them. If your web site is getting 100 hits at a time, and has 100 processors, this works- each processor deals with a single, unique transaction. But if you have 200 processors and 100 hits, you have two choices- either use multiple processors per transaction, or simply not use half your processing power. Since the number of threads are, more or less, doubling every generation, by ignoring half you threads it means your web site runs no faster on this generation of hardware than on last generation’s hardware. And what happens next generation, when you’re handed 400 processors?

You can ignore this, for the moment. Even single threaded, processors today provide a huge amount of computing power- esepcially compared to the bandwidth limitations of memory, disk, and internet access speeds. And, if your programming language is slow enough to start with, you can provide huge leaps in performance simply by fixing your language. But, sooner or later, multithreaded is going to happen.

I enjoyed the snippet of your presentation which I stuck around for, and really, the concept of pure functions as atoms of provable functionality (duh) has been stuck in my head since then.

I’m still chewing on it, which I think means you did enough to get your merit badge in functional evangelism to the unwashed.

Please join the unwashed masses interested in functional programming at lambda@ruby.mn

Thanks again for the presentation.