On 03/11/2011 08:20 AM, Stefan Behnel wrote:
Robert Bradshaw, 11.03.2011 01:46:
On Tue, Mar 8, 2011 at 11:16 AM, Francesc Alted
wrote:
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
> On a slightly higher level, are we just trying to use OpenMP from
> Cython, or are we trying to build it into the language? If the former,
> it may make sense to stick closer than one might otherwise be tempted
> in terms of API to the underlying C to leverage the existing
> documentation. A libr
Den 11.03.2011 01:46, skrev Robert Bradshaw:
On a slightly higher level, are we just trying to use OpenMP from
Cython, or are we trying to build it into the language?
OpenMP is a specification, not a particular implementation.
Implementation for Cython should either be compiler pragmas or a li
Dag Sverre Seljebotn, 11.03.2011 08:56:
Basically, I'm +1 to anything that can make me
pretend the GIL doesn't exist, even if it comes with a 2x performance hit:
Because that will make me write parallell code (which I can't be bothered
to do in Cython currently), and I have 4 cores on the laptop
Sturla Molden, 11.03.2011 12:13:
OpenMP is a specification, not a particular implementation. Implementation
for Cython should either be compiler pragmas or a library.
I'd like it to be a library, as it should also be usable from Python. I
have made some progress on the library route, depending o
On 03/11/2011 12:37 PM, Stefan Behnel wrote:
Dag Sverre Seljebotn, 11.03.2011 08:56:
Basically, I'm +1 to anything that can make me
pretend the GIL doesn't exist, even if it comes with a 2x performance
hit:
Because that will make me write parallell code (which I can't be
bothered
to do in Cyt
Hi,
ticket 654 describes a code generation problem where the arguments to a
cdef function are not being evaluated in the order they are written down in
the code.
http://trac.cython.org/cython_trac/ticket/654
This introduces problems when the arguments have side effects or are not
simple, e.
Den 11.03.2011 11:42, skrev Matej Laitl:
#pragma omp parallel for private(var1) reduction(+:var2) schedule(guided)
for i in range(n):
do_work(i)
I do like this, as it is valid Python and can be turned on/off with a
compiler flag to Cython.
Issues to warn about:
- We cannot jump out of
2011/3/11 Stefan Behnel :
> Hi,
>
> ticket 654 describes a code generation problem where the arguments to a cdef
> function are not being evaluated in the order they are written down in the
> code.
>
> http://trac.cython.org/cython_trac/ticket/654
>
> This introduces problems when the arguments hav
Vitja Makarov, 11.03.2011 15:04:
2011/3/11 Stefan Behnel:
Personally, I think it would be nice to keep up Python's semantics, but when
I implemented this I broke quite some code in Sage (you may have noticed
that the sage-build project in Hudson has been red for a while). There are
things in C a
Den 11.03.2011 12:43, skrev Stefan Behnel:
What's your use actual case for this?
Just avoid different syntax inside and outside nogil-blocks. I like this
style
with openmp.critical:
better than what is currently legal with nogil:
openmp.critical()
if 1:
openmp.end_criti
Sturla Molden, 11.03.2011 15:19:
Den 11.03.2011 12:43, skrev Stefan Behnel:
What's your use actual case for this?
Just avoid different syntax inside and outside nogil-blocks. I like this style
with openmp.critical:
better than what is currently legal with nogil:
openmp.critical()
if
On 11 March 2011 09:45, Stefan Behnel wrote:
> Hi,
>
> ticket 654 describes a code generation problem where the arguments to a cdef
> function are not being evaluated in the order they are written down in the
> code.
>
> http://trac.cython.org/cython_trac/ticket/654
>
> This introduces problems wh
Stefan Behnel, 11.03.2011 15:08:
Vitja Makarov, 11.03.2011 15:04:
2011/3/11 Stefan Behnel:
Personally, I think it would be nice to keep up Python's semantics, but
when
I implemented this I broke quite some code in Sage (you may have noticed
that the sage-build project in Hudson has been red for
A Friday 11 March 2011 11:42:26 Matej Laitl escrigué:
> I'm strongly for implementing thin and low-level support for OpenMP
> at the first place instead of (ab?)using it to implement high-level
> threading API.
My opinion on this continues to be -1. I'm afraid that difficult access
to OpenMP on
On Fri, Mar 11, 2011 at 9:36 AM, Stefan Behnel wrote:
> Stefan Behnel, 11.03.2011 15:08:
>>
>> Vitja Makarov, 11.03.2011 15:04:
>>>
>>> 2011/3/11 Stefan Behnel:
Personally, I think it would be nice to keep up Python's semantics, but
when
I implemented this I broke quite some co
Stefan Behnel wrote:
This introduces problems when the arguments have side effects or are not
simple, e.g.
f(g(a), a.x, h(a))
>
What do you think about this?
I think it's a bad idea to write code that relies on the order
of evaluation like this. If the order matters, it's better to
be
Stefan Behnel wrote:
To be a little clearer here, it's a problem in C for example with struct
values. Copying them by value into a temp variable can be expensive,
potentially twice as expensive as simply passing them into the function
normally.
What are you actually proposing to do here? Any
The free C/C++ compiler in Windows SDK supports OpenMP. This is the
system C compiler on Windows.
Visual C++ Express is an IDE for beginners and hobbyists.
OpenMP on GCC is the same on Windows as on any other platform.
Sturla
A Friday 11 March 2011 11:42:26 Matej Laitl escrigué:
I'm stro
19 matches
Mail list logo
