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:
Cita:
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.