ZONA DE PRUEBAS

Llevo un tiempo intentando exprimir al máximo las posibilidades del BASIC de distintos sistemas de 8 y 16 bits.

Con la experiencia que me da el haber programado el mismo programa en varios equipos me surgió la idea de hacer varias pruebas para comprobar que equipo tiene el BASIC más rápido.

Así, en una primera fase he decidido ejecutar un par de sencillos programas en multitud de sistemas, cronómetro en mano, para obtener la respuesta a mi pregunta.














El test se compone de estos dos programas de 5 líneas cada uno:

1) Poner texto en pantalla
Un doble bucle que situa una "X" en una posición determinada de la pantalla. En total se repito 32x16=512 veces. He tenido en cuenta que el AT del SPECTRUM, es el LOCATE del MSX, el PLOT del ORIC, etc., que en unos pones X,Y y en otros Y,X. Y que en unos la primera posición es la 0 y en otros la 1. Los valores los he adaptado a la resolución del DRAGON y el LASER 200.

10 FOR F=1 TO 16
20 FOR I=1 TO 32
30 PRINT AT F,I;"X"
40 NEXT I
50 NEXT F


2) Calcular e imprimir el resultado en pantalla
Se realiza, sobre el valor de una variable, un cálculo consistente en una multiplicación, una división y una resta. Esto se repite 99 veces y se va mostrando el resultado en pantalla.

10 A=1
20 B=A*2/3-4
30 PRINT B
40 A=A+1
50 IF A<100 THEN GOTO 20

Cada prueba se ha realizado con la pantalla inicialmente en blanco y se ha repetido entre 3 y 5 veces para sacar una media del tiempo empleado, ya que como no soy un robot, mi cuerpo necesita unos ciclos para activar los músculos que pulsarán los botones START y STOP del cronómetro.






Os muestro los resultados en "segundos:decimas", ordenados de más a menos rápido.

Resultados PROGRAMA-1: (Poner un carácter en pantalla)

01:23 = ATARI ST (usando GFA BASIC)
02:03 = BBC MICRO
02:80 = SHARP MZ-700
03:54 = ACORN ELECTRON
04:14 = ORIC-1
04:47 = MSX (03:54 usando variables integer)
04:56 = COMMODORE 16
04:91 = ATARI 800
05:20 = AMSTRAD CPC-464+
05:38 = DRAGON 32 (Incluye F*32+I, sino 02:04)
05:46 = THOMSON TO8
05:52 = COMMODORE 128
05:54 = SPECTRUM
06:03 = SINCLAIR QL
06:77 = MATTEL AQUARIUS (Reemplazada línea 30 por POKE 12288+F*40+I,65, sino 01:70)
07:34 = ALPHATRONIC PC
10:49 = LASER 200 (* leer en conclusiones)
28:66 = TEXAS INSTRUMENTS TI-99/4A
48:42 = ZX-81 (08:22 en modo FAST)


Resultados PROGRAMA-2: (Calcular e imprimir el resultado en pantalla)

01:92 = BBC MICRO
02:60 = ATARI ST (usando GFA BASIC)
02:90 = MATTEL AQUARIUS
02:95 = ACORN ELECTRON
03:91 = DRAGON 32
04:15 = AMSTRAD CPC-464+
04:24 = AMSTRAD PCW-8256
05:45 = COMMODORE 64
05:60 = MSX (05:26 usando variables integer)
05:91 = COMMODORE 16
06:16 = LASER 200
06:59 = ATARI 800
07:03 = COMMODORE 128
07:52 = SPECTRUM
07:96 = SHARP MZ-700
08:29 = ALPHATRONIC PC
10:14 = SINCLAIR QL
10:42 = THOMSON TO8
11:29 = ORIC-1
22:79 = TEXAS INSTRUMENTS TI-99/4A
62:32 = ZX-81 (11:48 en modo FAST)


Conclusiones:

- La bestia negra de los 8 bits es sin lugar a dudas el BBC MICRO.

- El ZX-81 come a parte, aunque en modo FAST funciona 6 veces más rápido.

- El DRAGON-32 no posiciona los caracteres en pantalla por coordenada X,Y sino que lo hace con una posición absoluta. En el primer ejercicio se ha optado por simular un posicionamiento mediante el cálculo F*32+I. Y a pesar de haber realizado 512 multiplicaciones y sumas, ha tardado poco más que la mayoría. Esto indica que un programa bien realizado lo hará funcionar casi tan rápido como el BBC MICRO.

- El MATTEL AQUARIUS no puede posiciona un caracteres en una posición determinada de la pantalla. Para ello hay que hacerlo POKEando directamente en la memoria de pantalla. He substituidola línea 30 por "POKE 12288+F*40+I,65". A pesar de haber realizado 512 multiplicaciones y 1024 sumas, ha tardado poco más que la mayoría.De una forma más óptima habría sido más rápido que la mayoría.

- El caso del posicionamiento en pantalla del LASER 200 es igual al del DRAGON 32, pero teniendo en cuenta que para imprimir 512 "X" una a continuación de la otra ya ha tardado casi 11 segundos, no he probado a hacerlo con el mismo cálculo que el DRAGON-32. Esto mismo lo hace un MATTEL AQUARIUS en solo 1:70 segundos.

- Hay ordenadores con un rápido acceso a pantalla, pero al hacer cálculos su rendimiento cae. Caso del ORIC-1 y el SHARP MZ-700, entre otros. Supongo que las rutinas del calculador no deben estar bien depuradas.

- En el caso de los MSX, se ha ejecutado el test dos veces, uno normal y el otro usando variables "integer %". En el primer test el rendimiento mejora un 20%, y en el segundo test, limitando los integer a la variable A, el rendimiento mejora un 10%. Es de suponer que en otros sistemas que admite el uso de variables integer el rendimiento también debería mejorar.

- Teniendo en cuenta la diferencia de velocidad entre los dos ejercicios en un mismo equipos, no descarto realizar algún ejercicio más para comprobar otras características, y mejorar el promedio total.


Más adelante me gustaría hacer un test de rutinas gráficas.

Continuará...

¿El ZX81 en modo fast el mas rápido? Curioso. Tenía entendido que el modo fast dejaba de dibujar en pantalla, pero los cálculos que son matemáticos, no de dibujo, iban igual. Seguro que estoy equivocado.

Podrías hacer un simple test de poner un texto en pantalla y que al llegar abajo, el propio texto obligue a "scrollear" hacia arriba. Ese "scroll" en el Spectrum es "asqueroso", a ver como lo hacen los demas.

jepalza escribió:¿El ZX81 en modo fast el mas rápido? Curioso. Tenía entendido que el modo fast dejaba de dibujar en pantalla, pero los cálculos que son matemáticos, no de dibujo

En modo "slow", la CPU del ZX81 está más tiempo dedicada a redibujar la pantalla que a otra cosa. Y esto lo hace aunque tu programa no tenga ni una sola instrucción de imprimir en pantalla (el tubo de imagen no espera )

Si de lo que se trata es de medir la velocidad del intérprete de BASIC, propongo un benchmark sintético muy sencillo, que se suele usar en procesadores "serios" para medir su eficiencia a nivel de juego de instrucciones, pero que aquí podemos usar para medir la velocidad del intérprete: es el bucle SAXPY.

Consiste en calcular para unos vectores dados X e Y, y un escalar "a", la expresión Y=a*X+Y (aX plus Y). La "S" del principio hace referencia a que se usan habitualmente números en precisión simple.

En BASIC genérico, el bucle quedaría así:


En las líneas 70 a 90 se prueban algunos aspectos del intérprete:
- Su capacidad para evaluar expresiones aritméticas
- Su capacidad para gestionar rupturas de secuencia (condicionales + saltos, para implementar el bucle FOR)
- Su capacidad para gestionar vectores y matrices, incluyendo el cálculo de la dirección efectiva del elemento

Por otra parte, siempre que se pueda, es conveniente hacer la medida usando el propio cronómetro del ordenador, no "a mano". En el Spectrum el contador de tiempo está en la variable del systema FRAMES, de 24 bits. Usándolo, nos queda esto:



En otras máquinas se hará de forma análoga. Por ejemplo, en el Dragon (PAL)se usa una variable llamada TIMER. Cuando se quiere resetear esta variable, se pone a 0. El sistema la actualiza automáticamente (creo que 50 veces por segundo, como en el Spectrum).
En el MSX y el C64 hay una variable muy similar, TIME. Se actualiza también 50 veces por segundo (en una máquina que sea PAL)
En el Amstrad CPC, la resolución de la variable TIME es de 300, no de 50. Es decir, un segundo son 300 cuentas de TIME.
En el ZX81 se usa una variable del sistema como en el Spectrum (FRAMES). En el ZX81 es de 16 bits, no de 24 bits. Y su localización depende de la ROM usada. En la ROM "antigua", FRAMES está en 16414. En la ROM "nueva", está en 16436.
Etc...

jepalza escribió:Podrías hacer un simple test de poner un texto en pantalla y que al llegar abajo, el propio texto obligue a "scrollear" hacia arriba. Ese "scroll" en el Spectrum es "asqueroso", a ver como lo hacen los demas.

El Scroll del Spectrum es asqueroso porque este ordenador no tiene modo texto. Al hacerlo, realmente ha de mover 6912 bytes, con una disposición de memoria de video también bastante peculiar, cuando no única.

En el resto de equipos, un SCROLL mueve entre 1 KB o 2 KB, como máximo, y con una disposición de memoria secuencial.

Por otro lado, los programas son sencillos, porque teclear el mismo programa 21 veces lleva su tiempo.

Así pues, los resultados son muy aproximados (los he calculado más de 3 veces y he hecho la media) pero no exactos.

dancresp escribió:En el resto de equipos, un SCROLL mueve entre 1 KB o 2 KB, como máximo, y con una disposición de memoria secuencial.

En el Amstrad CPC, que recuerde, la disposición de memoria tampoco es secuencial, ni tiene modo de sólo texto, con lo que el scroll es tan lento (o puede que más, ya que tiene que mover 16KB) que en el Spectrum. El QL tampoco tiene modo de texto, y tiene que mover 32KB para un scroll vertical (un poco menos en realidad porque sólo scrollea la ventana visible, no toda la pantalla). Por esto te dije la otra vez, cuando publicaste esta comparativa en RW, que hacer programas que usan la E/S del ordenador, más que medir la eficiencia del BASIC, lo que hacen es medir la eficiencia del ordenador en su conjunto. Un BASIC rápido puede aparecer como más lento por causa del cuello de botella que supone la E/S (con el ZX81 como caso extremo cuando está en modo "slow").

Olvidaste el Amiga, ya que esta el AtariST podrias haber puesto su competidor mas importante.

mcleod_ideafix escribió:

dancresp escribió:En el resto de equipos, un SCROLL mueve entre 1 KB o 2 KB, como máximo, y con una disposición de memoria secuencial.

En el Amstrad CPC, que recuerde, la disposición de memoria tampoco es secuencial, ni tiene modo de sólo texto, con lo que el scroll es tan lento (o puede que más, ya que tiene que mover 16KB) que en el Spectrum.

Por lo que yo se el BASIC del AMSTRAD CPC hace el scroll de texto por hardware, asi que en realidad no mueve nada, solo borra la parte de la pantalla que sale por el otro lado y la redibuja con el nuevo contenido, corregidme si me equivoco.

Toniman escribió:Olvidaste el Amiga, ya que esta el AtariST podrias haber puesto su competidor mas importante.

¿Para qué? ¿Para avergonzarlo? (léase: guerra entre Amiga-Atari ) ¡Qué maravillosos años aquellos!

La velocidad real, para medirla, habría que meterse en ASM, y eso, lo complicaría todo. Para hacerse una idea, está bien el Basic como medio de "BenchMark", al fin y al cabo, de eso se trata en el hilo, de hacerlo en Basic, que es lo que vas a programar en el día a día.

Una curiosidad que acabo de leer sobre el Basic del Atari ST en la wikipedia:

Lo pego tal cual lo he cogido de la wiki


Que viene a decir que el Basic del Atari ST era tan malo, que la gente no lo usaba y buscaba alternativas mas seguras. Debía de ser tan malo, que fallaba por cosas tan tontas como escribir "PRINT 75.3", como pone en el texto citado.

Na, no pasa nada, solo era para preguntar por curiosidad.