added openmp for the MC Loop

My experience is that it's hard to anticipate which scheduling mechanism
will work better, and if you care one way or the other you will end up
tuning on the hardware you actually have.  Leaving it with some sensible
setting based on performance on a typical architecture, and allowing users
who know what they're doing to go in and change it, is probably the best
approach.  Most people will leave it alone, if they enable the OpenMP at
all.

Glad to see this implemented!

Rollin

On Wed, Dec 3, 2014 at 12:55 AM, Michael <notifications@github.com> wrote:

> In tardis/montecarlo.pyx:
>
> >  import numpy as np
> >  cimport numpy as np
> > -from astropy import constants
> > +from libc.stdlib cimport malloc, free
> > +from libc.stdio cimport printf
> > +
> > +from cython.parallel cimport parallel, prange, threadid
> > +cimport openmp
> > +
> > +cdef int num_threads
> > +openmp.omp_set_dynamic(1)
>
> Static schedule means: that iterations blocks are mapped statically to the
> execution threads in an RR fashion. The nice thing with static scheduling
> is that OpenMP run-time guarantees that if you have two separate loops with
> the same number of iterations and execute them with the same number of
> threads using static scheduling, then each thread will receive exactly the
> same iteration range in both parallel regions. But we don't need this
> feature, and we are better up with dynamic. Dynamic scheduling works on an
> FCFS basis.
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/tardis-sn/tardis/pull/202/files#r21218490>.
>



-- 
Dr. R. C. Thomas
Computational Cosmology Center
Lawrence Berkeley National Lab
1 Cyclotron Road Mail Stop 50B4206
Berkeley, California 94720-8151
510.486.4697