Intel trabaja en un procesador de 48 núcleos

[[nlsgarcia]]

Club Delphi,

Intel trabaja en un procesador de 48 núcleos

Empezado por Pcworld En Español:

"Los investigadores de Intel están trabajando en un chip de 48 núcleos para teléfonos y tablets, pero estaría a cinco o 10 años de estar disponible en el mercado. Los laboratorios de Intel en Barcelona han creado un prototipo de procesador del especialmente diseñado para dispositivos portátiles."

Ver mas en los links:

http://www.pcworldenespanol.com/2012...8-nucleos.html

http://www.youtube.com/watch?v=3xJOS2SyLYw

http://communities.intel.com/communi...wapkw=48+cores

http://en.wikipedia.org/wiki/Single-chip_Cloud_Computer

Este hito representa el último logro del Tera-scale Computing Research Program de Intel y revolucionara todas las áreas de la computación.

Nelson.

[Casimiro Notevi]

Los investigadores de Intel están trabajando en un chip de 48 núcleos para teléfonos y tablets, pero estaría a cinco o 10 años de estar disponible en el mercado.

Qué bien, así puedo llamar a 48 amigos a la vez.
Menos mal que es para dentro de 5 ó 10 años, así me da tiempo a hacer 48 amigos

[Ñuño Martínez]

Y me pregunto, estúpido de mi: ¿Para qué narices quiero un microprocesador de 48 núcleos en mi teléfono móvil o en mi tableta?

[roman]

Empezado por Ñuño Martínez

¿Para qué narices quiero un microprocesador de 48 núcleos en mi teléfono móvil o en mi tableta?

Para nada. Pero es que la noticia lo dice claramente:

En unos 10 años, cuando el chip de 48 núcleos para teléfonos o tablet esté listo para el mercado, los dispositivos seguramente van a necesitar ese poder de cómputo.

// Saludos

[Casimiro Notevi]

No sé, no me veo yo con un teléfono móvil así:

[mamcx]

Ni tanto. Una GPU tiene cientos de nucleos. Ya salieron en este año procesadores moviles de 4 nucleos.

Tener varios nucleos es muy util, en parte, ayuda a ahorrar bateria. El problema ENORME no es tener los nucleos, es tener como programarlos!

Las herramientas/lenguajes actuales están muy crudos en ese aspecto (al igual que los OS) ya que están amarrados al concepto de thread/hilos.

Adicionalmente, existe el problema de que no es facil de paralelizar algoritmos/datos, y existen cosas que NO se pueden paralelizar.

Para poder llegar a eso, en parte:

- Hay que abandonar los lenguajes sincronicos
- Trabajar con tipos de datos inmutables
- Dejar a un lado la OO
- Poner a trabajar con la programacion funcional
- Abandonar los hilos
- Tener un sistema de "scheduling" que mezcle paralelizacion + rebalanceo + sequencialidad de forma inteligente
- Y cambio de herramientas (o mejoras. En especial depuracion: Como rayos vamos a depurar un proceso andando en 48 cores???)

Para los que quieren un abrebocas de lo que es trabajar en este tipo de ambientes, un paseito por http://www.erlang.org/

[Ñuño Martínez]

Empezado por mamcx

Tener varios nucleos es muy util, en parte, ayuda a ahorrar bateria.

¿Mande lo qué? No te digo que no, pero el sentido común me dicta lo contrario. Claro que en informática parece que el sentido común no suele funcionar...

Empezado por mamcx

Las herramientas/lenguajes actuales están muy crudos en ese aspecto (al igual que los OS) ya que están amarrados al concepto de thread/hilos.

Adicionalmente, existe el problema de que no es facil de paralelizar algoritmos/datos, y existen cosas que NO se pueden paralelizar.

Para poder llegar a eso, en parte:

- Hay que abandonar los lenguajes sincronicos
- Trabajar con tipos de datos inmutables
- Dejar a un lado la OO
- Poner a trabajar con la programacion funcional
- Abandonar los hilos
- Tener un sistema de "scheduling" que mezcle paralelizacion + rebalanceo + sequencialidad de forma inteligente
- Y cambio de herramientas (o mejoras. En especial depuracion: Como rayos vamos a depurar un proceso andando en 48 cores???)

Para los que quieren un abrebocas de lo que es trabajar en este tipo de ambientes, un paseito por http://www.erlang.org/

Sé que no es lugar para comentarlo, pero pero precisamente la "Programación Orientada a Objetos" es, por definición, multitarea. Es decir, la encapsulación dicta que no importa la implementación interna, que los objetos son completamente independientes entre sí y que se comunican mediante mensajes. Claro que, por lo que sé, sólo hay un lenguaje que lo implementa así: Small-Talk (de hecho, es el único lenguaje orientado a objetos que conozco ). Aunque creo que algunas implementaciones de Objective C también lo hacen así.

[mamcx]

Empezado por Ñuño Martínez

¿Mande lo qué? No te digo que no, pero el sentido común me dicta lo contrario. Claro que en informática parece que el sentido común no suele funcionar...

La razón es que se puede apagar/desacelerar los núcleos de acuerdo a la carga. Ademas, si en vez de tener una tarea "CPU-bound" tenemos cientos de tareas "IO-Bound" y/o asincronicas la velocidad de cada CPU se puede ralentizar, ahorrando energia.

Empezado por Ñuño Martínez

Sé que no es lugar para comentarlo, pero pero precisamente la "Programación Orientada a Objetos" es, por definición, multitarea. Es decir, la encapsulación dicta que no importa la implementación interna, que los objetos son completamente independientes entre sí y que se comunican mediante mensajes. Claro que, por lo que sé, sólo hay un lenguaje que lo implementa así: Small-Talk (de hecho, es el único lenguaje orientado a objetos que conozco ). Aunque creo que algunas implementaciones de Objective C también lo hacen así.

Lo de pasar datos mediante mensajes ayuda, pero dudo que Small-Talk tenga un diseño que ayude en estos casos. Las clases en OO tienden a ser capsulas de estado. En el momento que tenemos un objeto "State-Full" en vez de uno "State-less" las posibilidades de paralelizar se van al piso.

En general, la OO tienden a generar diseños en donde es dificil/imposible paralelizar. Me gustaria ver como se evita eso, ya que igual estoy full en lenguajes OO y de los funcionales solo se una pizca (realmente, es todo un shock manejar ese estilo: No me veo haciendo las apps que hago ahora de forma funcional).

[matabyte]

Que yo sepa en delphi puedes lanzar miles de threads si lo deseas y asignar un thread al procesador que tu quieras XD. Cada thread puede contener un objeto y sincronizarlos todos en un momento dado.

[mamcx]

Delphi puede. Pero hay un limite fisico de cuantos es posiles por nucleo, y otra cosa muy distinta es que tan facil sea de hacerlo. Comparado con lenguajes con soporte nativo a todo esto (ej: Erlang, que puede hacer miles por thread) ir mas alla de 3/4 empieza a ponerse bien dificil - mas si hay que meterle locks y todo eso-

Es como todo. Uno puede hacer OO con C plano, pero no es tan simple que con un lenguaje OO. Uno puede hacer programacion funcional con C plano, pero se llegan a limites tecnicos y de estilo...

[matabyte]

Me he perdido? Dices que delphi no soporta de forma nativa los threads?

Hombre, mas facil que crear un Objeto y asignarle que sea de tipo Thread en delphi... no se, no me parece muy dificil XD.

A parte de eso, lo de los 48 nucleos no es tan grande ni tan potente ni tan moderno ni tan dificil de programar.

Existen las GPUs que se pueden programar desde hace un par de años, y esas tienen mas de 48 nucleos XD.

[mamcx]

No he dicho que no soporta, sino que delphi (al igual que java, c#, c++, etc) tiene un soporte complejo y/o pobre al respecto.

El manejo tradicional de threads es muy similar al de la memoria manual. Hay que preocuparse por un montón de cosas (como hacer locks, evitar deadlocks, liberar y asignar recursos, etc) y en general, su API/librería son incompatibles con multihilos (ie: VCL, o librerías de bases de datos, etc). Esto implica que 1)Es algo que rara vez lo usan los programadores 2)Introducirlo en un proyecto tiende a ser para un caso puntual y limitado 3)Es muy difícil hacer un código de estos sin errores y de alto desempeño y 4) Hay que saber elegir y usar el codigo compatible o reescribir y cambiar porciones para poder lograrlo.

En apariencia, es

fácil que crear un Objeto y asignarle que sea de tipo Thread

, asi como de sencillo es crear y liberar memoria manualmente. Pero de ahí a hacer desarrrollos de forma natural y productiva que escalen a n-Cores es todo un cuento.

[matabyte]

Definitivamente no XD.

Todos esos "problemas" y ese "monton de cosas que hay que hay que hacer" que dices que hay que hacer son exactamente los mismos que a la programación para un solo núcleo XD.

Empezado por mamcx

1)Es algo que rara vez lo usan los programadores.

No me digas que los Threads es algo que rara vez usamos los programadores... eso seria hace 10 años.... Porque cualquier tarea compleja que no se haga en segundo plano con un Thread te va a congelar la ventana, cosa que a los usuarios no les gusta mucho la verdad... Por no hablar de interconexion a varias bases de datos en distintas webs (un thread por cada conexion), o de un server (un thread por cada socket), etc...

2)Introducirlo en un proyecto tiende a ser para un caso puntual y limitado

Con lo de arriba te respondo. Si un proyecto actual no usa Threads (ya sean juegos para la carga, servidores, aplicaciones, etc...), olvidate de lanzarlo de forma pública si no quieres que los usuarios se empiecen a quejar.

3)Es muy difícil hacer un código de estos sin errores y de alto desempeño

Pues que quieres que te diga, no es algo que sea dificil de hacer, o soy un genio o no es tan difícil de hacer las cosas sin bugs. Si te es difícil hacer un código usando Threads sin errores, olvídate de programar aplicaciones de tipo cliente/servidor, bases de datos, juegos y demás.

4) Hay que saber elegir y usar el codigo compatible o reescribir y cambiar porciones para poder lograrlo

Al igual que en cualquier programa cuando haces un programa desde 0. ¿Reusas todo el codigo de otros programas? No es que sea recomendable... De todas formas, un objeto Thread para la carga de datos de un fichero de un formato especial que se cargue de forma asincrona lo puedo reutilizar en cualquier programa. Depende de como programes tus objetos, los que creo yo los hago para que sean fáciles de reutilizar.

En apariencia, es , asi como de sencillo es crear y liberar memoria manualmente. Pero de ahí a hacer desarrrollos de forma natural y productiva que escalen a n-Cores es todo un cuento.

No se que tendras contra delphi, pero como te he dicho arriba, desde hace 5~10 años se puede programar de forma natural y productiva y sin quebraderos de cabeza e incluso elegir el/los nucleos con los que quieres trabajar, etc...

Todo ello te lo resumo de forma facil para que veas que se puede usar y hacer:

SKYPE

Si no sabes a que me refiero, mirate el club por informacion de skype

[matabyte]

No se porque el foro no permite la edicion de un post :S

Bueno, que eso, que no te lo tomes a mal mi respuesta. Que ya se sabe que los post son muy impersonales y no llevan sentimientos ni como esta dicho y demas y la gente se lo puede tomar a mal XD

[Casimiro Notevi]

No se permite modificar pasado 30 minutos. Puedes escribir un nuevo post si lo necesitas.

[mamcx]

Empezado por matabyte

No se que tendras contra delphi, pero como te he dicho arriba, desde hace 5~10 años se puede programar de forma natural y productiva y sin quebraderos de cabeza e incluso elegir el/los nucleos con los que quieres trabajar, etc...

Ok, empecemos por algo. No estoy diciendo que no sea posible hacer multi-hilos al dia de hoy, o que este en contra de Delphi. No es mi opinion personal, es el consenso de la industria y de programadores mas experimentados en este tema (ie: Los que les toca la parte compleja del asunto). La cosa es que la optica de si es natural o productivo o quebraderos de cabeza cambia radicalmente desde donde lo estes viendo. Al igual que muchos, uso *algo* de la programacion multi-hilos/procesos (aun mas con obj-c, donde es mas natural que con Delphi) pero ni a leguas estoy del punto donde pueda sacarle el jugo a todo...



Algunos articulos sobre el tema:

(Este fue el primer campanazo del que me entere)
http://www.gotw.ca/publications/concurrency-ddj.htm

(Nota que esta es una discusion de porque los Threads son considerados como dañinos, y que en general se deben evitar de ser posible)
http://c2.com/cgi/wiki?ThreadsConsideredHarmful

Empezado por matabyte

No me digas que los Threads es algo que rara vez usamos los programadores... eso seria hace 10 años.... Porque cualquier tarea compleja que no se haga en segundo plano con un Thread te va a congelar la ventana, cosa que a los usuarios no les gusta mucho la verdad... Por no hablar de interconexion a varias bases de datos en distintas webs (un thread por cada conexion), o de un server (un thread por cada socket), etc...

El asunto en si resulta dificil de apreciar, principalmente es un problema de escala y de enfoque. Por ejemplo, no es el mismo problema hacer un motor de bases de datos/servidor web de alto desempeño que hacer que una consulta SQL de un programa contable no bloquee la GUI.

Me arriesgare a suponer que lo de multi-hilos, por los comentarios que expones, se concentra en hacer un GUI que no se congele y no se va mas lejos que tener unas pocas tareas, y que esto ademas, es ppalmente programar asíncronamente, ej: Ejecuta este SQL en este hilo, voy haciendo otras cosas, luego recibo el resultado y actualizo la GUI. Este es el modelo mas común ahora y mas simple de todos (en cuanto a tener multihilos). De hecho, es un modo de programación simple porque todo lo asincrónico se puede escribir sequencial, se puede colocar en un queue y es solo cosa de tener callbacks y todo eso. Es ligeramente mas difícil que la secuencial, pero no mas difícil que la programación por eventos.

Empezado por matabyte

Definitivamente no XD.

Todos esos "problemas" y ese "monton de cosas que hay que hay que hacer" que dices que hay que hacer son exactamente los mismos que a la programación para un solo núcleo XD.

Para nada! Los mismos? Este es uno de los puntos de mas shock, es que pocos entienden lo difícil que es paralelizar las cosas:

http://www.futurechips.org/tips-for-...ogramming.html

La programacion multi-hilos/cores implica:

1- Una cosa es poder lanzar n-tareas en un hilo/proceso aparte, y esperar su resultado (osea asincrónico y relativamente facil). Este modelo tiende a ser ineficiente porque no utiliza los cores de la CPU de forma optima. Es una derivacion de la programacion sequencial, ligeramente dificil de depurar y de hacer bien (con 1-4 tareas de fondo, pan comido, una vez empiezas a tener decenas, cientos.....)
2- La capacidad de paralelizar una tarea (ie: si tarea A toma 100sec con 1 core, deberia tomar 25secs con 4). Jodidamente difícil de hacer a veces, porque por razones físicas y teóricas un montón de cosas no se pueden paralelizar.
3- Comunicacion y coordinacion entre tareas. AQUI es donde estan, por mucho, los ppales dolores de cabeza. Dependiendo de la dificultad de esa comunicacion, y de cuantos bloqueos hayan, sera mas o menos dificil de hacer y depurar
4-Limpieza de tareas y recursos vivos. Matar hilos es cosa maluca, y complicada de hacer correctamente bien.

Empezado por matabyte

Pues que quieres que te diga, no es algo que sea dificil de hacer, o soy un genio o no es tan difícil de hacer las cosas sin bugs. Si te es difícil hacer un código usando Threads sin errores, olvídate de programar aplicaciones de tipo cliente/servidor, bases de datos, juegos y demás.

Como todo, dependen del nivel de complejidad en el que estas. Puedes leer un hilo de la gente de synapse sobre complicaciones, consideraciones y demás dificultades relacionadas con la tarea. La parte importante es notar la cantidad de consideraciones, peros, condiciones y entendimiento que hay que tener para llegar a donde se quiere:

http://synopse.info/forum/viewtopic.php?id=57

Obvio, ese es lo que ven quienes hacen a synapse, no quienes lo usan. El problema es que cuando los que lo usan empiezan a subir de nivel, se van a enfrentar a problemas para los cuales no están preparados.

Esto no es especifico de Delphi. Con obj-c/Coccoa que tiene un soporte superior para este paradigma, es casi igual de dificil. Lo mismo C#, y Java, etc.

El principal problema es de la comunicacion, y el manejo de estado
http://gregbeech.com/blog/threading-...-state-is-hard

Cuando se hace programación asincrónica, quizás no se tope uno con eso, porque se envia el objeto/datos a la tarea de fondo y se recibe otro objeto/datos (o no se modifica por fuera de la tarea) y por eso todo sale fácil.
------------------------------------------------
Hasta aquí todavía puede que uno se sacuda la cabeza y no le vea el alboroto a todo esto, aparte de unos cuantos tipos que dicen que es difícil, pero que a uno no le parece tanto. Es como todo. Cuando lo que se usa en assembler uno no le ve cual es la gracia de un lenguaje de mayor nivel. Cuando obj-c gano la posibilidad de no manejar manualmente la memoria, había un MONTON de gente que decía "y que problema hay con hacerlo manual?" y así por el estilo.

Existe un limite a cuantos threads se pueden crear (http://blogs.technet.com/b/markrussi...8/3261309.aspx =55,000 en 64bits) aunque realistamente es MUCHO menor. En contraste, algo como erlang puede manejar 268'435.456.

[[nlsgarcia]]

matabyte,

Todo lo que comenta mamcx es lo que yo siempre he tenido entendido del manejo de Threads, sin embargo me llama mucho la atención el siguiente comentario:

Empezado por matabyte

desde hace 5~10 años se puede programar de forma natural y productiva y sin quebraderos de cabeza e incluso elegir el/los núcleos con los que quieres trabajar, etc...

1- ¿Puedes dar un ejemplo sencillo de como se puede elegir un núcleo del procesador en Delphi en programación Multi-Threads?

2- ¿Con que criterio selecciono un núcleo del procesador sobre otro en Delphi en programación Multi-Threads?.

Gracias de antemano

Nelson.

[matabyte]

La funcion para elegir la mascara de afinidad (AffinityMask) O elegir el núcleo que deseas que utilice un Thread es el siguiente:

SetProcessAffinityMask

Ejemplos tienes bastantes:

http://edn.embarcadero.com/article/27267
http://stackoverflow.com/questions/9...-one-processor
http://msdn.microsoft.com/es-es/libr...=vs.85%29.aspx
etc...

El criterio de uso depende del programa/aplicación que estés programando, cada programa es un mundo!
Y si no, siempre puedes lanzar tus threads sin la mascara de afinidad y que se ocupe el OS de repartir entre los núcleos disponibles los Threads. Ultimamente los OS realizan bien esa tarea .

Y Si, he usado bastante los multi-nucleos con multi-threads para procesar grandes cantidades de datos de forma paralela durante meses y meses.

Si bien hay un limite a lo que puedes "exprimir" a los núcleos:
-Por muchos nucleos y procesos que lances, la suma de los datos de todos ellos en un momento dado no podrá superar la velocidad maxima de tu memoria y/o disco duro, por lo que para computo de datos tiene el limite del disco duro y/o memoria.
-La sincronizacion de los datos de todos los Threads requiere un tiempo (a menos que sean procesos totalmente independientes, en ese caso estaríamos hablando ya de programas individuales lanzados por otro programa...).

Por desgracia, por mucho que aumenten los nucleos creo que poco vamos a notar si no se pre-cargan los datos a memoria (en cuyo caso el tiempo de carga disminuye el performance total de tener tantos nucleos).

Vamos, volviendo al inicio del post, me parece una tonteria 48 nucleos a menos que los vayas a usar para algo como prediccion del tiempo o simulaciones matemáticas. El tamaño que tendrías que tener de memoria RAM para aprovechar esa cantidad de núcleos yo lo pondría por los 100Gb para que tuviera un buen rendimiento.

Mas núcleos si, pero si no los usamos correctamente es una perdida de energía tremenda Muchas veces con 2 o 4 nucleos vamos mas que suficientes, y para el 70% de la poblacion que usa un pc, con 1~2 nucleos van mas que suficientes para navegar por internet y usar el word

[Casimiro Notevi]

Empezado por matabyte

Mas núcleos si, pero si no los usamos correctamente es una perdida de energía tremenda Muchas veces con 2 o 4 nucleos vamos mas que suficientes, y para el 70% de la poblacion que usa un pc, con 1~2 nucleos van mas que suficientes para navegar por internet y usar el word

Y para un teléfono ya me dirás

[[nlsgarcia]]

matabyte,

Gracias por la información

Nelson.