On 26 October 2011 11:23, Dag Sverre Seljebotn
wrote:
> On 10/26/2011 11:45 AM, mark florisson wrote:
>>
>> On 26 October 2011 08:56, Stefan Behnel wrote:
>>>
>>> Greg Ewing, 26.10.2011 00:27:
Dag Sverre Seljebotn wrote:
> I'd gladly take a factor two (or even four) slowdown of
On 10/26/2011 12:29 PM, Dag Sverre Seljebotn wrote:
On 10/26/2011 11:45 AM, mark florisson wrote:
On 26 October 2011 08:56, Stefan Behnel wrote:
Greg Ewing, 26.10.2011 00:27:
Dag Sverre Seljebotn wrote:
I'd gladly take a factor two (or even four) slowdown of CPython
code any
day to get rid
On 10/26/2011 11:45 AM, mark florisson wrote:
On 26 October 2011 08:56, Stefan Behnel wrote:
Greg Ewing, 26.10.2011 00:27:
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 c
On 10/26/2011 11:45 AM, mark florisson wrote:
On 26 October 2011 08:56, Stefan Behnel wrote:
Greg Ewing, 26.10.2011 00:27:
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 c
On 26 October 2011 08:56, Stefan Behnel wrote:
> Greg Ewing, 26.10.2011 00:27:
>>
>> 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 speedu
Greg Ewing, 26.10.2011 00:27:
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 lockin
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
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
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 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 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 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 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
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 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
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 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
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 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
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
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 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 another thread to index
>>> it without lock contention and
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 another thread to index
>> it without lock contention and other general overhead.
>
> I don't think that's safe. You can'
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 another thread to index
>> it without lock contention and other general overhead.
>
> I don't think that's safe. You can'
mark florisson wrote:
These will by default not lock for operations to allow
e.g. one thread to iterate over the list and another thread to index
it without lock contention and other general overhead.
I don't think that's safe. You can't say "I'm not modifying
this, so I don't need to lock it"
25 matches
Mail list logo
