Re: [Cython] OpenMP support
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 problem with using OpenMP inside the compiler, as opposed to > an external library, is that it depends on a stabile ABI. If an ABI > change to Cython's generated C code is made, even a minor change, > OpenMP support will be broken. 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). And, in addition, we can expect problems with the OpenMP support in GCC for Win. As I see this, if we could stick using just Python threads, that would be our best bet for having a good adoption of future Cython parallel capabilities. In the case that we need dealing with a low-level C-API thread library, I'd use pthreads, with a possible light wrapper for using it from the Windows thread API on Windows machines. -- Francesc Alted ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] OpenMP support
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 to establish what we want to do: do we
> > want to support code with Python objects (and exceptions etc), or
> > just C code written in Cython?
>
> I like the approach that Sturla mentioned: using closures to
> implement worker threads. I think that's very pythonic. You could do
> something like this, for example:
>
> def worker():
> for item in queue:
> with nogil:
> do_stuff(item)
>
> queue.extend(work_items)
> start_threads(worker, count)
>
> 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.
I like this approach too. I suppose that you will need to annotate the
items so that they are not Python objects, no? Something like:
def worker():
cdef int item # tell that item is not a Python object!
for item in queue:
with nogil:
do_stuff(item)
queue.extend(work_items)
start_threads(worker, count)
--
Francesc Alted
___
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] OpenMP support
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 the Windows 7 SDK instead :-) Yeah, but this is largely obscure and not-well documented venue (clearly, Microsoft does not want people going that route). > > In the case that we need dealing with a low-level C-API > > thread library, I'd use pthreads, with a possible light wrapper for > > using it from the Windows thread API on Windows machines. > > pthreads are available on Windows as well. You mean http://sourceware.org/pthreads-win32/index.html? Uh, this is an important dependency, and the project seems not maintained anymore (no updates since 2006). Besides, its LGPL license does not seem a good choice for Cython. I was thinking in something more like: http://locklessinc.com/articles/pthreads_on_windows/ which seems simple enough (just a .h header), and it also comes with a sensible license (BSD). -- Francesc Alted ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] OpenMP support
A Tuesday 08 March 2011 18:02:13 Sturla Molden escrigué: > 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. Yeah. I use exactly this technique for tracking errors in threaded code. It is a bit messy, but when done correctly, it works great. -- Francesc Alted ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] OpenMP support
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 Windows platforms (lack of OpenMP in MSVC Express is, as I see it, a major showstopper, although perhaps GCC 4.x on Win is stable enough already, I don't know) would prevent of *true* portability of OpenMP-powered Cython programs. IMHO, going to the native Python threads + possibly new Cython syntax is a better venue. But I'd like to be proved that the problem for Win is not that grave... -- Francesc Alted ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] OpenMP support
A Saturday 12 March 2011 02:43:16 Sturla Molden escrigué: > The free C/C++ compiler in Windows SDK supports OpenMP. This is the > system C compiler on Windows. System compiler on Windows? I've never heard defining MSVC like this ;) > OpenMP on GCC is the same on Windows as on any other platform. In principle yes. But it is curious how the NumPy crew are still not being able to offer 64-bit binaries for Windows. Could not they use the 'system C compiler'? Could not they use the GCC 4.x for Win? My impression is that this compiler issue on Win is more hairy than you are suggesting. Not that I'm a big fan of Windows platforms, but we have to accept the fact that its user base is simply huge. -- Francesc Alted ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] "Cython's Users Guide"
2011/4/11 William Stein > Hi, > > I'm teaching Cython in my Sage course yet again, and noticed that > again there are some very confusing aspects of the Cython > documentation organization, which could probably be improved by a few > simple changes. > > 1. At http://cython.org/ there is a big link in the middle of the > page labeled "Cython Users Guide" which goes to > http://docs.cython.org/. However, http://docs.cython.org/ is *not* > the users guide -- it is "Cython’s Documentation". In fact, the > Users Guide is Chapter 3 of the documentation. > > 2. Looking at http://docs.cython.org, we see that Chapter 2 is > "Tutorials". But then looking down to Chapter 3 we see that it is > "Cython Users Guide". Of course, that's what one is after having just > clicked a link called "Cython Users Guide". So we click on "Cython > Users Guide" again. > > 3. We arrive at a page that again has "Tutorial" as Chapter 2. For > some reason this makes me feel even more confused. > > Recommend changes: > > 1. Change the link on the main page from "Cython Users Guide" to > "Documentation" or put a direct link into the Users Guide, or have > two links. > > 2. At http://docs.cython.org/ rename the "Cython Users Guide" to > "Users Guide", since it is obviously the Cython Users Guide at this > point and "Cython documentation" is in the upper left of the page > everywhere. > > 3. Possibly rename the tutorial in chapter 2 of the users guide to > something like "First Steps" or "Basic Tutorial" or something. > Yeah, that's something that we discussed in the past workshop in Munich (BTW, many thanks for providing the means for making this happen!). The basic idea is to completely remove the Chapter 3 (Cython Users Guide) by moving its parts to either Chapter 2 (Tutorials), or either to Chapter 4 (Reference Guide). During the meeting we agreed that the doc repository should be moved (and has been moved indeed) into the source repo, so that modifications that affect to code and docs can be put in the same commit/branch. Also, the wiki has a lot of information that can be better consolidated and integrated into the User's Guide. In fact, I already started some job in this direction and created a couple of pull requests during the workshop (that they have been already integrated). I plan to continue this job, but unfortunately I'm pretty busy lately, so I don't think I can progress a lot in the next weeks, so if anybody is interested in joining the effort for improving Cython's documentation, she will be very welcome indeed! -- Francesc Alted ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
[Cython] Cython 0.15rc2 and parallelization issue
Hi, I'm trying to take advantage of the exciting new parallelizing capabilities recently introduced in forthcoming 0.15 version, but I'm having a small difficulty. When I try to compile a small demo routing (attached), I'm getting this error: $ cython -a mandel.pyx Error compiling Cython file: ... for pix in prange(num_pixels, nogil=True, schedule="dynamic"): x = pix % width y = pix // width cr = begin_r + (x * span_r / (width + 1.0)) ci = begin_i + (y * span_i / (height + 1.0)) n = MandelbrotCalculate(cr, ci, maxiter) ^ mandel.pyx:50:31: Calling gil-requiring function not allowed without gil While trying to figure out why MandelbrotCalculate does require GIL, I replaced the "for prange", by a trivial "for range", and the annotated HTML source reveals that the only line in (light) yellow in this function is return n which is translated as: /* "mandel.pyx":22 * ti = 2*zr*zi + ci * zr, zi = tr, ti * return n # <<<<<<<<<<<<<< * * @cython.boundscheck(False) */ __pyx_r = __pyx_v_n; goto __pyx_L0; __pyx_r = 0; __pyx_L0:; __Pyx_RefNannyFinishContext(); return __pyx_r; } My guess is that this __Pyx_RefNannyFinishContext() call is preventing to call the routing from the parallel loop. Is that a bug, a limitation of current implementation or it is just that I'm missing something? Thanks, -- Francesc Alted mandel.pyx Description: Binary data ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Cython 0.15rc2 and parallelization issue
Sure. And I'm seeing a good speed-up on my 2-core machine indeed: Without parallel loop: real0m0.923s user0m0.875s sys 0m0.045s With parallel loop: real0m0.544s user0m0.876s sys 0m0.045s Which is pretty awesome, given the simplicity of Cython parallel implementation :) Thanks a lot Mark! 2011/8/3, mark florisson : > On 3 August 2011 14:18, Francesc Alted wrote: >> Hi, >> >> I'm trying to take advantage of the exciting new parallelizing >> capabilities recently introduced in forthcoming 0.15 version, but I'm >> having a small difficulty. When I try to compile a small demo routing >> (attached), I'm getting this error: >> >> $ cython -a mandel.pyx >> >> Error compiling Cython file: >> >> ... >> for pix in prange(num_pixels, nogil=True, schedule="dynamic"): >> x = pix % width >> y = pix // width >> cr = begin_r + (x * span_r / (width + 1.0)) >> ci = begin_i + (y * span_i / (height + 1.0)) >> n = MandelbrotCalculate(cr, ci, maxiter) >> ^ >> >> >> mandel.pyx:50:31: Calling gil-requiring function not allowed without gil >> >> While trying to figure out why MandelbrotCalculate does require GIL, I >> replaced the "for prange", by a trivial "for range", and the >> annotated HTML source reveals that the only line in (light) yellow in >> this function is >> >> return n >> >> which is translated as: >> >> /* "mandel.pyx":22 >> * ti = 2*zr*zi + ci >> * zr, zi = tr, ti >> * return n # <<<<<<<<<<<<<< >> * >> * @cython.boundscheck(False) >> */ >> __pyx_r = __pyx_v_n; >> goto __pyx_L0; >> >> __pyx_r = 0; >> __pyx_L0:; >> __Pyx_RefNannyFinishContext(); >> return __pyx_r; >> } >> >> My guess is that this __Pyx_RefNannyFinishContext() call is preventing >> to call the routing from the parallel loop. Is that a bug, a >> limitation of current implementation or it is just that I'm missing >> something? >> >> Thanks, >> >> -- >> Francesc Alted >> >> ___ >> cython-devel mailing list >> cython-devel@python.org >> http://mail.python.org/mailman/listinfo/cython-devel >> >> > > Hey Francesc! > > The problem is that you didn't declare MandelbrotCalculate 'nogil'. > You have to write > > cdef long MandelbrotCalculate(double cr, double ci, long maxiter) nogil: > ... > > That's all, and it will compile :) > > Cheers, > > Mark > ___ > cython-devel mailing list > cython-devel@python.org > http://mail.python.org/mailman/listinfo/cython-devel > -- Francesc Alted ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Cython 0.15rc2 and parallelization issue
Hey Mark, Sure. And I'm seeing a good speed-up on my 2-core machine indeed: Without parallel loop: real0m0.923s user0m0.875s sys 0m0.045s With parallel loop: real0m0.544s user0m0.876s sys 0m0.045s Which is pretty awesome, given the simplicity of the Cython parallel implementation :) Thanks a lot! 2011/8/3, mark florisson : > On 3 August 2011 14:18, Francesc Alted wrote: >> Hi, >> >> I'm trying to take advantage of the exciting new parallelizing >> capabilities recently introduced in forthcoming 0.15 version, but I'm >> having a small difficulty. When I try to compile a small demo routing >> (attached), I'm getting this error: >> >> $ cython -a mandel.pyx >> >> Error compiling Cython file: >> >> ... >> for pix in prange(num_pixels, nogil=True, schedule="dynamic"): >> x = pix % width >> y = pix // width >> cr = begin_r + (x * span_r / (width + 1.0)) >> ci = begin_i + (y * span_i / (height + 1.0)) >> n = MandelbrotCalculate(cr, ci, maxiter) >> ^ >> >> >> mandel.pyx:50:31: Calling gil-requiring function not allowed without gil >> >> While trying to figure out why MandelbrotCalculate does require GIL, I >> replaced the "for prange", by a trivial "for range", and the >> annotated HTML source reveals that the only line in (light) yellow in >> this function is >> >> return n >> >> which is translated as: >> >> /* "mandel.pyx":22 >> * ti = 2*zr*zi + ci >> * zr, zi = tr, ti >> * return n # <<<<<<<<<<<<<< >> * >> * @cython.boundscheck(False) >> */ >> __pyx_r = __pyx_v_n; >> goto __pyx_L0; >> >> __pyx_r = 0; >> __pyx_L0:; >> __Pyx_RefNannyFinishContext(); >> return __pyx_r; >> } >> >> My guess is that this __Pyx_RefNannyFinishContext() call is preventing >> to call the routing from the parallel loop. Is that a bug, a >> limitation of current implementation or it is just that I'm missing >> something? >> >> Thanks, >> >> -- >> Francesc Alted >> >> ___ >> cython-devel mailing list >> cython-devel@python.org >> http://mail.python.org/mailman/listinfo/cython-devel >> >> > > Hey Francesc! > > The problem is that you didn't declare MandelbrotCalculate 'nogil'. > You have to write > > cdef long MandelbrotCalculate(double cr, double ci, long maxiter) nogil: > ... > > That's all, and it will compile :) > > Cheers, > > Mark > ___ > cython-devel mailing list > cython-devel@python.org > http://mail.python.org/mailman/listinfo/cython-devel > -- Francesc Alted ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Cython 0.16
On the contrary, this is an excellent idea! El 29/10/2011 15:14, "mark florisson" va escriure: > Before we do a release, would anyone be opposed to a 'chunksize' > keyword argument to prange()? That may have significant performance > impacts. > > On 29 October 2011 12:41, mark florisson > wrote: > > Hm ok I'll disable them then. Pointers and some other dtypes are also > > not supported yet. As for the documentation, have you guys reviewed > > the documentation for fused types and memoryviews? For instance this > > is the introduction for memoryviews: > > > > " > > Typed memoryviews can be used for efficient access to buffers. It is > > similar to the current buffer support, but has more features and > > cleaner syntax. A memoryview can be used in any context (function > > parameters, module-level, cdef class attribute, etc) and can be > > obtained from any object that exposes the PEP 3118 buffer interface. > > " > > > > but I'm not sure this new functionality won't confuse users of the old > > buffer support. > > > > For fused types, cython.numeric only includes long, double and double > > complex. I think that should be changed to short, int, long, float, > > double, float complex and double complex. I was deliberately avoiding > > long long and long double as they (if not used as a base type) would > > be preferred over the others and may be a lot slower. But then, such > > usage wouldn't be very useful. Should I include them then? > > > > On 29 October 2011 10:30, Dag Sverre Seljebotn > > wrote: > >> Re b), it would be better to disable object dtypes (or emit a warning > about > >> the possible bug when using them) than to delay the release. Object > >> memoryviews are rare in the first place, and those who contain > themselves > >> should be very rare. > >> -- > >> Sent from my Android phone with K-9 Mail. Please excuse my brevity. > >> > >> Robert Bradshaw wrote: > >>> > >>> On Fri, Oct 28, 2011 at 1:59 PM, mark florisson > >>> wrote: > On 28 October 2011 21:55, Robert > >>> Bradshaw wrote: >> With Mark's fused > types > >>> and memory views going in, I think it's about >> time for a new > release. > >>> Thoughts? Anyone want to volunteer to take up >> the process? >> >> - > Robert > >>> >> > >>> > >>> >> cython-devel mailing list >> cython-devel@python.org >> > >>> >> http://mail.python.org/mailman/listinfo/cython-devel >> > > That'd > be cool. > >>> >> However there are a few outstanding issues: >a) the compiler is > somewhat > >>> >> slower (possible solution: lazy utility codes) Yeah, I forgot about > that. > >>> >> This should get resolved. Lazy utility codes (perhaps breaking them > up) > >>> >> would probably got us most of the way there. Long term, I really > like the > >>> >> "declaration caching" idea which could be used for users .pxd files > as well > >>> >> as internally. >b) there's a potential memory leak problem for > >>> >> memoryviews with > object dtype that contain themselves, this still > needs > >>> >> investigation. I think this could be mentioned as a caviat rather > than being > >>> >> a blocker. > As for a), Stefan mentioned code spending a lot of > time in sub. > >>> >> > Stefan, could you post the code for this that made Cython compile > very > > >>> >> slowly? > > >>> > >>> > cython-devel mailing list > cython-devel@python.org > > >>> > http://mail.python.org/mailman/listinfo/cython-devel > > >>> > >>> cython-devel mailing list cython-devel@python.org > >>> http://mail.python.org/mailman/listinfo/cython-devel > >> > >> ___ > >> cython-devel mailing list > >> cython-devel@python.org > >> http://mail.python.org/mailman/listinfo/cython-devel > >> > >> > > > ___ > cython-devel mailing list > cython-devel@python.org > http://mail.python.org/mailman/listinfo/cython-devel > ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Cython 0.16
2011/10/31 mark florisson : > We can now pass a chunksize argument into prange: > https://github.com/cython/cython/commit/5c3e77d3c70686fedd5619d7267728fc819b4c60 Cool. And very well documented too. Thank you! -- Francesc Alted ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Conditional import in pure Python mode
On 5/1/12 2:39 PM, mark florisson wrote: On 1 May 2012 20:22, Stefan Behnel wrote: Stefan Behnel, 01.05.2012 21:14: 2) Use math.pxd as an override for the math module. I'm not sure yet how that would best be made to work, but it shouldn't be all that complex. It already works (mostly?) for numpy.pxd, for example, although that's done explicitly in user code. BTW, I think it would be helpful to make the numpy.pxd cimport automatic as well whenever someone does "import numpy" and friends, right? Stefan ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel I'm not sure, it means the user has to have numpy development headers. But if the user is going to compile a NumPy application, it sounds like strange to me that she should not be required to install the NumPy development headers, right? -- Francesc Alted ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
