Andy <[EMAIL PROTECTED]> writes: > >From what I read, I think that simply by making the package run in > several separate processes (web server, database server, Python > interpreter, etc.), and/or using multiple threads (which I will > anyway) the package should be able to use multiple CPUs.
Python threading doesn't support multiple CPU's because of the GIL. One approach to using your multiple cores is to embed a Python interpreter into a web server that runs in multiple processes, e.g. mod_python under Apache. Another is write your application as a separate process (e.g. as an FastCGI), then run multiple instances of it, connected to a concurrent web server. For what I'm currently doing, we're using lighthttpd as the http server and flup to connect to a set of Python FCGI's. For that matter, if your machine is just dual core, maybe it's ok to just run a single Python process, figuring that will run on one core and your database/httpd will run on the other one. However, you should figure the dual core situation won't last. Dual socket motherboards are fairly cheap these days, so we have a number of 4-core machines (two AMD dual core cpu's); Intel is already shipping quad core cpu's, so that puts 8 cores in a dual socket board (you can already buy Macintoshes configured that way). Higher end server motherboards have 4 sockets, so you have to expect that 16-core servers will be common pretty soon. So if you're working on a cpu-intensive application it's worth your while figuring out how to parallelize it. Note that the most careful concurrency stuff probably is in the database. Serious ones already know how to use multiple CPU's. -- http://mail.python.org/mailman/listinfo/python-list
