Martin Blais <[EMAIL PROTECTED]> writes: > On 9/18/05, Guido van Rossum <[EMAIL PROTECTED]> wrote: >> On 9/17/05, John J Lee <[EMAIL PROTECTED]> wrote: >> > c. Since time is needed to iron out bugs (and perhaps also to reimplememt >> > some pieces of code "from scratch"), very early in the life of Python 3 >> > seems like the least-worst time to begin work on such a change. >> > >> > I realize that not all algorithms (nor all computational problems) scale >> > well to MP hardware. Is it feasible to usefully compile both MP and a UP >> > binaries from one Python source code base? >> >> That's an understatement. I expect that *most* problems (even most >> problems that we will be programming 10-20 years from now) get little >> benefit out of MP. > > Some are saying it won't be a matter of choice if we want to get the > software to run faster (you know, that "MORE MORE MORE!" thing we all > seem to suffer from):
People have been saying this for _years_, and it hasn't happened yet. This time around it's a bit more convincing, but I reserve the right to remain a touch skeptical. > http://www.gotw.ca/publications/concurrency-ddj.htm > The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software > Herb Sutter > March 2005 I was disappointed that that article (hey, it was the only issue of ddj I've ever actually bought! :) didn't consider any concurrency models other than shared memory threading. Cheers, mwh -- . <- the point your article -> . |------------------------- a long way ------------------------| -- Christophe Rhodes, ucam.chat _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
