Il pranzo libero è finito? [chiuso]


12

Nel suo famoso articolo The Free Lunch Is Over del 2005, Herb Sutter ha predetto una rivoluzione della programmazione concorrente grande quanto la rivoluzione orientata agli oggetti. Questa rivoluzione è davvero accaduta negli anni 2005-2013?


Punti chiave nell'articolo:

  • I produttori di processori hanno esaurito lo spazio con la maggior parte dei loro approcci tradizionali per migliorare le prestazioni della CPU. Invece di aumentare la velocità di clock, si rivolgono invece a architetture hyperthreading e multicore.

  • Le applicazioni dovranno essere sempre più concorrenti se vogliono sfruttare appieno i guadagni della produttività della CPU.

  • "Oh, le prestazioni non contano molto, i computer continuano a essere sempre più veloci" affermazione sarà sbagliata.

  • L'efficienza e l'ottimizzazione delle prestazioni diventeranno sempre più importanti. Quelle lingue che si prestano già a una forte ottimizzazione troveranno nuova vita; quelli che non avranno bisogno di trovare modi per competere e diventare più efficienti e ottimizzabili. Aspettatevi una crescente domanda a lungo termine di linguaggi e sistemi orientati alle prestazioni.

  • Linguaggi e sistemi di programmazione saranno sempre più costretti a gestire bene la concorrenza. Abbiamo un disperato bisogno di un modello di programmazione di livello superiore per la concorrenza rispetto alle lingue offerte oggi.


15
Quanti core ha il tuo telefono?
Matt D

6
Il mio Nokia 2700 ha un core.
cpp

5
@MattD Siamo spiacenti, ma perché è il "momento di aggiornare", e cosa c'entra il numero di core nel telefono di cpp? Come fai a sapere che un Nokia 2700 non è abbastanza per le sue esigenze?
Andres F.

2
Vado a registrare per dire, con un'osservazione totalmente non scientifica, che c'è stata una tale rivoluzione dal lato hardware delle cose, ma la rivoluzione del software è stata straordinariamente lenta. Ottenere strumenti concorrenti di qualità per tutti i programmatori è ancora un duro concerto e la concorrenza è ancora qualcosa che inciampa anche in sviluppatori paralleli esperti in modi difficili da riprodurre.
Jesse C. Slicer,

2
Voglio solo sottolineare che solo perché i tempi delle previsioni sono sbagliati, non necessariamente le previsioni sono sbagliate. È abbastanza ovvio che i punti chiave che hai elencato sopra non hanno ottenuto l'importanza implicita, ma ci sono stati passi nella direzione di ciascuno di quei punti. Quindi direi che le predizioni di cui sopra diventeranno realtà, è solo una questione di quando. Sarà QUANDO quando diventerà un requisito e non solo un desiderio. Sapere quando verrà superata quella soglia è il motivo per cui prevedere quando è così difficile.
Dunk,

Risposte:


23

Sì, ma dipende.

Non puoi aspettarti di scrivere software non banale e ad alte prestazioni senza sfruttare l'hardware parallelo e utilizzare la concorrenza come tecnica di strutturazione del programma. Ma la maggior parte dei software è sia banale che non critica per le prestazioni. Un'app Web non sta facendo molto scricchiolare il numero e le app CRUD non hanno nulla come i limiti di temporizzazione di alcuni software di simulazione e medici.

In particolare, gli sviluppatori di giochi devono preoccuparsene, poiché i giochi sono il tipo più comune di applicazione con requisiti soft in tempo reale. Il problema è rilevante su un telefono cellulare, in cui si desidera spremere quanta più potenza di elaborazione e rendering possibile da un chip integrato con due core della CPU e una GPU a bassa potenza. Questa è un'altra ragione per cui così tanti sviluppatori guardano Haskell e aspettano che maturi linguaggi come Rust: vogliamo sicurezza e prestazioni sull'hardware moderno.

Dal 2005 abbiamo acquisito strumenti nuovi e migliorati come OpenCL, CUDA, OpenMP e set di istruzioni vettoriali per lavorare con la concorrenza e il parallelismo dei dati in lingue consolidate. Tuttavia, i nuovi arrivati ​​relativi sono progettati fin dall'inizio per fare molte altre cose interessanti con la concorrenza.

Il runtime simultaneo di Haskell consente al linguaggio di fornire un supporto completo per parallelismo leggero (scintille) e astrazioni di concorrenza (thread, canali e riferimenti mutabili condivisi). Go e Rust offrono anche attività leggere, Go utilizza i canali e Rust utilizza il passaggio dei messaggi.

Questi sistemi offrono sicurezza della memoria, runtime performanti e protezione statica contro determinati tipi di gare. L'immutabilità di default di Haskell e Rust rende la concorrenza molto più facile da gestire per gli umani. Erlang stava facendo questo già negli anni '80, ma le esigenze di software e la nostra conoscenza su come progettare sistemi di programmazione hanno anche migliorato dal momento che-meno male.

Infine, molte lingue esistenti - non nominerò i nomi - sono pronte a rifiutare come scelte credibili per la scrittura di nuovo software. I loro carichi di complessità e le astrazioni di scarsa concorrenza li rendono inadatti alle considerazioni delle applicazioni moderne. Stiamo semplicemente aspettando alternative mature.


2
Non sono così sicuro del declino di alcune lingue, spero che vedremo il codice scritto con più attenzione alla minimizzazione delle dipendenze di ogni altra cosa. Dopotutto, non è proprio la lingua che è in errore, è il modo in cui la usi. E il "frutto basso appeso" del suo uso non è più allineato con multithread / concorrenza.
Matt D

6
@MattD: sia il modo in cui usi una lingua che la lingua stessa possono essere in errore. Di 'che il tuo programma è sbagliato. Sei tu quello che l'ha scritto male, ma la lingua non ti ha necessariamente aiutato a scriverlo nel modo giusto , ed è altrettanto importante.
Jon Purdy,

6

Ecco alcuni punti dati; decidi tu stesso se conta come una rivoluzione.

Hardware parallelo

Intorno al 2005, sia Intel che AMD iniziano a produrre CPU desktop x86 a 2 core di produzione di massa (Pentium D e Athlon 64), con velocità di clock intorno a 3 GHz.

Nel 2006, viene rilasciato PlayStation 3, con il processore Cell con 8 + 1 core a 3,2 GHz.

Nel 2006, viene rilasciata la serie GeForce 8. Consiste in un gran numero (~ 100) di "processori di flusso" per scopi generici, al contrario di unità specifiche per la grafica. Intorno al 2007, viene rilasciata la specifica CUDA 1.0, che consente l'esecuzione di alcuni calcoli per scopi generici su hardware NVidia massicciamente parallelo.

Da allora, le tendenze sono continuate.

Supponiamo ora che nel 2013 sia Intel che AMD offrano CPU a 4, 8 e 16 core, con velocità di clock leggermente superiori a soli 4 GHz. I design dual-core e quad-core sono comuni per dispositivi a bassa potenza, come laptop e smartphone.

Tutto questo è hardware per computer di uso quotidiano, prodotto in serie.

Software

CUDA è stato rilasciato nel 2007, quindi OpenCL nel 2008, consentendo di utilizzare GPU massicciamente parallele nel calcolo generale (non grafico). Il modello diventa popolare; molte società di hosting (ad es. Amazon) offrono GPU per attività di elaborazione generali.

Go è stato rilasciato nel 2009, con thread preventivi molto economici ("goroutine") e che consentono di esprimere in modo efficiente algoritmi altamente concorrenti.

Akka toolkit è stato rilasciato per Java e Scala nel 2009, consentendo la concorrenza basata sugli attori.

Erlang (un linguaggio altamente concorrente) vede un aumento nell'uso.

Concorrenza vs parallelismo

Si noti che per utilizzare l'hardware parallelo, non è necessariamente necessaria la concorrenza del software , ovvero giocoleria con thread di esecuzione all'interno di un calcolo. Molti problemi sono risolti da processi paralleli e non interagenti, in cui ogni processo è un programma sequenziale tradizionale.

L'elaborazione parallela può utilizzare linguaggi e framework paralleli più tradizionali, come map-riduc o MPC o OpenMP. Per tali framework, la presenza di più core sullo stesso cristallo della CPU non è concettualmente molto diversa dal solo avere più CPU nel cluster; la differenza è principalmente la velocità.

Nessun pranzo gratuito finora

Le velocità della CPU persistono a circa 5 GHz nella fascia alta. Con le migliori tecnologie in vista, come i transistor al grafene, le frequenze potrebbero aumentare di nuovo in futuro, ma non molto probabilmente.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.