Después de Sieve en Javascript, o os dejo el mismo algoritmo, implementado en C, y generado con diferentes compiladores.
Como era de esperar, la velocidad de ejecución es francamente superior, por lo que para obtener resultados más precisos, he aumentado las iteraciones de 10.000 en la versión Javascript, a 50.000 en esta versión en C. Para los que no os hayáis leído la descripción del algoritmo, decir que su tiempo de ejecución es aproximadamente cúbico, es decir, 50.000 iteraciones no requieren 5 veces más cálculos que 10.000, sino 125 veces.
Todas las compilaciones se han hecho con el máximo nivel de optimización para velocidad en tiempo de compilación.
| Compilador | Plataforma | Tamaño código (bytes) | Tamaño ejecutable (bytes) | Tiempo de ejecución (ms) |
| Digital Mars C++ 8.52 | x86 | 506 | 40.476 | 24.945 |
| Embarcadero C++ Builder XE | x86 | 1.331 | 75.264 | 27.236 |
| Microsoft Visual C++ 2010 | x86 | 10.589 | 47.616 | 23.636 |
| Microsoft Visual C++ 2010 | x64 | 10.614 | 54.784 | 23.659 |
| MingW GNU C Compiler 3.4.5 | x86 | 930 | 18.315 | 24.904 |
| OpenWatcom C++ 1.9 | x86 | 732 | 30.720 | 25.880 |
| Pelles C 6.0 | x86 | 1.004 | 30.720 | 35.233 |
| Pelles C 6.0 | x64 | 1.297 | 38.912 | 35.412 |
Sobre los resultados, Visual C++ está en primera posición. La versión x64, es infinitesimalmente más lenta, debido a que manejar 64 bits con el número de iteraciones aplicado, no aporta ninguna ventaja, y requiere a cambio usar apuntadores a memoria de 64 bits. El tamaño del código generado es enorme, por lo agresivo del inlining que hace, aunque luego el ejecutable final esté entorno a la mitad de la tabla.
Le siguen muy de cerca GCC, con el ejecutable más compacto del lote; y luego los tecnologicamente obsoletos DigitalMars C++ (basado en Symantec/Zortech/Zorland C++) que obtiene el código más pequeño de todos; y OpenWatcom C++ (basado en Watcom C++).
A algo más de distancia, tenemos a C++ Builder, y es que Borland nunca brilló en la eficiencia de su compilador de C/C++, y con el paso del tiempo, tampoco se han dedicado los recursos necesarios a mejorarlo.
En el vagón de cola, tenemos a Pelles C, tanto en su arquitectura de 32 como de 64 bits.
En todo caso, las diferencias entre el primero y el último clasificados, rondan solamente el 20%, lo que quiere decir que es un código lo suficientemente simple como para que el optimizador no tenga mucha libertad de movimientos.
Comparando estos resultados con los obtenidos en la versión de Javascript, vemos que aunque JIT ha dado mucha mejoría, está todavía distante del código nativo en tiempo de compilación en un factor de al menos 25x.
Como de costumbre, tienes todos los fuentes y los binarios, disponibles para descargar aquí (179 Kb. en formato ZIP).