web securizada
Proyecto creado bajo licencia Creative Commons 4.0

benchmark zone

PROJECT HOSTED ON A SECURE SERVER CALENTAMIENTOGLOBALACELERADO.NET ©© 2022

Disculpe los errores / Sorry for the mistakes

... Estoy trabajando en este contenido / I am working on this content ...

web in spanishweb in englishbenchmarkzone en frances

· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 

Bienvenido a
benchMARK zone

Welcome to
benchMARK zone

Web temática sobre benchmarking informático dirigida a diferentes perfiles de usuarios de computadoras, basada especialmente en los test de rendimiento para procesadores y cuyo contenido se encuentra protegido bajo licencia Creative Commons.

Mi principal objetivo al poner en marcha este proyecto ha sido convertir esta publicación en un viaje al fondo de los BenchMarks computacionales y en ella recupero y comparto de paso parte de mis trabajos no publicados.

Todo su contenido es 100% accesible a cualquier nivel de conocimiento y ya os adelanto que no vamos adentrarnos en la programación recursiva ni vamos a diseñar un algoritmo heurístico para el cálculo de números primos, solo espero que el contenido de esta web pueda divertirte y ampliar de alguna manera tus conocimientos sobre los benchmark's.

Thematic website on computer benchmarking aimed at different profiles of computer users, based especially on performance tests for processors and whose content is protected under a Creative Commons license.

My main objective in starting this project has been to turn this publication into a trip to the bottom of the computational BenchMarks and in it I recover part of my unpublished works.

All its content is 100% accessible at any level of knowledge and I already tell you that we are not going to get into recursive programming nor are we going to design a heuristic algorithm for the calculation of prime numbers, I just hope that the content of this website can have fun and expand your knowledge about benchmarks.

separata_benchmarkzone_website

ÍNDICE DE CONTENIDOS / INDEX OF CONTENTS

¿Qué es un benchmark informático y para qué sirve?

Pasión por los benchmarks

Desde el benchmark más simple para microordenadores de los años 80 (era 8-bits)...

...Hasta PRIMEStone500, un benchmark actual con suficiente potencial

Viejos benchmarks corriendo en máquinas actuales (el presente se asoma al pasado)

LOOKIT, una vieja herramienta de la época de MS-DOS probada en la actualidad

FreeBASIC vs FreeBASIC. ¿Hacia dónde va el rey de los compiladores BASIC?)

Benchmark comparativo de algoritmos para el cálculo de números primos. TURBOPRIM++ vs La Criba de Eratóstenes.

Taller de desarrollo. Creamos nuestro propio benchmark: BenchSQUARE

C>OveRBooST o cómo liberar a nuestro procesador de la mochila de los servicios

Cuando los 486 superaron a los PENTIUM's

Enlaces a principales páginas webs sobre benchmarks

Área de descarga/Telechargue/Download
· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 

bencmarkzone cpu processor icoOrígenes y definición de benchmark informático (Métricas de rendimiento)

El origen de los benchmarks* (también llamados "prueba patron") es casi tan antiguo como el de las propias computadoras. Básicamente se trata de herramientas de software diseñadas exclusivamente para medir la capacidad de rendimiento de un sistema hardware y/o software o de un dispositivo concreto, tarjeta gráfica, procesador, coprocesador, etc. Sin embargo, si pretendemos llegar a una definición más precisa del concepto debemos ir a la traducción literal de este anglacismo que viene a significar "punto de referencia", lo cual nos lleva directamente a la esencia de su sentido que no es otro que la comparación objetiva entre diferentes sistemas partiendo de un "punto de referencia".

Y es que un benchmark, independientemente de la calidad de su algoritmo y/o de sus resultados, carece de cualquier valor sin no contamos con los suficientes "puntos de referencia" obtenidos en otros sistemas, de ahí la necesidad de mantener una rigurosidad estricta en cuanto a las condiciones de evaluación así como una base de datos en la que almacenar dichos resultados y alimentada mediante el testeo del máximo número posible de plataformas.

Aunque no existe hasta la fecha ningún estándar, los índices benchmarks informáticos, actualmente en desuso, que mayor aceptación obtuvieron en su momento son:

  • Dhrystone: prueba de rendimiento informático general creada en 1984 y desarrollada originalmente para probar la eficiencia del compilador ADA fue convertida posteriormente al lenguaje C para su ejecución en ordenadores compatibles con el IBM-PC. Debido a la gran cantidad de compiladores de C en uso, el Dhrystone sufrió el mismo tipo de sesgo que su antecesor, el Whetstone.
  • Whetstone: desarrollado en 1960, consiste en una prueba de computación general combinada con cálculos numéricos de coma flotante escrita originalmente en lenguaje FORTRAN, por lo que sus resultados estaban muy sesgados tanto por la eficiencia del compilador como por la relación entre las instrucciones matemáticas de coma flotante y las instrucciones aritméticas y de bucles.

El mundo de los benchmarks ha evolucionado al ritmo de la computación en general y en la actualidad, el campo de la ingeniería informática centrado en la métrica de rendimiento se estudia en un gran número de universidades como parte de la asignatura Arquitectura de los Computadores, pertenciente a la rama de Arquitectura y Tecnología.

*NOTA: Es importante saber que el vocablo benchmark no es ni mucho menos exclusivo del ámbito de la computación sino que también podemos encontrarlo en otros campos como el de la economía, de ahí la desambiguación que algunas fuentes hacen mediante la concreción en la entrada como benchmark informático (fuente Wikipedia).

 

 

separata_benchmarkzone_website

 

bencmarkzone cpu processor ico¿Para qué sirve un benchmark informático?

En realidad, y aunque podemos llegar a afirmar que cualquier usuario medio de computadoras podría sobrevivir a lo largo de toda su vida sin utilizar ningún benchmark informático, existen ámbitos en los que el uso de estas utilidades se torna fundamental. La ciencia de la computación necesita de herramientas precisas que puedan determinar la capacidad real de un sistema digital para afrontar y resolver un problema, ya sea un sistema gráfico, un procesador, una impresora, un software específico, un router, un adaptador wifi, una unidad de almacenamiento, etc., en la informática todo absolutamente debe ser cuantificado con la máxima precisión y para ello debe recurrirse irremediablemente a la comparativa mediante benchmarks.

Ajustes finos de BIOS, prácticas de OverClocking, testeo de rendimiento en videojuegos, etc. son tareas que carecen de sentido sin la existencia de un benchmark adecuado que nos permita conocer con certeza el nivel de eficiencia con el que trabajamos, por ello, y aunque en el momento de la edición de la GUÍA DEL COMPRADOR DE INFORMÁTICA 1984 (comentada posteriormente) aún no existiera el Dhrystone, queda ya patente en dicha obra como los benchmarks establecían el nivel de potencia de los computadores del momento tratando de orientar al usuario en un mercado que ya comenzaba a multiplicarse exponencialmente.

 

 

separata_benchmarkzone_website

 

 

bencmarkzone cpu processor icoPasión por los benchmarks

Supongo que aquella Guía del comprador de Informática tuvo algo que ver con toda esta historia. A decir verdad, aquel 1984 fue un año bastante emocionante en el que el nacimiento del Dhrystone fue solo una pincelada de lo que el futuro próximo nos aguaradaba, y ese mamotreto rebosante de información y repleto de fotografías de todo tipo de computadoras bien merecía su precio a pagar. Todo lo que podía contener aquella suerte de revista de 2 cm de grueso y casi 400 páginas por 1250 pesetas era pura gasolina para la mente de un adolescente enamorado ya de cualquier objeto que se asimilara a una computadora.

Algo curioso y destacable en esta publicación de HAYMARKET era que todas las máquinas allí reseñadas presentaban los tiempos obtenidos en unas pruebas de cálculo cuyo código fuente se incluía en las primeras páginas del volumen. Recuerdo fielmente que aquellos datos estimulaban mi imaginación hasta límites insospechados. Devorar sus páginas mientras soñaba con poder acceder un día a alguno de esos supercomputadores se convirtió en una actividad cotidiana para mí en aquellos tiempos. Enormes y gigantescos supercomputadores cuyas capacidades de computación caben hoy en la palma de nuestra mano.

guia comprador informatica 1984

Para ir entrando en materia voy a recuperar aquí 3 de los tests realizados en la computadoras reseñadas, en concreto los números 1, 2 y 3, descartando el resto por incluir algunas funciones gráficas. Estas pruebas fueron al parecer realizadas por el equipo técnico encargado de la propia Guía y lo cierto es que se testearon una cantidad importante de máquinas. Hoy, transcurridos casi 40 años desde entonces, podemos analizar sus resultados para comprender el auténtico avance en la capacidad de computación que debemos a los procesadores.

TEST 1:

10 PRINT "COMIENZO"

20 FOR I=1 TO 1000

30 A=1

40 IF A=1 THEN 50

50 A=2

60 IF A=3 THEN 60

70 B=1

80 GOSUB 120

90 NEXT I

100 PRINT "FIN"

110 END

120 RETURN

TEST 2:

10 PRINT "COMIENZO"

20 FOR I=1 TO 2000

30 A=I*2

40 B=A-I

50 C=B/I

60 D=C^2

70 NEXT I

80 PRINT "FIN"

90 END

TEST 3:

10 PRINT "COMIENZO"

20 FOR I=1 TO 2000

30 A=TAN(I)

40 B=SIN(I)

50 C=COS(I)

60 D=ATN(A)

70 E=LOG(I)

80 NEXT I

90 PRINT "FIN"

100 END

Viendo y comparando los resultados obtenidos para distintos sistemas he observado que alguna computadora se testeó usando el lenguaje BASIC compilado lo cual arrojaba cronos mucho más rápidos y desvirtúa los resultados. También se deja constancia que en algunas plataformas no pudo probarse el TEST 3 al ofrecerse éstos equipos solo con el lenguaje de programación COBOL que, al estar enfocado especialmente al desarrollo de aplicaciones de gestión, carecía de funciones trigonométricas. En otros casos, algunas máquinas directamente no se facilitaron por el fabricante para realizar los tests pero aún así el valor documental e histórico de este trabajo es innegable.

Publicaré aquí algunos ejemplos bastante significativos de esas "bestias" de cálculo relacionadas en esta GUÍA DE 1984 y de los resultados arrojados en las pruebas. De momento os paso este recorte de noticia que me constó horrores encontrar y que finalmente apareció por sorporesa entre las páginas de un libro de ensamblador de Anaya:

.

Espero mostrar pronto una relación de tiempos obtenios en los test 1, 2 y 3 por las computadoras analizadas en la gran Guía del comprador de Informática de 1984 y cuyos códigos fuentes ya hemos visto. ¿Habrá sorpresas?

 

 

separata_benchmarkzone_website

 

bencmarkzone cpu processor icoDesde el benchmark más sencillo para microordenadores de los años 80 (era 8-bits)...

Lo cierto es que tras disfrutar de lo lindo con la fantástica GUÍA DEL COMPRADOR DE INFORMÁTICA durante algunos años (la edición del año 1987 ya carecía de los benchmarks;), pocas máquinas pasaron por mis manos sin ser testeadas. Algunos de esos empeños, a veces trasnochados, resultaron en una tabla casera que yo mismo fui confeccionando crono en mano:

TIEMPO MEDIO OBTENIDO EN LA EJECUCIÓN DE BUCLE TIPO

FOR …NEXT de diez mil iteraciones

EN DIFERENTES PLATAFORMAS COMPUTACIONALES

Equipo Testeado

Tipo de plataforma

Año fabricación

Tiempo obtenido
[sg. ]

Casio FC-200 *

Calculadora financiera programable

1988

3861- 3452*

Sharp PC-1251

Pocket Computer/Computadora de bolsillo

1982

422

Casio FX-702P

Pocket Computer

1981

162

Sharp PC-1500

Pocket Computer

1981

141

Sharp PC-1401

Pocket Computer

1983

141

Casio PB-700

Pocket Computer

1983

107

Casio FX-770P

Pocket Computer

1985

104

Casio PB-410

Pocket Computer

1984

98

Casio FX-795P

Pocket Computer

1986

97

Casio FX-785P

Pocket Computer

1986

97

Casio FX-730P

Pocket Computer

1986

96

Sharp PC-1248

Pocket Computer

1995

80

Casio PB-100

Pocket Computer

1983

69

Casio FX-802P/PB-300

Pocket Computer

1983

69

Sharp PC-1350

Pocket Computer

1984

69

Sharp PC-1403

Pocket Computer

1984

64

Sinclair ZX-Spectrum (Z-80@3.5Mhz)

Microordenador

1982

61

Casio PB-1000 (Pocket Computer)

Pocket Computer

1986

38

Casio FX-880P (Pocket Computer)

Pocket Computer

1987

27

Oric Atmos (6502@1Mhz) (Microordenador)

Microordenador

1983

21

SharpPC-E500 (Pocket Computer)

Pocket Computer

1989

20

Sharp PC-G830 (Pocket Computer)
(BASIC no compilado)

Pocket Computer

1995

18

Amstrad NC-200 (Z-80@3.3Mhz)

Notebook (Microordenador portátil)

1993

10

Amstrad® CPC-464

Microordenador

1985

10

Sharp PC-G850 (Pocket Computer)
(BASIC no compilado / C compilado)

Pocket Computer

1995

9 / 4

PSION Series 3a (V30H@7,68 Mhz)
(Do...While) (BASIC compilado)

PDA

1993

<3

PalmTX® Tungsteno
(CPU intel ARM@312 Mhz)

(SmallBASIC no compilado)

PDA

2005

< 2

PSION Series 5 (ARM 7100@18 Mhz)
(Do...While) (BASIC compilado)

PDA

1997

< 1

IBM PC Aptiva®  (CPU IBM5x86-@100 Mhz )

Ordenador personal

1996

< 1

IBM ThinkPad (Celeron@600 Mhz)

Ordenador personal

1998

< 1

PC clónico (CPU AMD® XP 2.0 Ghz)

Ordenador personal

1999

< 0.001

*La Casio® FC-200 que encabeza la tabla es una calculadora financiera programable que si bien no dispone de intérprete BASIC ni de órdenes tipo FOR..NEXT, sí está dotada de un sencillo lenguaje con orden de salto/bifurcación (GOTO) y condicionales que me han permitido elaborar este sencillo test de 10 mil iteraciones sumando una variable hasta alcanzar este valor:

· Código del programa para CASIO FC-200:

0 → B :Lbl 1 :B+1→B :B<10000 ⇒ Goto 1

· Código alternativo del programa un 15% más rápido:

A→10000 :0→B :Lbl 1 :B+1→B :B<A ⇒ Goto 1

Observa que la Casio® FC-200 ha arrojado dos tiempos diferentes en función de si la comprobación del bucle la realizamos mediante B<A ó B<10000. Este sutil pero aparentemente inocuo cambio en el código del programa aporta una curiosa mejora en el rendimiento de casi un 15%.

Para que te hagas una idea de lo que significa el programa anterior, este breve código que hemos utilizado con nuestra calculadora Casio® FC-200 equivaldría en BASIC, más o menos, a lo siguiente:

10 A=10000: B=0

15 B=B+1: IF B<A THEN GOTO 15

De hecho, lo único que hace nuestro programa es sustituir a las órdenes FOR..NEXT mediante un contador (variable B) que incrementamos de uno en uno y un condicional IF..THEN que se encarga de comprobar si B es menor que A, en cuyo caso el programa salta a la línea 15 para que repita la acción de incrementar siempre que el valor de B sea menor al de la variable A, que habíamos establecido en 10000 en la línea 10. Finalmente, cuando el valor de B iguala al valor de A, se ignora la orden de salto/bifurcación GOTO y se finaliza la ejecución del programa.

NOTA: todos los BASIC lineales (los que utilizan número de línea) suelen admitir líneas de programa de tipo múltiple, es decir, aquellas en las que se incluyen varias órdenes separadas por dos puntos.

[ parte del contenido ha sido extraído de mi proyecto inacabado ALBACO ]

... Dicen algunos matemáticos que los números primos son a las matemáticas como los átomos a la ciencia, como si se tratase de los ladrillos que forman todo lo que conocemos en el universo, y aunque la afirmación puede resultar demasiado pretenciosa, lo cierto es que el reto sigue ahí intacto desde la noche de los tiempos. Para otros, cada número primo constituye una entidad única con vida propia y por ello, el cálculo de estos misteriosos elementos mediante computadoras ha supuesto un reto clásico en la programación llevando a algunos complejos algoritmos a competir por obtener el máximo rendimiento de cálculo posible. No obstante, y siempre que nuestras expectativas sean algo menos pretenciosas, el algoritmo estándar que aquí estudiaremos seguramente pueda satisfacer nuestras necesidades y nos servirá para calcular listas de números primos relativamente grandes, incluso, en microcomputadoras antiguas con procesadores de 8 bits.

Sin embargo, como trabajo ampliatorio y al objeto de ofrecer al lector una visión algo más viva de la evolución de la informática en poco más de dos décadas, consideré oportuno probar el presente algoritmo en diversas plataformas pertenecientes a distintas generaciones. El código que veremos a continuación, por su sencillez podrá ser comprendido y ejecutado por prácticamente cualquier programador y computadora existente.

· Código literal del programa escrito para Pocket Computer (computadora de bolsillo) SHARP PC-1350:

5400 REM * * * ALGORITMO ESTANDAR PARA CALCULO DE NUMEROS PRIMOS * * *

5405 WAIT 0 : CLS : CLEAR

5410 INPUT "N.PRIMOS DEL 1 AL? ";N

5417 PRINT " 2, 3,";

5420 FOR I=5 TO N STEP 2

5425 FOR D=3 TO SQR I STEP 2

5430 IF I/D=INT(I/D) THEN 5460

5440 NEXT D

5445 PRINT USING "#####";I;",";

5460 NEXT I

5465 BEEP 1

5499 END

En la tabla siguiente se muestran los resultados obtenidos en diferentes calculadoras científicas y computadoras de bolsillo de la época que se tornan ciertamente ridículos frente a los resultados obtenidos en sistemas más modernos. También debemos considerar que el uso de lenguajes compilados en los sistemas modernos, ya sea BASIC, C, Pascal o cualquier otro, permite convertir y correr el programa en código máquina directamente ejecutable por el procesador y no en modo interpretado, lo cual acelera de forma drástica la velocidad de ejecución al evitarse la traducción o interpretación de todas y cada una de las órdenes referidas en el código.

Partiendo del código fuente anterior, los resultados siguientes fueron obtenidos en pruebas realizadas sobre distintas plataformas utilizando en todos los casos un intérprete BASIC (no compilado) para correr el código y con las mínimas adaptaciones posibles:

Equipo testeado

Tipo de plataforma

Núm. primo alcanzado a los
10 minutos de proceso

Texas Instruments® TI-57

Calculadora científica programable

331

Sharp® PC-1211

Pocket computer/Computadora de bolsillo

359

Hewlett Packard® HP-41C

Calculadora científica programable

449

Casio® FX-702P

Pocket computer

739

Casio® PB-700

Pocket computer

1307

Sharp® PC-1350

Pocket computer

1823

Sharp® PC-1248

Pocket computer

2457

Toshiba T1800® (CPU i386SX@16 Mhz)

Ordenador personal

34159

IBM Aptiva (CPU IBM5x86-@100 Mhz)

Ordenador personal

3098899

PC compatible (iPentium® IV@2,53 Ghz)

Ordenador personal

17497097

PC compatible (AMD® Sempron 3500+@1.8 Ghz)

Ordenador personal

29999999

Si bien los resultados mostrados deben ser tomados como orientativos (dadas las significativas diferencias obtenidas en función de los sistemas operativos en los que se corra el código y sobre todo los intérpretes de BASIC empleados), estos datos nos ofrecen una idea bastante aproximada del incremento de potencia que las distintas generaciones de máquinas han ido aportando en lo que a velocidad de cálculo se refiere.

Tampoco debemos obviar que el rendimiento de los cálculos puede variar sensiblemente de una máquina a otra debido a la salida por pantalla de los números primos, por lo que una mayor precisión y fiabilidad en los resultados sería posible omitiendo el proceso de visualización por pantalla.

Otro frente determinante es el papel que juega el grado de optimización de un algoritmo y que bien podría llegar a multiplicar el rendimiento corriendo incluso en idénticas plataformas (hardware+software) y compilando el código con el mismo compilador.

En este último sentido que afecta exclusivamente a la optimización del código, tengamos en cuenta que de un algoritmo estándar SIN PULIR (y con un problema de coherencia que afecta los bucle D) como este:

5400 N=1000000 ' ENCUENTRA PRIMOS HASTA N

5410 PRINT "2 , 3, "; ' OMITE EL CALCULO DEL 2 Y EL 3

5420 FOR I=5 TO N STEP 2 ' INICIA COMPROBACIONES DESDE EL 5

5425 FOR D=3 TO INT(I/2) STEP 2

5428 IF D>SQR N THEN 5440

5430 IF I/D=INT(I/D) THEN 5460 ' SI ES DIVISIBLE SALTA

5440 NEXT D ' SI NO ES DIVISIBLE INCREMENTA D Y REPITE

5445 PRINT USING "#####";I;","; ' IMPRIME PRIMO

5460 NEXT I ' INCREMENTA CANDIDATO HASTA N

...a este otro, casi idéntico pero YA PULIDO:

5400 N=1000000 ' ENCUENTRA PRIMOS HASTA N

5410 PRINT "2 , 3, "; ' OMITE EL CALCULO DEL 2 Y EL 3

5420 FOR I=5 TO N STEP 2 ' INICIA COMPROBACIONES DESDE EL 5

5425 FOR D=3 TO SQR I STEP 2

5430 IF I/D=INT(I/D) THEN 5460 ' SI ES DIVISIBLE SALTA

5440 NEXT D

5445 PRINT USING "#####";I;","; ' IMPRIME PRIMO

5460 NEXT I ' INCREMENTA CANDIDATO HASTA N


... logramos prácticamente DUPLICAR la velocidad de cálculo demostrando que la optimización del código puede ser determinante en el rendimiento de algunos procesos y de ahí la necesidad de crear un marco de referencia fijo a la hora de implementar cualquier tipo de prueba de rendimiento.

Si observamos con detalle el código fuente de ambos programas, veremos que en el segundo caso lo único que hemos hecho ha sido suprimir un condicional (línea 5428) estableciendo el valor límite para la variable D en la línea 5425 en la que se define el propio bucle, es decir, en el primer caso comprobábamos en la línea 5428 que el valor de D (que se utiliza como divisor) no superara a la raíz de N y en el segundo algoritmo hemos establecido ese límite en la propia línea 5425 FOR D=3 TO SQR I STEP 2 ahorrando un condicional y un montón de iteraciones en el bucle principal D

Por otro lado, en ambos algoritmos establecemos el salto de dos en dos para los dividendos (números candidatos sobre los que se comprueba su divisibilidad para comprobar si son primos) en la línea 5420 FOR I=5 TO N STEP 2, ya que todo número primo es impar (salvo el 2).

Observa que, aunque carece de relevancia, en ambos ejemplos se comienza a buscar a partir desde el número 5, suponiendo ya el 2 y el 3 como primos e ignorando la comprobación de éstos.

Además, también podemos reducir el número de cálculos ignorando los divisores pares en el bucle de la línea 5425 FOR D=3 TO SQR I STEP 2 ya que al ser todos los primos números impares, en consecuencia nunca podrá ser divisible por un número par y de ahí que se compruebe solo su divisibilidad a partir del número 3 y únicamente con números impares.

Y cómo último punto de optimización en el segundo caso, ya comentado en el primer párrafo, observa que se comprueba solo los divisores hasta la raíz del número candidato que se está comprobando en ese momento (almacenado en la variable I) y al superar el divisor a la raíz del mismo, se pasa a comprobar directamente el siguiente candidato para ser primo (incrementando el valor de I) sin necesidad de continuar comprobando más divisores (línea 5425), algo que no ocurre en el primer ejemplo en el que el techo del bucle D es hasta la mitad del valor de I

Es obvio que si implementamos nuestro código en un ordenador mínimamente actualizado los resultados pueden alcanzar fácilmente números primos de varios millones pero la disparidad en los resultados asociada a la optimización del código puede ser notable.

Y a estas alturas muchos ya os habéis hecho la pregunta del millón... ¿Qué peso puede tener en la velocidad de cálculo el compilador a la hora de ejecutar un código? Bien, este asunto lo retomaremos en el apartado Benchmark de compiladores de código y lenguajes de programación probados en máquinas retro y actuales de forma mucho más detallada y profunda, pero para ir haciendo boca permitidme un pequeño apunte para programadores que habla por sí solo.

· Código fuente de ejemplo compilado con diferentes compiladores y ejecutado en la misma plataforma:

5410 INPUT "N.PRIMOS DEL 2 AL";N

5415 PRINT T$=TIME$: PRINT T$

5417 FOR I=2 TO N STEP 2

5425 FOR D=3 TO SQR(I) STEP 2

5430 IF I/D=INT(I/D) THEN 5460

5440 NEXT D

5445 PRINT I; ",";

5460 NEXT I

5499 PRINT ">CALCULO DE NUM.PRIMOS DEL 2 AL ";N

5505 PRINT "> comienzo a: ";T$

5510 PRINT "> finalizo a: ";TIME$

A continuación se muestran los tiempos obtenidos en la misma plataforma corriendo exactamente el mismo código en distintos intérpretes y compiladores BASIC's para N=1000000 (1 millón):

· Microsoft® QBasic (interpretado) corriendo MS-DOS: 180 sg

· Microsoft® QuickBASIC 4.5 (compilado) corriendo MS-DOS: 55 sg

· POWERBasic® 3.5 (compilado) corriendo MS-DOS: 5 sg

Como puedes ver en este sencillo experimento la importancia de los compiladores es determinante y su peso en los resultados podría incluso superar a veces al de la propia optimización del código. Este problema precisamente fue el que debió afectar al clásico índice benchmark Dhrystone desarrollado en 1984 y que provocaba enormes sesgos en los resultados en función del compilador empleado.

En la sección Comparativa de rendimiento entre algoritmos para el cálculo de números primos de esta misma web profundizaremos en el cálculo de estos fascinantes y misteriosos números que son los primos.

 

 

separata_benchmarkzone_website

 

bencmarkzone cpu processor ico... Hasta el benchmark PRIMEStone500 CPU Benchmark

El software PRIMEStone500 es mi último microproyecto sobre BenchMARKs y su código (público) está escrito en uno de los compiladores más rápidos existente. El índice PRIMEStone500 refleja la capacidad de cálculo computacional matemático de procesadores compatibles con la arquitectura x86/x64 corriendo sistemas operativos Windows® 32/64 bits a partir de su algoritmo principal que calcula el primer millón de números primos.

PRIMEStone500 constituye un test sintético de "alto nivel" y está formado por un único archivo ejecutable (EXE) de apenas 69 Kbytes que se ejecuta en el sistema destino sin ningún tipo de instalación y que arroja el índice de rendimiento en pocos segundos.

Una vez finalizado el test usted puede ver y estudiar el código fuente del algoritmo TurboPRIM++ empleado en PRIMEStone500 para calcular el primer millón de números primos que, de hecho, muestro a continuación. Digamos que TURBOPRIM++ es un método estándar mejorado para obtener números primos de forma más rápida. Para ello me inspiré en la idea propuesta por el ingeniero Ramón Farrando Boix (Perito Industrial Eléctrico y Mecánico) en su obra "109 PROGRAMAS PARA ORDENADORES PERSONALES Y CALCULADORAS" y que veremos más adelante en la sección Comparativa de rendimiento entre algoritmos para el cálculo de números primos de esta misma web.

Aquí les presento el código literal y comentado empleado en el algoritmo TURBOPRIM++ empleado en el benchmark PRIMEStone500:

SE OMITE DECLARACION VARIABLES POR CARECER DE RELEVANCIA PARA FUNCIONAMIENTO ALGORITMO

---------------------------------------------

N=15485863 : T=Sqr(N) : DIM P(T) ' NUMERO MAXIMO A COMPROBAR Y TAMANO LIMITE DE VECTOR

P(0)=2 : P(1)=3 : J=2 : TP=2 ' TP=2 PORQUE ASI CONTABILIZA 2 Y 3 COMO PRIMOS

L2=Timer ' INICIA PROCESO PRIMARIO Y CUENTA DE TIEMPO

For D=5 To N Step 2 ' BUCLE DE DIVIDENDOS/POSIBLES/CANDIDATOS PRIMOS

 For I=3 To Sqr(D) Step 2 ' BUCLE DE DIVISORES

   If D Mod I=0 Then Goto S2 ' SI D ES DIVISIBLE LO DESCARTA COMO PRIMO Y SALTA

 Next I ' SIGUIENTE BUCLE DIVISORES

 TP+=1: P(J)=D ' SI D NO ES DIVISIBLE INCREMENTA TOTAL Y GUARDA NUMERO PRIMO

 If D>Sqr(N) Then Goto S3 ' SI CANDIDATO ES > QUE RAIZ DE NUMERO MAXIMO (=T) SALE DEL PROCESO

 J+=1 ' INCREMENTA VALOR INDICE DEL VECTOR

S2: ' LABEL DE SALTO

Next D ' SIGUIENTE BUCLE DIVIDENDOS/POSIBLES/CANDIDATOS PRIMOS

S3: ' LABEL. FINALIZA PROCESO PRIMARIO E INICIA SECUNDARIO

For E=D To N Step 2 ' BUCLE DE DIVIDENDOS/POSIBLES/CANDIDATOS PRIMOS

 For V=1 To J ' BUCLE CON INDICE QUE RECORRE VECTOR P()

  K=P(V) ' K = VALOR DE LA TABLA DE PRIMOS GUARDADA EN P(V)

  If E Mod K=0 Then Goto S4 ' SI E ES DIVISIBLE SE DESCARTA COMO PRIMO Y SALTA

 Next V ' SIGUIENTE BUCLE DE DIVISORES

 TP+=1 ' SI E NO ES DIVISIBLE INCREMENTA TOTAL PRIMOS

S4: ' LABEL DE SALTO

Next E ' SIGUIENTE BUCLE DE DIVIDENDOS/POSIBLES/CANDIDATOS PRIMOS

T2=Timer-L2 : ip=Int(((1/T2)*500)) ' CALCULA INDICE PRIMEStone500

El código del algoritmo TURBOPRIM++ ©© ha sido escrito por MaRaF SOFT para el compilador FreeBASIC y hace un uso comedido de variables numéricas de 64-bit del tipo ULongInt capaces de operar valores enteros entre 0 y 18.446.744.073.709.551.615 (>18 trillones). Esta característica convierte por tanto al benchmark PRIMEStone500 en una prueba con importante recorrido en máquinas acutales y futuras.

Tal y como podemos comprobar en las gráficas de la sección Comparativa de rendimiento entre algoritmos para el cálculo de números primos de esta misma web el nivel de rendimiento obtenido al usar vectores (matrices unidimensionales) en el que almacenar una tabla de los primeros números primos a medida éstos se van calculando para ser usada posteriormente en los cálculos marca una diferencia notable con respecto a los algoritmos de generación estándar más utilizados.

 

 

separata_benchmarkzone_website

 

bencmarkzone cpu processor icoViejos benchmarks corriendo en máquinas actuales

Hacia mediados de los años 90, tras un pequeño paréntesis de un par de años algo desconectado, mi vida vuelve a ligarse fuertemente con los ordenadores en un momento en el que los 486 (procesadores de 32 bits compatibles con el IBM PC) ya corrían por muchos hogares.

En diciembre de 1993 llegó a mis manos un clónico con procesador intel 486DX-2 funcionando a una vertiginosa frecuencia de 66 MHz (gracias a la duplicación del reloj) y aunque intel había comercializado en la primavera de 1993 sus "todopoderosos" Pentium (que incorporaba ya un bus externo de 64-bits), lo cierto es que este 486 seguía siendo algo bastante potente para la época. En esos momentos, un sencillo benchmark captó mi atención cautivándome nuevamente, era el Landmark System Speed Test ©1990 en su versión 2.00

En una única pantalla y con solo ejecutarla desde la línea de comandos del MS-DOS esta minúscula utilidad arrojaba una precisa gráfica con los índices de rendimiento de la CPU (procesador principal), la FPU (el coprocesador matemático o unidad de coma flotante) y el sistema gráfico, a la vez que emitía un sutil y llamativo chasquido cada vez que refrescaba los índices. El programa Landmark System Speed Test era sin duda toda una maravilla de la ingeniería y no hubo equipo que pasara por mis manos en el que no colocara una copia del ejecutable de 42 KB en la carpeta \UTILS

A estas alturas sobra decir que Landmark System Speed Test no funcionará en su sistema Windows 10 (daos cuenta que estamos viajando al siglo pasado) y que los benchmarks no son aplicaciones diseñadas precisamente para ser ejecutabdas desde máquinas virtuales o emuladores. Por ello y como es lógico, para poder ejecutar este software tendremos que iniciar el sistema mediante una unidad de arranque alternativa que no cargue Windows en memoria. Una vez creado nuestro pendrive de arranque ya estamos listos para iniciar nuestras pruebas..

En la imagen siguiente pueden ver el resultado del benchmark Landmark System Speed Test corriendo en un equipo con procesador AMD-FX6300 arrancando desde un pendrive con el sistema operativo FREEDOS (espero que sepan disculpar la calidad de las fotos;)

sp landmark benchmark msdos

Y es que aún a día de hoy este benchmark de 1990 puede ofrecernos información muy interesante. Para poder intrepetar correctamente los datos que vemos en la pantalla es importante saber que en el momento en el que se desarrolló el software no existían la mayor parte de los procesadores que hoy conocemos por lo que al probarlo con un procesador moderno la utilidad no puede determinar de qué procesador se trata pero aún así el benchmark calibra su rendimiento y establece una comparación a partir de su procesador de referencia (intel 486) ofreciéndonos la equivalencia de éste último con el procesador que estamos probando.

Si nos fijamos en la imagen de arriba veremos que mi flamante AMD-FX6300 de 6 núcleos a 3,5-4 Ghz nos arroja un redimiento equivalente al que obtendríamos con un hipotético intel 486 que funcionara a 16133 Mhz, o lo que es lo mismo, 16 Ghz de frecuencia de reloj !!!

NOTA: En el blog de Guti encotramos un interesante artículo que documenta al detalle la historia del benchmark de Landmark Research International Corporation.

Otro gran estándar en esa época fueron las potentes utilidades Norton, toda una suite de herramientas profesionales que ayudaban al usuario a mantener nuestro sistema con buena salud. Entre estas utilidades se hallaba un benchmark que medía no sólo la velocidad del procesador sino también la memoria, unidaes de disco, etc. Además y como no podía ser de otra manera, el benchmark incluía el valor añadido de la comparativa enfrentando el resultado de nuestro procesador al obtenido por otros procesadores contemporáneos.

En la imagen siguiente observamos el resultado obtenido en un intel Pentium 4 Nortwood a 2,53Ghz testeado con la versión Norton Utilities 7.0

Norton_Utilities_7_benchmark_CPU
NU7

Si bien reconoce la familia de procesador Pentium, ante la imposibilidad de detectar la frecuencia real del procesador iPentium 4@2,53Ghz la versión 7.0 de las utilidades Norton resuelve con un clasificación que no deja de ser curiosa: Pentium a más de 999 Mhz. En esta sencilla gráfica de barras también destaca la escasa puntuación obtenida por el 286 de intel operando a 12 Mhz de velocidad.

Las Norton Utilities 8.0 actualizaba algunas herramientas de la suite aunque en el caso de la comparativa de velocidad de la CPU la renovación consiste básicamente en una copia de la anterior en la que, además de una ligera variación en el Indice de Cálculo, se actualiza la gráfica comparativa incluyendo distintos procesadores de ejemplo. Como puede verse se continúa detectando al procesador exactamente igual que la versión 7.0

En la imagen siguiente la ejecutamos con el mismo procesador iPentium 4@2,53Ghz.

Norton_Utilities_8_benchmark_CPU
NU8

.

separata_benchmarkzone_website

 

bencmarkzone cpu processor icoLOOKIT, una sencilla herramienta MS-DOS corriendo en máquinas actuales

Pero volvamos por ahora a 1996. Sorprendido como no podía ser de otro modo con este prodigio de los benchmarks informáticos que era Landmark System Speed Test, recuerdo que probé con entusiasmo numerosas plataformas de la época y que utilizaba con frecuencia este benchmark sobre todo para medir la velocidad del sistema de video o para comprobar los incrementos de rendimiento cuando aplicaba técnicas de overclocking a la computadora de algún amigo o a la mía propia, pero un impulso misterioso me empujó a ir más allá y comencé un pequeño proyecto al que más tarde bauticé con el nombre de LOOKIT. Supongo que recordaría entonces los primeros benchmarks basados en iteraciones y me decidí a elaborar un sencillo bucle. Sí, seguramente este fue el comienzo de todo lo que vino después pero como he conseguido recuperar el código fuente de las primeras versiones y podemos arrancar nuestras flamantes máquinas sin necesidad de cargar Windows (pen de arranque con FreeDOS) creo que nos va a venir muy bien probarlo todo para comprender ciertos detalles a tener en cuenta a la hora de elaborar un benchmark.

Y así, tras estudiar un poco más a fondo este lenguaje estructurado y utilizar el compilador TurboBASIC 1.1 de Borland algunas pruebas me llevaron a conclusiones sorprendentes que hoy vamos intentar reproducir. Veamos en primer lugar el código fuente (no puede ser más simple) que, una vez compilado con el potente compilador TurboBASIC de Borland, y corriendo sobre mi máquina (con procesador AMD-FX6300) nos arroja el resultado siguiente:

REM OMITO ALGUNOS FRAGMENTOS DE CÓDIGO Y DECLARACIÓN DE VARIABLES POR NO SER RELEVANTES

LOCATE 2, 3: ? "Test de cálculo por Marien SOFT 96"

LOCATE 3, 3: ? "Código compilado con TurboBASIC 11"

TIMER ON

ON TIMER(1) GOSUB 10

n# = 0

DO

   n# = n# + 1

LOOP

10

LOCATE 12, 23: ? n#; " sumas realizadas en 1 seg."

IF INKEY$ = CHR$(27) THEN SYSTEM

n# = 0

RETURN

benchmark lookit 1.0
CRONOTB.EXE

Y ahora estad muy atentos, porque cambiando una única orden (en color azulado) el resultado obtenido es radicalmente diferente y la computadora parece que se hubiese dopado literalmente. Observa los cambios aplicados en el código y los resultados obtenidos en la misma plataforma (AMD-FX6300):

REM OMITO ALGUNOS FRAGMENTOS DE CÓDIGO Y DECLARACIÓN DE VARIABLES POR NO SER RELEVANTES

LOCATE 2, 3: ? "Test de cálculo por Marien SOFT 96"

LOCATE 3, 3: ? "Código compilado con TurboBASIC 11"

TIMER ON

ON TIMER(1) GOSUB 10

n# = 0

DO

   incr n#,5

LOOP

10

LOCATE 12, 23: ? n#; " sumas realizadas en 1 seg."

IF INKEY$ = CHR$(27) THEN SYSTEM

n# = 0

RETURN

benchmark lookit 1.0
CRONOTB2.EXE compilado con TurboBasic de Borland

¿Qué ha ocurrido en mi primer LOOKIT 0.1b (antes incluso de que le hubiera puesto nombre) para que el rendimiento de la misma máquina sea tan dispar? La instrucción incr es una función derivada directamente del lenguaje ensamblador (código máquina) que incrementa en un entero el valor de un registro. En nuestro ejemplo, esta función equivale exactamente a la línea n# = n# + 1 del primer listado y aunque su resultado funcional es idéntico la diferencia de rendimiento que se obtiene es sencillamente espectacular como puede observarse al enfrentar el número de iteraciones alcanzadas en ambos casos: 1608490 frente a las 8106040 de las obtenidas con el empleo de la función incr

Ahora podemos comenzar a comprender mucho mejor el sesgo que afectó a los índices clásicos Dhrystone y Whetstone debido en este caso a la disparidad de rendimiento entre las diferentes instrucciones aritméticas y de bucles utilizadas en la prueba, incluso aún empleando el mismo compilador e idéntica plataforma hardware.

En cualquier caso, lo que debe quedarnos claro es que cualquier cambio en el código fuente del test, por pequeño e insignificante que nos parezca puede ser deternimante en los resultados y por tanto en la fiabilidad de una prueba de rendimiento.

Sentada esta premisa volvemos a someter la misma máquina (AMD-FX6300) exactamente al mismo código pero compilado con distintos compiladores. Los resultados de esta prueba no son menos sorprendentes, el enfrentamiento directo entre el archipopular compilador de Microsoft QuickBASIC 4.5 y el mucho menos famoso PowerBASIC de Robert S. Zale en su versión 3.2, probablemente uno de los compiladores de BASIC más rápidos jamás escrito para sistemas DOS de 16 bits.

Juzguen ustedes:

lookit v1.0  qb+
CRONOQB.EXE compilado con Microsoft QuickBasic 4.5

.

lookit v1.0  pb+
CRONOPB.EXE compilado con PowerBASIC 3.0 de Robert S. Zale

Otra vez sorpresa. Lo que ustedes ven en la segunda captura es el resultado de compilar exactamente el mismo código en uno y otro compilador. El resultado es aplastante y no deja margen para la duda. Dicho sea de paso, el compilador PowerBASIC fue desarrollado por Robert S. Zale sobre la base del TurboBASIC de Borland y mejoró muchísimos aspectos de éste último. Si TurboBASIC acabó con la "legendaria" lentitud del Basic (era un lenguaje originariamente interpretado) el compilador final de Robert S. Zale llevó el lenguaje Basic a nuevo nivel. Este lenguaje-compilado para sitemas de 16 bits fue actualizado por su autor hasta la versión 3.5 en 1997.

En cualquier caso y a tenor de los resultados de esta última prueba estamos en disposición de extraer un sencillo pero importante aprendizaje: el compilador es determiante en el rendimiento de las pruebas, volviendo a recordar nuevamente el sesgo al que se enfrentó sobre todo el clásico Dhrystone cuando fue reescrito en lenguaje C, debido a la enorme cantidad de compiladores C ya existentes en ese momento.

SPIN-OFF - Hace unos años, fallecido ya Robert S. Zale (autor de PowerBASIC), un buen amigo (también amante incondicional de este lenguaje-compilador) me escribió para decirme que la viuda del autor había decidido liberar bajo licencia Freeware (bajo registro) la última versión del compilador para sistemas MS-DOS (la 3.5) y es posible que aún podáis solicitar una versión registrada de este prodigio técnico que es PowerBASIC. Además de llevar el rendimiento de una computadora a límites desconocidos, de PowerBASIC solo puedo decir que todo en él rezuma belleza ;)

powerbasic 3.5
Última versión de PowerBASIC de Robert S. Zale para MS-DOS, la 3.5

Y aclarados ya sobradamente los orígenes de mi benchmark LOOKIT para entornos MS-DOS volvemos sobre los pasos de esta prueba para conocer las posibilidades de este software Freeware en las últimas versiones que publiqué. Pero... ¿Podremos medir y comparar nuestra máquina "actual" con viejas anticuallas incluso de la era prePentium? ¿Funcionará el ejecutable del benchmark LOOKIT en nuestro Windows 7x86?

Veamos pues como responde el procesador intel Atom N455 a 1.66Ghz con el benchmark LOOKIT corriendo en modo ventana en una plataforma Windows 7 x86: (se muestran varias subversiones del benchmark):


Curioso ver como el AMD 486@133Mhz adelanta al Pentium-75 (a 75 Mhz) a golpe de megahertzios.
Obsérvese la barra amarilla (intel Atom) que muestra algo más de 12 millones de operaciones/seg (fuera de la escala comparativa).


En la versión 2.01 de LOOKIT añadí el resultado que obtuve con nuevos procesadores, entre ellos el otrora todopoderoso Pentium 200MMX de intel.
En esta captura se ejecuta el benchmark desde mi netbook Samsung dotado de un intel Atom.


Captura de la última subversión del benchmark LOOKIT mostrando comparativas de cálculo con curiosos participantes como el AMD486 overclockeado
hasta los 160Mhz (40Mhz de bus FSB y 4x de multiplicador), probablemente, el 486 más rápido que vio la luz.

En esta subversión 2.04, la última que llegué a liberar, incorporé como novedad el procesador AMD 486 (denominado comercialmente como 5x86) overclockeado a 160Mhz, velocidad que se obtenía cambiando la frecuencia del bus de 33Mhz a 40Mhz (40 x 4 = 160Mhz). En los resultados podemos comprobar que el rendimiento de este procesador overclockeado se queda a medio camino entre el Pentium 100 y el Pentium 166. Nada desdeñable para tratarse de una arquitectura 486. Creo de hecho que fue el procesador más rápido que llegó a comercializarse de esta generación.

 

 

separata_benchmarkzone_website

bencmarkzone cpu processor icoBreve comparativa de compiladores de código y lenguajes de programación probados en máquinas retro y actuales ...CON ANÉCDOTAS

FREEBASIC 1.05.0 vs FREEBASIC 1.08.1

¿HACIA DÓNDE VAMOS EN EL TERRENO DE LOS COMPILADORES?

A la espera de ponerme con la web que quiero hacer dedicada en exclusiva a la comparativa de rendimiento entre compiladores antiguos y actuales y de todo tipo de lenguajes (desde GW-BASIC hasta PYTHON, pasando por C, Pascal, Java y hasta GO), voy a dejar constancia por aquí de algo que tal vez sorprenda a algunos locos de la métrica computacional como me ha sorprendido a mi...

Verán, hace unos meses, mi tocayo y buen amigo Rafael, como eterno amante del BASIC y también fiel usuario del todopoderoso FreeBASIC, estuvo haciendo a petición mía unas pruebas de rendimiento con cálculos de números primos en Ensamblador y FreeBASIC, arrojando estas pruebas unos resultados bastante similares. Aprovecho para hacer un apunte: Durante el transcurso de estas pruebas fue precisamente cuando él se percató (y sorprendió) del compilado "puente" que FreeBASIC hace del código entre bambalinas, pasando antes del código máquina final ejecutable por un código C de bajo nivel.

Lo cierto es que yo no podía realizar las pruebas directamente por falta de conocimientos, ya que el Ensamblador me produce cefaleas tensionales, pero él se puso a ello y lo hizo, algo que le agradezco enormemente y que espero algún día poder publicar en la comparativa de rendimiento que tengo pendiente entre compiladores de todo tipo y de todos los tiempos.

Aquí les muestro algunas capturas con los resultados obtenidos en las pruebas llevadas a cabo en mi todoterreno Samsung NetBook dotado de un "potentísimo" procesador intel ATOM en una comparativa de búsqueda de números primos hasta los 100 millones:

La verdad es que, acostumbrado a las comparativas entre otros viejos BASIC y el sagrado ensamblador (la primera vez que pruebas ensamblador en una computadora de 8 bits te queda grabado en la memoria para toda la vida), la diferencia no parece tan relevante como cabría de esperar, y esto puede ser así debido al complejo proceso de optimización (o compilado puente) que el compilador de FreeBASIC aplica al código durante el proceso de compilado y que transforma el mismo fuente BASIC en un código C de bajo nivel justo antes de crear el archivo objeto.

¿Y porqué les cuento esto? Pues lo cierto es que, hace apenas unos días, revisando y reorganizando el contenido de mi pequeño ordenador y mirando los compiladores que andaban por el disco me percaté de que contaba con distintas versiones del compilador FreeBASIC en mi sistema, la 1.05 de 32 bits con la que yo estuve trabajando en la era precovid para hacer TURBOPRIM y la 1.08 de 32 y 64 bits (los compiladores de 32 y 64 bits son en realidad dos ejecutables distintos) que me envió Rafael al poco de realizar la comparativa entre Ensamblador y Freebasic y con la que él precisamente había realizado sus pruebas.

Aunque pueda parecer absurdo en principio, no recuerdo muy bien porqué se me ocurrió un pequeño experimento coincidiendo con un correo que recibí hace unos días de otro viejo y buen amigo (Miguel) apasionado también del BASIC y gran conocedor del compilador PowerBASIC de Robert S. Zale (ya citado en estas páginas), una mejora del TurboBASIC de Borland capaz de aplastar a cualquier compilador coétaneo en su momento, incluso a los mejores de C y Pascal. En este escenario de competitividad, decidí comparar precisamente a PowerBASIC (MS-DOS) con FreeBASIC (Windows) y para enfrentar a ambos compiladores, se me ocurrió preparar un minúsculo bechmark que llenara una pantalla de 640 x 480 píxeles (SCREEN 13) dibujando píxel a píxel, así que me puse a ello en mi viejo netbook Samsung con Win7 x86 y en pocos minutos lancé las primeras pruebas.

Primero lo hice en PowerBASIC 3.5 para MS-DOS, como digo uno de los compiladores más optimizados en su momento y capaz de generar un código ejecutable cuyo rendimiento superaba incluso a otros compiladores de C ó PASCAL. Los resultados en mi humilde máquina arrojaban algo más de 3 segundos, pero teniendo en cuenta que se ejecutaba en una ventana de Windows, el test no era demasiado fiable. Aún así, aproveche el código fuente para copiar y pegar directamente en el flamante FreeBASIC 1.08 que me había enviado Rafa hacía unos meses. Lo cierto es que no tuve que cambiar ni siquiera el comando SCREEN ya que FreeBASIC guarda una compatibilidad muy alta con los BASIC de la era DOS y acepta todos los modos de pantalla de aquella época. De manera que ya teníamos nuestro código listo:

REM benchmark fill screen 640x480
REM for BenchMARKZONE
REM calentamientoglobalacelerado.net

screen 12
dim x as integer
dim y as integer
dim t as double
t=timer
for x=0 to 639
   for y=0 to 479
      pset (x,y)
   next
next
print "Fill to 640x480 pixels"
print timer-t; " seconds"
print "Please wait. Closing this windows ..."
sleep 3000
end

Vista la imponente superioridad de FreeBASIC frente a PowerBASIC, algo más de 3 segundos para el primer compilador frente a unas pocas décimas del segundo, y al otorgando con cariño al viejuno PowerBasic el beneficio de la duda al estar corriendo en un entorno virtualizado y no nativo, procedí a enfrentar en un nuevo duelo a muerte (FreeBASIC vs FreeBASIC) las dos versiones de este compilador, de manera que compilé la rutina en 32 bits* con los dos compiladores de FreeBASIC citados, en concreto la versión 1.08 y la 1.05.
* En ese momento, la versión x64 no pude hacerla ya que el sistema que corre en mi viejuno netbook Samsung es Win 7 x86.

En cualquier caso y juzguen ustedes mismos, los resultados que obtuve son poco menos que sorprendentes:

BREVE DESCRIPCIÓN DEL ENFRENTAMIENTO:

La ventana de la izquierda es la que corresponde a la versión 1.08.1 del compilador, mientras que la derecha se centra en la versión 1.05.0. El contenido de las ventanas es prácticamente el mismo pero lo detallo brevemente por si queda alguna duda en su interpretación.

Lo primero que se muestra en ambas ventanas es la rutina de relleno que vamos a usar como benchmark en ambos compiladores y cuyo código fuente tenemos ya preparado en el fichero fillbenc.bas

A continuación se procede al compilado con fbc.exe y luego comprobamos que se ha creado ya el ejecutable fillbenc.exe. En cada ventana se compila con la versión indicada anteriormente.

Lo que se muestra luego son los cronos obtenidos en cinco ejecuciones, en las que se aprecian diferencias de rendimiento cercanas al 100-120 % de mejora en favor de la versión más antigua del compilador, la 1.05.0.

Tras varias compilaciones con diferentes opciones de optimización en la versión 1.08, debo decir que los resultados no han mostrado cambios significativos.

Aquí muestro una imagen que he montado con los resultados probados ya en un portátil ASUS con CORE-i5 y Win10 x64 (de mi hijo) e incluyendo también la versión del benchmark compilada en x64:

Y aquí les dejo los archivos con el código fuente y los compilados en ambas versiones para que puedan comprobarlo por ustedes mismos:

fill_benchmark-FBvsFB.zip

Por supuesto, no soy nadie para cuestionar el impresionante trabajo que supone un desarrollo de estas características y estoy convencido de que las nuevas versiones de este compilador incorporarán mejoras en muchos aspectos con respecto a las versiones antiguas y aprovecho para dejar aquí constancia de mi incondicional admiración por los programadores que desarrollan y mantienen de forma absolutamente altruista una herramienta como FreeBASIC, pero al ver los tiempos arrojados en este minibenchmark no puedo evitar recordar algo que leí en una ocasión no recuerdo donde y que afirmaba que la línea evolutiva del software iba exactamente en dirección contraria a la del hardware, mientras éste avanza hacia la miniaturización y la velocidad, el software se mueve justo en sentido contrario. De ahí el título elegido para esta entrada de benchMARKZONE:

¿HACIA DÓNDE VAN LOS COMPILADORES?

A medida que la complejidad de la computación, tanto a nivel de harware como de software, crece exponencialmente, es previsible que los compiladores pierdan cierta capacidad de rendimiento en algunas tareas tan simples como la descrita en este ejemplo para llenar la pantalla de píxeles.

 

separata_benchmarkzone_website

 

 

bencmarkzone cpu processor icoComparativa de rendimiento entre algoritmos para el cálculo de números primos

Como ya comentaba en una sección anterior, algunos matemáticos consideran a los números primos como los átomos a la física y es bastante probable que estos enigmáticos números ya se conocieran incluso antes de la Grecia Clásica (entre los siglos V-IV a.c.). No en vano, su existencia es tan importante para las ciencias exactas que el propio Teorema Fundamental de la Aritmética dice que cualquier número natural se puede escribir como una multiplicación de números primos.

Si bien fue el matemático griego Euclides (325-265 a.c.) quien descubrió que la serie de los números primos es infinita, como puede serlo el universo, al adentrarnos en los algoritmos informáticos más empleados para descubrir números primos llegamos sin remedio al matemático, astrónomo y geógrafo griego Eratóstenes (276-194 a.c.), y su método, conocido como la Criba de Eratóstenes, el que se ha venido utilizando con mayor frecuencia para comparar y enfrentar el rendimiento de diferentes lenguajes de programación y compiladores. Este método es popularmente conocido en inglés como Sieve of Erathostenes o simplemente Sieve, en castellano podemos encontrarlo indistintamente con el nombre de criba o tamiz.

Sobra decir que desde que Eratóstenes desarrollara su famosa "criba/tamiz" otros muchos matemáticos se han asomado al fascinante abismo de los números primos tratando de desvelar sin éxito el misterio que los envuelve. Entre estas mentes privilegiadas cabe destacar la figura del matemático alemán Georg Friedich Bernhard Riemann (1826-1866) que definió la que hoy se denomina "función zeta de Riemann":

f(s) = 1 + 1/2s + 1/3s + 1/4s + ........, s = u + iv

Pero volvamos a tierra. Igual que hace más de 2000 años Eratóstenes tachara con su punzón descartando los números no primos (compuestos), este método computacional denominado la Criba de Eratóstenes utiliza un marcado mediante flags (banderas) para discriminar números no primos o copmpuestos. Las banderas, que son elementos de uso frecuente sobre todo en la programación de bajo nivel (ensamblador/assembler) no son otra cosa que variables a las que adjudicamos un valor abierto o cerrado, encendido o apagado, 0 ó 1, etc. En el caso del algoritmo original se emplean los valores -1 ó 0 para determinar si el número es primo (-1) o no lo es (0). Pero todo esto ya lo veremos con mayor profundidad un poco más adelante.

Lo que quiero exponer ahora es mi humilde e insignificante experiencia en este vasto y complejo campo de los números primos, un campo investigado por la teoría de números, quizá el área de las matemáticas con la mayor cantidad de problemas no resueltos, y su aplicación en el cálculo computacional como parte de un sencillo benchmark informático al que denominé PRIMEStone500

Verán, el algoritmo TURBOPRIM++ es el motor generador de primos utilizado en el benchmark PRIMEStone500 y su sencillo código se muestra para su estudio o análisis en la sección PRIMEStone500 de la presente web o ejecutando el propio benchmark en su ordenador. Lo cierto es que fue desarrollado y bautizado por mí a partir de una idea que tomé en un viejo libro siendo apenas un adolescente, cuando ya mostraba una atracción pasional por las computadoras. Les cuento, en 1984, el catedrático Ramón Farrando Boix (Perito Industrial Eléctrico y Mecánico) en su obra "109 PROGRAMAS PARA ORDENADORES PERSONALES Y CALCULADORAS" ya abordaba el problema del cálculo de números primos con microordenadores y calculadoras científicas de la época, dicho sea de paso, bellos artilugios a cuya colección me dediqué durante bastante tiempo. En el capítulo dedicado a los números primos Ramón Farrando implementaba un método básico (al que podemos denominar estándar) para la obtención de números primos y de cuya limitada velocidad ya se hacía eco el propio autor, pero al final del capítulo, este ingeniero aludía a una posible modificación del programa para mejorar la velocidad de cálculo comprobando solo los divisores primos y descartando así una parte importante de las comprobaciones de divisibilidad. Es de esta fuente precisamente de donde procede mi idea de almacenar los números primos en un vector o array (matriz unidimensional) para conseguir reducir al máximo el número de comprobaciones en la búsqueda de primos.

ANÉCDOTA ACERCA DE TURBOPRIM++

A pesar de que algún revisor de Wikipedia me censurara rápidamente (por plagio, fin de lucro y alguna otra causa más que ya prefiero no recordar) por una mínima edición de la entrada BECNHMARK INFORMÁTICO en la que únicamente pretendía incluir/citar esta pequeña utilidad completamente gratuita en la relación de aplicaciones benchmarks allí documentadas, quiero aprovechar para dejar constancia de que el código fuente principal del algoritmo TURBOPRIM++ fue escrito completamente por mí, es completamente abierto y puede estudiarse desde el propio software de testeo. Si bien en este caso mi obra no se ajusta exactamente al estándar de licencia GNU pues lo que yo distribuyo es una utilidad gratuita pero ya compilada, cualquiera puede recompilar el código principal si así lo desea, solamente citando la fuente de la que lo ha obtenido, o sea, la que está leyendo en este momento. Con ello no quiero en absoluto menospreciar la difícil y encomiable labor que estos "cybercensores" realizan filtrando toda la basura y/o información cuestionable que pretende colarse en la mayor enciclopedia conocida de la historia, simplemente dejo constancia de lo ocurrido a través de esta web para disipar cualquier duda que pudiera existir al respecto de mi legitimidad e intención acerca de este contenido.

Cierto es que cuando escribí TURBOPRIM++ aún no había probado los cronos del algoritmo de la CRIBA DE ERATÓSTENES y debo confesar que tras comparar el método estándar con mi flamante TURBOPRIM++ llegué a pensar ingenuamente que mi método podía hacerle sombra e incluso igualar a la Criba de Eratóstenes, de hecho, las únicas pruebas comparativas que había realizado enfrentando el algoritmo estándar con TURBOPRIM++ prometían bastante. Usted mismo puede ver aquí las gráficas comparativas de rendimientos de los distintos algoritmos para el cálculo de números primos en un procesador Intel Core i7-4720HQ:

comparativa algoritmo estandar vs turboprim++

Y a continuación los resultados obtenidos en un procesador AMD FX-6300 con 6 núcleos:

Comparativa algoritmo numeros primos


En ambas gráficas se constata como el algoritmo TURBOPRIM++, a diferencia del algoritmo estándar y el TURBOPRIM (una versión poco pulida de TURBOPRIM++), muestra una inversión de tiempo mucho más estable y cuya ventaja se va acrecentando de forma proporcional a la carga de cálculo exigida. Es a priori un hecho irrevocable que el método TURBOPRIM++ presenta un nivel de eficiencia mucho mayor que el método estándar y eso me llevó a creer inocentemente que podría enfrentarse a un método de cálculo tan refinado como la Criba de Erastótenes. Nada más lejos de la realidad. Este sería el código de la Criba de Eratóstenes (también conocido como Sieve) en un lenguaje BASIC estándar y estructurado:

defint a-z

size=50

dim flags(50) ' MARCADO

for i=2 to size

flags(i)=-1

next

for i=2 to sqr(size) ' CRIBADO

if flags(i) then

for k=i*i to size step i

flags(k)=0

next

end if

next

for i=0 to size ' VOLCADO

if flags(i) then print i;

next

Comprobado el método SIEVE con un pequeño software experimental de código abierto escrito por mí para tal fin, podemos afirmar sin temor a equivocarnos que el método de la Criba de Eratóstenes está a otro nivel de eficiencia y, posiblemente, estemos ante el algoritmo más rápido que se haya escrito hasta la fecha para el cálculo de número primos. Para hacer mis pruebas benchmarks, he escrito como digo esta pequeña utilidad experimental de código abierto AlgorPrimVS.zip que puedes descargar directamente desde aquí.

BREVE ANÁLISIS DEL MÉTODO COMPUTACIONAL LA CRIBA DE ERATÓSTENES:

1.- El método consta de un primer bucle en el que se inicializan todos los números de la criba/tamiz como posibles candidatos a primo, asignando el valor -1 a todos ellos.

2.- La siguiente parte del código constituye el motor del algoritmo y en él se crean dos bucles anidados en los que se va descartando a los números compuestos.

3.- El último bucle del código se limita a imprimir por pantalla los números primos que no han sido eliminados por el cribado.

Este método fue publicado por primera vez en enero de 1983 en la revista BYTE MAGAZINE y como y acomenté anteriormente es posible que estemos ante el algoritmo más rápido que se haya jamás para el cálculo de número primos. La pregunta del millón ahora es.... ¿Se puede mejorar el método de la Criba de Eratóstenes? Ahora es cuando empieza a sonar de verdad la música de suspense....

La verdad es que, sinceramente, no me veo capaz en absoluto de mejorar este refinado algoritmo en su diseño ni tampoco siquiera de depurar su código y reescribirlo en ensamblador, sin embargo, si revisamos y jugamos un poco con el código es probable que podamos arañar algo de rendimiento, además, tal vez tengamos una buena oportunidad para volver a comprobar como las capacidades de un determinado compilador pueden volver a marcar diferencias notables en lo que al rendimiento computacional se refiere. Me explico.

Si leyeron la sección anterior dedicada a la prehistórica utilidad benchmark LOOKIT, una sencilla herramienta MS-DOS corriendo en máquinas actuales, allí observamos como un simple cambio literal en un comando o sentencia podía provocar sesgos más que significativos en los rendimientos, y ahí precisamente es donde vamos a tantear a la Criba para ver todo lo que puede darnos. Una de las claves está en el tipado de variables.

Analizando una vez más el código del método básico, observamos que la función de la variable dimensional flags() es solo la de almacenar valores booleanos (-1 ó 0) que determinarán si el número es primo (-1) o compuesto/no primo (0). En cualquier caso, aunque revisemos y adaptaemos nuestro programa de La Criba utilizando variables, por ejemplo, del tipo uLongInt (64 bits y capacidad de cifras del orden de los 18 trillones) al objeto de alcanzar cifras mucho mayores en nuestros cálculos, la realidad es que la variable flags() no necesita mayor capacidad y se sobra con un valor del tipo Byte (8 bits). Aunque algunos compiladores no trabajan con el tipo Byte, otros como Visual Basic® y muchos compiladores de C/C++ incluso permiten tipos de variables aún menores como el tipo Boolean cuyo tamaño en memoria es de 1 ó 2 bits y que por lo tanto, al menos en principio, deberían mostrarse más eficientes en los cálculos. Fijaos que solo modificar el tipo de variable empleada como bandera de Integer a Byte puede aportar incrementos en el rendimiento del orden del 15-30% dependiendo del tipo de procesador.

Veamos la parte relevante del código original y los cambios aplicados:

CRIBA ERATÓSTENES ESTÁNDAR:

Dim flags(N) As Long
s1=Timer 'inicia crono
For m=2 To N
  flags(m)=-1
Next
'criba tachado de NO PRIMOS
For m=2 To Sqr(N)
  If flags(m) Then
  For l=m*m To N Step m
    flags(l) = 0
  Next
  End If
Next
'contea primos ó imprime
For m=0 To N
  If f(m) Then tp3=tp3+1 'si f(m)=-1 cuenta
Next m
s3=Timer - s1 'detiene crono

1ª EVOLUCIÓN DE CRIBA ERATÓSTENES:

Dim f(N) As Byte 'retipifica variable
s1=Timer 'inicia crono
For m=2 To N
  f(m)=1
Next
'inicia criba tachado de NO PRIMOS
For m=2 To Sqr(N)
  If f(m) Then
  For L=m*m To N Step m
     f(L) = 0
  Next
End If
Next
'contea primos ó imprime
For m=0 To N
  If f(m) Then tp3=tp3+1 'si f(m)=1 cuenta
Next m
s3=Timer - s1 'detiene crono


A continuación se muestran los tiempos obtenidos corriendo el software experimental recogido en AlgorPrimVS , una suerte de pequeño taller que como digo he desarrollado para comparar el algortimo estándar de división por tentativa, el algoritmo mejorado TURBOPRIM++ y las dos adaptaciones de la todopoderosa e intratable Criba de Eratóstenes, en su versión estándar y "BOOST", obtenida esta última después de alguna pasada con el paño de pulir al código original y aprovechando características propias del compilador utilizado en las pruebas: FreeBASIC 32 bits.

Para aquellos programadores que puedan seguir pensando en el viejo tópico de que BASIC es un lenguaje lento o poco eficiente, una falsa idea que se consolidó en las primeras ediciones en las que BASIC era un lenguaje interpretado y no compilado, solo quiero invitarles a que comparen ustedes mismos los resultados obtenidos en una comparativa (efectuada en la misma plataforma hardware-software) entre el compilador FreeBASIC 32 bits y el utilizado por Dev-C++, el MinGW/MinGW-w64 y el mismo compilador en 32 bits.

ANÉCDOTA CURIOSA

Con respecto a FreeBASIC, hace relativamente poco, un buen amigo también amante del Basic y doctorado en estos asuntos, me comentó algo realmente curioso acerca del proceso de compilación de FreeBASIC que me dejó un tanto desconcertado. Lo cierto es que este software, durante el proceso de compilación y antes de generar el código máquina ejecutable a partir del código fuente en Basic, lo traduce a un código en lenguaje C de bajo nivel (con registros y comandos de memoria) prácticamente inteligible para la mayoría de los mortales. Él, como buen ingeniero, se percató de esto al observar un archivo temporal que creaba el compilador antes del proceso de linkado (creación del EXE) y que luego se eliminaba. De manera que el resultado final es que tenemos un compilador BASIC de élite pero híbrido (con C) y no tan puro como algunos imaginábamos. De todos modos, existe otro compilador para los apasionados del QBasic (antiguo lenguaje interpretado de Microsoft de la era MS-DOS) que ribaliza con FreeBASIC en cuanto a rendimiento bruto se refiere y que pronto veremos enfrentados en BenchMARRK zone.

Bueno, tal y como os decía, muy atentos aquí para los amantes de la velocidad porque hay sorpresa. Para realizar esta prueba he escrito y optimizado (dentro de mis limitados conocimientos de este lenguaje y compilador) el método de la Criba de Eratóstenes para el entorno Dev-C++, lanzando la búsqueda de primos hasta 100 millones. El código fuente también lo incluyo en la sección de descarga directa de esta misma web por si quieres abordar el reto de mejorarlo.

Estos que verá a continuación son los resultados obtenidos en ejecutables para plataformas x86 y x64 pero probados en el mismo equipo sobre Windows 10 x64:

sieve eratosthenes boost version

Observamos que la versión compilada para plataformas x64 se ha mostrado más rápida que la versión de 32 bits corriendo en idéntico hardware y sistema Win10 x64:

criba_eratostenes_Dev-c++

Sin embargo, curiosamente vemos que esta diferencia de crono se reduce si corremos el benchmark compilado en 32 bits en un sistema Win7-x86:

Aún así, no podemos dejar de quitarnos el sombrero ante los tiempos obtenidos por el compilador FreeBASIC-32 bits que, pese a generar solo código de 32 bits vuelve a proclamarse campeón absoluto:

sieve eratostenes boost in freebasic - super fast

... y si las pruebas se realizan bajo el mismo hardware pero sobre un Windows de 32 bits (Win7-x86) en lugar de Win-10-x64, los resultados arrojados resultan ya aplastantes en favor de FreeBASIC-32 bits:

Todos estos resultados han sido obtenidos en pruebas realizadas con el software experimental de código abierto AlgorPrimVS en un
procesador AMD FX-6300 corriendo Windows10 x64. Puede descargar todo este material (código fuente incluido) para sus experimentos en la sección de descarga directa de esta misma web.


NOTA: Nunca debmos obviar que un compilador es al fin y al cabo un programa y como tal, el programador puede ingeniárselas de mil maneras distintas para optimizar el código máquina resultante, de ahí que idéntico código, incluso del mismo lenguaje, arroje a veces resultados tan dispares en diferentes compiladores.

Pero sigamos de nuevo con la mejora de tiempo que habíamos logrado en la Criba de Eratóstenes. Llegados a este punto y habiendo obtenido un incremento bastante destacable en la velocidad de cálculo con solo modificar el tipo de variable de Long a Byte, yo ya intuía que los posibles cambios para mejorar el rendimiento estarían en la línea: ¿Qué es más rápido? ... ¿Un For..Next ó un Do..While? y cosas por el estilo, pero sorprendentemente el código original aún escondía otra vuelta de tuerca para aplicar.

Repasando de nuevo el algoritmo original de La Criba y tras comprobar que el compilador FREEBasic, pese a sus infinitas virtudes carece del tipo Boolean (supuestamente el tipo de dato más eficiente para tratar banderas/flags), decidí probar a modificar ligeramente el código para arañar algo de velocidad más allá de la conseguida al retipificar la variable entera flag ( ) como tipo Byte. Para ello, después de analizar detenidamente el sentido de las estructuras y de los bucles y comprobar la consistencia de los cálculos, me percato de que éstos podrían aún simplificarse un poco reduciendo la carga de manera considerable. Et Voilà!!

Volvamos a ver ahora la parte relevante del código y los cambios aplicados en esta última adaptación:

1ª EVOLUCIÓN DE CRIBA ERATÓSTENES:

Dim f(N) As Byte 'retipifica variable
s1=Timer 'inicia crono
For m=2 To N
  f(m)=1
Next
'inicia criba tachado de NO PRIMOS
For m=2 To Sqr(N)
  If f(m) Then
  For L=m*m To N Step m
     f(L) = 0
  Next
End If
Next
'contea primos ó imprime
For m=0 To N
  If f(m) Then tp3=tp3+1 'si f(m)=1 cuenta
Next m
s3=Timer - s1 'detiene crono

CRIBA ERATÓSTENES BOOST / TURBO SIEVE:

Dim f(N) As Byte
tp3=1 ' contea ya el 2 como primo
s1=Timer 'inicia crono
For m=3 To N step 2 'asume 2=primo y OMITE PARES
  f(m)=1
Next
'inicia en 3 criba tachado de NO PRIMOS
For m=3 To Sqr(N)
  If f(m) Then
  For L=m*m To N Step m
    f(L) = 0
  Next L
  End If
Next m
'contea primos ó imprime
Print "2 "; 'asume 2=primo
For m=3 To N step 2 'inica en 3 y OMITE PARES
  If f(m) Then tp3=tp3+1 'si f(m)=1 cuenta/imprime
Next m
s3=Timer - s1 'detiene crono

En el código de la derecha hemos reducido los ciclos de proceso atacando a los bucles e insertando un salto de 2 para omitir directamente valores pares en la lista de candidatos a primos. Este salto se aplica tanto en el marcado inicial como en el conteo de números primos que realizamos al final de programa y mediante el cual verificamos la consistencia de los cálculos.

Aunque estos porcentajes en el incremento de la velocidad de cálculo pueden variar en mayor o menor medida dependiendo del tipo de procesador testado y de su arquitectura específica para el cálculo aritmético, queda sobradamente probado que algunos pequeños ajustes pueden lograr una mejora drástica en nuestra sencilla y humilde adaptación del método de la Criba de Eratóstenes, a la que he decidido denominar la versión BOOST de la Criba de Eratóstenes.

Anécdota sobre el método de la CRIBA DE ERATÓSTENES:

Cuando comprobé recientemente el potencial de la Criba de Eratóstenes debo reconocer que reconecté con el pasado de algún modo. Verán, hacia 1984 yo "estudiaba" 1º de BUP en el instituto y la asignatura de informática era, como no, la protagonista del curso. En aquella época, un compañero del instituto cuyo padre era profesor de matemáticas, me mostró en una CASIO FX-801P un programita para calcular primos del que solo recuerdo algo, su enorme velocidad en comparación con los burdos algoritmos que yo había escrito hasta entonces. La CASIO FX-801P era en realidad una pocket computer que integraba micrograbadora e impresora en una única consola transportable y como la mayoría de microcomputadoras del momento su capacidad de proceso era bastante limitada, creo recordar que su RAM apenas alcanzaba los 2KBytes. Cuando este compañero ejecutó ante mis ojos su código y lancé mi crono para elaborar mi propia métrica de rendimiento debí quedar perplejo al constatar que su reducida máquina superaba en tiempo a mi flamante Sinclair ZX-Spectrum 48K y otras máquinas supuestamente más potentes que su FX-801P. Al comprobar ahora que el algoritmo de la Criba fue publicada en enero de 1983 en la revista BYTE y transcurridos unos 36 años desde aquella anécdota, casi estoy convencido de que ese fue mi primer contacto con la Criba de Eratóstenes aún sin saberlo. Recuerdo perfectamente que anoté su código en una nota de papel para intentar revisar su magia y anduvo conmigo durante algún tiempo antes de que se perdiera. Por cierto, al final de esta web, en la sección de descarga directa, encontrarás un línk al artículo original preservado sobre la Criba de Eratóstenes (Sieve) publicado en la revista BYTE en enero de 1983 (7 MB) que yo mismo he preparado por si algunos retromaníacos quieren deleitarse.

......

Si a estas alturas aún no te has empachado y ya has tenido pesadillas nocturnas que te despiertan sobresaltado pensando que alcanzabas la fórmula huidiza de los números primos, para concluir la sección voy a entregarte algunos de mis apuntes "en sucio" sobre este misterioso asunto esperando que pueda servirte para algo más que perder el sueño:

BIBLIOTECA AMPLIA Y SUCULENTA SOBRE LOS NÚMEROS PRIMOS

 

separata_benchmarkzone_website

 

 

bencmarkzone cpu processor icoCreamos nuestro propio benchmark: BenchSQUARE

Recuperando el espíritu de la GUÍA DEL COMPRADOR DE INFORMÁTICA como si de una "guía espiritual" se tratase, en esta sección veremos como desarrollar un sencillo benchmark informático desde cero utilizando para ello herramientas y métodos bastante sencillos y asequibles.

Nuestra aplicación benchmark consistirá en una reducida y sencilla utilidad compilada en código nativo para sistemas operativos Microsoft Windows y ejecutable tanto en arquitecturas x86 como x64, y aunque BenchSQUARE (así he decidido bautizarla) no es más que un pequeño proyecto experimental sin grandes pretensiones creo que aporta una visión global práctica para el usuario que pretenda adentrarse en el ámbito de los benchmarks informáticos. Además, no deja de ser una sencilla y accesible herramienta para aquellos usuarios que deseen comparar el rendimiento de distintos procesadores y/o sistemas operativos.

Partiendo de un sencillísimo algoritmo, si es que podemos denominarlo así pues es poco más que un bucle y una función matemática, crearemos una pequeña y práctica utilidad para medir el potencial de cálculo matemático de cualquier procesador que se nos ponga a tiro. Lo cierto es que, a pesar de que fue lanzado hace unos 25 años, Microsoft Visual Basic 5 ofrece aún hoy un entorno de desarrollo con bastantes posibilidades para crear pequeños proyectos y siempre podremos entretenernos lo que queramos para conseguir que nuestra aplicación tome un acabado lo más agradable posible. En este aspecto he trabajado la mayor parte del tiempo de creación de BenchSQUARE sin estar completamente seguro de haberlo conseguido.


En la última revisión de BenchSQUARE he incluido un pequeño complemento (Ver código...) para que podamos comparar la pequeña variación aplicada para obtener cada uno de los índices.

Como verás en la imagen anterior, BenchSQUARE arroja dos tiempos en cada prueba. Para ofrecer estos dos índices de rendimiento distintos, por un lado el índice Float Point o de coma flotante y por otro el índice INTeger o cálculo con números enteros, BenchSQUARE recurre al cálculo de la raíz cuadrada de mil millones de números empleando una mínima modificación al motor principal del código utilizando dos tipos de variables diferentes: la variable del tipo DOUBLE de 64 bits y la variable del tipo LONGint de 32 bits. Esta sutil variación en el código fuente puede arrojar resultados sorprendentes en diferentes procesadores desvelando peculiaridades técnicas interesante de cada uno de ellos. Aunque algunos procesadore emplean tiempos muy similares operando con variables enteras o en coma flotante, otros en cambio muestran rendimientos del 300 ó 400% superiores al operar con variables tipo INTeger, e incluso, encontramos algún caso sorprendente como el del AMD Turion 64x2 @2Ghz de doble núcleo , el cual muestra una optimización superior operando con variables tipo FLOAT.

Estas particularidades son las que producen los sesgos que ya experimetaban los benchmarks primigenios como Dhyrstone y Whetstone y que, además de las provocadas por la propia arquitectura de los procesadores, pueden acentuarse por las características de los compiladores empleados.

El código compilado resultante es un código nativo de 32 bits directamente ejecutable tanto en plataformas x86 (sistemas de 32 bits) como x64 (64 bits) de Microsoft Windows. Para su desarrollo, como ya he comentado, he empleado un antiguo compilador (Microsoft Visual Basic 5) que logra generar un código nativo bastante optimizado y, aunque no llega al nivel de eficiencia de otros lenguajes compilados si ofrece algo importante, una retrocompatibilidad difícil de superar que alcanza incluso al primer sistema operativo de 32 bits lanzado por Microsoft, el mítico Windows 95, pasando por todos los sistemas operativos del gigante (9x/NT 3.x/NT 4/2000/ME/XP/Vista/7/8/10) en versiones x86 y x64, ¡ahí es nada!

NOTA: Por si a alguno de ustedes les cuesta creer que este software pueda correr en máquinas con más de 25 años, en la reducida tabla integrada en el propio programa BenchSQUARE (imagen anterior) pueden observar como el último de la fila es un procesador 486 y que precisamente ha sido testeado corriendo BenchSQUARE sobre Windows 95 OSR2. Trás una hora y 15 minutos aproxidamente, el mítico IBM Aptiva-486@100Mhz nos ofrece los siguientes resultados:


BenchSQUARE 1.0 corriendo en Windows 95 sobre mi equipo IBM-Aptiva con procesador IBM 486@100 Mhz

Si desean ampliar la tabla comparativa o enviar sus propios resultados para que se publiquen en la tabla oficial del índice de rendimiento BenchSQUARE puede hacerlo en los siguientes enlaces:

Ver tabla actualizada con índice de rendimiento BenchSQUARE en procesadores probados

Acceder a la web propia del programa BenchSQUARE

 

separata_benchmarkzone_website

 

 

bencmarkzone cpu processor icoC>OveRBooST o cómo liberar a nuestro procesador de la mochila de los servicios

En esta ocasión voy a publicar aquí un pequeño desarrollo que realicé hace poco con motivo de una práctica sobre servicios. Con la era Windows llegaron los servicios. Antes, con MS-DOS, a estos programas que corrían en segundo plano se les conocía como TSR o residentes en memoria, pero eran poco frecuentes. A partir de Windows 95, con la irrupción de los sistemas multitareas, los servicios comenzaron a implantarse para realizar funciones que el usuario no debía controlar expresamente y que se ejecutan en background.

Los servicios, también denominados daemons en Unix y Linux, son programas residentes en memoria que se ejecutan (en segundo plano) fuera del control interactivo de los usuarios y apoyando al sistema operativo para que todo funcione correctamente. Existen gran cantidad de servicios y básicamente aseguran que ciertas características del sistema operativo estén disponibles cuando el usuario las necesite. Esta característica inherente de los servicios de trabajar “desde la sombra” proporciona mayor seguridad pues algunos de estos servicios son cruciales para el funcionamiento del sistema operativo.

Los servicios ofrecen capacidades como escanear nuestro disco duro y/o ficheros en busca de virus, comprobar periódicamente la bandeja de entrada de nuestro gestor de correos o gestionar la cola de impresión. Aunque muchos servicios se inician automáticamente en el arranque del sistema, otros pueden iniciarse a demanda cuando, por ejemplo, conectamos un dispositivo o intentamos emparejar nuestros auriculares Bluetooth.

Cómo he dicho, los servicios son programas y como tales cada uno funciona de manera diferente pero algunos de ellos pueden acaparar en ocasiones al procesador mediante interrupciones y procesos que aumentan su carga. Por ello, se me ocurrió crear una diminuta utilidad que intente cerrar todos los servicios posibles de nuestro sistema, manteniendo únicamente activos los relativos al sonido y a la red si así lo decidimos. Así nació C>OveRBooST

COVERBOOST is system utility for Full Stop Services on Windows System

C>OveRBooST es un software gratuito completamente seguro (NO OVERCLOCKEA EL PROCESADOR) y está pensado para plataformas GAMING en modo local o equipos con una gran carga de cálculo puntual (simulación, resolución de algoritmos complejos, etc...), por ello, no debería ejecutarse NUNCA en entornos corporativos ni de juego en red ya que puede detener servicios esenciales para seguir desempeñando determinadas tareas, además, al tratar de detener servicios concernientes a la seguridad el propio sistema podría detectarlo como una amenaza y proceder a su bloqueo y/o eliminación.

¡OJO! Ejecute C>OveRBooST de forma limitada y en momentos puntuales en los que requiera elevar al máximo el rendimiento y la dedicación del procesador, y si experimenta algún problema durante su ejecución intente reanudar los servicios o reinicie directamente su ordenador.

 

 

separata_benchmarkzone_website

 

bencmarkzone cpu processor ico Cuando los 486 alcanzaron su máximo grado de perfección y superaron a los PENTIUM's (elaborando...)

Como en todos los ámbitos de la historia, en la informática también existen sombras dignas de ser recuperadas para completar el puzzle de nuestro pasado tecnológico y uno de ellos fue sin duda la encarnizada lucha que libraron dos generaciones míticas de procesadores como fueron los 486 y los Pentiums.

En la composición de este humilde artículo-ensayo se han utilizado y contrastado numerosas fuentes que nos traladarán a la última década del pasado siglo XX para reconstruir este capítulo tan desconocido como apasionante.

Fuentes principales:

https://www.zonadepruebas.com/

http://www.cpu-collection.de

https://kripkit.com/cyrix/

https://web.archive.org/web/20090601075329/http://www.interwb.com/486bench.txt

Nuestro capítulo de la historia se remonta al año 1994 y tiene como primer protragonista a la empresa norteamericana Cyrix, una empresa con experiencia en el diseño de microprocesadores pero sin capacidad de manufacturación. Por ello, en ese año, tras una serie de desacuerdos con TI (Texas Instruments) y problemas de producción con SGS Thompson, la firma diseñadora de procesadores Cyrix recurrió a IBM Microelectronics, una división de la gigante azul cuya tecnología de producción rivalizaba con la de Intel. Como parte del Acuerdo de producción entre las empresas, IBM recibió el derecho de construir y vender CPU diseñadas por Cyrix bajo la marca IBM.

Estamos hablando del microprocesador Cyrix 5x86, al que IBM comercializó con la denominación IBM 5x86C y cuya arquitectura incoporaba ya funciones de la siguiente generación pero que fueron deshabilitadas para evitar posibles errores por su lanzamiento urgente al mercado o, tal vez, para no entrar en competencia directa con los 6x86 que Cyrix ya tenía en la tostadora.

En este contexto de auténtica carrera comercial y con un mercado contra reloj dominado ya por Intel, cualquier desacierto en la estrategia de mercado podía llevar al fracaso más rotundo cualquier proyecto por muy bueno que fuese..

separata_benchmarkzone_website

bencmarkzone cpu processor icoEnlaces a webs basadas en benchmarks (informáticos)

Existen numerosos websites, de mayor o menor envergadura, dedicados al mundo del benchmark:

https://www.cpu-world.com web de referencia que permite realizar comparativa de procesadores.
https://www.cpubenchmark.net Gran portal en inglés con numerosos rankings de procesadores, tarjetas gráficas, memorias RAM, unidades de almacenamiento, etc.
https://www.cpu-upgrade.com Interesante web dinámica en inglés con potentes generadores de gráficas comparativas de procesadores. Lamentablemente, este magnífico portal parece que dejó de actualizarse hacia 2017, aún así, contiene un enorme volumen de valiosa información relativa a procesadores.
https://valid.x86.fr: CPU-Z Benchmark (x64) Lista de resultados obtenidos mediante la utilidad de referencia CPU-Z de Franck Delattre.
https://cpuid.comWebsite oficial de Franck Delattre sobre la utilidad de referencia de este autor: CPU-Z
https://www.hd-tecnologia.com/?s=BENCHMARK Web sobre tecnología computacional con gran contenido relacionado con los benchmarks
https://www.mersenne.org Web oficial del proyecto GIMPS (Great Internet Mersenne Prime Search) para la búsqueda de récords mundiales de números primos astronómicos mediante computación distribuida.

https://www.userbenchmark.com Imponente site de referencia en la métrica de rendimientos para usuarios de cualquier tipo de PC. En su propia web reza:
Somos un equipo independiente de científicos e ingenieros. No tenemos tiempo para recursos humanos, relaciones públicas o marketing.
Calculamos y analizamos millones de puntos de referencia. Los usuarios pueden medir rápidamente sus PC y explorar el rendimiento del mundo real.
Es difícil elegir hardware. Una multitud de especialistas en marketing arrasan las redes sociales con cuentas anónimas: reddit, foros, youtube, etc. e información poco veraz.
Nuestros usuarios son pensadores independientes, exigen hechos comprobables y no respetan el status quo ni la última moda.

https://benchmarks.ul.com Website oficial de la empresa desarrolladora de benchmarks como 3DMark o PCMark. UL es el desarrollador de referencia independiente líder en el mundo. Los benchmarks de UL permiten a las personas medir, comprender y administrar el rendimiento del hardware de la computadora. El equipo de UL crea las pruebas de rendimiento más confiables y más utilizadas de la industria para computadoras de escritorio, portátiles, tabletas, teléfonos inteligentes y sistemas de realidad virtual.
https://benchmark.unigine.com Site oficial de UNIGINE, una empresa global creada en 2005 y centrada en tecnologías 3D en tiempo real. UNIGINE desarrolla soluciones B2B y B2C de vanguardia para simulación, visualización, investigación científica, videojuegos, sistemas de realidad virtual y más. En esta web corporativa de este desarrollador podemos encontrar los benchmarks VALLEY, HEAVEN, SUPERPOSITION, SANCTUARY (discontinuado en 2007 y muy interesante para harware antiguo) y TROPICS (discontinuado en 2008)
https://novabench.com Web del benchmark Novabench desde la que podemos descargar la versión Free para evaluar nuestro sistema y compararlo con los resultados publicados por otros usuarios. Novabench testea el rendimiendo de CPU, GPU, Memoria y unidades de disco.
https://www.cpuid.com/softwares/powermax.html PowerMAX es el tostador de CPUID pensado para poner al límite la CPU y GPU del sistema. Si quieres poner a prueba tu hardware, es importante conocer antes las advertencias del propio desarrollador:
¡Utilice powerMAX bajo su propia responsabilidad!
powerMAX tensiona su PC de tal manera que puede revelar la debilidad de algunos de los componentes y causar daños irreversibles a los VRM de la placa base, VRM de la tarjeta de video, PSU o cualquier otro componente. Por esa razón, powerMAX debe utilizarse bajo su entera responsabilidad y CPUID no será responsable de ningún daño que pueda surgir como resultado de su uso de powerMAX.
https://www.guru3d.com/files-categories/benchmarks-demos.html GURU3D.com es en realidad un site especializado sobre tecnolgía 3D abarcando desde noticias, fotos, benchmarks hasta drivers de aceleradoras gráficas. Publicado a modo de Blog, ofrece una navegación cómoda en intuitiva en un contenido prácticamente infinito que viene alimentándose por su autor desde 2004.

https://www.maxon.net/en/cinebench CINEBENCH es el benchmark de la empresa MAXON Computer fundada en 1986. MAXON es un desarrollador líder de software 3D para las industrias creativas, mejor conocido por su software insignia de modelado, pintura, renderizado y animación en 3D, Cinema 4D. Hoy en día, los usuarios de todo el mundo confían en Cinema 4D para crear gráficos en movimiento 3D de vanguardia, visualizaciones arquitectónicas y de productos, gráficos de videojuegos, ilustraciones y mucho más. La web ofrece la última versión de CINEBENCH compatible con procesadores AMD e Intel (x64). Además, acerca de este popular becnhmark debemos saber que:

- Debido a los cambios en el código y el compilador, los valores de puntuación de Cinebench se reajustan a un nuevo rango, por lo que no deben compararse con las puntuaciones de versiones anteriores de Cinebench. (esto puede ocurrir con cualquier actualización)

- Cinebench R23 no prueba el rendimiento de la GPU. (solo se centra en el procesador principal)

- Las tareas de fondo pueden influir significativamente en la medición y generar resultados diversos. Siempre es una buena idea cerrar todos los programas en ejecución y deshabilitar cualquier comprobación de virus o indexación de disco, pero es imposible eliminar todos los procesos en segundo plano. Los sistemas operativos modernos realizan varias tareas en segundo plano que no pueden o no deben deshabilitarse, aunque podrían tener una influencia menor en los resultados. (En este aspecto precisamente incide mi miniproyecto C>OveRBooST )

https://www.spec.org Basado en los benchmarks propios, la web spec.org (Standard Performance Evaluation Corporation) ofrece un interesante centro de referencia sobre comparativas de rendimiento entre configuraciones de diferentes marcas. En su apartado dedicado a benchmarks https://www.spec.org/benchmarks.html#tools podemos acceder a todos los benchmarks desarrollados, algunos creados hace casi 30 años.

https://www.3dmark.com Página oficial dedicada a la comercialización de los benchmarks de la empresa UL. No solo podemos encontrar interesantes ofertas para adquirir las últimas versiones de estas herramientas sino que además la web ofrece interesantes cosas como este repositorio de antiguos benchmarks discontinuados por UL pero completamente funcionales y además ¡¡en versiones completas y registradas con números de seriales válidos y autorizados por la empresa !!

https://benchmarks.ul.com/legacy-benchmarks

Una auténtica delicia para los amantes del retrogaming que podrán disfrutar a tope testeando sus RIVAs TNTs y su aceleradoras VOODOOs en sus potentes y flamantes máquinas RetroGAMING.
https://geeks3d.com/furmark Furmark es el benchmark específico para OpenGL de Geeks3d
http://www.benchmarkhq.ru/english.html Contenido sencillamente descomunal servido con un diseño algo anticuado el de esta megaweb rusa sobre benchmarks. En ella puede encontrarse prácticamente cualquier cosa relacionada con los benchmarks informáticos. Solo disponible en Inglés y en su idioma nativo.
http://www.oldskool.org/pc/benchmark Curioso proyecto discontinuado en 2015 sobre benchmarks para ajustes en el rendimiento de máquinas emuladas mediante emuladores como DOSbox. Ofrece algún material de interés para retrousuarios.

https://www.philscomputerlab.com La página de Phils es una atractiva web atemporal dedicada al hardware con jugosos contenidos retro y benchmarks sobre aceleradoras Matrox, Voodoos, procesadores 486, etc. Vean este imagen de ejemplo: https://www.philscomputerlab.com/uploads/3/7/2/3/37231621/slide9_2_orig.png (imagen comparativa de rendimiento en un procesador 486 overclockeado a distintas frecuencias de Bus y multiplicador)

https://thandor.net/benchmarks Interesante web de diseño y navegación sencilla que ofrece también contenidos de especial interés para retrogramers.
https://calentamientoglobalacelerado.net/benchmarkzone La web que estás viendo.
PRIMEStone500 CPU Benchmarkhttps://calentamientoglobalacelerado.net/primestone La web del benchmark PRIMEStone500
PRIMEStone500 CPU Benchmarkhttps://calentamientoglobalacelerado.net/benchmarkzone/benchsquareLa web del benchmark BenchSQUARE
https://calentamientoglobalacelerado.net/benchmarkzone/coverboost/ Pequeña utilidad experimental que intenta acelerar el procesador mediante la descarga de servicios del sistema. Lea las instrucciones antes de ejecutar este software

 

separata_benchmarkzone_website

 

 

 

Descargas / Telechargue / Download

Aquí incluiré algunas descargas interesantes relacionadas con los benchmarks. Todo el software que desarrollo es compilado para sistemas operativos Windows de 32 bits, pero está probado y corre perfectamente en sistemas de arquitectura x64 desde Windows 2000 hasta Windows 10, además se trata de software totalmente PORTABLE que no requiere ningún tipo de instalación en el sistema destino.

*Si desea probar algún software en sistemas LiNuX o sistemas de Microsoft más antiguos como Windows 98, Millenium ó incluso Windows 95, consulte con el autor de este site en el correo electrócnico eurocamsuite@yahoo.es

Enlaces de descarga directa / links direct download / Telechargue:
Última versión del software benchmark de desarrollo propio PRIMEStone500 (69 KB) - (código del motor principal abierto para su análisis)
Última versión del software benchmark de desarrollo propio BenchSQUARE (685 KB) - (código del motor principal abierto para su análisis)
Última versión del software de desarrollo propio C>OveRBooST (690 KB) ¡LEA INSTRUCCIONES!
Artículo original preservado sobre la criba de Eratóstenes (Sieve) publicado en la revista BYTE en enero de 1983 (7 MB)
Software experimental de código abierto AlgorPrimVS.zip (336 KB) - (incluye códigos fuente y ejecutables escritos para los entornos/compiladores FREEBasic y Dev-C++)
Biblioteca suculenta con apuntes y material diverso publicado sobre los números primos

separata_benchmarkzone_website

 

DONATIVO AL AUTOR

Estoy convencido de que el reconocimiento al trabajo es el único camino para que el hombre pueda llegar a superarse.

Con este humilde y honorable gesto usted contribuye a la continuidad, mejora y mantenimiento de esta página web y al desarrollo de sus contenidos y aplicaciones gratuitas.

· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 

   

separata_benchmarkzone_website

 

|      Proyecto alojado en https://calentamientoglobalacelerado.net      |     eurocamsuite@yahoo.es     |   

maraf soft primestone 500 2000 ©© 2022