Frikis, mensajes navideños, cadenas en hexadecimal y computación concurrente

El megafriki de Pablo Alvarez Doval, nos envió una felicitación navideña códificada con caractéres hexadecimales. Cualquier persona normal hubiese pegado la felicitación en un editor de texto un poco potente y hubiese visto lo que decía. Pero el amigo Octavio Hernandez abrió la caja de Pandora: mando un método extensor para la clase String que descodificaba el mensaje.


Yo no he podido menos que recoger el guante e implementar mi propia solución al problema. He tratado de hacer algo original ,no eficiente, de hecho la solución de Octavio (que espero que publique en su blog) es infinitamente más eficiente. Yo he decidido usar paralelización, usando Microsoft Parallel Extensions, siguiendo mi proposito de este año de actualizar mis conocimientos de programación concurrente.


Dada la cadena en hexadecimal del mensaje, se hace evidente que la conversión de cada uno de los caracteres desde su represantación hexadecimal a un valor de tipo char es un operación atómica e independiente para cada caracter. Sin duda es una buena ocasión de usar programación concurrente (aunque a nadie se le debería ocurrir usar esto en un escenario real, el coste de la paralelización anula cualquier ventaja de rendimiento, en casos donde cada operación independiente tiene un coste mínimo como es el caso).



    1 using System;


    2 using System.Diagnostics;


    3 using System.Threading;


    4 


    5 namespace ParallelDecode


    6 {


    7   class Program


    8   {


    9     const string message =


   10       «%46%65%6C%69%63%65%73%20%46%69%65%73» +


   11       «%74%61%73%2C%20%63%61%63%68%6F%20%66» +


   12       «%72%69%6B%69%21%20%41%68%6F%72%61%2C» +


   13       «%20%64%65%6A%61%74%65%20%64%65%20%74» +


   14       «%6F%6E%74%65%72%69%61%73%20%79%20%76» +


   15       «%65%74%65%20%61%20%65%6D%62%6F%72%72» +


   16       «%61%63%68%61%72%74%65%20%75%6E%20%70» +


   17       «%6F%71%75%69%6E%21%21%20%4B%65%65%70» +


   18       «%20%52%6F%63%6B%69%6E%27%21%21»;


   19 


   20     static void Main(string[] args)


   21     {


   22       Stopwatch sw = new Stopwatch();


   23       sw.Start();


   24 


   25       string[] splitedMessage = message.Split(‘%’);


   26 


   27       char[] result = new char[splitedMessage.Length – 1];


   28 


   29       Parallel.For(0, result.Length, i =>


   30         {


   31           result[i] = (char)(int.Parse(splitedMessage[i + 1], System.Globalization.NumberStyles.AllowHexSpecifier));


   32         }


   33       );


   34 


   35       sw.Stop();


   36 


   37       Console.WriteLine(result);


   38       Console.WriteLine(«Tiempo de proceso: {0} ms.», sw.ElapsedMilliseconds);


   39 


   40       Console.ReadKey();


   41     }


   42   }


   43 }


En un post reciente me preguntaba si las abstracciones que se están construyendo serían lo suficientemente simples para facilitar la programación concurrente al comuún de los mortales… parece que sí, pues el código no puede ser más simple y desde luego es muchísimo más simple usar Parallel Extensions que la que hacer lo mismo usando hilos. La clase Parallel nos propociona mecanismos sumamente potentes y simples a la hora de añadir paralelización a porciones iterativas de nuestro código sin esfuerzo alguno.


¿Alguien más se anima a publicar otras soluciones diferentes al problema? ¿Quizás con LINQ o PLINQ? ¿Alguien con F#? ¿Alguien con T-SQL?…

ALM’08 Sessions ya disponbles en línea

Si no pudiste asistir o sólo pudiste ver una parte del ALM´08 Sessions, ahora tienes la oportunidad de disfrutar de más de 20 de las ponencias que se impartieron el pasado 16 de octubre. Todas grabadas en vídeo, con su audio original y sus presentaciones para repasar todas las áreas desarrolladas en el evento: Procesos, Integración y Herramientas (Solución ALM de Microsoft: Visual Studio Team System).

ALM08 Sessions Online 

Os invito a ver mi ponencia sobre Control de proyectos con metodologías ágiles y Team System. Podéis encontrar la ppt del evento aquí.

Por cierto, la web ha sido desarrollado en Silverligth por Plain Concepts. ¡Mi enhorabuena al equipo de UX por el resultado!.

¡La broma ha terminado!

Complejidad

¡La broma ha terminado…! es la frase que su agente de bolsa le dijo a Groucho Marx por teléfono minutos antes de suicidarse tras el crack del 29. La frase vuelve a  estar de moda ahora que la crisis es una realidad de nuevo. Que nadie piense que me he vuelto loco y ahora mi blog va a tratar de economía. Hoy vengo a hablar de otra crisis que nos toca más directamente a los programadores: el fin de la Ley de Moore tal y como la conocíamos hasta ahora. No es que los microprocesadores  vayan a dejar de doblar su potencia cada año y medio más o menos, sino que este incremento de velocidad va a dejar de ser transparente para los desarrolladores de software. Los desarrolladores tenemos nuestra propia crisis técnica. El crecimiento de velocidad va a venir de las mejoras en paralelización de los microprocesadores, no de las mejoras de velocidad de proceso en sí. Los procesadores serán capaces de hacer más cosas a la vez, pero no serán capaces de hacerlas más rápido. La potencia se define como trabajo por unidad de tiempo. Hacer más trabajo a la vez es una manera tan buena de mejorar la potencia como hacer el trabajo más rápido.

 

A la economía se le acabo la confianza, a los desarrolladores se nos acabo el poder confiar en que nuestro software se ejecutará más rápido con solo cambiar de máquina. Igual que ha ocurrido con la economía hay voces que ya nos llevan hablando de los posibles problemas desde hace tiempo. Esta es una realidad que ha mordido ya a algunos, con paradojas como que incrementar el número de procesadores de su servidor de bases de datos haga que las consultas sean más lentas. Pero la cosa no va a quedar aquí. Si a futuro queremos que nuestro software siga beneficiándose de las mejoras de rendimiento de los procesadores en el futuro debemos empezar a cambiar ya nuestra manera de desarrollar.

 

No tengo claro aun cual va a ser la magnitud del impacto, igual que ocurre con la crisis económica se están tomando infinidad de medidas para tratar de minimizar el impacto de esta crisis. Hay cientos de equipos de desarrollo trabajando a bajo nivel para dotarnos de abstricciones que puedan evitar que los desarrolladores de negocio tengan que preocuparse por estas cuestiones. En cualquier caso el mundo del desarrollo va a ser más complejo, no importa como de buenas sean las abstracciones.

 

Lo que está claro es que los desarrolladores seremos quienes de un modo u otro tendremos que empezar a pensar en paralelización. Y la paralelización no es un problema trivial. Es un problema que separa el trigo de la paja, al buen desarrollador (desde programadores a arquitectos) del desarrollador en la media. Cierto es que los desarrolladores de herramientas de desarrollo nos van a tratar de facilitar la vida construyendo herramientas y abstracciones que faciliten la adopción de este nuevo paradigma, pero toda abstracción no trivial fuga detalles, como reza la ley enunciada por Joel Spolky.

 

Se están construyendo nuevas abstracciones, como las Parallels Extensions de .Net, la Parallel Patterns Library de C++ y muchas otras, que van ha permitir que los desarrolladores de negocio se centren en resolver los problemas que realmente importan, los del negocios. Pero mucho me temo que estas abstracciones nos van a plantear problemas: exigen cambios de diseño y tendrán, como todas las abstracciones, fugas y en este caso las fugas serán fugas de complejidad elevada. En cualquier caso el cambio de paradigma nos exige una nueva manera de pensar. Los hilos son una abstracción demasiado débil. Tenemos que empezar a pensar en tareas no en hilos. Y en relaciones entre esas tareas y su concurrencia en lugar de en sincronización de hilos. Es la única manera de abordar la complejidad que la programación concurrente aplicada a un amplio espectro de aplicaciones impone.

 

Dicen que en Chino crisis y oportunidad se expresa con la misma palabra. A la vista de la silenciosa revolución que está ocurriendo una nueva raza de desarrolladores va a surgir: aquellos que dominen la programación concurrente. En mis primeros tiempos como desarrollador de C/C++, había una casta especial de desarrolladores, mejor pagados y más considerados que los demás, esa casta estaba formada por los desarrolladores de C/C++ que además dominaban las optimizaciones en esamblador del código. Llego un momento en que la Ley de Moore y la mejora en los compiladores hizo innecesarios a estos desarrolladores, pero durante mucho tiempo, contar con uno de estos en tu equipo fue algo clave. Creo que esto va ha ocurrir de nuevo.

 

De aquí se deriva mi propósito en el ámbito técnico para el año que viene: actualizar mis conocimientos sobre programación multihilo a la programación concurrente. Si alguien más se quiere unir a este propósito le invito a empaparse el número de Octubre de MSDN Magazine y a visitar el centro de desarrollo de Parallel Computing de Microsoft.