Quando dovrei usare i modelli di espressione C ++ nella scienza computazionale e quando * non * usarli?

Supponiamo che sto lavorando su un codice scientifico in C ++. In una recente discussione con un collega, è stato affermato che i modelli di espressione potrebbero essere davvero una brutta cosa, rendendo potenzialmente il software compilabile solo su alcune versioni di gcc. Presumibilmente, questo problema ha interessato alcuni codici scientifici, come indicato nei sottotitoli di questa parodia di Downfall . (Questi sono gli unici esempi che conosco, quindi il link.)

Tuttavia, altre persone hanno sostenuto che i modelli di espressione sono utili perché possono produrre miglioramenti delle prestazioni, come in questo articolo nel SIAM Journal of Scientific Computing , evitando la memorizzazione dei risultati intermedi in variabili temporanee.

Non so molto sulla metaprogrammazione dei modelli in C ++, ma so che si tratta di un approccio utilizzato nella differenziazione automatica e nell'aritmetica degli intervalli, ed è così che sono entrato in una discussione sui modelli di espressioni. Dati sia i potenziali vantaggi in termini di prestazioni sia i potenziali svantaggi nella manutenzione (se questa è anche la parola giusta), quando dovrei usare i modelli di espressione C ++ nella scienza computazionale e quando dovrei evitarli?

Il mio problema con i modelli di espressione è che sono un'astrazione che perde molto. Trascorri molto lavoro a scrivere codice molto complicato per svolgere un compito semplice con una sintassi migliore. Ma se vuoi cambiare l'algoritmo, devi pasticciare con il codice sporco e se scivoli con tipi o sintassi, ricevi messaggi di errore completamente incomprensibili. Se la tua applicazione si associa perfettamente a una libreria basata su modelli di espressioni, potrebbe valere la pena prendere in considerazione, ma se non sei sicuro, consiglierei di scrivere semplicemente il codice normale. Certo, il codice di alto livello è meno carino, ma puoi semplicemente fare ciò che deve essere fatto. Come vantaggio, il tempo di compilazione e le dimensioni binarie diminuiranno e non dovrai far fronte a una grande variazione nelle prestazioni a causa della scelta del compilatore e della bandiera di compilazione.

Altri hanno commentato il problema di quanto sia difficile scrivere programmi ET e la complessità della comprensione dei messaggi di errore. Permettetemi di commentare il problema dei compilatori: è vero che qualche tempo fa uno dei grandi problemi era trovare un compilatore abbastanza conforme allo standard C ++ per far funzionare tutto e farlo funzionare in modo portabile. Di conseguenza, abbiamo trovato molti bug: ho 2-300 segnalazioni di bug nel mio nome, distribuite su gcc, Intel icc, IBM xlC e Portland pgicc. Di conseguenza, lo script di configurazione di deal.II è un repository di un gran numero di test di bug del compilatore, principalmente nell'area di template, dichiarazioni di amici, spazi dei nomi, ecc.

Ma si scopre che i produttori di compilatori hanno davvero messo insieme le loro azioni: oggi, gcc e icc oggi superano tutti i nostri test ed è facile scrivere codice che sia portatile tra loro. Direi che l'IGP non è molto indietro ma ha una serie di stranezze che non sembrano andare via nel corso degli anni. xlC, d'altra parte, è una storia completamente diversa: risolvono un bug ogni 6 mesi, ma nonostante la presentazione di segnalazioni di bug per anni, i progressi sono estremamente lenti e xlC non è mai stato in grado di compilare l'affare. II con successo.

Ciò significa tutto questo: se rimani con i due grandi compilatori, puoi aspettarti che funzionino solo oggi. Poiché la maggior parte dei computer e dei sistemi operativi oggi in genere ne ha almeno uno, è sufficiente. L'unica piattaforma in cui le cose sono più difficili è il BlueGene, in cui il compilatore del sistema è in genere xlC, con tutti i suoi bug.

Ho sperimentato un po 'con ET molto tempo fa quando, come hai detto, i compilatori stavano ancora lottando con loro. Ho usato la libreria blitz per l'algebra lineare in un mio codice. Il problema quindi era ottenere il buon compilatore e poiché non sono un programmatore C ++ perfetto, interpretando i messaggi di errore del compilatore. Quest'ultimo era semplicemente ingestibile. Il compilatore genererebbe in media circa 1000 righe di messaggi di errore. In nessun modo sono stato in grado di trovare rapidamente il mio errore di programmazione.

Puoi trovare maggiori informazioni sulla pagina web oonumerics (ci sono gli atti di due seminari ET).

Ma starei lontano da loro ...

Il problema inizia già con il termine "modelli di espressione (ET)". Non so se esiste una definizione precisa per questo. Ma nel suo uso comune in qualche modo accoppia "come si codificano le espressioni di algebra lineare" e "come viene calcolato". Per esempio:

Si codifica l'operazione vettoriale

v = 2*x + 3*y + 4*z;                    // (1)

E viene calcolato da un loop

for (int i=0; i<n; ++i)                 // (2)
    v(i) = 2*x(i) + 3*y(i) + 4*z(i);

A mio avviso si tratta di due cose diverse che devono essere disaccoppiate: (1) è un'interfaccia e (2) una possibile implementazione. Voglio dire, questa è una pratica comune in programmazione. Certo (2) potrebbe essere una buona implementazione predefinita, ma in generale voglio essere in grado di utilizzare un'implementazione specializzata e dedicata. Ad esempio, voglio che funzioni come

myGreatVecSum(alpha, x, beta, y, gamma, z, result);    // (3)

mi viene chiamato quando sto codificando (1). Forse (3) usa solo internamente un loop come in (2). Ma a seconda della dimensione del vettore altre implementazioni potrebbero essere più efficienti. Ad ogni modo, alcuni esperti di alte prestazioni possono implementare e ottimizzare (3) il più possibile. Quindi se (1) non può essere mappato su una chiamata di (3) allora evito piuttosto lo zucchero sintattico di (1) e richiamo direttamente (3) immediatamente.

Quello che descrivo non è una novità. Al contrario, è l'idea alla base di BLAS / LPACK:

• Tutte le operazioni critiche per le prestazioni in LAPACK vengono eseguite chiamando le funzioni BLAS.
• BLAS definisce semplicemente un'interfaccia per quelle espressioni di algebra lineare che sono comunemente necessarie.
• Per BLAS esistono diverse implementazioni ottimizzate.

Se l'ambito di BLAS non è sufficiente (ad es. Non fornisce una funzione come (3)), si può estendere l'ambito di BLAS. Quindi questo dinosauro degli anni '60 e '70 realizza con il suo strumento dell'età della pietra una separazione pulita e ortogonale di interfaccia e implementazione. È strano che le librerie C ++ (la maggior parte) numeriche non raggiungano questo livello di qualità del software. Sebbene il linguaggio di programmazione stesso sia molto più sofisticato. Quindi non sorprende che BLAS / LAPACK sia ancora vivo e sviluppato attivamente.

Quindi secondo me gli ET non sono di per sé cattivi. Ma il modo in cui sono comunemente usati nelle librerie numeriche C ++ ha guadagnato loro una pessima reputazione nei circoli di informatica scientifica.