cython openmp único, barreira

Estou tentando usar o openmp no cython. Preciso fazer duas coisas no cython:

i) usar o #pragma omp single{}escopo em meu código de cito.

ii) usar o #pragma omp barrier{}

Alguém sabe fazer isso no cython?

Aqui estão mais detalhes. Eu tenho uma função cdef nogil my_fun()que chamo em um omp for-loop:

from cython.parallel cimport prange
cimport openmp

cdef int i

with nogil:
    for i in prange(10,schedule='static', num_threads=10):
        my_func(i)

Por dentro my_func, preciso colocar uma barreira para esperar que todos os threads sejam alcançados, depois executar uma operação demorada apenas em um dos threads e com o gil adquirido e, em seguida, liberar a barreira para que todos os threads continuem simultaneamente.

cdef int my_func(...) nogil:

    ...

    # put a barrier until all threads catch up, e.g. #pragma omp barrier

    with gil:
        # execute time consuming operation in one thread only, e.g. pragma omp single{}

    # remove barrier after the above single thread has finished and continue the operation over all threads in parallel, e.g. #pragma omp barrier

    ...

Cython tem algum suporte para openmp, mas provavelmente é mais fácil codificar em C e envolver o código resultante com Cython se openmp-pragmas forem usados ​​extensivamente.

Como alternativa, você poderia usar código C literal e truques com define para trazer algumas das funcionalidades para Cython, mas o uso de pragmas em define não é simples ( _Pragmaé uma solução C99 , MSVC fazendo suas próprias coisas como sempre com __pragma), existem alguns exemplos como prova de conceito para Linux / gcc:

cdef extern from *:
    """
    #define START_OMP_PARALLEL_PRAGMA() _Pragma("omp parallel") {
    #define END_OMP_PRAGMA() }
    #define START_OMP_SINGLE_PRAGMA() _Pragma("omp single") {
    #define START_OMP_CRITICAL_PRAGMA() _Pragma("omp critical") {   
    """
    void START_OMP_PARALLEL_PRAGMA() nogil
    void END_OMP_PRAGMA() nogil
    void START_OMP_SINGLE_PRAGMA() nogil
    void START_OMP_CRITICAL_PRAGMA() nogil

fazemos Cython acreditar que START_OMP_PARALLEL_PRAGMA()e Co. são funções nogil, então ele os coloca em código C e, assim, eles são selecionados pelo pré-processador.

Devemos usar a sintaxe

#pragma omp single{
   //do_something
}

e não

#pragma omp single
do_something

devido à forma como o Cython gera o código C.

O uso pode ser o seguinte (estou evitando aqui from cython.parallel.parallel, pois faz muita mágica para este exemplo simples):

%%cython -c=-fopenmp --link-args=-fopenmp
cdef extern from *:# as listed above
    ...

def test_omp():
    cdef int a=0
    cdef int b=0  
    with nogil:
        START_OMP_PARALLEL_PRAGMA()
        START_OMP_SINGLE_PRAGMA()
        a+=1
        END_OMP_PRAGMA()
        START_OMP_CRITICAL_PRAGMA()
        b+=1
        END_OMP_PRAGMA() # CRITICAL
        END_OMP_PRAGMA() # PARALLEL
    print(a,b)

Chamando test_ompimprime "1 2" na minha máquina com 2 threads, como esperado (pode-se alterar o número de threads usando openmp.omp_set_num_threads(10)).

No entanto, o acima ainda é muito frágil - alguma verificação de erro pelo Cython pode levar a código inválido (Cython usa goto para controlar o fluxo e não é possível pular do bloco openmp). Algo assim acontece no seu exemplo:

cimport numpy as np
import numpy as np
def test_omp2():
    cdef np.int_t[:] a=np.zeros(1,dtype=int)

    START_OMP_SINGLE_PRAGMA()
    a[0]+=1
    END_OMP_PRAGMA()

    print(a)

Por causa da verificação de limite, Cython produzirá:

START_OMP_SINGLE_PRAGMA();
...
//check bounds:
if (unlikely(__pyx_t_6 != -1)) {
    __Pyx_RaiseBufferIndexError(__pyx_t_6);
    __PYX_ERR(0, 30, __pyx_L1_error)  // HERE WE GO A GOTO!
}
...
END_OMP_PRAGMA();

Neste caso especial, definir a verificação de limite como falso, ou seja,

cimport cython
@cython.boundscheck(False) 
def test_omp2():
   ...

resolveria o problema do exemplo acima, mas provavelmente não em geral.

Mais uma vez: usar openmp em C (e envolver a funcionalidade com Cython) é uma experiência mais agradável.

Como uma observação lateral: Python-threads (os governados por GIL) e openmp-threads são diferentes e não sabem nada um sobre o outro. O exemplo acima também funcionaria (compilar e executar) corretamente sem liberar o GIL - openmp-threads não se importam com o GIL, mas como não há objetos Python envolvidos, nada pode dar errado. Portanto, adicionei nogilàs "funções" empacotadas, para que também possam ser usadas em blocos nogil.

No entanto, quando o código fica mais complicado, torna-se menos óbvio, que as variáveis ​​compartilhadas entre diferentes threads Python não são acessadas (tudo acima porque esses acessos podem acontecer no código C gerado e isso não fica claro a partir do Cython- código), pode ser mais sensato não liberar gil, ao usar openmp.