I'm not an expert on this, but wouldn't it be more dependent on the platform
than python version? Perhaps it is Windows 7 that is very slow. Perhaps my
processor architecture. Not sure...
Here are some for 3.1.2x64
>>> import timeit
>>> timeit.timeit('Lock()', 'from threading import Lock')
1.4162
On Mon, 28 Jun 2010 16:46:41 -0700
Zac Burns wrote:
> In my experience it is far more expensive to allocate a lock in python then
> it is the types that use them. Here are some examples:
>
> >>> timeit.timeit('Lock()', 'from threading import Lock')
> 1.4449114807669048
>
> >>> timeit.timeit('dic
On 29 Jun, 05:11, Ryan Kelly wrote:
> Very interesting idea. Will it work if accessed through ctypes?
>
> ticker = ctypes.c_int.in_dll(ctypes.pythonapi,"_Py_Ticker")
> ticker.value = 0x7fff
>
> Or does ctypes muck with the GIL in a way that would break this idea?
>
>>> ctypes.pythonap
On Mon, 2010-06-28 at 19:45 -0700, sturlamolden wrote:
> > > Many lockless algorithms that I have looked at thusfar require a
> > > "Compare and Swap" operation. Does python have an equivalent to this?
> > > Is python high level enough that it has something better than this or
> > > it simply doesn
> > Many lockless algorithms that I have looked at thusfar require a
> > "Compare and Swap" operation. Does python have an equivalent to this?
> > Is python high level enough that it has something better than this or
> > it simply doesn't need it?
Python does have a GIL, and contrary to the title
> > Many lockless algorithms that I have looked at thusfar require a
> > "Compare and Swap" operation. Does python have an equivalent to this?
> > Is python high level enough that it has something better than this or
> > it simply doesn't need it?
Python does have a GIL, and contrary to the title
On Mon, 2010-06-28 at 18:27 -0700, Zac Burns wrote:
>
>
>
> I've managed to avoid locking in some cases by using
> dict.setdefault() as a kind of atomic test-and-set operation.
> It's not a full compare-and-swap but you could implement a
> simple locking sch
>
> Sure, but I think you're timing the wrong thing here. You would only
> allocate the lock relatively rarely - it's the overhead of *acquiring*
> the lock that's the real problem.
>
> r...@durian:~$ python -m timeit -s "from threading import Lock; l =
> Lock()" "l.acquire(); l.release()"
> 1
On Mon, 2010-06-28 at 16:46 -0700, Zac Burns wrote:
> In my experience it is far more expensive to allocate a lock in python
> then it is the types that use them. Here are some examples:
>
> >>> timeit.timeit('Lock()', 'from threading import Lock')
> 1.4449114807669048
>
> >>> timeit.timeit('dict
In my experience it is far more expensive to allocate a lock in python then
it is the types that use them. Here are some examples:
>>> timeit.timeit('Lock()', 'from threading import Lock')
1.4449114807669048
>>> timeit.timeit('dict()')
0.2821554294221187
>>> timeit.timeit('list()')
0.17358153222
10 matches
Mail list logo
