¿Cómo ayuda la comprensión de la arquitectura de la computadora a un programador? [duplicar]

¿Cómo la comprensión física ayuda a las personas a conducir un automóvil?

2. Comprenden fenómenos como el desgaste de los frenos y lo compensarán.
3. Entienden el centro de gravedad y cómo los neumáticos se agarran al camino.
4. Comprenden el hidroplaneo y cómo evitarlo.
5. Saben la mejor manera de entrar y salir de una curva.
6. Son mucho menos propensos a la puerta trasera.

Y así sucesivamente. Puedes conducir un auto sin saber mucho sobre física, pero entender la física te hace un mejor conductor.

Dos ejemplos de cómo la comprensión de la arquitectura de la computadora puede afectar la forma en que usted codifica:

• predicción de rama
• Tamaño de caché y patrones de acceso

Básicamente es la misma razón para comprender C y los punteros o quizás incluso los algoritmos; La única diferencia es que si conoces la arquitectura de la computadora, realmente entiendes los punteros (en realidad, los punteros parecen muy triviales después de conocer la arquitectura de la computadora).

No puedo decir sobre mí que soy un programador experimentado, pero un libro (en realidad) sobre arquitectura de computadoras que leí fue para mí el libro más interesante que he leído, relacionado con las computadoras y la programación. Al entender la arquitectura de la computadora, básicamente comprendes cómo todo está enlazado, cómo funciona una computadora y cómo funciona realmente un programa; ves el cuadro grande Sin la arquitectura de la computadora realmente no se puede entender:

• gestión de la memoria: montón, pila, memoria virtual, jerarquía de memoria y los punteros que tanto se hablan (¿por qué hay un desbordamiento de pila, por qué la recursión no es tan buena, etc.)?
• programación de ensamblajes (si desea programar integrado)
• compiladores e intérpretes (si desea comprender las optimizaciones y cuando es inútil optimizar el código porque el compilador ya lo está haciendo)
• enlazadores (bibliotecas enlazadas dinámicamente)
• sistemas operativos (si desea leer el código del kernel de Linux)
• la lista puede continuar ...

Desde mi punto de vista realmente subjetivo, es mucho más interesante y quizás incluso más útil que los algoritmos de conocimiento.

En el mundo de hoy, este razonamiento es insignificante si está presente en la mayoría de las situaciones de programación.

Los lugares a los que se aplica son cuando uno está escribiendo un ensamblaje para un procesador en particular, trabajando en una situación que requiere que uno se aproveche de una arquitectura en particular, o está limitado significativamente por la arquitectura (sistemas integrados) para que los dos anteriores los puntos son cada vez más importantes.

Para los programadores de lenguajes interpretados (perl, python, ruby) o lenguajes que se ejecutan en su propia máquina virtual (java, C #), la máquina subyacente está completamente abstraída. Un programa Java no se codificaría de manera diferente para ejecutarse en un clúster masivo o en el escritorio de uno.

Los casos en los que la arquitectura hace una diferencia, como se mencionó, son los sistemas integrados donde es necesario tener en cuenta las preocupaciones de muy bajo nivel que son para ese entorno. El otro extremo también existe: donde uno escribe código de alto rendimiento en ensamblaje o algo que se compila en código nativo (no se ejecuta en una máquina virtual). En estos extremos, uno se preocupa por lo que encaja en la memoria caché del procesador y qué tan rápido es acceder a diferentes partes de la memoria, de qué manera va la predicción de bifurcación en el procesador (si el procesador utiliza la predicción de bifurcación o retrasa las ranuras). / p>

La cuestión de la predicción de bifurcaciones y las ranuras de retardo o la memoria caché del procesador no entra en la gran mayoría de los problemas de programación y no puede ingresar en lenguajes de máquina virtual o interpretados.

Dicho todo esto, es útil comprender un nivel de lo que está sucediendo uno más profundo que el código existente en el que se está escribiendo. Cuanto más lejos alcanza rápidamente los rendimientos decrecientes. Un programador de Java debe entender un lenguaje de programación con administración de memoria manual y matemática de puntero para entender lo que está pasando debajo de las cubiertas. Un programador de C debería entender el ensamblaje para que uno pueda darse cuenta de qué son los punteros realmente y de dónde viene la memoria realmente . Los programadores de ensamblajes deben estar familiarizados con la arquitectura para comprender qué implican las compensaciones de predicción de ramificación y las ranuras de retardo ... y para ir más lejos, los procesadores que diseñan deben estar familiarizados con la mecánica cuántica de cómo funcionan los semiconductores y las puertas a un nivel muy básico .

Iría tan lejos como para decir que cualquiera que no entienda la organización de computadoras está condenado a ser un mal programador. Lo sabrás:

• cómo organizar sus estructuras de datos y algoritmos para que sean más eficientes en caché
• cómo funciona una llamada a una función, y las implicaciones para llamar a la convención
• los segmentos de la memoria y sus implicaciones para las declaraciones de variables
• cómo leer el ensamblaje y, por lo tanto, interpretar la salida de un compilador
• los efectos del paralelismo a nivel de instrucción y la programación de instrucciones fuera de orden, y lo que eso significa para la ramificación

Básicamente, aprenderá cómo funciona realmente una computadora y, por lo tanto, podrá asignarle su código de manera más efectiva.

Comprender los principios de la arquitectura de computadora requiere aprender muchos principios importantes de programación. Por lo tanto, un conocimiento de la arquitectura de la computadora es relevante para la programación en cualquier lenguaje, sin importar cuán alto sea el nivel.

Estos principios importantes incluyen:

• Estructuras de datos fundamentales como matrices y pilas
• Estructura del programa : bucles, condicionales, subrutinas (salto y llamada)
• Consideraciones de eficiencia de tiempo y espacio
• Sistemas: la forma en que varios componentes se combinan a través de interfaces abstractas. Aparentemente esto es controvertido, así que lo explicaré. Tome el conjunto de instrucciones, una construcción con una forma general (operandos, modos de direccionamiento, codificación) eso es aplicable a muchos tipos diferentes de operaciones, como aritmética, lógica, modificación de memoria y control de interrupciones. Esto ilustra un principio general del diseño del sistema, a saber, que los sistemas están compuestos por subsistemas individuales que comparten todos los mismos interfaz abstracta, y que las interfaces abstractas son capaces de manejar muchos componentes específicos. Este principio también es visible en una aplicación web. que puede almacenar el mismo tipo de objeto (interfaz abstracta) en una base de datos, en la memoria o en una página web (subsistemas). En cada caso, la interfaz abstracta. Especifica la forma general sin especificar el detalle concreto. El diseño de sistemas es el arte de saber qué hacer general y qué hacer específico. Esta es una habilidad perfeccionada mediante el diseño y la comprensión de sistemas, en cualquier idioma y en cualquier nivel.

Actualización 2018: ¿Cuántos desarrolladores de software se necesitan para cambiar una bombilla? ¿¡A quien le importa!? ¡Eso es un problema de hardware!

En general NO, no necesita conocer la arquitectura de la computadora para ser un buen programador, eso es más en el ámbito de EEO de EEO .. a menos que esté en el desarrollo de sistemas integrados, pero en En ese caso, está casado con el chip y la programación directamente en él, por lo que deberá conocer la arquitectura de ESE "computadora" (e incluso entonces puede que no importe), pero tener un conocimiento arquitectónico general de cómo funcionan las computadoras. ser bueno para mucho más que las discusiones de pozos de agua.

Yo diría que es aún menos importante en estos días a la velocidad en que el hardware está disminuyendo en precio y el rendimiento está mejorando / aumentando y la rapidez con la que las tecnologías están cambiando y los idiomas están evolucionando. Las estructuras de datos y los patrones de diseño no tienen mucho que ver con la arquitectura del hardware físico, que yo sepa.

En general, los programadores provienen de un entorno informático, en cuyo caso, es más que probable que hayan tomado clases de arquitectura informática, pero hoy en día, los sistemas operativos se están volviendo virtuales, el espacio en disco es compartido, la memoria es escalable, etc. .. etc ..

He podido hacer una gran carrera en la programación (más de 10 años) y tengo muy poco conocimiento educativo de arquitectura de computadoras, principalmente porque ... ¡¡era un estudiante de arte !!

Actualización: Para ser justos, MI "poco conocimiento educativo" vino de mi CPU Sci. Menor. y aún así, nunca he necesitado usar nada de lo que aprendí de mis clases de ensamblaje o mis clases de arquitectura de computadoras en mi carrera de "Programación".

Incluso ahora cuando juego con algunas ideas de Mesh Networking Idea implementando la especificación de ZigBee , he encontrado que al usar los productos y herramientas disponible ( XBee ), puedo programar en Python y coloque el código en el chip (SoC) y haga algunas cosas realmente buenas con él. TODO sin tener que preocuparse por nada que tenga que ver con la arquitectura real de los chips, etc. ... definitivamente hay limitaciones de hardware para ser cognitivas debido al tamaño del chip y al objetivo de bajo precio previsto ... pero incluso ESO será menos en los próximos años. Por lo tanto, estoy a la altura de mi respuesta "Generalmente NO"

En realidad puede ayudar bastante. Comprender conceptos como la memoria compartida y la comunicación entre procesadores y los posibles retrasos relacionados con estos pueden ayudar al programador a organizar sus datos y métodos comunicativos para evitar depender en gran medida de estos mecanismos, si es necesario. Esto es cierto para otras áreas de la programación, como la escala horizontal, donde la distribución y la comunicación entre un programa o sistema de programas es un punto focal principal.

Comprender los escollos o fosas de alquitrán de un sistema físico puede ayudarlo a organizar dicho programa para ayudarlo a negociar los sistemas físicos de la manera más rápida y eficiente posible. El simple hecho de enviar datos a una cola de comunicación y esperar que se amplíe es una visión oculta de lo que realmente debe implementarse, especialmente si debe escalar su software a sistemas más grandes para un mejor soporte.

Igualmente, entender los beneficios de algo como la programación funcional puede ejemplificarse realmente a la luz de entender lo que está sucediendo a nivel físico, de sistemas y, por lo tanto, hace aún más atractivo para conceptos como estos, en mi opinión.

Un último y rápido ejemplo podría ser comprender el concepto de proceso de transmisión de datos y cómo se puede hacer mejor el envío de datos a una unidad de procesamiento como una tarjeta de video de una manera muy específica, como por ejemplo: enviar todos los cálculos necesarios, volver a recibir El marco de datos de una sola vez cayó. En algo como gráficos de video o quizás incluso cálculos físicos, no querría tener una comunicación abierta con un dispositivo de este tipo; por lo tanto, sabiendo esto, querría organizar esta parte de su programa como tal.

Después de todo, si los programadores no entendieran estos problemas y obstáculos, estas soluciones nunca existirían en el formato que tienen.

Conocer su arquitectura le permite saber cuándo es imposible algo que se solicita.

Una vez me pidieron que escribiera un programa para comunicarme con un PIC a través de un puerto serie de PC. El protocolo tendría el PIC enviando bytes de nueve bits, sin control de flujo. Mostraría en la IU de mi programa los valores de los campos en los paquetes que envió el PIC. Pregunta obvia: ¿cómo leo el noveno bit de cada byte? El ingeniero de protocolo y yo decidimos que intentaríamos establecer la paridad en MARCAR y luego trataríamos el noveno bit como un bit de paridad. Leería el valor del noveno bit de acuerdo con el éxito o el fracaso de la verificación de paridad. Bueno, implementé eso, y no funcionó. Los valores mostrados estaban obviamente equivocados. Y después de tres días continuos de investigación sobre la arquitectura de PC UART, descubrí por qué.

He aquí por qué. El PC UART almacena su entrada. En el momento en que interrumpe la CPU para decir "LISTO PARA LEER", cualquier número de bytes podría haberse acumulado en su búfer. Sin embargo, solo hay un registro de estado de línea para mantener el valor del control de paridad. Por lo tanto, es imposible decir qué byte en el búfer falló la verificación de paridad. Entonces, ¿asegúrate de que el búfer solo tiene un byte de largo, dices? Esa es una configuración de control de flujo, y ya mencioné que este protocolo no tenía control de flujo. Si no supiera la arquitectura del hardware que estaba programando, nunca habría podido decir: "Leer el noveno bit es imposible y hay que cortarlo".

El aprendizaje de la arquitectura de la computadora ayuda enormemente en la programación.

Sin entender el entorno en el que se está ejecutando el programa, su modelo mental está seriamente impedido. Vemos el mundo, no como es, sino como somos nosotros, a través del modelo mental.

No notará la diferencia en los escenarios de casos felices, donde todo funciona, pero marcará una diferencia crucial cuando esté trabajando en problemas más difíciles o depurando errores extraños (es decir, programación de la vida real).

Es la diferencia entre "WTF?" y "¡Ah, por supuesto!".