In quali aree della programmazione il tempo di esecuzione dell'algoritmo è in realtà un problema importante?

A volte ho sentito dire che a causa della velocità dei processori e della quantità di memoria disponibile, l'efficienza dell'algoritmo e il tempo di esecuzione non sono, in pratica, di grande preoccupazione.

Ma immagino che ci siano ancora aree in cui tali considerazioni rimangono di fondamentale importanza. Due che vengono in mente sono il trading algoritmico, dove migliaia di transazioni devono essere condotte in frazioni di secondo, e la programmazione di sistemi integrati, dove memoria e potenza sono spesso scarse. Ho ragione su questi esempi? e quali altre aree sarebbero anche esempi?

La velocità è sempre richiesta. Immagino tu abbia ragione. Ecco alcuni esempi in cui sono richiesti algoritmi accurati:

1. Crittografia

2. Ricerca di database di grandi dimensioni

3. Ordinamento e fusione

4. Ricerca di testo (non indicizzata), compresi i caratteri jolly

5. Problemi di matematica con calcoli intensivi

6. Simulazione

7. Applicazioni di data mining

8. Animazione

9. AI

10. Visione computerizzata

Ci sono alcuni casi in cui il runtime dell'algoritmo potrebbe non essere un grosso problema, perché siamo arrivati ​​al punto in cui puoi semplicemente eseguire un punch in un algoritmo a esecuzione più lunga con hardware più potente. Ma ci sono sicuramente alcuni posti in cui gli acceleratori sono essenziali.

In generale, tutto ciò che utilizza enormi set di dati sarà un problema. Quando hai qualcosa che si ridimensiona male con n, e poi fai un numero davvero enorme, hai un problema. Sospetto che se sei passato al sito beta di Computational Science e hai cercato un po 'in giro, potresti trovare molti problemi che necessitano di algoritmi migliori e più veloci. Alcune aree in cui mi sono imbattuto:

• Analisi statistiche particolarmente complesse. Una combinazione di algoritmi inefficienti e insiemi di dati di grandi dimensioni può comportare notevoli rallentamenti. Per alcuni studi, questo potrebbe non avere importanza, ma cosa succede se stai cercando di fare qualcosa con un giro veloce? "Arriverà dal server tra un mese" è probabilmente una brutta cosa quando si esegue un sistema di sorveglianza di minacce chimiche / nucleari / biologiche.
• Data mining su grandi set di dati.
• Simulazioni che coinvolgono molte variabili.

In generale, l'informatica scientifica sembra in genere un'area in cui la complessità di ciò che viene programmato genera opportunità per gravi rallentamenti se l'algoritmo è lento (molti dei quali soffrono di n molto grandi). E, come hai detto, ci sono applicazioni finanziarie. Quando i millisecondi possono determinare se guadagni o perdi denaro in uno scambio, gli algoritmi "abbastanza buoni" non lo taglieranno se c'è qualcosa di meglio che può essere fatto.

A volte ho sentito dire che a causa della velocità dei processori e della quantità di memoria disponibile, l'efficienza dell'algoritmo e il tempo di esecuzione non sono, in pratica, di grande preoccupazione.

Prendilo con un granello di sale. Più potenza di calcolo significa sostanzialmente che la tua n può diventare molto più grande prima che rallenti in modo significativo. Per la maggior parte dei problemi di tutti i giorni, questo n è ora abbastanza grande da non doverti preoccupare. Tuttavia, dovresti comunque conoscere le complessità dei tuoi algoritmi.

Con più risorse disponibili, potrebbe essere necessario unire più dati in un secondo momento. Oggi è necessario analizzare un file di registro da 10 MB con 100.000 righe. In un anno potresti avere un file di registro da 100 GB con 1.000.000.000 di righe. Se la quantità di dati aumenta più rapidamente rispetto alle risorse, si verificano problemi in un secondo momento.

Con più risorse disponibili, più livelli sono impilati uno sull'altro. Sistema operativo, framework del sistema operativo, framework di terze parti, interprete di lingua e infine il tuo strumento personale. Tutte le inefficienze inutili in tutti i diversi livelli si moltiplicano. Domani il tuo strumento potrebbe funzionare su un nuovo sistema operativo con più campane e fischietti, che a sua volta consuma più cicli e più memoria, lasciandoti meno.

Quindi, per rispondere alla tua domanda, devi ancora preoccuparti di dove devono essere sgranati sempre più dati (abbastanza esempi forniti nelle altre risposte) e dove non fornisci lo strumento finale, ma un altro livello di astrazione per altri strumenti.

Qualche anno fa ho dovuto scrivere un algoritmo che ordinava le provette disposte su nrack in due partizioni distinte: cioè un sottoinsieme delle provette veniva "scelto" e il resto non era "scelto" e il risultato finale sarebbe che nessun rack avrebbe sia un tubo "scelto" che "non scelto" (c'erano alcuni requisiti extra come la compressione). Ogni rack conteneva un massimo di 100 provette.

L'algoritmo doveva essere utilizzato per guidare un robot di smistamento di tubi in un laboratorio farmaceutico.

Quando mi sono state fornite le specifiche originali, mi è stato assegnato un intervallo di tempo di calcolo di circa 1 minuto per ordinare circa 2000 provette poiché ritenevamo che l'usabilità non fosse troppo dolorosa. Era necessario che il numero di mosse fosse minimo su tutte le possibili combinazioni poiché il robot stesso era lento .

L'assunto implicito era che la complessità sarebbe esponenziale con il numero di tubi. Tuttavia, mentre lavoravo alla progettazione dell'algoritmo, ho scoperto che esiste un O(n)algoritmo veloce in cui nè il numero di rack che ha eseguito un partizionamento ottimale dei tubi. Il risultato è stato che il tempo di ordinamento dell'algoritmo era istantaneo, quindi la visualizzazione dell'ordinamento sarebbe stata aggiornata in tempo reale mentre l'utente configurava l'operazione di ordinamento.

Per me la differenza tra l'utente seduto per un minuto dopo ogni modifica e avere una GUI immediatamente reattiva era la differenza tra un software funzionalmente sufficiente e un software che era un piacere usare.

Altre aree includono molti tipi di elaborazione del segnale in tempo reale, sistemi di controllo del feedback, deconvoluzione dell'esplorazione petrolifera, compressione video, ray tracing e rendering di frame di film, sistemi di realtà virtuale, giochi in cui un frame rate elevato potrebbe rappresentare un vantaggio competitivo significativo e smartphone e altri app per dispositivi mobili, in cui un numero elevato di cicli della CPU consumerà più rapidamente la durata della batteria degli utenti.

Sono piuttosto sorpreso che questa domanda venga persino posta, dal momento che per qualsiasi supercomputer Top-500 mai costruito, esiste probabilmente una lista d'attesa di ricercatori che possono massimizzare e desiderare magnitudini più potenza di calcolo o magnitudini algoritmi migliori per risolvere alcuni problemi (piega alcune proteine ​​per decifrare il cancro, ecc.) prima che si ritirino.

Penso che i motori di ricerca come Google e Bing siano una delle aree più grandi in cui vengono utilizzati algoritmi complessi e svolgono un ruolo chiave nell'accelerare i risultati con pertinenza (ranking delle pagine) apportando maggiore utilità agli utenti.

L'efficienza dell'algoritmo non è una delle principali preoccupazioni al giorno d'oggi perché stiamo usando algoritmi efficienti. Se utilizzassi un algoritmo O (n!), Sarebbe lento su qualsiasi tipo di hardware.

La complessità dell'algoritmo sta diventando sempre più importante con l'aumentare della mole di dati. Fortunatamente, soluzioni generiche efficienti per problemi di programmazione comuni (ricerca e ordinamento, principalmente) sono incluse in quasi tutte le librerie standard di ogni linguaggio di programmazione moderno, quindi normalmente un programmatore non deve preoccuparsi molto di queste cose. L'aspetto negativo è che molti programmatori non sanno affatto cosa sta succedendo sotto il cofano e quali sono le caratteristiche degli algoritmi che usano.

Ciò diventa particolarmente problematico poiché molte applicazioni non sono adeguatamente sottoposte a stress test: le persone scrivono codice che funziona bene per piccoli set di dati di test, ma quando si confronta con alcune migliaia di volte più dati, il codice si interrompe. Qualcosa che funziona bene per dieci record esplode rapidamente quando il set di dati cresce. Esempio del mondo reale: un pezzo di codice che avrebbe dovuto ripulire gli oggetti che non erano più collegati a nessuna categoria utilizzava un ciclo annidato a tre livelli, che è O (n ^ 3). Con solo 10 record nel database di test, ciò significava 1000 controlli - perfettamente fattibili e non introducono un notevole ritardo. Tuttavia, il database di produzione si riempì rapidamente di circa 1000 righe e all'improvviso il codice esegue ogni volta un miliardo di controlli.

Quindi: No, non è necessario conoscere i dettagli dell'implementazione di tutti i tipi di algoritmi accurati e non è necessario essere in grado di inventare i propri, ma è necessaria una conoscenza di base degli algoritmi comuni, quali sono i loro i punti di forza e di debolezza sono, quando e quando non usarli, e devi essere consapevole del possibile impatto della complessità algoritmica, in modo da poter decidere quale livello di complessità è accettabile.

Non si tratta di quali domini applicativi siano sensibili al runtime. Qualsiasi programma, ovunque, ha una prestazione minima al di sotto della quale è effettivamente senza valore. Il punto della complessità dell'algoritmo è come varia con l'aumentare della dimensione dell'input. In altre parole, le aree in cui la velocità è particolarmente importante sono quelle in cui ci si aspetta che si riduca oltre la dimensione del problema attuale, ma l' ordine di grandezzadelle attuali dimensioni del problema. Se si elaborano le domande fiscali dei cittadini di un dipartimento della Francia, l'attività potrebbe essere grande, ma non è probabile che né la dimensione della popolazione né la complessità dell'elaborazione di un record aumenteranno mai di dieci o cento volte, quindi tutto ciò che funziona per ora probabilmente continuerai a lavorare. Ma se si tenta di creare qualcosa che possa decollare in volumi internet, algoritmo di complessità è fondamentale: tutto ciò che dipende più che lineare o log-lineare delle dimensioni di ingresso sarà diventato molto più costoso molto veloce, e alla fine la velocità del processore proprio non posso tenere il passo con la crescita.

Nel mio campo (VFX, che copre cose come tracciato di percorsi, animazione al computer, simulazione di particelle, fluidodinamica, elaborazione di immagini, ecc.), La complessità algoritmica è fondamentale. Non c'è modo che nulla operi in peggio del tempo linearitmico possa sperare di completare in un tempo ragionevole su input che raggiungono comunemente milioni di vertici, poligoni, voxel, particelle, texel, specialmente quando molte di queste cose devono completare molte volte al secondo per fornire feedback interattivo in tempo reale.

Detto questo, non c'è una forte enfasi sulla complessità algoritmica nella discussione in genere tra colleghi, forse perché è in qualche modo data per scontata e piuttosto "rudimentale". In genere, se si sta scrivendo un tracciatore di percorsi, si presume che funzionerà in un tempo logaritmico o superiore e che le strutture di dati come le gerarchie di volumi limitanti siano familiari e relativamente banali da implementare per il lettore. Ho anche avuto un collega esperto che continuava a dire che il multithreading e il SIMD sono più importanti degli algoritmi, e non penso che intendesse ciò, nel senso che ci si potrebbe aspettare di ottenere molto dal parallelizzare una sorta di bolla. Penso che lo abbia detto perché dato per scontato che avremmo applicato algoritmi sensibili,

Spesso in questi giorni l'attenzione si concentra sul prendere molti di questi algoritmi familiari e farli sfruttare meglio le caratteristiche sottostanti dell'hardware come cache della CPU, registri e istruzioni SIMD, GPU e core multipli. Ad esempio, Intel ha escogitato un nuovo modo di prendere il vecchio BVH familiare e di elaborare il concetto di "pacchetti di raggi", fondamentalmente testando più raggi coerenti contemporaneamente con una sorta di attraversamento di alberi ricorsivo (che potrebbe sembrare simile) verrebbe con la sua parte di complessità e spese generali, tranne che è più che compensato dal fatto che quei raggi possono ora essere testati simultaneamente per intersezioni raggio / AABB e raggio / triangolo attraverso istruzioni e registri SIMD).

Una cosa simile con una simile suddivisione catmull-clark, che è roba molto rudimentale nella computer grafica. Ma oggi ciò che è competitivo, caldo e super efficiente sono le implementazioni GPU che si avvicinano alla suddivisione CC usando Gregory Patches, come reso popolare da Charles Loop e successivamente adottato da Pixar. L'implementazione della CPU più semplice è ora piuttosto obsoleta, non necessariamente perché è stata sostituita in termini di complessità algoritmica, ma perché è stata sostituita da qualcosa che gioca bene con la GPU.

E di solito questa è una grande sfida in questi giorni non sta presentando il miglior algoritmo in un modo relativamente indipendente dalle caratteristiche sottostanti dell'hardware. In realtà ho avuto il mio piede nel settore inventando una nuova struttura di accelerazione che ha notevolmente accelerato il rilevamento delle collisioni per l'animazione di personaggi e altri corpi molli negli anni '90 usando un approccio di segmentazione gerarchica rispetto a un indice spaziale, che mi ha procurato molto offerte di lavoro, ma al giorno d'oggi non è più così impressionante da quando l'ho pubblicato molto prima che avessimo cache CPU e core multipli e GPU programmabili e cosa no, e al giorno d'oggi utilizzo un approccio completamente diverso a seguito delle modifiche significative hardware sottostante.

Una volta mi sono imbattuto in un problema in cui un algoritmo di solito funzionava in O (n), ma in circostanze rare ed estremamente improbabili avrebbe avuto bisogno di tempo O (n ^ 3) - le circostanze "rare" erano una directory contenente file con nomi che erano validi in un sistema operativo ma non in un altro.

Nessuno ha mai avuto problemi. Quindi un cliente ha utilizzato una strategia per denominare i file che verrebbero sistematicamente inseriti nel caso O (n ^ 3) e con pochi 100 file il sistema si è arrestato in modo virtuale. Il risultato è stato che l'algoritmo doveva essere modificato.

Altre tre che non sono state menzionate:

1) Molti giochi di strategia in tempo reale. Guarda quelle che hanno unità che non possono condividere una posizione. Guarda cosa succede all'individuazione del percorso quando un grande gruppo di unità si muove attraverso un terreno limitato. Devo ancora incontrare un gioco senza una sorta di sostanziale problema con questo perché semplicemente non c'è abbastanza potenza della CPU disponibile.

2) Molti problemi di ottimizzazione. (Modifica: da quando ho scritto questa risposta ne ho colpito uno. Il mio obiettivo era quello di potare i percorsi ridondanti in modo da lasciare tutti i nodi collegati con il peso minimo dei percorsi di connessione. Il mio approccio originale ha funzionato abbastanza bene fino a quando non ho spostato più della potatura a quella routine, poi mi sono reso conto che era 2 ^ n. Ora è n ^ 2 anche se a volte può produrre un risultato leggermente non ottimale.)

3) Cose che devono operare su grandi quantità di dati in tempo reale. Prendi in considerazione un DVD: di solito ricevi 2 ore di video in 4,7 GB. Prendi in considerazione un tipico file video con la stessa risoluzione: quelle 2 ore di video verranno generalmente inferiori a 1 GB. Il motivo è che quando sono state stabilite le specifiche del DVD non è stato possibile creare un lettore DVD a prezzi ragionevoli in grado di decodificare i formati più moderni abbastanza velocemente.

Bene, qualsiasi applicazione che viene in genere eseguita su un supercomputer ( elenco delle macchine più grandi ) si qualifica. Questi sono diversi, ma una grande sottoclasse è rappresentata dalle simulazioni fisiche:

• Simulazioni fisiche:
  • Previsioni del tempo
  • Simulazioni climatiche
  • Simulazioni di stelle che esplodono ecc.
  • Simulazioni di bombe esplosive
  • Simulazioni aerodinamiche di automobili / aerei / treni ecc.
  • ...
• Calcolo delle immagini dai dati del radiotelescopio
• Applicazioni biologiche:
  • Roba con sequenze di DNA (non mi piacciono molto quelle)
  • Cose biochimiche come il ripiegamento delle proteine
  • Simulazioni di come le cellule nervose collaborano per elaborare le informazioni
  • Simulazioni di altre interazioni complesse come gli ecosistemi
  • ...
• ...

Questi sono solo i miei argomenti principali, ma leggo l'elenco dei diversi supercomputer e realizzo che ognuno di questi è costruito per consentire alcuni tipi di calcoli che non sarebbero possibili senza macchine così gigantesche.

E, quando vedi che abbiamo effettivamente bisogno di queste macchine, rendi conto di quanti costi possono essere risparmiati, semplicemente accelerando queste applicazioni del 10% . Qualsiasi ottimizzazione di questi codici aumenta direttamente la quantità di risultati che siamo in grado di ottenere da queste macchine.