Parallelization on muli-CPU hardware?

[Nicolas Lehuen]

<exarkun at divmod.com> a écrit dans le message de news:mailman.4747.1097588259.5135.python-list at python.org...
> > Plus, the benchmarks is highly questionable. Compare a single threaded =
> > CPU intensive program with a multi-threaded CPU intensive program, the =
> > single threaded program wins. Now compare IO intensive (especially =
> > network IO) programs, the multi-threaded program wins. Granted, you can =
> > built high performing asynchronous frameworks (Twisted or medusa come to =
> > mind), but sooner or later you'll have to use threads (see the DB =
> > adapter for Twisted).
> 
>   Uh, no.  Threads are useful for supporting libraries with blocking APIs.  Nothing about database access requires threads.  Twisted uses threads DB-API 2.0 specifies a blocking API, and it is useful to support DB-API 2.0 modules.
> 
>   Several SQL modules provide an asynchronous API which can be used without threads.
> 
>   When it comes to network-bound tasks, single-threaded wins the performance contest.
> 
>   Jp

OK, how many SQL modules with an asynchronous API in Python ?

You are perfectly right. "Threads are useful for supporting libraries with blocking APIs.". Blocking APIs are way more current in Python and other languages than asynchronous APIs.

Many people (including me) find it more easy to write and debug synchronous code than asynchronous bug. As I've wrote elsewhere, building a language is about bringing a service to developers. So either we make it easy to write asynchronous code (e.g. include Twister's Deferred in the stdlib) and add functionalities to debuggers to be able to track asynchronous code (because, well, the basic programming model in a debugger is synchronous call stacks), or we build a better multi-threading support in Python. Or we could stick back to assembly code, use "jump" all over the place and forget about building fancy languages.

Regards,
Nicolas