¿Quién ha dicho que sea imposible? Es extremadamente difícil. No proporciona necesariamente los beneficios que se esperan. Prohibitivamente caro. Pero imposible. No, no es imposible.
¿Se podría hacer con una sola aplicación de software? Sí, si se está dispuesto a gastar algo del orden de mil millones de dólares para construir una aplicación de este tipo y probablemente esperar cinco años para que sea utilizable y probablemente seguiría teniendo errores y siendo temperamental.
Ya es bastante difícil para los humanos escribir aplicaciones multihilo. Automatizar el proceso es mucho más difícil.
Déjame darte un ejemplo concreto. Una de mis últimas tareas en Intel fue convertir una parte de esta herramienta de expresiones regulares llamada Hyperscan para hacer algunas cosas multihilo. Ahora las expresiones regulares son un tipo de programa bastante conocido y contenido. Puedes escribir un simple intérprete de expresiones regulares como estudiante universitario. Uno realmente simple podría incluso ser simplemente una tarea para casa.
Además, la teoría está bien establecida y una parte de hyperscan convirtió NFAs en DFAs usando el algoritmo estándar. Pero los DFAs son de un solo hilo y sufren de explosión combinatoria. Así que, hyperscan tiene estrategias de respaldo si la conversión no funciona, como ejecutar un NFA. Pero, ejecutar un DFA es más eficiente cuando la conversión funciona. Así que, mi tarea era convertir el NFA en múltiples DFAs (hasta un máximo de ocho) y luego tratar de ejecutar esos DFAs en paralelo.
Paso 1, reescribí el motor DFA para que si la explosión combinatoria se establecía, dejaba de construir el DFA actual y pasaba a construir uno nuevo. Sólo dejaba de hacerlo si ya había construido ocho.
Paso 2, ejecutar los DFAs en paralelo como si fueran hilos, pero a paso de tortuga.
Paso 3, rehacer los DFAs para que estuvieran intercalados y hacer todo el trabajo posible en paralelo.
He escrito en otro lugar sobre el paso 3. Sin embargo, ninguna de esas tareas fue del todo trivial y eso a pesar de ser cosas esencialmente de manual. El proyecto tardó unos seis meses antes de que tuviéramos algo que funcionara lo suficientemente bien como para que el resultado fuera mejor que simplemente ejecutar el NFA original y valiera la pena enviarlo. Por supuesto, en ese momento, cuando funcionó, conseguimos una mejora sustancial en el rendimiento y una victoria en el diseño para el cliente específico al que nos dirigíamos.
Así que se trataba de un multihilo en una aplicación, y no en toda la aplicación, sino en una parte específica de la misma, en la que la parte en la que hacíamos el multihilo tenía propiedades sencillas y agradables, y aún así estamos hablando de meses de tiempo de una persona que conoce a fondo esa área de aplicación.
Compare eso con la cantidad de esfuerzo que se dedica a cosas como los emuladores para un chip en otro. Esos proyectos son de varios años y de varias personas. No están haciendo ningún multihilo, sólo tratando de asegurar que la semántica de un chip se recrea fielmente en otro chip. O cosas como VMware, que ni siquiera está haciendo todo el conjunto de instrucciones, sólo un pequeño subconjunto y, sin embargo, se han formado empresas enteras en torno a la idea. O compiladores just-in-time para JVMs.
Todas estas cosas son grandes, y tratar de reestructurar un programa de un solo hilo en un programa multihilo es tan grande como cualquiera de estos.
No va a suceder pronto. Desde luego, no será algo que cuando ocurra puedas soltar 50 dólares y conseguir un acelerador de juegos.