Prima di tutto, desidero ringraziare Aron Ahmadia per avermi indicato questo thread.
Per quanto riguarda OpenCL nel codice scientifico: OpenCL è pensato per essere un'API di basso livello, quindi è fondamentale racchiudere questa funzionalità in qualche modo per raggiungere una produttività ragionevole. Inoltre, non appena sono coinvolti diversi kernel di calcolo, il codice può diventare MOLTO sporco se il kernel OpenCL e gli handle di memoria devono essere pesantemente passati all'interno di un'applicazione. Non conosco OCLTools, quindi non posso dire se siano utili al riguardo.
Per quanto riguarda ViennaCL: sono il capo di ViennaCL, quindi ho lavorato di recente con la biblioteca. :-) Nel seguito tratterò la richiesta di un confronto con la cuspide in un ambito leggermente più ampio, vale a dire ViennaCL rispetto alle librerie matematiche basate su CUDA cusp e MAGMA . Viene preso in considerazione solo lo stato attuale, anche se c'è molto sviluppo in corso (almeno dalla nostra parte).
Funzionalità . MAGMA offre la funzionalità BLAS per matrici dense tramite le solite interfacce funzionali. La maggior parte di questa funzionalità è fornita anche con ViennaCL 1.2.0 utilizzando sovraccarichi dell'operatore e altri zuccheri sintattici.
Gli stessi tre solutori iterativi (CG, BiCGStab, GMRES) sono forniti con cuspide e ViennaCL. L'insieme dei precondizionatori differisce in particolare: Cusp fornisce diagonali, SA-AMG e vari precondizionatori Bridson. ViennaCL offre fattorizzazioni LU incomplete, precondizionatori diagonali e recentemente vari gusti AMG e precondizionatori inversi approssimativi sparsi. Per quanto ne so, tutti i precondizionatori di cuspidi girano interamente sulla GPU, mentre ViennaCL si affida in particolare alla fase di installazione su calcoli basati su CPU. Attualmente, il numero di formati di matrice sparsa è maggiore in cuspide: COO, CSR, DIA, ELL, HYB, mentre ViennaCL 1.2.0 fornisce COO e CSR.
Vi sono numerose funzionalità aggiuntive fornite con ViennaCL, che non fanno parte di MAGMA o cuspide: tipi di matrici strutturate (Circulant, Hankel, ecc.), Trasformata di Fourier veloce, algoritmi di riordino (ad es. Cuthill-McKee) e wrapper per l'algebra lineare tipi da altre librerie.
Prestazione. Il set più ampio di funzionalità e supporto hardware in ViennaCL di solito comporta un costo inferiore rispetto alle implementazioni basate su CUDA. Ciò è anche in parte dovuto al fatto che CUDA è adattato all'architettura dei prodotti NVIDIA, mentre OpenCL rappresenta in un certo senso un ragionevole compromesso tra diverse architetture multi-core.
Nel complesso, ViennaCL è attualmente più lenta di MAGMA, in particolare a livello BLAS 3. Le ragioni sono il diverso focus di ViennaCL (sparsa anziché densa algebra lineare) e quindi il più alto grado di ottimizzazione in MAGMA. In particolare, le operazioni di livello 3 BLAS sono attualmente notevolmente più veloci in MAGMA.
Allo stesso modo, la cuspide offre prestazioni generali leggermente migliori in generale. Tuttavia, poiché le operazioni con matrici sparse sono generalmente limitate dalla larghezza di banda della memoria, le differenze sono considerevolmente più piccole e spesso trascurabili rispetto alla configurazione dei dati e simili. La scelta del precondizionatore e dei suoi parametri di solito ha un impatto maggiore sul tempo di esecuzione complessivo rispetto a qualsiasi differenza di prestazioni nelle moltiplicazioni sparse matrice-vettore.
Portabilità . Per quanto riguarda la portabilità dell'hardware, ViennaCL può utilizzare CPU e GPU di tutti i principali fornitori grazie a OpenCL. Al contrario, cuspide e MAGMA si basano su una GPU NVIDIA adatta.
ViennaCL è solo intestazione, può essere compilato su una vasta gamma di compilatori C ++ e deve essere collegato alla libreria OpenCL solo se è richiesto il supporto GPU. In linea di principio, gli algoritmi generici in ViennaCL possono anche essere utilizzati senza alcun collegamento OpenCL, mentre cusp e MAGMA richiedono il compilatore NVIDIA per la compilazione e la libreria CUDA sul sistema di destinazione per l'esecuzione. MAGMA richiede anche una libreria BLAS, che a volte può essere un po 'una seccatura per trovare o installare su un nuovo sistema.
. MAGMA fornisce interfacce di funzioni in stile BLAS per la funzionalità BLAS. L'interfaccia C ++ di cusp usa anche alcune funzioni di BLAS, ma nessun sovraccarico dell'operatore. Dato che la maggior parte delle interfacce di ViennaCL sono intenzionalmente simili a Boost.uBLAS e presentano zucchero sintattico come sovraccarichi dell'operatore, ViennaCL deve essere utilizzato anche come Boost.uBLAS. Pertanto, oltre a chiamare un set predefinito di operazioni e algoritmi, la nostra intenzione è di rendere il più semplice possibile una transizione dall'esecuzione basata esclusivamente sulla CPU al codice GPU, anche se devono essere utilizzati algoritmi non standard. Nel caso in cui sia richiesto un kernel OpenCL dedicato, esiste anche un framework per l'integrazione dei propri kernel OpenCL in ViennaCL. Pertanto, ViennaCL punta molto di più versoAlta produttività API nel senso che il tempo necessario per l'implementazione di nuovi algoritmi sulla GPU è ridotto al minimo . Questi risparmi possono superare in modo significativo qualsiasi penalità di prestazione (se presente) rispetto a cuspide e MAGMA. (È stato anche menzionato nel thread sui test unitari che il tempo di sviluppo del codice è una risorsa preziosa nella scienza.)
Ci sono certamente una serie di questioni ideologiche (ad esempio CUDA vs. OpenCL, interfaccia BLAS contro sovraccarichi dell'operatore) durante il mio confronto, ma la loro discussione va oltre lo scopo della domanda iniziale.