On Wed, 19 Apr 2000, Christopher Petrilli wrote: > Salz, Rich [SalzR@CertCo.com] wrote: > > >This definitely slows Python down. If an object is known to be visible to > > >only one thread, then you can avoid the atomic inc/dec. But that leads to > > >madness :-) > > > > I would much rather see the language extended to indicate that a particular > > variable is "shared" across free-threaded interpreters. The hit of taking > > a mutex on every incref/decref is way bad. > > I wonder if the energy is better spent in a truly highly-optimized > implementation on the major platforms rather than trying to > conditional this. This may mean writing x86 assembler, and a few > others, Bill Tutt had a good point -- we can get a bunch of assembler fragments from the Linux kernel for atomic inc/dec. On specific compiler and processor architecture combinations, we could drop to assembly to provide an atomic dec/inc. For example, when we see we're using GCC on an x86 processor (whether FreeBSD or Linux), we can define atomic_inc() as an __asm fragment. > but then again, once written, it shouldn't need much > modification. I wonder if the conditional mutexing might be slower > because of the check and lack of focus on bringing the core > implementation up to speed. Won't work anyhow. See previous email. Cheers, -g -- Greg Stein, http://www.lyra.org/
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