Intel 80 core processor

Joe Gregorio

Everyone seems to be playing the "how are we going to program for lots of cores" game since Intel announced their experimental 80 core processor.

Maybe we can go forward by looking backward:

StartServers 80
Seriously! I have seen quite a few "threads aren't so bad" and "Python's GIL will doom it" posts since that announcement. People seem to forget that threads are were created as shared-memory lightweight processes. Why not just use *real* processes and let the OS do its job? I suspect that there will be more revolution and adaptation to multiprocessing in OS land than in language land. If you properly structure your applications, multi-processing is a great way to scale. Push your work on a queue, fire up a bunch of worker processes, and you are set. The operating system will take care of the rest, thank you very much, and now I don't have to debug an endless and complex system of locks, events, mutexes and the like. Hooray for multi-processing.

Posted by Jonathan LaCour on 2007-02-20

Maybe we can go forward by looking forward

Posted by Stelios Sfakianakis on 2007-02-21

Stelios,

You should read Jonathan's comment.

Posted by joe on 2007-02-21

Joe, I have read Jonathan's comment. So let's see what Erlang (for example) can offer: Now I don't know if Erlang ever becomes "mainstream" the way Java is but IMHO it offers all the features that a modern "concurrency-oriented" programming language should have (of course there are others, like Termite, Oz/Mozart,Comega, etc.)

Posted by Stelios Sfakianakis on 2007-02-21

For the record, Joe, I would love it if Python would grow first-class concurrency-oriented features. Erlang definitely beats Python in that regard, but claiming that Erlang is the first language to come up with such a model is not exactly correct. Honestly though, the situation isn't that bad as it is with Python. We already have the option of using Stackless if we want nice pickleable "tasklets" and Python 2.5 introduced basic coroutine support. PyPy has the ability to build a stackless Python as well. Given these building blocks, it seems reasonable to expect tha, at some point in the future Python will have a standardized set of concurrency-oriented functionality. At least, I hope so :)

Posted by Jonathan LaCour on 2007-02-21

Ah, the "throw more hardware at it" approach. That is indeed looking back; I remember in the 90's when one of my employers scaled a Web application by deploying a Sun E4000 for every 8 concurrent connections they needed to support.

People with stupid amounts of money notwithstanding, being able to support 80 concurrent connections* is not worth the money one of these beasts would cost, especially when you'd have to deploy them in pairs for redundancy.

The other concern is memory; processes will have more overhead, and that adds up pretty quickly. Sure, you can pile more on, but again, that's cash out of your pocket.

Erlang is certainly cool, but I join others in the hope that Python will get better at concurrency over time.

* Assuming you're using Apache and mod_worker; mod_event isn't ready for prime time, and may never be at the current rate. Lighttpd shows more promise here.

Posted by Mark Nottingham on 2007-02-22

Mark,

We've hit the wall as far as speed goes with Moore's Law. The only option at this point is to scale out, with the choices being spread between either 80 separate machines, or an 80 core processor; both ends of that spectrum fit in "throw more hardware at it", if you measure hardware by counting transistors. Your comment confuses me since you seem to be impugning the "throw more hardware" approach. Do you know a way to scale w/o throwing more hardware (transistors) at the problem?

Posted by joe on 2007-02-22

Yes. Give people better tools to work with. The way that most Web sites are served today is massively inefficient, and Apache is one of the main culprits. More soon. :)

Posted by Mark Nottingham on 2007-02-23

comments powered by Disqus