Jump to content

ARTICULO: GRAND CENTRAL


Recommended Posts

Bueno, dado que la característica más importante de Snow Leopard es una cosa pelín oscura, y muy oculta dentro de las tripas del sistema operativo, este largo artículo pretende explicar de manera asequible qué es, por qué es importante, qué tiene de innovador, y, en definitiva, qué mejoras se espera que note el usuario, que es de lo que se trata.

 

Un poco de paciencia con la longitud, y ánimo ;)

 

GRAND CENTRAL (el enlace)

Edited by borjam
Link to post
Share on other sites

Hola:

 

Enhorabuena por el articulo. A ver que es lo que ha hecho Apple... :)

 

 

Tengo la sensacion que todo esto solo debe de ir bien en maquinas con arquitecturas muy modernas...Tipo MacPro y demas...Porque lo que es en arquitecturas mas antiguas, las que no llevan el ultimo MacPro (para entendernos) y los ultimos controladores de memoria, el tema del paralelismo (en este caso multicore) funciona francamente mal...porque la memoria es el gran cuello de botella, al menos por lo que yo he visto y he probado.....Como no tengo MacPro...pues ajo y agua....

 

 

Saludos

 

JP

Edited by jp
Link to post
Share on other sites
Tengo la sensacion que todo esto solo debe de ir bien en maquinas con arquitecturas muy modernas...Tipo MacPro y demas...Porque lo que es en arquitecturas mas antiguas, las que no llevan el ultimo MacPro (para entendernos) y los ultimos controladores de memoria, el tema del paralelismo (en este caso multicore) funciona francamente mal....al menos por lo que yo he visto y he probado.....Como no tengo MacPro...puea ajo y agua....

A tí que estás más al día de estos temas que yo, ¿te suena que pueda haber una diferencia entre la granularidad de la protección de páginas de memoria en los últimos Intel (al menos a partir del CoreDuo) y los PowerPC?

 

Porque se me ocurre que por ahí podrían ir los tiros del "Intel-only".

Link to post
Share on other sites

Un excelente descripción de GCD, sin duda. Mis felicitaciones :D

 

Sólo una pregunta. Hace unos días escribí una entrada sobre GCD y comenté que tal vez el sistema contara con cierta "inteligencia" al asignar bloques a ejecución, de forma que se optimizaran, por ejemplo, los accesos a cachés, ¿creéis que será lo suficientemente inteligente como para hacer ese tipo de "dispatching" de los hilos?

Link to post
Share on other sites
¿te suena que pueda haber una diferencia entre la granularidad de la protección de páginas de memoria en los últimos Intel (al menos a partir del CoreDuo) y los PowerPC?

 

Hombre, eso exactamente no lo se. Pero si que se me ocurre, que estan optimizando (a nivel de hardware) por ahi. Los ultimos diseños de PC/Mac tratan de implementar algo asi como lo que se conoce como una arquitectura NUMA. Apple trata de aprovechar eso, todo lo que puede y mas...

 

 

La idea es justamente esta http://www.apple.com/es/macpro/features/processor.html. En el dibujo de la arquitectura se aprecia que en cierto modo, el acceso a memoria es "un poco mas" independiente que en arquitecturas previas. La idea final seria que cada procesador (o nucleo) tuviera su propia memoria, pero eso no lo van a hacer nunca, ya que aunque se obtienen muy buenos rendimientos, es muy dificil de programar.

 

 

Los tiros van por ahi...Si no se hace asi, hoy por hoy, no hay otra manera de hacerlo. He probado maquinas de SGI con esta arquitectura y Linux, y van decentemente....Lo del Mac, de momento no, ya que la Conselleria no debe de tener ni un duro (la crisis) y este año no ha sacado proyectos...con lo cual no he podido pedir nada, para investigar en este campo....Quiero meterme, ya que la casa Mathworks ha sacado un Toolkit para Matlab para programacion paralela...pero de momento todo lo mas he probado el Toolkit con una demo...en mi Mac y se acabo....En mi iMac C2D (el blanquito) va fatal....

 

Un excelente descripción de GCD, sin duda. Mis felicitaciones :D

 

Sólo una pregunta. Hace unos días escribí una entrada sobre GCD y comenté que tal vez el sistema contara con cierta "inteligencia" al asignar bloques a ejecución, de forma que se optimizaran, por ejemplo, los accesos a cachés, ¿creéis que será lo suficientemente inteligente como para hacer ese tipo de "dispatching" de los hilos?

 

A nivel de soft, intel tiene cosas, para trabajar con esto...Creo que el soft se llama algo asi como Threading Building Blocks o algo asi....Y segun me dice algun compañero, es la solucion, pero, ciertamente no lo he probado.....

 

Saludos

 

JP

 

Saludos

 

JP

Edited by jp
Link to post
Share on other sites
Sólo una pregunta. Hace unos días escribí una entrada sobre GCD y comenté que tal vez el sistema contara con cierta "inteligencia" al asignar bloques a ejecución, de forma que se optimizaran, por ejemplo, los accesos a cachés, ¿creéis que será lo suficientemente inteligente como para hacer ese tipo de "dispatching" de los hilos?

Pues no se, hay una cosa que tienen en cuenta algunos planificadores, que es establecer una relación de afinidad entre procesos o hilos y procesadores para mejorar en lo posible la eficacia de los caches. Ni idea de cómo lo han hecho, no he catado el Snow Leopard ;)

 

 

¿te suena que pueda haber una diferencia entre la granularidad de la protección de páginas de memoria en los últimos Intel (al menos a partir del CoreDuo) y los PowerPC?

 

Hombre, eso exactamente no lo se. Pero si que se me ocurre, que estan optimizando (a nivel de hardware) por ahi. Los ultimos diseños de PC/Mac tratan de implementar algo asi como lo que se conoce como una arquitectura NUMA. Apple trata de aprovechar eso, todo lo que puede y mas...

 

(...)

 

A nivel de soft, intel tiene cosas, para trabajar con esto...Creo que el soft se llama algo asi como Threading Building Blocks o algo asi....Y segun me dice algun compañero, es la solucion, pero, ciertamente no lo he probado.....

Me he explicado fatal, no me refería a la granularidad, sino a reducir el coste de los cambiazos de permisos. Si hacen algo así, GC tendrá importantes implicaciones desde el punto de vista de la seguridad.

Link to post
Share on other sites
Sólo una pregunta. Hace unos días escribí una entrada sobre GCD y comenté que tal vez el sistema contara con cierta "inteligencia" al asignar bloques a ejecución, de forma que se optimizaran, por ejemplo, los accesos a cachés, ¿creéis que será lo suficientemente inteligente como para hacer ese tipo de "dispatching" de los hilos?

Pues no se, hay una cosa que tienen en cuenta algunos planificadores, que es establecer una relación de afinidad entre procesos o hilos y procesadores para mejorar en lo posible la eficacia de los caches. Ni idea de cómo lo han hecho, no he catado el Snow Leopard ;)

 

 

¿te suena que pueda haber una diferencia entre la granularidad de la protección de páginas de memoria en los últimos Intel (al menos a partir del CoreDuo) y los PowerPC?

 

Hombre, eso exactamente no lo se. Pero si que se me ocurre, que estan optimizando (a nivel de hardware) por ahi. Los ultimos diseños de PC/Mac tratan de implementar algo asi como lo que se conoce como una arquitectura NUMA. Apple trata de aprovechar eso, todo lo que puede y mas...

 

(...)

 

A nivel de soft, intel tiene cosas, para trabajar con esto...Creo que el soft se llama algo asi como Threading Building Blocks o algo asi....Y segun me dice algun compañero, es la solucion, pero, ciertamente no lo he probado.....

Me he explicado fatal, no me refería a la granularidad, sino a reducir el coste de los cambiazos de permisos. Si hacen algo así, GC tendrá importantes implicaciones desde el punto de vista de la seguridad.

 

Pues ni idea...

 

Saludos

 

JP

Link to post
Share on other sites

Saliéndome por la tangente: ¿qué impacto tendría esta tecnología en dispositivos como el iPhone? Creo que se esperaba que en la generación siguiente a la actual se empleasen ARMs multinúcleo, y hay un OpenCL para móviles previsto: ciertas tareas estilo DSP y tal podrían apañarse por la GPU, si el coste en batería compensase. ¿GCD regularía también el tráfico de trabajos OpenCL?

Link to post
Share on other sites
Saliéndome por la tangente: ¿qué impacto tendría esta tecnología en dispositivos como el iPhone? Creo que se esperaba que en la generación siguiente a la actual se empleasen ARMs multinúcleo, y hay un OpenCL para móviles previsto: ciertas tareas estilo DSP y tal podrían apañarse por la GPU, si el coste en batería compensase. ¿GCD regularía también el tráfico de trabajos OpenCL?

Yo, por lo que he leído hasta el momento, creo que OpenCL y Grand Central son cosas separadas. Por ejemplo, para OpenCL hay que andar compilando microcódigo en tiempo de ejecución para la tarjeta en cuestión y Grand Central es más un "planificador" de procesos como Dios manda.

 

Respecto al iPhone, por ejemplo, podríamos ver cómo con el SoC de CPU + memoria + GPU que llevan en un futuro pueda bastar y se eliminen los chips de DSP que llevan aparte, realizando estas funciones sobre la GPU. Aunque habría que ver si los servicios de voz, codificación GSM y demás temas en tiempo real que requiere un teléfono pueden ejecutarse "de sobra" en la GPU, claro.

 

Creo que Snow Leopard tiene un futuro apasionante, ya que establece un, ahora sí, "nuevo estándar" tecnológico con OpenCL, Grand Central, etc. que le hace tener muchas más posibilidades de futuro en cualquier dispositivo prácticamente :D

Link to post
Share on other sites

Borjan, excelente articulo porque has sabido explicar GC.

 

La explicación del pipeline del micro con lo de la ventanilla se entiende bien. Falta el detalle que en realidad no se ejecutan dos tareas al mismo tiempo (es imposible) si no que existe un dispach que se encarga de la multitarea, la verdad es que es difícil de explicar ya que se deben tener conocimientos muy técnicos.

 

La única pega es la forma con la que mencionas la programación concurrente. En el grupo de investigación en donde trabajo, hay informáticos de sistemas y telecos que programan a diario sistemas de tiempo real en lenguaje C. Solo que se debe tener en cuenta una serie de detalles para que los hilos o tareas no corrompan las variables compartidas de los recursos. A groso modo claro pero por ejemplo POSIX.

 

Otro ejemplo de concurrencia (en el que trabajo) es el uso de ésta característica en diseño electrónico (VHDL) en donde todos los procesos se ejecutan concurrentemente y todo esto se enseña en la Universidad.

 

No entro si el lenguaje C es el más indicado para realizar aplicaciones, pero por lo menos en mi universidad si lo enseñan.

 

Gran trabajo

Link to post
Share on other sites
La explicación del pipeline del micro con lo de la ventanilla se entiende bien. Falta el detalle que en realidad no se ejecutan dos tareas al mismo tiempo (es imposible) si no que existe un dispach que se encarga de la multitarea, la verdad es que es difícil de explicar ya que se deben tener conocimientos muy técnicos.

Exacto, por lo que es un detalle irrelevante omitido a propósito. No se trata de hacer una demostración de "alcance mingitorio", sino de que las cosas se entiendan ;) :D

 

Por otra parte, si es un multiprocesador hay varios núcleos o es un sistema distribuido, claro que se ejecutan simultáneamente..

 

La única pega es la forma con la que mencionas la programación concurrente. En el grupo de investigación en donde trabajo, hay informáticos de sistemas y telecos que programan a diario sistemas de tiempo real en lenguaje C. Solo que se debe tener en cuenta una serie de detalles para que los hilos o tareas no corrompan las variables compartidas de los recursos. A groso modo claro pero por ejemplo POSIX.

Claro, la "serie de detalles" es lo que hace que sea complicado. Si el personal muchas veces no es capaz ni de inicializar variables, imagina con secciones críticas e interbloqueos. ¿Qué tiene que ver esto con Posix?

 

Vamos, que no, que la programación concurrente no es fácil. Lo he hecho hace bastantes años con sistemas en tiempo real, y exige mucho más trabajo debido a esos "detallitos". De hecho ahora la cosa es más complicada porque cosas como Una Metodología Lamentable son contraproducentes.

 

Otro ejemplo de concurrencia (en el que trabajo) es el uso de ésta característica en diseño electrónico (VHDL) en donde todos los procesos se ejecutan concurrentemente y todo esto se enseña en la Universidad.

 

No entro si el lenguaje C es el más indicado para realizar aplicaciones, pero por lo menos en mi universidad si lo enseñan.

No lo es en absoluto, es un lenguaje de programación de sistemas. De ahí que haya multitud de problemas de seguridad (desbordamientos, etc) absurdos que no deberían producirse.

Link to post
Share on other sites

Quote "Exacto, por lo que es un detalle irrelevante omitido a propósito. No se trata de hacer una demostración de "alcance mingitorio", sino de que las cosas se entiendan

 

Por otra parte, si es un multiprocesador hay varios núcleos o es un sistema distribuido, claro que se ejecutan simultáneamente.."

 

Esta claro que no ibas a dar una clase de Arquitectura de Computadores y es complicado. En cuanto a al ser multiprocesador se ejecutan simultáneamente, habría casos que sí y casos en los que no, por lo que mejor no generalizar.

 

Si has programado en tiempo real muchos años sabrás que existen sistemas empotrados que usan posix (1.c con librerias de sincronización de hilos) que hacen que los sistemas sean Fault Tolerant.

 

 

Quote "No lo es en absoluto, es un lenguaje de programación de sistemas. De ahí que haya multitud de problemas de seguridad (desbordamientos, etc) absurdos que no deberían producirse."

 

Gran parte de la programación de satélites está hecha en RTEMS (parejo a C) que corre en arquitectura LEON3 (multinucleo) y es un desarrollo software fault tolerant.

Link to post
Share on other sites
Esta claro que no ibas a dar una clase de Arquitectura de Computadores y es complicado. En cuanto a al ser multiprocesador se ejecutan simultáneamente, habría casos que sí y casos en los que no, por lo que mejor no generalizar.

A efectos prácticos, se ejecutan a la vez. Más bien te da igual. Eso es lo que se consigue con la multiprogramación, que sea básicamente lo mismo. Si desactivas uno de los núcleos de tu ordenata, lo único que notarás es una posible mejora de rendimiento, pero no tienes que instalar una versión "mono-núcleo" y otra "multi-núcleo" del Safari. ¿Para qué marear al personal? Cada nivel de abstracción permite ignorar una serie de detalles.

 

 

Si has programado en tiempo real muchos años sabrás que existen sistemas empotrados que usan posix (1.c con librerias de sincronización de hilos) que hacen que los sistemas sean Fault Tolerant.

 

Gran parte de la programación de satélites está hecha en RTEMS (parejo a C) que corre en arquitectura LEON3 (multinucleo) y es un desarrollo software fault tolerant.

El que uses las librerías de hilos de Posix no hace que sean tolerantes a fallos. RTEMS puede ayudar a que tus programas sean tolerantes a fallos, ciertamente, pero es la arquitectura de tus programas y el diseño de tus algoritmos lo que los hace tolerantes a fallos, no el estar hechos en tal lenguaje o en tal sistema operativo.

 

Pero en fin, ¿por qué nos salimos de tema?

Link to post
Share on other sites

En primer lugar, creo que GCD es una gran idea y la solución apropiada al problema (¿necesidad?) de aprovechar los múltiples núcleos/procesadores presentes en gran parte de los computadores actuales. Borjam ha explicado de forma clara y sencilla por qué es así.

 

Dicho esto, lamento que algo como GCD se haya hecho necesario. La causa de ello es la barrera tecnológica que se ha alzado ante el diseño de CPUs cada vez más veloces: la disipación de calor. Ante esta barrera, los diseñadores y fabricantes de procesadores han optado por otro camino: aprovechar la progresiva miniaturización de los procesos de fabricación para empaquetar más núcleos en la misma superficie. La consecuencia es que ello ha convertido en ubicuas las arquitecturas de procesamiento paralelo o distribuido, antes reservadas a aplicaciones muy específicas.

 

Existen diversos algoritmos que son paralelizables por naturaleza; pero hay muchísimos más que no lo son. La multiprogramación, como explica borjam, es un técnica (y un arte) un tanto difícil que posibilita diseñar algoritmos y programas concurrentes, compuestos de unidades que se ejecutan como procesos o hilos independientes (aunque relacionados entre sí). Este tipo de programas pueden aprovechar en mayor o menor grado un computador con varios procesadores o núcleos. No obstante, el objetivo principal de las técnicas de programación concurrente no es aprovechar mejor ese tipo de arquitecturas, sino facilitar la división de un problema grande en otros más pequeños e independientes, facilitando así la solución a ese problema grande, o consiguiendo una mayor robustez de dicha solución.

 

En cuanto a los algoritmos que sí son paralelizables por naturaleza, en su caso resulta relativamente sencillo dividir sus requisitos computacionales (es decir, de cálculo), aprovechando así mucho más eficientemente una arquitectura hardware con múltiples procesadores o núcleos. Ejemplos de ello puede ser la codificación y descodificación de vídeo, por citar un caso bastante popular. No obstante, la inmensa mayoría de programas que se ejecutan en un computador de usuario típico no pertenecen a esa clase: son inherentemente secuenciales.

 

En cualquier caso, la tendencia actual a que los computadores cuenten con cada vez más procesadores o núcleos traslada la patata caliente del hardware al software. El problema es que resulta muy complicado poder aprovechar al máximo las arquitecturas paralelas. Precisamente la gran ventaja de GCD es que facilita la paralelización de tareas, pudiendo así Mac OS X distribuir éstas (o más bien trozos de éstas) entre los núcleos con los que cuente el computador de manera mucho más eficiente, gracias a la granularidad mucho más fina que se logra con GCD.

 

Pero como decía al principio, lamento que GCD sea necesario. En realidad ello simboliza la renuncia a continuar aumentando la velocidad bruta de los procesadores. Es verdad que la tecnología electrónica actual no da soluciones a esto (salvo emplear mecanismos imaginativos de refrigeración), pero hay que tener en cuenta que se investiga en tecnologías alternativas. Y no hablo sólo de cambios de paradigma radicales, como la tecnología fotónica o la superconductora; existen aproximaciones híbridas y otras ideas muy interesantes. Lo interesante sería que se continuase dedicando un esfuerzo enorme de investigación hacia ese tipo de tecnologías, para en el futuro poder contar con procesadores que sean mucho más veloces, en lugar de basar su potencia en sumar la de dos, cuatro, dieciséis o 1024 núcleos. En otras palabras, que la patata caliente vuelva al campo del hardware.

 

Pero bueno, mientras tanto GCD facilitará las cosas. :)

 

(Edito: aquí os pongo el enlace a una entrevista al legendario Donald Knuth. La cuarta pregunta (y su respuesta) va precisamente en la línea de lo comento en este mensaje.

Entrevista a Donald Knuth)

Edited by Dæmon
Link to post
Share on other sites
  • 2 months later...

Actualizo con la referencia a un artículo de 1989 donde describen algo que, desde el punto de vista del lenguaje de programación, tiene elementos en común con uno de los aspectos de Grand Central: el uso de extensiones del lenguaje de programación.

 

Lo publicó la revista Dr. Dobb's Journal en 1989, y en su día me llamó un montón la atención: A Timed Event Network Scheduler in Forth.

 

Véase la sencillez con la que se define una red de tareas interdependientes y concurrentes.

 

Ojo, esto se aplica solamente a un determinado tipo de problemas muy bien definido. Pero sin duda se trata de un trabajo pionero.

Link to post
Share on other sites
  • 4 weeks later...

Han publicado un interesante comentario sobre los beneficios de Grand Central y OpenCL :)

 

El autor de MovieGate dice que estos son los resultados de emplear GCD y OpenCL en un Mac Pro 2007 (Quad Core 2.66 GHz con una GeForce 8800 GT).

 

Es impresionante, desde luego ;)

 

Snow Leopard

150 frame/s for encoding in MPEG-2

70% CPU load for decoding

130% CPU load for MPEG-2 encoding (ffmpeg)

 

Leopard

104 frame/s for encoding in MPEG-2

165% CPU load for decoding

100% CPU load for MPEG-2 encoding (ffmpeg)

Link to post
Share on other sites
Han publicado un interesante comentario sobre los beneficios de Grand Central y OpenCL :)

 

El autor de MovieGate dice que estos son los resultados de emplear GCD y OpenCL en un Mac Pro 2007 (Quad Core 2.66 GHz con una GeForce 8800 GT).

 

Es impresionante, desde luego ;)

 

Snow Leopard

150 frame/s for encoding in MPEG-2

70% CPU load for decoding

130% CPU load for MPEG-2 encoding (ffmpeg)

 

Leopard

104 frame/s for encoding in MPEG-2

165% CPU load for decoding

100% CPU load for MPEG-2 encoding (ffmpeg)

 

Ciertamente impresionante. Y eso que aún estas tecnologías no están muy maduras... ¿cómo será la diferencia en un futuro?. Desde luego es algo a adoptar en el resto de SOs si no quieren quedarse atrás.

 

Da gusto ver los primeros pasos de algo que va a hacer que realmente podamos aprovechar todo el potencial de nuestro hardware para realizar las tareas más cotidianas y no sólo a la hora de echarse la partida al Quake XXVI como hasta ahora.

Link to post
Share on other sites
Ciertamente impresionante. Y eso que aún estas tecnologías no están muy maduras... ¿cómo será la diferencia en un futuro?. Desde luego es algo a adoptar en el resto de SOs si no quieren quedarse atrás.

 

*TOC TOC*

 

¿Que no están maduras? Disculpa, ¿algún motivo para afirmar tal cosa? OpenCL se apoya sobre el compilador clang-llvm, que ya se usaba en el subsistema OpenGL de Leopard. Creo que está más que maduro.

 

¿GCD? Bueno, es de las cosas que si no están "maduras" impiden incluso el arranque mismo del sistema. Otra cosa es que se estén usando poco, claro. Tampoco sabemos cuánto tiempo lleva Apple trabajando en esto, pero me imagino que no son solamente dos años.

Link to post
Share on other sites
Han publicado un interesante comentario sobre los beneficios de Grand Central y OpenCL :)

 

El autor de MovieGate dice que estos son los resultados de emplear GCD y OpenCL en un Mac Pro 2007 (Quad Core 2.66 GHz con una GeForce 8800 GT).

 

Es impresionante, desde luego ;)

 

Snow Leopard

150 frame/s for encoding in MPEG-2

70% CPU load for decoding

130% CPU load for MPEG-2 encoding (ffmpeg)

 

Leopard

104 frame/s for encoding in MPEG-2

165% CPU load for decoding

100% CPU load for MPEG-2 encoding (ffmpeg)

 

Al ver los resultados, al margen de alegrarme por el aumento de rendimiento, me surge una pregunta:

 

Si GCD optimiza el trabajo multihilo y en varios núcleos, ¿no sería deseable observar una mayor carga del procesador respecto a leopard?

En este programa los resultados son contradictorios entre encoding y decoding, y el artículo es tan breve que supongo que sólo se puede especular, lo pregunto más bien en general, a cualquier programa que aproveche GCD.

¿Lo teóricamente ideal en un trabajo intensivo en un Quad Core no sería que llegase al 400% (800% si esos pocesadores tienen hyperthreading, que no lo sé)?

 

Saludos

 

(¿O la ganancia simplemente será porque lo hayan ejecutado en un kernel de 64 bits? :P)

Link to post
Share on other sites
¿no sería deseable observar una mayor carga del procesador respecto a leopard?

Yo veo un aumento del 30% al codificar en Snow Leopard :)

 

Snow Leopard: 130% CPU load for MPEG-2 encoding (ffmpeg)

Leopard: 100% CPU load for MPEG-2 encoding (ffmpeg)

Link to post
Share on other sites
¿no sería deseable observar una mayor carga del procesador respecto a leopard?

Yo veo un aumento del 30% al codificar en Snow Leopard :)

 

Snow Leopard: 130% CPU load for MPEG-2 encoding (ffmpeg)

Leopard: 100% CPU load for MPEG-2 encoding (ffmpeg)

 

A eso me refería con resultados contradictorios en este programa, porque en decoding tiene una disminución del 57%:

 

Snow Leopard

70% CPU load for decoding

 

Leopard

165% CPU load for decoding

 

Saludos

Link to post
Share on other sites
Al ver los resultados, al margen de alegrarme por el aumento de rendimiento, me surge una pregunta:

 

Si GCD optimiza el trabajo multihilo y en varios núcleos, ¿no sería deseable observar una mayor carga del procesador respecto a leopard?

No. GCD no te hace el trabajo. Te lo facilita. Es decir, GCD no es un compilador mágico al que tú le das un programa y por arte de birlibirloque lo convierte en concurrente. Si tu programa es secuencial, por mucho que tengas mil núcleos funcionará igual, a la velocidad de uno de los núcleos.

 

Lo que hace GCD es proporcionarte herramientas para que te resulte más fácil hacer tu programa concurrente sin dispararte en las gónadas.

 

De la mejora que ha obtenido el hombre éste, la parte debida a GCD (que no especifica) la podría haber obtenido haciéndo su programa concurrente. La diferencia está en el tiempo de desarrollo y la probabilidad de introducir fallos difíciles de reproducir.

 

En este programa los resultados son contradictorios entre encoding y decoding, y el artículo es tan breve que supongo que sólo se puede especular, lo pregunto más bien en general, a cualquier programa que aproveche GCD.

¿Lo teóricamente ideal en un trabajo intensivo en un Quad Core no sería que llegase al 400% (800% si esos pocesadores tienen hyperthreading, que no lo sé)?

En teoría, si, si consigues mejorar mediante la concurrencia una tarea que hace muchos cálculos, tu uso de procesador se disparará al máximo. El objetivo de GCD será, en principio, saturar los núcleos.

 

Pero, y el pero es muy importante, aquí hablan de GCD *y* OpenCL. Y con OpenCL parte del trabajo se va a parar al procesador gráfico, con lo que el uso de CPU disminuye.

 

Alguno se preguntará si OpenCL + GCD no tenderían a tratar de saturar tanto la GPU como las CPU, pero no es así porque no se trata de un reparto simétrico ni automático. Hay un reparto simétrico entre núcleos/CPUs (cuando digo CPUs me refiero a núcleos o CPUs indistintamente) pero para que una tarea vaya a parar a la GPU debes usar explícitamente OpenCL.

 

En fin, me ha quedado un galimatías pero creo que se entiende ;)

 

(¿O la ganancia simplemente será porque lo hayan ejecutado en un kernel de 64 bits? :P)

 

En realidad debería correr 4 veces más en el kernel de 64 bits. Veamos por qué:

 

- Doble de bits. Eso multiplica la velocidad por 2.

 

- Bits más pequeños. Al ser 64 bits en vez de 32 dentro del mismo ordenador, éstos son más pequeños. Al ser más pequeños su masa es más pequeña, y la misma fuerza los acelera el doble. De ahí que su velocidad sea doble.

 

¿El resultado? Pues eso, que la velocidad se multiplicaría por cuatro. Como los bits son más pequeños, además, su rozamiento con los cables también se reducirá. Pero esto es más complicado de calcular.

 

Pero bueno, digamos que levantando un poco el dedo debería ser cuatro veces más rápido. Va a resultar que OpenCL y GCD sí están inmaduros, porque aquí se ve una mejora de solamente el 50 %. O bien no usan técnicas homeopáticas, sino alopáticas. O eso o Apple ha capado algo adrede. Cabrones.

 

 

 

 

 

 

 

;) :lol:

Edited by borjam
Link to post
Share on other sites

Pero vale, con esos recursos los ceros pasan a cholón ... pero los unos se atascan en los cables seguro... :(

 

 

 

 

En serio , por lo que leo es algo genial, pero si dijera que lo entiendo del todo, mentiría. Digamos que más o menos lo pillo. :)

Link to post
Share on other sites
Ciertamente impresionante. Y eso que aún estas tecnologías no están muy maduras... ¿cómo será la diferencia en un futuro?. Desde luego es algo a adoptar en el resto de SOs si no quieren quedarse atrás.

 

*TOC TOC*

 

¿Que no están maduras? Disculpa, ¿algún motivo para afirmar tal cosa? OpenCL se apoya sobre el compilador clang-llvm, que ya se usaba en el subsistema OpenGL de Leopard. Creo que está más que maduro.

 

¿GCD? Bueno, es de las cosas que si no están "maduras" impiden incluso el arranque mismo del sistema. Otra cosa es que se estén usando poco, claro. Tampoco sabemos cuánto tiempo lleva Apple trabajando en esto, pero me imagino que no son solamente dos años.

 

 

 

Diferencia de criterios, me temo... Para mí algo está maduro cuando lleva un cierto tiempo de rodaje llamémoslo público, es decir, cuando lleva un tiempo siendo usada por una cierta variedad de fabricantes, desarrolladores...

 

¿Que openCL se apoya sobre clang-llvm, que ya se usaba en el subsistema OpenGL de Leopard?. Perfecto, pero lo de arriba (openCL) interpreto que es nuevo y casi no se ha usado, entiendo. Eso sí, tendrá una buena base. Como la puede tener Mac OS X y no creo que su primera versión fuera la más satisfactoria para sus usuarios.

¿Que si GCD no estuviera suficientemente depurado el sistema no arrancaría?. Vale, está probado y es lo suficientemente sólido y confiable. Pero quiero que otros desarrolladores de aplicaciones aparte de Apple lo usen para ver cómo de bien funciona realmente y para poder hacerlo evolucionar a algo todavía mejor a base de feedbacks. Ya tenemos el 5 (no colgamos el sistema), pero quiero un 8 o un 9 mínimo. Estaremos de acuerdo en que tendremos más casos de prueba si son 100 empresas las que hacen tests (desarrollan aplicaciones haciendo uso de GCD) y no sólo una.

 

Al final lo que quiero decir es que las cosas cuanto más se usen y por más variedad de gente, más se depuran y mejor rendimiento alcanzarán. A eso me refiero con "no estar muy maduras". No estoy diciendo que Apple meta "betas" en su SO. Eso es cosa de Linux ;)

Sería la leche que, recien salidos openCL y GCD, fueran perfectos. Pero me temo que cuanto más se usen, más cosas mejorables se encontrarán (lo cual es bueno, creo yo, porque así se crece). No sé si me he explicado.

 

Ahora bien, salvo lo que he leido en estos foros, no tengo otras noticias sobre el uso de openCL y GCD. Lo mismo llevan usándose años para el desarrollo de aplicaciones y no me he enterado... ahí ya me callo :)

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.