On Sun, Mar 11, 2012 at 9:09 AM, mark florisson <markflorisso...@gmail.com> wrote: > On 11 March 2012 09:26, Lisandro Dalcin <dalc...@gmail.com> wrote: >> On 11 March 2012 09:46, mark florisson <markflorisso...@gmail.com> wrote: >>> On 10 March 2012 14:00, Stefan Behnel <stefan...@behnel.de> wrote: >>>> Lisandro Dalcin, 10.03.2012 10:51: >>>>> On 10 March 2012 03:41, mark florisson wrote: >>>>>> On 9 March 2012 14:22, Lisandro Dalcin wrote: >>>>>>> I'm basically experiencing the issues here: >>>>>>> http://www.cocoabuilder.com/archive/xcode/310299-error-calling-builtin-expect-inside-omp-parallel-for.html >>>>>>> >>>>>>> Can you imagine any way to workaround it? >>>>>> >>>>>> What a lovely C compiler bug... Did you file a bug report with gcc or >>>>>> xcode? What version of gcc does Lion ship with? >>>>>> >>>>> >>>>> I'm using a Mac just by accident, no idea (nor motivation) to report >>>>> bugs to Apple. >>>>> >>>>> $ gcc --version >>>>> i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. >>>>> build 5658) (LLVM build 2336.9.00) >>>>> >>>>> Could that be the the bug is actually in the LLVM backend? >>>>> >>>>>> I suppose the macro would have to be disabled for OS X Lion inside >>>>>> parallel sections (there seems to be __APPLE__ and __OSX__, I don't >>>>>> know about detecting the OS X version), that's easy to do (undef and >>>>>> redefine to no-ops before parallel section and redefine it again after >>>>>> the section). I'll try fixing it during the sprints next week. >>>>> >>>>> Perhaps switching to use a "omp_likely"/"omp_unlikely" macros inside >>>>> OpenMP blocks would be nicer than defining/undefining? >>>> >>>> Could that be coded into the macro or would it require to change the >>>> generated code? But at least it sounds like it would not impact code in >>>> functions that are being called from within the OpenMP blocks, would it? >>>> Just the code straight inside the block. A work-around could still have a >>>> substantial impact if it requires changes to the generated code. >>> >>> Yeah, that's why I suggested the undef/re-def approach around OpenMP >>> blocks. It's some code bloat, but only for the C preprocessor, so it >>> should be fine. >>> >> >> I still feel bad about this. What about just disabling branch >> prediction if OpenMP is ever used? Or perhaps just protect the >> definitions of likely/unlikely with some guard, such as users can >> disable them using a -D definition? >> > > Why? That would disable all compiler optimizations in all code that > could be gotten through the hints, due to a stupid C compiler bug when > using cython.parallel. It would be better to do an easy fix, a nasty > workaround for a nasty bug, but it shouldn't slow down other code. The > only problem with it is a couple of extra bytes in your .c file, and > the fact that it makes us feel less fuzzy inside because we realize > our world isn't what we want it to be.
+1 _______________________________________________ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
