Paralelización de procesos

Cuando se programa un algoritmo, se pueden ir resolviendo sus partes en serie o en paralelo.

La opción de paralelizar, en efecto aumenta el rendimiento cuando hay una etapa que tiene un elevado período de espera, ya que las otras pueden seguir avanzando.

Una de las novedades de Windows XP, era que durante el proceso de arranque se paralelizaban los procesos de comprobación y chequeo. De esta forma no había que esperar hasta que un dispositivo respondiese, o diera timeout, para ir repitiendo el proceso con los otros dispositivos.

Que la aplicación de esta idea es buena, lo demuestra el artículo que leo en Anedonia.net, informando que los desarrolladores de Linux, están trabajando para incorporar esta característica en el proceso de arranque.

Las ventajas de paralelizar procesos usando hilos de ejecución en procesadores multi-core, o con Hyperthreading, ya se comentaron en el pasado artículo titulado Hyperthreading y las aplicaciones.

A nivel general siempre que hay un recurso redundante o duplicado, es conveniente paralelizar. Sean varios dispositivos a inicializar, o varios procesadores.

En cambio, es una filosofía que a pesar de sus grandes ventajas, no suele explotarse al máximo. En concreto, es especialmente determinante el trabajo con discos.

Los discos son un dispositivo lento, y operar con ellos supone un cuello de botella casi por definición. En este caso, es donde si paralelizásemos las tareas, obtendríamos ganancias más espectaculares. Como los discos operan lentamente, las operaciones donde intervienen, duran mucho tiempo. Si lográsemos reducir el tiempo necesario en un pequeño porcentaje, el ahorro en valor absoluto, sería influyente.

Por ejemplo, los desfragmentadores de disco, no permiten reorganizar todos los discos al mismo tiempo. En mi caso primero defragmento mi disco C:, y cuando ha acabado, hago lo mismo con D:. Teniendo dos discos duros, es evidente que el proceso tardaría casi la mitad si se paralelizase.

La ejecución de CHKDSK, bajo demanda, o bien automáticamente tras un apagado incorrecto, también se ejecuta en serie. Escaneando primero un disco, y al acabar el siguiente. Lo mismo ocurre con la herramienta de comprobación de discos con interfaz GUI. De nuevo el ahorro sería de casi el 50%.

Los antivirus funcionan de esta misma manera, primero se analiza el contenido de un disco, y luego el del siguiente. En este caso, el consumo de CPU es más elevado que en las situaciones anteriores, por lo que paralelizar ahorraría un 30% o 40% del tiempo.

El defecto de diseño causado por ejecutar los procesos en serie, es especialmente palpable en aquellos casos en los que la multitarea no está disponible, y no es posible realizar ningún otro trabajo con el ordenador. Es el caso del arranque del sistema operativo, o de la comprobación de discos tras un apagado irregular.

14 comentarios en “Paralelización de procesos”

  1. Otro sitio donde se ganaria tiempo es en la busqueda de archivos en varios discos duros. El buscador que trae Windows lo hace de forma secuencial no en paralelo.

  2. Javier Gutiérrez Chamorro (Guti)

    Pues es verdad Bleach, la verdad que no había caído en eso, pero seguro que todos perdemos multitud de tiempo al día buscando en varios discos.

  3. Muy bueno el artículo.
    Sólo una pequeña matización, y es que no es siempre posible la paralelización y en ocasiones el coste de paralelizar un proceso tarda más tiempo que si se ejecutara ese mismo proceso secuencialmente, por ello hay que estudiar el rendimiento muy bien antes de paralelizar.
    Ahhh, y el disco duro no es ningún periférico 🙂

    Salu2

  4. Genial, muy interesante ^^.
    ¿Linux si busca paralelamente no? Porque le da 1000 vueltas al buscador de Windows, tarda muchísimo menos.
    Enhorabuena.
    Saludos!

  5. Javier Gutiérrez Chamorro (Guti)

    Cek, tu corrección me ha hecho dudar, ya que yo tenía claro que un disco duro era un periférico, así que he ido a la wikipedia a consultar la definición en español de periférico de ordenador. Por lo que dice, hoy en día no está claro que el disco sea un periférico. En la definición en inglés de data storeage device, parece que si que lo es.

    Al final, la definición de disco duro parece aclarar las cosas, ya que lo denomina dispositivo, que me parece mucho más coherente, por lo que de inmediato rectifico el artículo. Así que gracias por la corrección Cek.

    Tantoril, que yo sepa, *NIX no buscan en paralelo, solamente que los sistemas de archvos que en general usan, suelen ser más eficientes en el setido de las búsquedas.

  6. De nada 🙂

    El caso es que me hace dudar ahora, como existen discos duros USB que son externos en ese caso sí se podría considerar como periférico, puesto que al ser externo está en la periferia y no dentro.

    En cualquier caso los HD de toda la vida no son periféricos. 🙂

    Salu2

  7. Ahora que lo leo no veo en ningún sitio en el enlace en inglés en que diga que el disco duro sea un periférico, simplemente dice que es un data storage device, es decir, un dispositivo de almacenamiento de datos.
    Sin embargo en http://en.wikipedia.org/wiki/Peripheral sí que lo mete dentro de periféricos y también la RAM. Cosa curiosa, a lo mejor pronto meten también al procesador, jejeje 🙂

  8. Puede que consideren periférico a cualquier cosa externa a la CPU.

    A muy bajo nivel, acceder a la RAM o al controlador de un dispositivo externo no deja de ser un acceso a una dirección de memoria, sobre todo cuando los controladores comparten los buses de datos y direcciones: basta hacer un RD o ST en la dirección de memoria correspondiente al controlador y se envían/reciben la información por el bus de datos.

    De todos modos, yo llamaría periférico a los dispositivos completamente externos.

  9. ¿Linux si busca paralelamente no? Porque le da 1000 vueltas al buscador de Windows, tarda muchísimo menos.

    Pues no, lo que pasa es que utiliza una base de datos con todos los ficheros (man updatedb) y en base a eso funciona el locate.

    Si no recuerdo mal:

    El programa de la base de datos (updatedb) se actualiza solo mediante cron. El archivo de la base de datos creo que era /var/cache/locate/locatedb. Y digo creo por que yo uso slocate y este guarda la base de datos en /var/lib/slocate/slocate.db Puedes hacer la prueba mirando la fecha de ultima actualización, ejecutar updatedb y comprobar como ha cambiado la hora del fichero.

    Bueno, creo no equivocarme pero como siempre se ha recomendado, sigue el método empirico 😉

  10. Uups, no me fije que la dirección de correo aparecia al comentar y ademas no salia ofuscada… ¿Guti podrias añadirle un NOSPAM_GRACIAS? 😉

  11. Javier Gutiérrez Chamorro (Guti)

    Cek, tradicionalmente cuando yo lo estudié, había CPU, memoria, y el resto eran periféricos de E/S.

    Parece que a medida que pasa el tiempo, hay componentes que pasan a ser indispensables del ordenador, por ello lo de que el HD no se considere periférico. Pero en ese caso, porque hay definiciones en las que la RAM también lo es?

    Me gusta la definición de Oscar, que añade el matiz de totalmente externo.

    Armonth, gracias por la contribución del buscador de Linux, la verdad que no tenía ni idea de que usase una base de datos de índices. Tampoco te preocupes por tu dirección de email, si miras el código fuente, verás que está suficientemente protegida.

  12. En esta página hay un programa con el codigo fuente para hacer busquedas en paralelo.
    Esta programado en Delphi y se pueden conseguir los codigos fuente.

  13. Javier Gutiérrez Chamorro (Guti)

    No he tenido tiempo de mirarme los fuentes, pero si de probar el binario. Aunque la interfaz no está pensada para lo que decía mi artículo la idea es justo esa.

Deja un comentario