Greg Ewing, 09.03.2011 00:27:
Stefan Behnel wrote:
You *can* use Python references inside of nogil blocks, even if there's a
lot of stuff that you can't do with them, ... But you can access cdef
> attributes on them,
Strictly speaking it's not even safe to do that, unless
you know there's so
Stefan Behnel wrote:
You *can* use Python references inside of nogil blocks, even if there's
a lot of stuff that you can't do with them, ... But you can access cdef
> attributes on them,
Strictly speaking it's not even safe to do that, unless
you know there's some locking mechanism in effect
Den 08.03.2011 20:34, skrev Stefan Behnel:
... but that could be put into a builtin Cython library, right? At
least a couple of primitives, decorators, helpers, etc.
Yes.
Sturla
___
cython-devel mailing list
cython-devel@python.org
http://mail.pyth
A Tuesday 08 March 2011 20:24:51 Sturla Molden escrigué:
> Den 08.03.2011 20:13, skrev Francesc Alted:
> > And another problem that should be taken in account is that MS
> > Visual Studio does not offer OpenMP in the Express edition (the
> > free, as in beer, one).
>
> Which is why one should get
Vitja Makarov, 08.03.2011 20:12:
What is the right way to handle cdefed unbounds?
cdef object foo
print foo
cdef int foo
print foo
Fail with a compile error.
And how buffers and arrays should be handled? Now I'm skipping
buffers, arrays and structs.
There are some examples in test suite:
Sturla Molden, 08.03.2011 20:18:
We still need sychonization and scheduling primitives similar to those in
OpenMP. For example a special 'range' function that will share the workload
of a for loop. But this is not a major programming task.
... but that could be put into a builtin Cython library
Francesc Alted, 08.03.2011 20:16:
A Tuesday 08 March 2011 18:50:15 Stefan Behnel escrigué:
mark florisson, 08.03.2011 18:00:
What I meant was that the
wrapper returned by the decorator would have to call the closure
for every iteration, which introduces function call overhead.
[...]
I guess w
Den 08.03.2011 20:13, skrev Francesc Alted:
And another problem that should be taken in account is that MS Visual
Studio does not offer OpenMP in the Express edition (the free, as in
beer, one).
Which is why one should get the Windows 7 SDK instead :-)
As I see this, if we could stick using j
Den 08.03.2011 18:50, skrev Stefan Behnel:
Note that the queue is only needed to tell the thread what to work on.
A lot of things can be shared over the closure. So the queue may not
even be required in many cases.
Instead of putting a "#pragma omp parallel for" over the for loop, we
put the
A Tuesday 08 March 2011 18:50:15 Stefan Behnel escrigué:
> mark florisson, 08.03.2011 18:00:
> > What I meant was that the
> > wrapper returned by the decorator would have to call the closure
> > for every iteration, which introduces function call overhead.
> >
> >[...]
> >
> > I guess we just have
A Tuesday 08 March 2011 17:38:46 Sturla Molden escrigué:
> But should we care if this is implemented with OpenMP or Python
> threads? It's just an implementation detail in the library, not
> visible to the user.
>
> Also I am not against OpenMP, I use it all the time in Fortran :-)
>
> Another pr
What is the right way to handle cdefed unbounds?
cdef object foo
print foo
cdef int foo
print foo
And how buffers and arrays should be handled? Now I'm skipping
buffers, arrays and structs.
There are some examples in test suite:
...
Apologies for the OT post, but a quick FYI: I've been using openmp
with cython pretty extensively, usually wrapped in static inline or
template functions in a separate header. However, I've been hindered
by a strange bug that seems to appear when python loads gomp, gcc's
openmp implementation (htt
mark florisson, 08.03.2011 18:00:
What I meant was that the
wrapper returned by the decorator would have to call the closure for
every iteration, which introduces function call overhead.
[...]
I guess we just have to establish what we want to do: do we
want to support code with Python objects (an
Den 08.03.2011 18:00, skrev mark florisson:
Sure, that's not what I was hinting at. What I meant was that the
wrapper returned by the decorator would have to call the closure for
every iteration, which introduces function call overhead.
OpenMP does this too, in addition to work-scheduling overh
Sturla Molden, 08.03.2011 17:50:
Den 08.03.2011 17:04, skrev Stefan Behnel:
Could you elaborate what you are referring to here?
Nothing, except my own ignorance :-)
Now that we've settled that... ;)
What about writing up a little "parallel computing with Cython closures"
tutorial in the Wi
Den 08.03.2011 17:33, skrev mark florisson:
With OpenMP code, exactly how common are exceptions and error handling?
Error handling is always needed, but OpenMP does not help with this.
One can use an integer variable as error flag, and use an atomic write
in case of error.
Sturla
__
On 8 March 2011 17:38, Sturla Molden wrote:
> Den 08.03.2011 17:10, skrev mark florisson:
>>
>> But how useful is it to parallelize CPU-bound code while holding GIL?
>> Or do you mean to run the CPU-intensive section in a 'with nogil'
>> block and when you need to do locking, or when you need to d
Den 08.03.2011 17:04, skrev Stefan Behnel:
Could you elaborate what you are referring to here?
Nothing, except my own ignorance :-)
As for OpenMP I'd like to add that closures in Cython/Python more
cleanly map to Apple's "grand central dispatch" than OpenMP.
Yet a third way to easy parallel
Den 08.03.2011 17:10, skrev mark florisson:
But how useful is it to parallelize CPU-bound code while holding GIL?
Or do you mean to run the CPU-intensive section in a 'with nogil'
block and when you need to do locking, or when you need to deal with
Python objects you reaqcuire the GIL?
The Python
On 8 March 2011 16:28, Dag Sverre Seljebotn wrote:
> On 03/08/2011 11:34 AM, mark florisson wrote:
>>
>> I'd like to implement OpenMP support for Cython. Looking at
>
> Great news! It looks like this will be a topic on the coming workshop, with
> Francesc coming as well (but nothing wrong with get
mark florisson, 08.03.2011 17:10:
But how useful is it to parallelize CPU-bound code while holding GIL?
Or do you mean to run the CPU-intensive section in a 'with nogil'
block and when you need to do locking, or when you need to deal with
Python objects you reaqcuire the GIL?
You don't need the
On 8 March 2011 16:10, Sturla Molden wrote:
> Den 08.03.2011 11:34, skrev mark florisson:
>>
>> However, considering that OpenMP has quite a few constructs,
>
> No, OpenMP has very few contructs, not quite a few. And most of them are not
> needed, nor wanted, because the functionality is covered b
Sturla Molden, 08.03.2011 16:10:
once Cython has closures working properly.
Could you elaborate what you are referring to here?
Cython does have closure support. Maybe you are missing closures for cdef
functions? Or is it block level closures that you want? That could be done
as well, just l
Den 08.03.2011 11:34, skrev mark florisson:
However, considering that OpenMP has quite a few constructs,
No, OpenMP has very few contructs, not quite a few. And most of them are
not needed, nor wanted, because the functionality is covered by the
Python language (such as scoping rules).
I.e.
Reposting this, seems it got lost in cyber space.
Sturla
Den 8. mars 2011 kl. 16.10 skrev Sturla Molden :
Den 08.03.2011 11:34, skrev mark florisson:
However, considering that OpenMP has quite a few constructs,
No, OpenMP has very few contructs, not quite a few. And most of them
are not
On 03/08/2011 11:34 AM, mark florisson wrote:
I'd like to implement OpenMP support for Cython. Looking at
Great news! It looks like this will be a topic on the coming workshop,
with Francesc coming as well (but nothing wrong with getting started
before then).
(And please speak up if you are
Den 08.03.2011 11:34, skrev mark florisson:
What do you guys think?
Make Cython fully support closures, then we can easily implement our own
"OpenMP" using Python threads. No change to the compiler is needed. You
might not realise this at first, but OpenMP is just a way of
implementing closu
Den 08.03.2011 11:34, skrev mark florisson:
What do you guys think?
Make Cython fully support closures, then we can easily implement our own
"OpenMP" using Python threads. No change to the compiler is needed. You
might not realise this at first, but OpenMP is just a way of
implementing closu
Den 08.03.2011 11:34, skrev mark florisson:
could be written
for i in openmp.prange(..., firstprivate=('a', 'b'), reduction='+:result'):
...
How would you deal with name mangling, aliases, unboxing of numpy
arrays, etc.?
Sturla
___
I'd like to implement OpenMP support for Cython. Looking at
http://wiki.cython.org/enhancements/openmp I agree a close
1:1 mapping would be nice. It would probably make sense to start with
support for 'nogil' sections because GIL-holding
sections would be hard to deal with considering all the 'goto
Vitja Makarov, 08.03.2011 11:01:
Hi!
Here is example code:
def foo(seq):
cdef int x
return any(x for x in seq)
Here inner x have type int, how does cdef affects nested scope?
Is that correct?
Yes, that's intended. Otherwise there'd be no way to assign types to
variables used in gene
Hi!
Here is example code:
def foo(seq):
cdef int x
return any(x for x in seq)
Here inner x have type int, how does cdef affects nested scope?
Is that correct?
--
vitja.
___
cython-devel mailing list
cython-devel@python.org
http://mail.python.or
33 matches
Mail list logo
