cpu - sueldo - funciones de un desarrollador de software
¿El advenimiento de las arquitecturas MultiCore me afecta como desarrollador de software? (11)
Como desarrollador de software que se ocupa principalmente de lenguajes de programación de alto nivel, no estoy seguro de qué puedo hacer para prestar atención de forma apropiada a la omnipresencia futura de las computadoras multinúcleo. Escribo principalmente aplicaciones comunes y no exigentes, sin embargo, creo que es importante saber si necesito cambiar algún paradigma de programación o incluso el lenguaje para dominar el futuro.
Mi pregunta por lo tanto:
How to deal with increasing multicore presence in day-by-day hacking?
Aprenda OpenMP y MPI para el código C y C ++.
OpenMP también se aplica a otros idiomas, así como a Fortran, supongo.
Aprende Erlang / F # (dependiendo de tu plataforma)
Conozca los beneficios de la concurrencia y los límites (por ejemplo, la ley de Amdahl).
Para que pueda, cuando sea posible, explotar la única ruta para un mayor rendimiento que estará abierto. Se están realizando muchos trabajos innovadores en enfoques más fáciles (bibliotecas de futuros y de tareas) y se redescubre el trabajo anterior (lenguajes funcionales y datos inmutables).
El almuerzo gratis ha terminado, pero eso no significa que no haya nada que explotar.
Creo que dependerá del tipo de aplicaciones que estés escribiendo.
Algunas aplicaciones se benefician más del hecho de que se ejecutan en una CPU de varios núcleos y otras. Si su aplicación se puede beneficiar del hecho de varios núcleos, entonces debe estar listo para ir en paralelo. El almuerzo gratis ha terminado; es decir: en el pasado, su aplicación se volvió más rápida cuando se lanzó una nueva CPU y no tuvo que esforzarse en su aplicación para obtener esa velocidad extra. Ahora, para aprovechar las capacidades que ofrece una CPU multinúcleo, debe asegurarse de que su aplicación pueda aprovecharla. Es decir: debe ver qué tareas se pueden ejecutar en subprocesos / concurrentemente, y esto trae algunos problemas a la tabla ...
En general, hazte muy amigable con el enhebrado. Es un mecanismo terrible para la paralelización, pero es lo que tenemos.
Si trabaja con .NET, mire las Extensiones Paralelas. Le permiten realizar fácilmente muchas tareas de programación paralelas.
Herb Sutter escribió sobre esto en 2005: El almuerzo gratis ha terminado: un giro fundamental hacia la concurrencia en el software
La mayoría de los problemas no requieren mucho tiempo de CPU. Realmente, los núcleos individuales son bastante rápidos para muchos propósitos. Cuando descubra que su programa es demasiado lento, primero perfilelo y observe su elección de algoritmos, arquitectura y almacenamiento en caché. Si eso no te da suficiente, trata de dividir el problema en procesos separados. A menudo, esto vale la pena simplemente para el aislamiento de fallas y para que pueda comprender el uso de la CPU y la memoria de cada proceso. Además, normalmente cada proceso se ejecutará en un núcleo específico y hará un buen uso de los cachés del procesador, por lo que no tendrá que sufrir la sobrecarga de rendimiento sustancial de mantener constantes las líneas de caché. Si opta por un diseño de proceso múltiple y todavía encuentra que el problema necesita más tiempo de CPU del que obtiene con la máquina que tiene, está en una buena posición para extenderlo y ejecutarlo en un clúster.
Hay situaciones en las que necesita varios subprocesos dentro del mismo espacio de direcciones, pero tenga en cuenta que los subprocesos son realmente difíciles de corregir. Las condiciones de carrera, especialmente en idiomas no seguros, a veces tardan semanas en depurarse; a menudo, simplemente agregar seguimiento o ejecutar bajo un depurador cambiará los tiempos lo suficiente para ocultar el problema. Simplemente poner cerraduras en todas partes a menudo significa que tienes muchos bloqueos y, a veces, tanta contención de bloqueo que realmente no obtienes la ventaja de concurrencia que esperabas. Incluso cuando tiene el bloqueo correcto, necesita un perfil para sintonizar la coherencia de la caché. En última instancia, si realmente desea sintonizar un código altamente concurrente, probablemente terminará buscando construcciones sin bloqueo y esquemas de bloqueo más complejos que aquellos en las bibliotecas actuales de multi-threading.
Me han hecho la misma pregunta y la respuesta es "depende". Si sus Joe Winforms, tal vez no tanto. Si su código de escritura debe ser eficaz, sí. Uno de los mayores problemas que puedo ver con la programación paralela es el siguiente: si algo no se puede paralistar, y se miente y se le dice que el tiempo de ejecución lo haga en paralelo, no va a fallar, solo va a hacer las cosas mal , y obtendrá resultados desagradables y culpará al marco.
Para beneficiarse de más de un solo núcleo, debería considerar la posibilidad de paralelizar su código. Múltiples hilos, tipos inmutables y un mínimo de sincronización son tus nuevos amigos.
Escribir programas más pequeños.
Otros lenguajes / estilos de código le permitirán hacer un multihebra mejor (aunque el multihilo todavía es muy difícil en cualquier idioma), pero el gran beneficio para los desarrolladores regulares, en mi humilde opinión, es la capacidad de ejecutar muchos programas más pequeños al mismo tiempo para realizar tareas mucho más grandes.
Por lo tanto, acostúmbrese a dividir sus problemas en componentes independientes que puedan ejecutarse cuando lo desee.
También creará un software más fácil de mantener.