In che modo la comprensione dell'architettura del computer aiuta un programmatore? [duplicare]

In che modo la comprensione della fisica aiuta le persone a guidare un'auto?

2. Comprendono fenomeni come la dissolvenza dei freni e la compenseranno.
3. Comprendono il baricentro e il modo in cui i pneumatici aderiscono alla strada.
4. Comprendono l'aquaplaning e come evitarlo.
5. Sanno come entrare e uscire al meglio da una curva.
6. Sono molto meno probabili al portellone posteriore.

E così via. Puoi guidare una macchina senza sapere molto sulla fisica, ma capire la fisica ti rende un pilota migliore.

Due esempi di come la comprensione dell'architettura del computer può influire sul modo in cui si codifica:

• previsione del ramo
• Dimensioni della cache e schemi di accesso

È fondamentalmente la stessa ragione per comprendere C e i puntatori o forse anche gli algoritmi; l'unica differenza è che se si conosce l'architettura del computer si capiscono i puntatori (in realtà i puntatori sembrano molto banali dopo aver conosciuto l'architettura del computer).

Non posso dire di me stesso che sono un programmatore esperto, ma un (effettivamente il) libro sull'architettura del computer che ho letto è stato per me il libro più interessante che ho letto, relativo ai computer e alla programmazione. Comprendendo l'architettura del computer, capisci in pratica come tutto è collegato, come funziona un computer e come mai un programma funziona davvero; vedi il quadro generale. Senza l'architettura del computer non puoi veramente capire:

• gestione della memoria: heap, stack, memoria virtuale, gerarchia di memoria e puntatori (perché c'è un overflow dello stack, perché la ricorsione non è così buona ecc.)
• programmazione assembly (se vuoi programmare embedded)
• compilatori e interpreti (se vuoi capire le ottimizzazioni e quando è inutile ottimizzare il codice perché è già stato creato dal compilatore)
• linker (librerie collegate dinamicamente)
• sistemi operativi (se vuoi leggere il codice del kernel di Linux)
• l'elenco può continuare ...

Dal mio punto di vista molto soggettivo, è di gran lunga più interessante e forse anche più utile della conoscenza degli algoritmi.

Nel mondo di oggi, questo ragionamento è trascurabile se è presente per la maggior parte delle situazioni di programmazione.

Il punto in cui è applicabile è quando si scrive un assembly per un particolare processore, lavorando su una situazione che richiede uno di sfruttare una particolare architettura, o limitato in modo significativo dall'architettura (sistemi embedded) in modo che i due precedenti i punti diventano tanto più importanti.

Per i programmatori di linguaggi interpretati (perl, python, ruby) o linguaggi che vengono eseguiti nella propria macchina virtuale (java, C #) la macchina sottostante è completamente astratta. Un programma Java non sarebbe codificato in modo diverso per essere eseguito su un enorme cluster o sul proprio desktop.

I casi in cui l'architettura fa la differenza, come detto, sono sistemi incorporati in cui è necessario considerare i problemi di livello molto basso che sono per quell'ambiente. L'altro estremo esiste anche - dove si scrive codice ad alte prestazioni in assembly o qualcosa che viene compilato in codice nativo (non in esecuzione in una macchina virtuale). In questi casi estremi, ci si occupa di ciò che si adatta alla cache del processore e quanto è veloce accedere a diverse parti della memoria, in quale direzione va la previsione del ramo sul processore (se il processore usa la previsione del ramo o lo slitter). / p>

La questione della previsione dei branch e degli slot di delay o della cache del processore non entra nella maggior parte dei problemi di programmazione e non può entrare nei linguaggi interpretati o virtuali della macchina.

Tutto ciò che è stato detto, è utile comprendere un livello di ciò che sta accadendo in uno più profondo rispetto al codice esistente in fase di scrittura. L'ulteriore che rapidamente raggiunge rendimenti decrescenti. Un programmatore Java dovrebbe comprendere un linguaggio di programmazione con gestione manuale della memoria e matematica del puntatore per capire cosa sta succedendo sotto le copertine. Un programmatore C dovrebbe capire l'assemblaggio in modo che si possa capire quali sono i realmente puntatori e dove la memoria veramente arriva. I codificatori di assiemi dovrebbero avere familiarità con l'architettura per capire che cosa significano gli scambi di predizione delle branch e gli slot di delay ... e per portarli ancora più in là, quelli che progettano i processori dovrebbero avere familiarità con la meccanica quantistica su come i semiconduttori e le porte funzionano a un livello molto basilare .

Direi che chiunque non capisca l'organizzazione dei computer è destinato a essere un pessimo programmatore. Lo saprai:

• come organizzare le strutture dati e gli algoritmi per essere più efficienti nella cache
• come funziona una chiamata di funzione e le implicazioni per chiamare la convenzione
• i segmenti di memoria e le loro implicazioni per le dichiarazioni di variabili
• come leggere l'assembly e quindi interpretare l'output di un compilatore
• gli effetti del parallelismo a livello di istruzioni e la programmazione delle istruzioni fuori ordine, e cosa significa per la ramificazione

Fondamentalmente, imparerai come funziona un computer, e quindi sarai in grado di mappare il tuo codice in modo più efficace.

Comprendere i principi dell'architettura dei computer richiede l'apprendimento di molti importanti principi di programmazione. Pertanto, una conoscenza dell'architettura del computer è rilevante per la programmazione in qualsiasi lingua, indipendentemente dal livello elevato.

Questi importanti principi includono:

• Strutture dati fondamentali come matrici e stack
• Struttura del programma : loop, condizionali, subroutine (salta e chiama)
• Considerazioni sull'efficienza di tempo e spazio
• Sistemi: il modo in cui i vari componenti si adattano tra loro attraverso interfacce astratte. Apparentemente questo è controverso, quindi elaborerò. Prendi il set di istruzioni, un costrutto con una forma generale (operandi, modalità di indirizzamento, codifica) ciò è applicabile a molti diversi tipi di operazioni, come l'aritmetica, la logica, la modifica della memoria e il controllo degli interrupt. Questo illustra un principio generale di progettazione del sistema, vale a dire che i sistemi sono composti da singoli sottosistemi che condividono tutti la stessa cosa interfaccia astratta e che le interfacce astratte sono in grado di gestire molti componenti specifici. Questo principio è visibile anche in un'applicazione web che può memorizzare lo stesso tipo di oggetto (interfaccia astratta) in un database, in memoria o su una pagina Web (sottosistemi). In ogni caso, l'interfaccia astratta specifica la forma generale senza specificare i dettagli concreti. Il design del sistema è l'arte di sapere cosa fare in generale e cosa rendere specifico. Questo è un'abilità affinata dalla progettazione e dalla comprensione dei sistemi, in qualsiasi lingua e ad ogni livello.

Aggiornamento 2018: Quanti sviluppatori software impiega per cambiare una lampadina ??? Che importa!? Questo è un problema hardware!

Generalmente NO, Non è necessario conoscere l'architettura del computer per essere un buon programmatore, Questo è più nel regno IME IMO .. a meno che, naturalmente, non si sia nello sviluppo di sistemi embedded, ma in In quel caso sei sposato con il chip e programmato proprio su di esso, quindi avrai bisogno di conoscere l'architettura di QUESTO "computer" (e anche allora potrebbe non avere importanza), ma avere una comprensione architettonica generale di come i computer funzionano. essere buono per molto altro che discussioni Waterhole.

Direi che in questi giorni è ancora meno importante al tasso di declino del prezzo dell'hardware e che le prestazioni stanno migliorando / aumentando e quanto velocemente le tecnologie stanno cambiando e le lingue si stanno evolvendo. Le strutture dati e gli schemi di progettazione non hanno molto a che fare con l'architettura hardware fisica per quanto ne so.

Generalmente i programmatori provengono da un background informatico, nel qual caso hanno più che probabilmente preso lezioni di architettura del computer, ma oggigiorno i sistemi operativi stanno diventando virtuali, lo spazio su disco è condiviso, la memoria è scalabile, ecc. .. ecc.

Sono stato in grado di fare una grande carriera nel campo della programmazione (oltre 10 anni) e ho una conoscenza pedagogica dell'architettura dei computer molto poco, soprattutto perché ... Ero un grande dell'arte !!!

Aggiornamento: Giusto per essere onesti, la mia "piccola conoscenza educativa" è venuta dalla mia CPU Sci. Minore. e ancora, non ho mai avuto bisogno di usare tutto ciò che ho imparato dalle mie lezioni di Assembly o dalle mie lezioni di Computer Architecture nella mia carriera di "Programmazione".

Anche ora mentre gioco con alcune Mesh Networking Idea che implementano la ZigBee specifica, ho scoperto che usando i prodotti e gli strumenti disponibile ( XBee ), sono in grado di programmare in Python e plop il codice direttamente sul chip (SoC) e fai qualcosa di veramente pulito con esso .. TUTTO senza doversi preoccupare di nulla con l'architettura reale dei chip, ecc. .. ci sono sicuramente limiti hardware per essere cognitivi a causa delle dimensioni del chip e del target di prezzo basso previsto .. ma anche THAT diventerà meno nei prossimi anni. Pertanto, sostengo la mia risposta "Generalmente NO"

Può davvero aiutare un bel po '. Comprendere concetti come la memoria condivisa e la comunicazione tra processori e i potenziali ritardi coinvolti con questi possono aiutare un programmatore a organizzare i propri dati e metodi comunicativi per evitare di basarsi pesantemente su questi meccanismi, se necessario. Questo è vero per altre aree di programmazione come il ridimensionamento orizzontale, in cui la distribuzione e la comunicazione tra un programma o un sistema di programmi è un punto focale principale.

Comprendere le insidie o le catrame di un sistema fisico può aiutarti a organizzare un tale programma per aiutare a negoziare i sistemi fisici nel modo più rapido ed efficiente possibile. Semplicemente lanciando i dati in una coda di comunicazione e aspettandone la scalabilità è un difetto di ciò che potrebbe davvero essere necessario, specialmente se si deve ridimensionare il software su sistemi più grandi per un supporto migliore.

Allo stesso modo, comprendere i vantaggi di qualcosa come la programmazione funzionale può essere esemplificato alla luce della comprensione di ciò che sta accadendo a livello fisico, dei sistemi e, di conseguenza, rende ancora più strong la trazione per concetti come questi.

Un ultimo esempio veloce potrebbe essere la comprensione del concetto di elaborazione del flusso di dati e come inviare i dati a un'unità di elaborazione come una scheda video può essere meglio fatto in un modo molto specifico come: inviare tutti i calcoli richiesti, ricevere indietro la cornice dei dati in un colpo solo. In qualcosa come la grafica video o forse anche i calcoli fisici, non si vorrebbe avere una comunicazione aperta con un dispositivo del genere; quindi, sapendo questo, vorresti organizzare questa parte del tuo programma in quanto tale.

Dopo tutto, se i programmatori non capivano questi problemi e blocchi stradali, allora queste soluzioni non sarebbero mai esistite nel formato che fanno.

Conoscere la tua architettura ti consente di sapere quando qualcosa che viene richiesto è impossibile.

Una volta mi è stato chiesto di scrivere un programma per comunicare con un PIC su una porta seriale del PC. Il protocollo avrebbe il PIC che inviava byte da nove bit, senza controllo del flusso. Mostrerei nell'interfaccia utente del mio programma i valori dei campi nei pacchetti inviati dal PIC. Domanda ovvia: come leggo il nono bit di ogni byte? L'ingegnere del protocollo e io abbiamo deciso che avremmo provato a impostare la parità su MARK e poi trattare il nono bit come un bit di parità. Vorrei leggere il valore del nono bit in base al successo o al fallimento del controllo di parità. Bene, l'ho implementato e non ha funzionato. I valori visualizzati erano ovviamente sbagliati. E dopo tre giorni continui di ricerca dell'architettura PC UART, ho scoperto perché.

Ecco perché. L'UART del PC memorizza il suo input. Nel momento in cui interrompe la CPU per dire "READY TO READ", qualsiasi numero di byte potrebbe essersi accumulato nel suo buffer. C'è, tuttavia, solo un registro di stato di linea per mantenere il valore del controllo di parità. È quindi impossibile stabilire quale byte nel buffer ha fallito il controllo di parità. Quindi: assicurati che il buffer sia lungo solo un byte, dici? Questa è un'impostazione di controllo del flusso e ho già detto che questo protocollo non aveva il controllo del flusso. Se non conoscessi l'architettura dell'hardware che stavo programmando, non avrei mai potuto dire: "Leggere il nono bit è impossibile e deve essere tagliato".

L'apprendimento dell'architettura del computer aiuta immensamente nella programmazione.

Senza comprendere l'ambiente in cui il programma è in esecuzione, il tuo modello mentale è gravemente handicappato. Vediamo il mondo, non come è, ma come siamo - attraverso il modello mentale.

Non noterai la differenza in scenari caso felice, dove tutto funziona, ma farà una differenza cruciale quando lavorerai su problemi più complessi o eseguirai il debug di bug strani (ad esempio la programmazione in tempo reale).

È la differenza tra "WTF?" e "Ah, certo!".