On Mon, 17 May 2010 10:11:03 PDT Bill Janssen <janssen at parc.com> wrote: > > I'd hate to let a fundamental flaw like this go through simply because > someone somewhere somewhen set a completely synthetic deadline. [...] > I've read through that issue (several times), and I have to say that I > wind up gnashing my teeth each time. Here's a fix that's rejected > because it "only" supports NT and POSIX threads. What percentage of > Python use cases do those two threading systems cover? Do we know? Well, if instead of gnashing your teeth, you had contributed to the issue, perhaps a patch would have been committed by now (or perhaps not, but who knows?). If you stay silent, you cannot assume that someone else will stand up for *your* opinion (and the fact that nobody did could indicate that not many people care about the issue, actually). > But right now, *everyone* has to be an expert just to use Python 2.x > effectively on modern multicore hardware Python works reasonably well on multicore hardware, especially if you don't run spinning loops and if you're not on Mac OS X. It may lose *at most* 10-20% performance compared to a single-core run but that's hardly the end of the world. And some workloads won't suffer any degradation. Besides, today's multicore CPUs have far better single-threaded performance than yesteryear's single-core CPUs, which makes the performance regression issue more theoretical than practical. In real life, you have very little risk of witnessing a performance regression when switching your Python from a single-core to a multicore machine. Regards Antoine.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4