mark florisson, 24.10.2011 21:50:
This is in response to
http://groups.google.com/group/cython-users/browse_thread/thread/bcbc5fe0e329224f
and http://trac.cython.org/cython_trac/ticket/498 , and some of the
previous discussion on cython.parallel.
Basically I think we should have something more p
On 25 October 2011 05:47, Robert Bradshaw wrote:
> On Mon, Oct 24, 2011 at 2:52 PM, mark florisson
> wrote:
>> On 24 October 2011 22:03, Greg Ewing wrote:
>>> mark florisson wrote:
These will by default not lock for operations to allow
e.g. one thread to iterate over the list and
On 25 October 2011 08:33, Stefan Behnel wrote:
> mark florisson, 24.10.2011 21:50:
>>
>> This is in response to
>>
>> http://groups.google.com/group/cython-users/browse_thread/thread/bcbc5fe0e329224f
>> and http://trac.cython.org/cython_trac/ticket/498 , and some of the
>> previous discussion on c
mark florisson, 25.10.2011 11:11:
On 25 October 2011 08:33, Stefan Behnel wrote:
mark florisson, 24.10.2011 21:50:
This is in response to
http://groups.google.com/group/cython-users/browse_thread/thread/bcbc5fe0e329224f
and http://trac.cython.org/cython_trac/ticket/498 , and some of the
previ
On 10/25/2011 09:33 AM, Stefan Behnel wrote:
mark florisson, 24.10.2011 21:50:
This is in response to
http://groups.google.com/group/cython-users/browse_thread/thread/bcbc5fe0e329224f
and http://trac.cython.org/cython_trac/ticket/498 , and some of the
previous discussion on cython.parallel.
Ba
Dag Sverre Seljebotn, 25.10.2011 15:28:
On 10/25/2011 09:33 AM, Stefan Behnel wrote:
mark florisson, 24.10.2011 21:50:
All of this functionality should also get a sane C API (to be provided
by cython.h). You'd get a Cy_INCREF(obj, have_gil)/Cy_DECREF() etc.
Every class using this functionality
On 25 October 2011 12:22, Stefan Behnel wrote:
> mark florisson, 25.10.2011 11:11:
>>
>> On 25 October 2011 08:33, Stefan Behnel wrote:
>>>
>>> mark florisson, 24.10.2011 21:50:
This is in response to
http://groups.google.com/group/cython-users/browse_thread/thread/bcbc5fe
mark florisson, 25.10.2011 18:58:
On 25 October 2011 12:22, Stefan Behnel wrote:
mark florisson, 25.10.2011 11:11:
On 25 October 2011 08:33, Stefan Behnel wrote:
mark florisson, 24.10.2011 21:50:
What if we support acquisition counting for every instance of a cdef
class? In Python and Cython
On 25 October 2011 19:10, Stefan Behnel wrote:
> mark florisson, 25.10.2011 18:58:
>>
>> On 25 October 2011 12:22, Stefan Behnel wrote:
>>>
>>> mark florisson, 25.10.2011 11:11:
On 25 October 2011 08:33, Stefan Behnel wrote:
>
> mark florisson, 24.10.2011 21:50:
>>
>> Wha
On 10/25/2011 06:58 PM, mark florisson wrote:
On 25 October 2011 12:22, Stefan Behnel wrote:
The problem is not so much the INCREF (which is just an indirect add), it's
the DECREF, which contains a conditional jump based on an unknown external
value, that may trigger external code. That can kil
On 10/25/2011 09:01 PM, Dag Sverre Seljebotn wrote:
On 10/25/2011 06:58 PM, mark florisson wrote:
On 25 October 2011 12:22, Stefan Behnel wrote:
The problem is not so much the INCREF (which is just an indirect
add), it's
the DECREF, which contains a conditional jump based on an unknown
external
On 10/25/2011 08:45 PM, mark florisson wrote:
On 25 October 2011 19:10, Stefan Behnel wrote:
See? That's what I mean with language complexity. These things quickly turn
into an open can of worms. I don't think the language should handle any of
these. Message passing is up to libraries, for exam
On 25 October 2011 20:01, Dag Sverre Seljebotn
wrote:
> On 10/25/2011 06:58 PM, mark florisson wrote:
>>
>> On 25 October 2011 12:22, Stefan Behnel wrote:
>>>
>>> The problem is not so much the INCREF (which is just an indirect add),
>>> it's
>>> the DECREF, which contains a conditional jump base
On 25 October 2011 20:15, Dag Sverre Seljebotn
wrote:
> On 10/25/2011 08:45 PM, mark florisson wrote:
>>
>> On 25 October 2011 19:10, Stefan Behnel wrote:
>>>
>>> See? That's what I mean with language complexity. These things quickly
>>> turn
>>> into an open can of worms. I don't think the langu
Dag Sverre Seljebotn wrote:
I'd gladly take a factor two (or even four) slowdown of CPython code any
day to get rid of the GIL :-). The thing is, sometimes one has 48 cores
and consider a 10x speedup better than nothing...
Another thing to consider is that locking around refcount
changes may
15 matches
Mail list logo