Intel trabaja en un procesador de 48 núcleos

[Casimiro Noteví]

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.