Comprensione dei livelli di elaborazione

Scusa, per la mia domanda confusa. Sto cercando alcuni suggerimenti.

Fino ad ora ho lavorato principalmente con Java e Python a livello di applicazione e ho solo una vaga comprensione dei sistemi operativi e dell'hardware. Voglio capire molto di più sui livelli inferiori di elaborazione, ma in qualche modo diventa davvero travolgente. All'università ho frequentato un corso sulla microprogrammazione, ovvero su come i processori sono cablati per implementare i codici ASM. Fino ad ora ho sempre pensato di non fare di più se imparassi di più sul "livello basso".

Una domanda che ho è: come è possibile che l'hardware venga nascosto quasi completamente dallo sviluppatore? È corretto affermare che il sistema operativo è un livello software per l'hardware? Un piccolo esempio: in programmazione non ho mai incontrato la necessità di capire cos'è la cache L2 o L3. Per il tipico ambiente di applicazione aziendale non è quasi mai necessario comprendere assemblatore e livelli inferiori di elaborazione, poiché al giorno d'oggi esiste uno stack tecnologico per quasi tutto. Immagino che il punto centrale di questi livelli inferiori sia fornire un'interfaccia a livelli superiori. D'altra parte, mi chiedo quanta influenza possano avere i livelli inferiori, ad esempio l'intera faccenda del calcolo grafico.

Quindi, d'altra parte, c'è questo ramo teorico dell'informatica, che lavora su modelli di calcolo astratti. Tuttavia, ho anche incontrato raramente situazioni in cui l'ho trovato utile pensare nelle categorie di modelli di complessità, verifica delle prove, ecc. In un certo senso so che esiste una classe di complessità chiamata NP e che sono in qualche modo impossibili da risolvere un gran numero di N. Quello che mi manca è un riferimento per un framework per pensare a queste cose. Mi sembra che ci siano tutti i tipi di campi diversi, che interagiscono raramente.

Nelle ultime settimane ho letto di problemi di sicurezza. Qui in qualche modo, molti dei diversi strati si uniscono. Gli attacchi e gli exploit si verificano quasi sempre al livello inferiore, quindi in questo caso è necessario conoscere i dettagli dei livelli OSI, i meccanismi interni di un sistema operativo, ecc.

La parola chiave per pensare a queste cose è astrazione .

Astrazione significa semplicemente ignorare deliberatamente i dettagli di un sistema in modo da poterlo considerare come un singolo componente indivisibile quando si assembla un sistema più grande da molti sottosistemi. È inimmaginabilmente potente - scrivere un moderno programma applicativo mentre si considerano i dettagli dell'allocazione della memoria e della registrazione del registro e dei tempi di esecuzione del transistor sarebbe possibile in un modo idealizzato, ma è incomparabilmente più facile noa pensarci e usare solo operazioni di alto livello. Il moderno paradigma informatico si basa essenzialmente su molteplici livelli di astrazione: elettronica a stato solido, microprogrammazione, istruzioni macchina, linguaggi di programmazione di alto livello, API di programmazione del sistema operativo e Web, framework e applicazioni programmabili dall'utente. Praticamente nessuno può comprendere l'intero sistema al giorno d'oggi, e non esiste nemmeno un percorso concepibile attraverso il quale potremmo mai tornare a quello stato di cose.

Il rovescio della medaglia dell'astrazione è la perdita di potere. Lasciando le decisioni sui dettagli a livelli inferiori, spesso accettiamo che possano essere prese con un'efficienza non ottimale, poiché i livelli inferiori non hanno il "quadro generale" e possono ottimizzare il loro funzionamento solo dalle conoscenze locali e non sono (potenzialmente) intelligente come essere umano. (Di solito. Per isntance, la compilazione di HLL in codice macchina è oggigiorno spesso eseguita meglio dalle macchine che persino dall'essere umano più esperto, poiché l'architettura del processore è diventata così complicata.)

La questione della sicurezza è interessante, perché spesso difetti e "perdite" nell'astrazione possono essere sfruttati per violare l'integrità di un sistema. Quando un'API postula che è possibile chiamare i metodi A, B e C, ma solo se la condizione X è valida, è facile dimenticare la condizione ed essere impreparati per la ricaduta che si verifica quando la condizione viene violata. Ad esempio, il classico overflow del buffer sfrutta il fatto che la scrittura su celle di memoria produce un comportamento indefinito a meno che non sia stato allocato questo particolare blocco di memoria. L'API garantisce solo che qualcosaaccadrà di conseguenza, ma in pratica il risultato è definito dai dettagli del sistema al livello inferiore successivo - che abbiamo deliberatamente dimenticato! Fintanto che soddisfiamo la condizione, ciò non ha alcuna importanza, ma in caso contrario, un utente malintenzionato che comprende intimamente entrambi i livelli può in genere indirizzare il comportamento dell'intero sistema come desiderato e far accadere cose brutte.

Il caso dei bug di allocazione della memoria è particolarmente grave perché si è rivelato molto, molto difficile gestire la memoria manualmente senza un singolo errore in un sistema di grandi dimensioni. Questo potrebbe essere visto come un caso fallito di astrazione: sebbene sia possibile fare tutto il necessario con il CmallocAPI, è semplicemente facile da abusare. Parti della comunità di programmatori ora pensano che questo fosse il posto sbagliato in cui introdurre un limite di livello nel sistema, e invece promuovono linguaggi con gestione automatica della memoria e garbage collection, che perde un po 'di potere, ma fornisce protezione contro il danneggiamento della memoria e comportamenti indefiniti . In effetti, uno dei motivi principali per cui ancora oggi si utilizza C ++ è proprio il fatto che consente di controllare esattamente quali risorse vengono acquisite e rilasciate quando. In questo modo, lo scisma maggiore tra lingue gestite e non gestite oggi può essere visto come un disaccordo su dove definire con precisione uno strato di astrazione.

Lo stesso si può dire per molti altri grandi paradigmi alternativi nel campo dell'informatica: il problema sorge davvero tutto il tempo in cui devono essere costruiti grandi sistemi, perché non siamo semplicemente in grado di progettare soluzioni da zero per i complessi requisiti comuni oggi. (Un punto di vista comune in AI questi giorni è che il cervello umano in realtà non lavoro così - comportamento risultante attraverso anelli di retroazione, reti massicciamente interconnesse ecc invece di moduli separati e strati con semplici interfacce astratte tra loro, e che è per questo che hanno avuto così poco successo nel simulare la nostra intelligenza.)