Intel trabaja en un procesador de 48 núcleos

[[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 Noteví]

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.

[[nlsgarcia]]

Club Delphi,

Este artículo esta relacionado al tema:

Procesadores de múltiples núcleos, ¿realmente necesarios?: http://www.configurarequipos.com/doc905.html

Un procesador de 48 Núcleos es un salto cuántico en poder de computo y un gran avance en ingeniería. La tecnología Multi-Core evoluciona y se adapta a su entorno, es solo cuestión de tiempo para que la tecnología móvil pueda aprovechar todas sus ventajas y estas sean visibles en términos prácticos.

Nelson.

[mamcx]

Por ahí es la cosa. Los lenguajes y entornos actuales (en su mayoría) son inadecuados para esa nueva frontera, noten sobre Delphi (no esta limitado a Delphi! muchas de esas cosas pasan en otros entornos!). No escalan con la capacidad disponible, imaginense que uno ponga un motor SQL con 64 GB y que este no las aprovechara. Así es actualmente, para la mayoría de los programas actuales a mas núcleos +...ok prácticamente nada. El OS enmascara y hace mucho del trabajo pero los programas que están diseñados con la premisa de "solo trabajo en 1 núcleo" simplemente no pueden sacarle mucho jugo.

Contrasten contra Erlang es escalable actualmente a 32 nucleos. Delphi NO. .NET NO. Erlang SI. Es algo que hace parte de su arquitectura. Que se diga que lo es a 32 nucleos se refiere a Erlang, su VM, runtime, completo. No es *meramente* una vaina de poner algún código en un hilo, es pura cosa de arquitectura y diseño.

Una excelente disertacion sobre el tema, consideraciones y los limites reales que aun un ambiente tuneado para ese fin se encuentra en el tutorial de erlang que en resumen dice: Aunque erlang puede, no siempre se debe. Es de notar, y es la parte importante, el darse cuenta: Cuando se preocupa uno por lo que esta alli expuesto? Si el lenguaje, librerías, programas, desarrolladores no toman en cuenta esa arquitectura, entonces realmente no podrán escalar.

Con todo, un ejemplo de como seria de facil, si un lenguaje X fuera del tipo de erlang:

Crear una funcion que suma 2+2, y la convierte en un micro-hilo escalable:

1> F = fun() -> 2 + 2 end.
#Fun<erl_eval.20.67289768>
2> spawn(F).
<0.44.0>

Eso mismo, se puede hacer que corra en N-maquinas*N-Cores*N-Threads*N-Microhilos (ej: Facebook), SIN HACER CAMBIOS DE CODIGO. Comparen eso, con tener que hacer todo en un TThread, e intentar escalar, hasta el nivel de N-maquinas... No es que no se pueda, es que es mas facil, seguro y confiable, cuando el lenguaje y librerias se diseñan conforme...

GO tambien tiene un soporte parecido. Es solo decir "go FUNCTION" y listo.

Para ver un modelo que es independiente del lenguaje, el que mas se menciona es el "Actor Model"

----
P.D: Lo que quiero enfatizar es el cambio de paradigma, lo que implica. Y mostrar como Erlang (en parte limitada GO, node.js, haskell) han resuelto este problema a un nivel superior (y mas fácil de usar!) que lo que normalmente usamos ahora. La leccion es buscar aplicaciones con OO menos denso y acoplado, mas paso de mensajes/datos y no compartir nada para que escale facil.