On Wed, Sep 26, 2012 at 2:25 PM, Florian Philipp <[email protected]> wrote: > Am 25.09.2012 17:01, schrieb Michael Mol: >> On Tue, Sep 25, 2012 at 10:42 AM, James <[email protected]> wrote: >>> Hello, >>> >>> background: >>> It seems there is a major push now to put openmp: >>> [1,2] into embedded systems [3]. >>> >>> So I looked at these [4] packages to find something >>> interesting to look deeper into related to openMP. >>> >>> Blender immediately jumped out at me as a good example, >>> cause an old friend Ken Hughes is, imho, one of the >>> world's most amazing C programmers, and a stalwart at >>> the blender project. >>> >>> >>> OK, here's the question, I went to emerge blender >>> and found that the openmp flag is already set. {?} >>> Yet I looked everywhere and did not see the openmp flag >>> set (/etc/make.conf, /etc/portage/package.use) >>> so where is it getting set on my AMD workstation? >>> >>> [ebuild N ] media-gfx/blender-2.49b-r2 USE="ffmpeg >>> nls ogg openmp -blender-game -openal -verse" >>> >>> I feel like I should know (profiles etc) but, I'm a little >>> bit brain_dead this am, so any help is appreciated. >> >> Packages can choose to have USE flags enabled or disabled for them by >> default. So blender likely has openmp enabled by default, without that >> affecting any other packages. >> >>> >>> OH, anyone is encouraged to "chime in" about openmp >>> and your thoughts as to it's viability and usefulness. >>> Do you believe it will become a core technology, >>> embedded into GCC? Used widely? >> >> If you can use it, use it. OpenMP is little more than a set of >> extensions to C (and C++) which allows the normally-scalar language to >> do some things in a parallel fashion without resorting to the costs of >> multithreading. This is good, because vector instructions have been >> available in x86 since MMX came out, and improvements to the vector >> instructions available to x86 still goes on. >> > > I guess this is just poorly phrased but to clarify: OpenMP *does* use > multithreading and nothing else. It does not, in any way, make more use > of vector instructions than GCC without -fopenmp. I guess what you mean > is avoiding the costs of *manual* multithreading using POSIX threads and > the like.
Fair point. > > If you want to use vector instructions for your own code, you should > look into compiler intrinsics (i.e. vector instructions as built-in C > functions). > http://ds9a.nl/gcc-simd/ Personally, I don't like compiler intrinsics; they're specific to given compilers. I've tended to write code which is supposed to compile on multiple compilers. (There's a world outside GCC...) > And, just to nit-pick: OpenMP also works for Fortran. True; this slipped my mind. :) > >> Related are CUDA and OpenCL, which are two other systems for >> parallelizing code. CUDA assumes you have access to an nVidia GPU (and >> have a CUDA-enabled driver installed). OpenCL is a big more generic, >> and supports dispatching to CUDA, CPU vector instructions or even >> thread pools. >> >> Personally, my recommendation is to enable everything you can get >> working (be it, OpenMP, CUDA or OpenCL); vector processing is going to >> be generally more efficient than scalar processing. You don't need to >> worry about which is better unless you're a software developer. (And >> if you're a software developer, go study up on their differences; >> tradeoffs happen.) >> > > +1 > > By the way: Did anyone get good results out of dev-util/intel-ocl-sdk > for OpenCL? Some time ago I tested it with a package that supported both > OpenMP and OpenCL (not sure which) and OpenCL didn't really make an > impact on my Core i5. Haven't tried it, no. I've got a Radeon 6870, and I can only have one OpenCL driver loaded at a time. (IBM has a middleman driver which supports dispatching to multiple backends, but I believe its a for-pay package.) -- :wq
