On Mon, Feb 28, 2011 at 10:20:33PM +0100, jeremy rosen wrote: > Hello everybody > > At FOSDEM we did some work to use the OpenMP framework. I have > continued working on it since and these are my conclusions
> A non-scientific measure showed a reduction of the average AI turn on > a AI vs AI game of 8% on my 4core HT computer. So this is not > neglectable. Nice gain. > Thus, when compiling with GCC, enabling OMP is just a matter of adding > the -fopenmp flag and linking with -lgomp (which can also be used to > detect if openmp is available on the computer) I'll have a look at a OMP build flag for cmake later so it can be enabled in a more user friendly way. > Overall I recommend reading http://bisqwit.iki.fi/story/howto/openmp/ > which is a rather good tutorial. Quickly glanced over it and it looks interesting, will read it later. > Once a suitable area for OpenMP is identified, the tricky part is to > understand clearly what happens in the code that we are handling. The > reason it took me so long to integrate OpenMP was that I hadn't > realized that reading an image meant writing it in the cache, and thus > the image cache had to be protected. Once that was figured out, adding > criticall section around the variable access was easy. Same thing with > SDL surfaces that need to be protected because they are ref-counted. Since threading in general is tricky, I wonder how easy will it be to accidently break OMP due to seemingly unrelated changes? Would it make sense to document what code is depending on OMP and which preconditions it relies upon? -- Regards, Mark de Wever aka Mordante/SkeletonCrew _______________________________________________ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
