Domanda

La maggior parte delle persone in uso calcolo scientifico OpenMP come un quasi-standard quando si tratta di parallelizzazione memoria condivisa.

C'è qualche ragione (diversa leggibilità) per utilizzare OpenMP su pthreads? Quest'ultimo sembra più fondamentale e ho il sospetto che potrebbe essere più veloce e più facile da ottimizzare.

È stato utile?

Soluzione

Si riduce in sostanza fino a quale livello di controllo che si desidera sul vostro parallelizzazione. OpenMP è grande se tutto quello che vogliamo fare è aggiungere un paio di dichiarazioni #pragma e hanno una versione parallela del codice abbastanza rapidamente. Se si vuole fare le cose davvero interessanti con codifica MIMD o accodamento complesso, è ancora possibile fare tutto questo con OpenMP, ma è probabilmente molto più semplice da utilizzare threading in quel caso. OpenMP ha anche vantaggi simili in termini di portabilità in che un sacco di compilatori per diverse piattaforme supporta ora, come con pthreads.

Quindi sei assolutamente corretto - se avete bisogno di controllo messo a punto sopra la parallelizzazione, utilizzare pthreads. Se si vuole parallelizzare con il minor lavoro possibile, usare OpenMP.

In qualunque modo si decide di andare, buona fortuna!

Altri suggerimenti

Un altro motivo: l'OpenMP è basato sulle attività, Pthread si basa filo. Ciò significa che OpenMP assegnerà lo stesso numero di fili come numero di core. Così si otterrà scalabile soluzione. Non è così facile compito di farlo utilizzando thread prime.

Il secondo parere: OpenMP offre funzionalità di riduzione: quando è necessario calcolare i risultati parziali in fili e combinarli. È possibile implementare solo usando la linea singola di codice. Ma usando le discussioni prime si dovrebbe fare di più lavoro.

Basta pensare le vostre esigenze e cercare di capire: è OpenMP abbastanza per voi? Potrai risparmiare un sacco di tempo.

OpenMP richiede un compilatore che lo sostiene, e lavora con pragma. Il vantaggio di questo è che quando si compila senza OpenMP-supporto (ad esempio PCC o Clang / LLVM fin d'ora), il codice verrà comunque compilazione. Inoltre, dare un'occhiata alla quello che Charles Leiserson ha scritto su multithreading fai da te .

Pthread è uno standard POSIX ( IEEE POSIX 1003.1c ) per le librerie, mentre specifiche OpenMP devono essere realizzate su compilatori; ciò detto, ci sono una varietà di implementazioni pthread (ad esempio OpenBSD rthreads, NPTL), e una serie di compilatori che supportano OpenMP (ad esempio GCC con il flag -fopenmp, MSVC ++ 2008).

Pthread sono valide solo per la parallelizzazione quando più processori sono disponibili, e solo quando il codice è ottimizzato per il numero di processori disponibili. Codice per OpenMP è più-facilmente scalabile di conseguenza. È possibile combinare il codice che si compila con OpenMP con codice utilizzando pthreads, anche.

Sei la domanda è simile alla domanda "Dovrei programmare C o di montaggio", C essendo OpenMP e montaggio essendo pthread.

Con pthreads si può fare molto meglio parallelizzazione, meglio che significa molto regolato strettamente al vostro algoritmo e hardware. Questo sarà un sacco di lavoro però.

Con pthreads è anche molto più facile da produrre un codice mal parallelised.

  

C'è qualche ragione (diversa leggibilità) per utilizzare OpenMP su pthreads?

Mike tipo di toccato questo:

  

OpenMP ha anche vantaggi simili in termini di portabilità in che un sacco di compilatori per diverse piattaforme supporta ora, come con pthreads

Crypto ++ è cross-platform, che significa in gira su Windows, Linux, OS X e BSD. Esso utilizza OpenMP per filettare il supporto in luoghi dove l'operazione può essere costoso, come elevamento modulare e moltiplicazione modulare (e dove mascherato può essere eseguita).

Windows non supporta pthreads, ma moderni compilatori di Windows supportano OpenMP. Quindi, se volete la portabilità per i non * nix di, allora OpenMP è spesso una buona scelta.


E come Mike ha anche sottolineato:

  

OpenMP è grande se tutto quello che vogliamo fare è aggiungere un paio di dichiarazioni #pragma e hanno una versione parallela del codice abbastanza rapidamente.

Di seguito un esempio di Crypto ++ precomputing alcuni valori utilizzati nelle firme Rabin-Williams utilizzando Roots ottimizzato come descritto da Bernstein in firme RSA e firme Rabin-Williams ... :

void InvertibleRWFunction::Precompute(unsigned int /*unused*/)
{
    ModularArithmetic modp(m_p), modq(m_q);

    #pragma omp parallel sections
    {
        #pragma omp section
            m_pre_2_9p = modp.Exponentiate(2, (9 * m_p - 11)/8);
        #pragma omp section
            m_pre_2_3q = modq.Exponentiate(2, (3 * m_q - 5)/8);
        #pragma omp section
            m_pre_q_p = modp.Exponentiate(m_q, m_p - 2);
    }
}

Si adatta con l'osservazione di Mike - il controllo a grana fine e la sincronizzazione non era davvero necessario. Parallelizzazione è stato utilizzato per accelerare l'esecuzione, e la sincronizzazione è venuto a costo zero nel codice sorgente.

E se OpenMP è non a disposizione, il codice si riduce a:

m_pre_2_9p = modp.Exponentiate(2, (9 * m_p - 11)/8);
m_pre_2_3q = modq.Exponentiate(2, (3 * m_q - 5)/8);
m_pre_q_p = modp.Exponentiate(m_q, m_p - 2);

OpenMP è ideale quando è necessario eseguire lo stesso compito in parallelo (cioè, su dati più), una sorta di macchina SIMD (single-instruction multiple data).

è necessario Pthread quando si desidera eseguire (molto diverse) i compiti in parallelo, come, ad esempio, la lettura dei dati in un thread e interagire con l'utente in un altro thread.

Si veda questa pagina:

http://berenger.eu / blog / c-cpp-OpenMP-vs-pthread-OpenMP-o-POSIX-thread /

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top