tipos son serial protocolos los introduccion electronica cuales comunicacion clasificacion language-agnostic parallel-processing concurrency

language agnostic - son - ¿Cuál es la diferencia entre programación concurrente y programación paralela?



protocolos de comunicacion pdf (14)

¿Cuál es la diferencia entre programación concurrente y programación paralela? Le pregunté a Google pero no encontré nada que me ayudara a entender esa diferencia. ¿Podría darme un ejemplo para ambos?

Por ahora encontré esta explicación: http://www.linux-mag.com/id/7411 - pero "la concurrencia es una propiedad del programa" vs "la ejecución paralela es una propiedad de la máquina" no es suficiente para mí - Todavía no puedo decir qué es qué.

En programación, la concurrencia es la composición de procesos de ejecución independiente, mientras que el paralelismo es la ejecución simultánea de cálculos (posiblemente relacionados).
- Andrew Gerrand -

Y

La concurrencia es la composición de los cálculos de ejecución independiente. La concurrencia es una forma de estructurar el software, particularmente como una forma de escribir código limpio que interactúa bien con el mundo real. No es paralelismo.

La concurrencia no es el paralelismo, aunque permite el paralelismo. Si solo tiene un procesador, su programa aún puede ser concurrente pero no puede ser paralelo. Por otro lado, un programa concurrente bien escrito podría ejecutarse de manera eficiente en paralelo en un multiprocesador. Esa propiedad podría ser importante ...
- Rob Pike -

Para entender la diferencia, recomiendo ver este video de Rob Pike (uno de los creadores de Golang). La concurrencia no es paralelismo

  • Concurrent programming es, en un sentido general, referirse a entornos en los que las tareas que definimos pueden ocurrir en cualquier orden. Una tarea puede ocurrir antes o después de otra, y algunas o todas las tareas pueden realizarse al mismo tiempo.

  • Parallel programming es referirse específicamente a la ejecución simultánea de tareas concurrentes en diferentes procesadores. Por lo tanto, toda la programación paralela es concurrente, pero no toda la programación concurrente es paralela.

Fuente: Programación PThreads - Un estándar POSIX para un mejor multiprocesamiento, Buttlar, Farrell, Nichols

1. Definiciones:

La programación clásica de tareas puede ser SERIAL , PARALLEL o CONCURRENT

SERIAL: análisis muestra que las tareas DEBEN SER ejecutadas una después de la otra en un orden conocido de secuencia trucada O no funcionará .

Es decir: Bastante fácil, podemos vivir con esto.

PARALLEL: análisis muestra que las tareas DEBEN SER ejecutadas al mismo tiempo O no funcionará .

  • Cualquier falla en cualquiera de las tareas, funcionalmente o en el tiempo, resultará en una falla total del sistema.
  • Todas las tareas deben tener un sentido común y confiable del tiempo.

Es decir: intenta evitar esto o tendremos lágrimas a la hora del té.

CONCURRENT. El análisis muestra que no necesitamos atención . No somos descuidados, lo hemos analizado y no importa; Por lo tanto, podemos ejecutar cualquier tarea utilizando cualquier servicio disponible en cualquier momento.

Es decir: FELICES DÍAS

A menudo, la programación disponible cambia en eventos conocidos que llamé un cambio de estado.

2. Esto no es un {Software | Programación} Característica pero un enfoque de diseño de sistemas :

La gente suele pensar que se trata de software, pero de hecho es un concepto de diseño de sistemas que precede a las computadoras

Los sistemas de software fueron un poco lentos en su uso, muy pocos idiomas de software intentaron abordar el problema.

Si está interesado en un buen intento, puede intentar buscar el lenguaje de occam .

( occam tiene muchas características principalmente innovadoras (si no son insuperables), incluido el soporte de lenguaje explícito para los constructores de ejecución de partes de código PAR y SER que otros lenguajes sufren principalmente en la próxima generación de Arrays de Procesadores Paralelos Masivos disponibles en los últimos años, reinventar la rueda InMOS Transputers utilizados hace más de 35 años (!!!))

3. Lo que un buen Diseño de Sistemas se ocupa de cubrir:

Sucintamente, el diseño de sistemas aborda lo siguiente:

EL VERBO - ¿Qué estás haciendo? ( operación o algoritmo )

THE NOUN - A que lo estas haciendo ( Datos o interfaz )

CUANDO - Iniciación, horario, cambios de estado, SERIAL , PARALLEL , CONCURRENT

DÓNDE: una vez que sabes cuándo suceden las cosas, puedes decir dónde pueden suceder y no antes.

POR QUÉ - ¿Es esta una manera de hacerlo? ¿Hay alguna otra manera? ¿Hay una mejor manera?

.. y por último pero no menos importante ... ¿QUÉ PASA SI NO LO HACES?

4. Ejemplos visuales de enfoques PARALELOS vs. SERIALES :

Arquitecturas paralelas recientes disponibles en 2014 en acción en matrices de 16-, 64-, 1024- RISC uP-s paralelo

Un cuarto de siglo atrás: una parte de la verdadera historia paralela con el video de demostración de CPU Inmos Transputer de principios de la década de 1990

Buena suerte

Aunque no hay un acuerdo completo sobre la distinción entre los términos paralelo y concurrente , muchos autores hacen las siguientes distinciones:

  • En computación concurrente, un programa es aquel en el que se pueden realizar múltiples tareas en cualquier momento.
  • En computación paralela, un programa es aquel en el que múltiples tareas cooperan estrechamente para resolver un problema.

Por lo tanto, los programas paralelos son concurrentes, pero un programa como un sistema operativo multitarea también es concurrente, incluso cuando se ejecuta en una máquina con un solo núcleo, ya que múltiples tareas pueden estar en progreso en cualquier momento.

Fuente : Introducción a la programación paralela, Peter Pacheco.

Creo que la programación concurrente se refiere a la programación multiproceso, que consiste en permitir que su programa ejecute varios subprocesos, abstenido de los detalles de hardware.

La programación paralela se refiere al diseño específico de los algoritmos de su programa para aprovechar la ejecución paralela disponible. Por ejemplo, puede ejecutar en paralelo dos ramas de algunos algoritmos con la expectativa de que alcanzará el resultado antes (en promedio) que si primero verificara la primera y luego la segunda rama.

Encontré este contenido en algún blog. Pensé que es útil y relevante.

La concurrencia y el paralelismo NO son lo mismo. Dos tareas T1 y T2 son concurrentes si el orden en el que las dos tareas se ejecutan a tiempo no está predeterminado,

T1 se puede ejecutar y terminar antes de que T2, T2 se pueda ejecutar y terminar antes de que T1, T1 y T2 se puedan ejecutar simultáneamente en la misma instancia de tiempo (paralelismo), T1 y T2 se pueden ejecutar alternativamente, ... Si dos subprocesos concurrentes están programados por el sistema operativo para ejecutarse en un procesador de un solo núcleo que no sea SMT sin CMP, puede obtener concurrencia pero no paralelismo. El paralelismo es posible en sistemas multinúcleo, multiprocesador o distribuidos.

La concurrencia a menudo se denomina propiedad de un programa y es un concepto más general que el paralelismo.

Fuente: https://blogs.oracle.com/yuanlin/entry/concurrency_vs_parallelism_concurrent_programming

Entendí que la diferencia era:

1) Concurrente - ejecutándose en tándem usando recursos compartidos 2) Paralelo - ejecutando lado a lado usando diferentes recursos

Por lo tanto, es posible que ocurran dos cosas al mismo tiempo independientes entre sí, incluso si se unen en los puntos (2) o dos cosas que se acumulan en las mismas reservas en todas las operaciones que se ejecutan (1).

Interpretar la pregunta original como cómputo paralelo / concurrente en lugar de programación .

En la computación concurrente, dos computaciones avanzan independientemente una de la otra. El segundo cálculo no tiene que esperar hasta que finalice el primero para que avance. No establece sin embargo, el mecanismo de cómo se logra esto. En la configuración de un solo núcleo, se requiere la suspensión y alternancia de subprocesos (también llamado multithreading preventivo ).

En el cálculo paralelo, ambos cálculos avanzan simultáneamente , es decir, literalmente al mismo tiempo. Esto no es posible con una sola CPU y requiere una configuración multi-core en su lugar.

versus

De acuerdo con: "Paralelo vs Concurrente en Node.js" .

La programación concurrente se refiere a las operaciones que parecen superponerse y está relacionada principalmente con la complejidad que surge debido al flujo de control no determinista. Los costos cuantitativos asociados con los programas concurrentes suelen ser tanto el rendimiento como la latencia. Los programas concurrentes a menudo están enlazados a IO pero no siempre, por ejemplo, los recolectores de basura concurrentes están completamente en la CPU. El ejemplo pedagógico de un programa concurrente es un rastreador web. Este programa inicia las solicitudes de páginas web y acepta las respuestas simultáneamente a medida que los resultados de las descargas están disponibles, acumulando un conjunto de páginas que ya se han visitado. El flujo de control no es determinista porque las respuestas no se reciben necesariamente en el mismo orden cada vez que se ejecuta el programa. Esta característica puede hacer que sea muy difícil depurar programas concurrentes. Algunas aplicaciones son fundamentalmente concurrentes, por ejemplo, los servidores web deben manejar las conexiones de los clientes al mismo tiempo. Erlang es quizás el lenguaje más prometedor para la programación altamente concurrente.

La programación paralela se refiere a operaciones que se superponen para el objetivo específico de mejorar el rendimiento. Las dificultades de la programación concurrente se evitan al hacer que el flujo de control sea determinista. Normalmente, los programas generan conjuntos de tareas secundarias que se ejecutan en paralelo y la tarea principal solo continúa una vez que cada subtarea ha terminado. Esto hace que los programas paralelos sean mucho más fáciles de depurar. La parte difícil de la programación paralela es la optimización del rendimiento con respecto a cuestiones como la granularidad y la comunicación. Este último sigue siendo un problema en el contexto de los multinúcleos porque hay un costo considerable asociado con la transferencia de datos de un caché a otro. La matriz matriz densa multiplicada es un ejemplo pedagógico de programación paralela y se puede resolver de manera eficiente mediante el uso del algoritmo de dividir y conquistar de Straasen y atacar los subproblemas en paralelo. Cilk es quizás el lenguaje más prometedor para la programación paralela de alto rendimiento en computadoras con memoria compartida (incluidos los multinúcleos).

La programación paralela ocurre cuando el código se ejecuta al mismo tiempo y cada ejecución es independiente de la otra. Por lo tanto, generalmente no hay una preocupación por las variables compartidas y eso porque eso probablemente no sucederá.

Sin embargo, la programación concurrente consiste en que el código se ejecute mediante diferentes procesos / subprocesos que comparten variables y, por lo tanto, en la programación concurrente, debemos establecer algún tipo de regla para decidir qué proceso / subproceso se ejecuta primero, lo queremos para que podamos estar seguros de que habrá Se coherencia y que podamos saber con certeza lo que sucederá. Si no hay control y todos los subprocesos se calculan al mismo tiempo y almacenan cosas en las mismas variables, ¿cómo sabremos qué esperar al final? Tal vez un hilo sea más rápido que el otro, tal vez uno de los hilos incluso se detuvo en medio de su ejecución y otro continuó una computación diferente con una variable dañada (aún no totalmente calculada), las posibilidades son infinitas. Es en estas situaciones que usualmente usamos programación concurrente en lugar de paralela.

Si programa utilizando subprocesos (programación concurrente), no necesariamente se ejecutará como tal (ejecución paralela), ya que depende de si la máquina puede manejar varios subprocesos.

Aquí hay un ejemplo visual. Hilos en una máquina no roscada:

-- -- -- / / >---- -- -- -- -- ---->>

Hilos en una máquina roscada:

------ / / >-------------->>

Los guiones representan código ejecutado. Como puede ver, ambos se dividen y se ejecutan por separado, pero la máquina con hilos puede ejecutar varias partes separadas a la vez.

Son dos frases que describen lo mismo desde puntos de vista (muy ligeramente) diferentes. La programación paralela describe la situación desde el punto de vista del hardware: hay al menos dos procesadores (posiblemente dentro de un solo paquete físico) trabajando en un problema en paralelo. La programación concurrente está describiendo las cosas más desde el punto de vista del software: dos o más acciones pueden suceder exactamente al mismo tiempo (al mismo tiempo).

El problema aquí es que las personas están tratando de usar las dos frases para hacer una distinción clara cuando en realidad no existe. La realidad es que la línea divisoria que intentan dibujar ha sido borrosa e indistinta durante décadas, y se ha vuelto cada vez más indistinta con el tiempo.

Lo que están tratando de discutir es el hecho de que una vez, la mayoría de las computadoras tenían una sola CPU. Cuando ejecutó varios procesos (o subprocesos) en esa única CPU, la CPU solo estaba ejecutando realmente una instrucción desde uno de esos subprocesos a la vez. La apariencia de concurrencia era una ilusión: la CPU que cambia entre la ejecución de instrucciones de diferentes subprocesos lo suficientemente rápida como para la percepción humana (a la que cualquier cosa menos de 100 ms aproximadamente parece instantánea) parecía que estaba haciendo muchas cosas a la vez.

El contraste obvio con esto es una computadora con múltiples CPU o una CPU con múltiples núcleos, por lo que la máquina está ejecutando instrucciones desde varios subprocesos y / o procesos exactamente al mismo tiempo; el código que ejecuta uno no puede / no tiene ningún efecto en el código que se ejecuta en el otro.

Ahora el problema: una distinción tan limpia casi nunca ha existido. Los diseñadores de computadoras son en realidad bastante inteligentes, por lo que notaron hace mucho tiempo que (por ejemplo) cuando necesitaban leer algunos datos de un dispositivo de E / S como un disco, tomó mucho tiempo (en términos de ciclos de CPU) para terminar. En lugar de dejar la CPU inactiva mientras ocurría, descubrieron varias formas de permitir que un proceso / subproceso realice una solicitud de E / S, y permiten que el código de algún otro proceso / subproceso se ejecute en la CPU mientras se completa la solicitud de E / S.

Por lo tanto, mucho antes de que las CPU de múltiples núcleos se convirtieran en la norma, tuvimos operaciones de varios subprocesos que sucedían en paralelo.

Eso es solo la punta del iceberg. Hace décadas, las computadoras comenzaron a proporcionar otro nivel de paralelismo también. Nuevamente, siendo personas bastante inteligentes, los diseñadores de computadoras notaron que en muchos casos tenían instrucciones que no se afectaban entre sí, por lo que era posible ejecutar más de una instrucción de la misma secuencia al mismo tiempo. Un ejemplo temprano que se hizo bastante conocido fue el Control Data 6600. Esta fue (por un margen bastante amplio) la computadora más rápida del mundo cuando se introdujo en 1964, y gran parte de la misma arquitectura básica sigue en uso hoy en día. Rastreaba los recursos utilizados por cada instrucción y tenía un conjunto de unidades de ejecución que ejecutaban las instrucciones tan pronto como los recursos de los que dependían estaban disponibles, muy similar al diseño de los procesadores Intel / AMD más recientes.

Pero (como solían decir los comerciales) espera, eso no es todo. Hay otro elemento de diseño para agregar aún más confusión. Se le han dado varios nombres diferentes (por ejemplo, "Hyperthreading", "SMT", "CMP"), pero todos se refieren a la misma idea básica: una CPU que puede ejecutar varios subprocesos simultáneamente, utilizando una combinación de algunos recursos que son independientes para cada subproceso y algunos recursos que se comparten entre los subprocesos. En un caso típico, esto se combina con el paralelismo a nivel de instrucción descrito anteriormente. Para hacer eso, tenemos dos (o más) conjuntos de registros arquitectónicos. Luego tenemos un conjunto de unidades de ejecución que pueden ejecutar instrucciones tan pronto como los recursos necesarios estén disponibles. Estos a menudo se combinan bien porque las instrucciones de los flujos separados casi nunca dependen de los mismos recursos.

Luego, por supuesto, llegamos a los sistemas modernos con múltiples núcleos. Aquí las cosas son obvias, ¿verdad? Tenemos N (en algún lugar entre 2 y 256 o más, en este momento) núcleos separados, que pueden ejecutar instrucciones al mismo tiempo, por lo que tenemos un caso claro de paralelismo real: ejecutar instrucciones en un proceso / subproceso no lo hace Afecta a ejecutar instrucciones en otro.

Especie de. Incluso aquí tenemos algunos recursos independientes (registros, unidades de ejecución, al menos un nivel de caché) y algunos recursos compartidos (generalmente al menos el nivel más bajo de caché, y definitivamente los controladores de memoria y el ancho de banda a la memoria).

Para resumir: los escenarios simples que a las personas les gusta contrastar entre recursos compartidos y recursos independientes prácticamente nunca suceden en la vida real. Con todos los recursos compartidos, terminamos con algo como MS-DOS, donde solo podemos ejecutar un programa a la vez, y debemos dejar de ejecutar uno antes de que podamos ejecutar el otro. Con recursos completamente independientes, tenemos N computadoras que ejecutan MS-DOS (sin siquiera una red para conectarlas) sin capacidad para compartir nada entre ellas (porque si incluso podemos compartir un archivo, eso es un recurso compartido, un recurso violación de la premisa básica de no compartir nada).

Cada caso interesante implica una combinación de recursos independientes y recursos compartidos. Todas las computadoras razonablemente modernas (y muchas que no son en absoluto modernas) tienen al menos alguna capacidad para realizar al menos algunas operaciones independientes simultáneamente, y casi cualquier cosa más sofisticada que MS-DOS ha aprovechado eso al menos algun grado.

La división agradable y limpia entre "concurrente" y "paralelo" que a la gente le gusta dibujar simplemente no existe, y casi nunca lo ha hecho. Lo que a la gente le gusta clasificar como "concurrente" generalmente implica al menos uno y, a menudo, más tipos diferentes de ejecución paralela. Lo que les gusta clasificar como "paralelos" a menudo implica compartir recursos y (por ejemplo) un proceso que bloquea la ejecución de otro mientras usa un recurso compartido entre los dos.

Las personas que intentan establecer una distinción clara entre "paralelo" y "concurrente" viven en una fantasía de computadoras que nunca existieron.