# [OpenMP] Variables de entorno (abierto)

## the incredible hurd

Con la actualización de GCC me he interesado por las posibles optimizaciones de OPENMP y sus variables de entorno:

https://computing.llnl.gov/tutorials/openMP/#EnvironmentVariables

Si alguien tiene más experiencia o puede aportar la suya, sería de agradecer.

He aquí las mías (para un dual core):

OMP_SCHEDULE=runtime

OMP_DYNAMIC=TRUE

OMP_NUM_THREADS=2

OMP_NESTED=TRUE

OMP_WAIT_POLICY=ACTIVE

OMP_MAX_ACTIVE_LEVELS=2

(Que nadie las use sin consultar toda la información disponible en Google).

imagemagick y gettext no se han quejado hasta ahora.

Las opciones por defecto de openmp son las peores posibles.

----------

## the incredible hurd

Introduzco una modificación:

 *man gcc wrote:*   

> 
> 
> -fopenmp
> 
>            Enable handling of OpenMP directives "#pragma omp" in C/C++ and "!$omp" in Fortran.  When -fopenmp is specified, the compiler generates parallel code according to the OpenMP Application Program Interface v2.5 <http://www.openmp.org/>.  This option implies -pthread, and thus is only supported on targets that have support for -pthread.
> ...

 

Por lo que se sigue la versión 2.5 del API, así pues, consultando http://openmp.org/wp/openmp-specifications/

Más en concreto:

http://www.openmp.org/mp-documents/spec25.pdf

OMP_SCHEDULE no tiene aún el valor runtime (ajustar los hilos en tiempo de ejecución), dado que ese valor es de la versión 3.0 creo. Por lo que lo he cambiado a dynamic (o el valor más cómodo).

Edito: Estas son las variables de entorno que tengo ahora:

OMP_SCHEDULE=dynamic

OMP_DYNAMIC=TRUE

OMP_NUM_THREADS=2

OMP_NESTED=TRUE

----------

## the incredible hurd

De acuerdo con OpenMP: overview and resource guide, OpenMP puede ser usado también en sistemas con un solo procesador (sin cores adicionales), mientras que se haga uso de la memoria compartida (shm).

Resulta extraño, porque las especificaciones POSIX indican que se usa mmap en lugar de shm (que pertenece a System V) y OpenMP depende de pthread (o Posix Thread), pero si shm hace el milagro posible pues se añade al kernel y a las USE de /etc/make.conf

Por tanto, mi suposición de crear un hilo por cada procesador o core, era incorrecta. Lo mejor es crear un hilo por cada -jX que se tenga en el MAKEOPTS de /etc/make.conf

Siendo OMP_NUM_THREADS=X

Por ejemplo, en un sistema monoprocesador, en el que tengo MAKEOPTS="-j2", puse OMP_NUM_THREADS=2 y eso fue lo único que me permitió compilar openoffice sin verme obligado a cambiar a -j1 en el MAKEOPTS, la diferencia es muy importante.

Con respecto a los -jX, no hay normas fijas ni nada que indique lo correcto, dado que depende de lo que se compile. Yo, personalmente, tengo como norma, añadir uno más al número de procesadores. Tengo -j3 en un dual core y -j2 en el monoprocesador, como ya he indicado.

OpenMP es un extraordinario avance en GCC. Todos los programas deberían incorporar su API.

Sigue resultándome curioso que no haya despertado mayor interés en la comunidad Gentoo.

----------

## gringo

 *Quote:*   

> Sigue resultándome curioso que no haya despertado mayor interés en la comunidad Gentoo.

 

imagino que despertará interés cuando lo incorporen mas programas, como tu mismo has dicho. 

Ahora mismo es completamente insuficiente.

 *Quote:*   

> eso fue lo único que me permitió compilar openoffice sin verme obligado a cambiar a -j1 en el MAKEOPTS, la diferencia es muy importante. 

 

sólo por si no lo sabías, para openoffice ( y los productos de mozilla) se puede añadir WANT_MP="true" al make.conf lo que habilitará la compilación en paralelo de mas de un hilo.

saluetes

----------

## the incredible hurd

 *gringo wrote:*   

> sólo por si no lo sabías, para openoffice ( y los productos de mozilla) se puede añadir WANT_MP="true" al make.conf lo que habilitará la compilación en paralelo de mas de un hilo.

 

Hablo de openoffice no por casualidad. WANT_MP (ya leí el hilo en su día, afortunadamente para mí) únicamente sirve para los productos de mozilla:

 *Quote:*   

> 
> 
> $ grep WANT_MP /usr/portage/*/*/*.ebuild
> 
> /usr/portage/app-office/mozilla-sunbird/mozilla-sunbird-0.9.ebuild:	[ "${WANT_MP}" = "true" ] && jobs=${MAKEOPTS} || jobs="-j1"
> ...

 

Se cuelan el d1x-rebirth y el d2x-rebirth, pero queda claro que con openoffice no hay quien pueda  :Evil or Very Mad: . Ya nos gustaría a todos que fuese modular y que le metieran el API de OpenMP a diestro y siniestro.   :Rolling Eyes: 

----------

## gringo

igual está reflejado en la eclass, la verdad nunca me paré a mirar donde se declaraba WANT_MP en el caso de ooo, pero puedo asegurar que funciona y se habilita la compilación de varios hilos en paralelo. Si no te lo crees, prueba tu mismo o lee el changelog de ooo en gentoo :

http://gentoo-portage.com/app-office/openoffice/ChangeLog#ptabs

 *Quote:*   

> 14 Sep 2006; Andreas Proschofsky <suka@gentoo.org>
> 
> files/2.0.4_rc1/gentoo-2.0.4_rc1.diff, openoffice-2.0.4_rc1-r1.ebuild:
> 
> Use xsltproc during the build even when java is available, this should
> ...

 

creo que hoy en día ( apartir de la 3.0.1) ya se habilita por defecto en caso de encontrar >-j1 en el MAKEOPTS del make.conf, pero no estoy seguro al 100%. 

 *Quote:*   

> Ya nos gustaría a todos que fuese modular y que le metieran el API de OpenMP a diestro y siniestro

 

lo de modular creo que es imposible en su estado actual, ya que creo que realmente es un único binario que se ejecuta con extensiones.

A mi ya me dá lo mismo la verdad, ya no uso openoffice.

saluetes

----------

## luispa

 *gringo wrote:*   

> 
> 
> creo que hoy en día ( apartir de la 3.0.1) ya se habilita por defecto en caso de encontrar >-j1 en el MAKEOPTS del make.conf, pero no estoy seguro al 100%. 
> 
> 

 

Te confirmo que en mi caso empezé con la 3.0.1 y tanto esa como la 3.1.0 y 3.1.1 han usado todos los threads durante la compilación (8 en mi caso).

Mi make.conf

```
CFLAGS="-O2 -pipe -march=native"

CHOST="x86_64-pc-linux-gnu" 

CXXFLAGS="${CFLAGS}" 

MAKEOPTS="-j9"

USE="unicode xcb -motif -mozilla -firefox xulrunner vhosts font-server alsa esd pulseaudio mysql maildir sasl oggvorbis apache2 imap nvidia xvmc gnome jpeg kde ogg opengl png truetype udev vorbis X xml xv ffmpeg snmp samba tiff java imagemagick exif x264 gtk zeroconf avahi lm_sensors lcms qt3support hal fuse"

LINGUAS="es en"

INPUT_DEVICES="evdev"

VIDEO_CARDS="nvidia"

PORTDIR_OVERLAY=/usr/local/portage

CAMERAS="canon directory template"

source /usr/local/portage/layman/make.conf

```

Luis

----------

