Decepción con el BASIC del Spectrum

[antligen]

Me he encontrado este vídeo que compara (supuestamente) el rendimiento del Z80 con el del 6502 usando un Amstrad CPC (Z80) y un Commodore 64(6502). El vídeo es este

https://www.youtube.com/watch?v=pxye-RbKFpY

El CPC tardó 1:20 y el C64 2:15

Siempre he dado por hecho que el Z80 es más rápido que el 6502, y no lo digo por los MHz. Sino por el rendimiento en juegos de CPU pura como los vectoriales tipo Star Wars (En los juegos "normales" el C64 cuenta con muchas ayudas que hacen que vayan mucho mejor que en Spectrum )
Incluso el CPC aun yendo el Z80 a 4Mhz el diseño de hardware lo penaliza con un rendimiento equivalente a 3MHz.

Así que pensé ¿que tal sería esto en el spectrum con un Z80 a 3,5 Mhz?

Y como me aburría un poco decidí hacer el "test" para Spectrum

https://www.youtube.com/watch?v=XRyS6Je10So

El resultado es bastante decepcionante.

unos 4:07

Supongo que es cosa del intérprete BASIC que es muy malo. Si alguien se anima con el Mallard BASIC del CP/M del +3 a ver que tal igual dignificamos un poco al Speccy.

[mcleod_ideafix]

Hace tiempo hice un test parecido, pero usando otro algoritmo, un benchmark sintético llamado SAXPY. Lo probé con un montón de equipos y para medir el tiempo no lo hice a ojo, sino usando el propio cronómetro del ordenador.

La característica principal del bucle que empleé es que en el contaje del tiempo no incluyo operaciones de E/S (por ejemplo, PRINT) por lo que el tipo de pantalla no afecta al resultado. En el benchmark que has empleado incluyes el PRINT, y resulta que el C64 tiene una pantalla de modo texto, en la cual imprimir caracteres es muy rápido, mientras que el Spectrum siempre trabaja en modo bitmap, con lo que cada letra ha de pintarse en pantalla. Esa es una de las razones por las que resulta tan lento el Spectrum.
La otra razón, la principal, es que el BASIC del Spectrum no es para nada rápido. Primó el tamaño de código sobre la velocidad de ejecución de la ROM.

Estos fueron los resultados:


Más tarde pude hacer el mismo benchmark en otros dos equipos: Atari 800XL y el Oric Atmos:

[BlackHole]

Y como me aburría un poco decidí hacer el "test" para Spectrum. El resultado es bastante decepcionante. unos 4:07

Como muy bien ha apuntado mcleod_ideafix, el movimiento de scroll de toda la pantalla de 6.75 KB para cada nueva impresión penaliza ampliamente el resultado. Yo te animo a que pongas PRINT AT 0,0; antes del cálculo matemático y que compartas los resultados.

[mcleod_ideafix]

He probado tu benchmark pero optimizándolo un poco para el caso del Spectrum. No he cambiado para nada el cóigo: sólo he agrupado en lo posible varias sentencias en una linea, acortado el nombre de las variables para que el intérprete tarde menos en encontrarlas, y he cambiado el PRINT para que imprima dos números por linea, evitando así demasiados scrolles (en el Spectrum, el desplazamiento de pantalla supone mover 6912 bytes, mientras que en el C64 supone no mover ninguno ya que el scroll se hace desplazando la ventana de texto). Este es el código, al que le he incluido la misma forma de calcular el tiempo que en los benchmarks que hice:



Y este es el resultado:



Que son 3 minutos, 47 segundos.
Para ver cuánto se come la E/S de este tiempo, quité la linea con el PRINT y sólo dejé la que muestra el tiempo, obteniendo:



Casi 8 segundos menos respecto a la medida anterior.

Respecto al Mallard BASIC, también hice la prueba



En el caso de este intérprete, no tengo ni idea de cómo medir el tiempo, así que para hacerlo con la misma exactitud, al menos, a cómo lo hago con el BASIC Sinclair, lo que hice fue grabar en video la salida del emulador y luego en un editor contar frames desde que tecleo RUN hasta que veo el Ok. En un segundo hay 50 frames.

Así, la versión original tarda desde el frame 239 de mi video hasta el 3782, es decir, 70.86 segundos, o 1 minuto, 10.86 segundos.
La misma versión, pero sin E/S, es decir, sin PRINT, tarda desde el frame 4524 hasta el 7351, es decir, 56.54 segundos.

[BlackHole]

¡Vaya! ¿Solo se ahorran 6 segundos al no imprimir los números primos? Pues algo decepcionante.
Las operaciones en coma flotante nunca fueron el punto fuerte del BASIC de Sinclair, eso es cierto.

[zup]

Tres preguntas...
- ¿Por qué precisamente Mallard BASIC y no otros compiladores BASIC?
- ¿Alguien ha hecho una comparativa de BASICs para Spectrum?
- ¿Penalizan mucho las interrupciones del +2A/+3 la ejecución del BASIC con respecto al 48k pelado? (Imagino que las del 128k también, pero menos)

[radastan]

El BASIC del ZX Spectrum es extremadamente lento y poco optimizado, aparte que un ejemplo concreto no sirve de benchmark justo. En un programa BASIC normal no se suele emplear SQR a tochomocho, aparte que habría que ver la precisión en cálculos con decimales en otros ordenadores. De todas formas mi BASIC favorito es el del MSX, seguido muy de cerca del Sam Coupé. El Sinclair QL es leeeeeeeeento, pero es que posee cosas que el resto de BASIC ni sueñan, está orientado 100% a entornos de trabajo.

Yo no pondría tan mal el BASIC del ZX Spectrum, de echo permite trucos verdaderamente geniales para ganar velocidad, y es bastante completo. Yo he llegado a hacer un motor 3D en BASIC (busca Crysis para ZX Spectrum), sencillo pero plenamente funcional.

De verdad, no te guíes por estos piques entre plataformas y no tengas tan subestimado el BASIC del ZX Spectrum.

[dancresp]

Hombre mcleod_ideafix, volvemos a los rendimientos del BASIC !!!

Yo no pondría tan mal el BASIC del ZX Spectrum, de echo permite trucos verdaderamente geniales para ganar velocidad, y es bastante completo. Yo he llegado a hacer un motor 3D en BASIC (busca Crysis para ZX Spectrum), sencillo pero plenamente funcional.

Totalmente de acuerdo.

Está claro que no es el mejor, pero si programas un juego entero, en el que hay cálculos más "normales", impresión en pantalla, etc, el rendimiento esta más que bien.

Por ejemplo, el CPC tiene un BASIC muy rápido, pero es exageradamente lento imprimiendo en pantalla.

Por cierto, no he encontrado el "Crysis" que comentas. ¿Que es?

[antligen]

He probado tu benchmark pero optimizándolo un poco para el caso del Spectrum. No he cambiado para nada el cóigo: sólo he agrupado en lo posible varias sentencias en una linea, acortado el nombre de las variables para que el intérprete tarde menos en encontrarlas, y he cambiado el PRINT para que imprima dos números por linea, evitando así demasiados scrolles (en el Spectrum, el desplazamiento de pantalla supone mover 6912 bytes, mientras que en el C64 supone no mover ninguno ya que el scroll se hace desplazando la ventana de texto). Este es el código, al que le he incluido la misma forma de calcular el tiempo que en los benchmarks que hice:



Y este es el resultado:



Que son 3 minutos, 47 segundos.
Para ver cuánto se come la E/S de este tiempo, quité la linea con el PRINT y sólo dejé la que muestra el tiempo, obteniendo:



Casi 8 segundos menos respecto a la medida anterior.

Respecto al Mallard BASIC, también hice la prueba



En el caso de este intérprete, no tengo ni idea de cómo medir el tiempo, así que para hacerlo con la misma exactitud, al menos, a cómo lo hago con el BASIC Sinclair, lo que hice fue grabar en video la salida del emulador y luego en un editor contar frames desde que tecleo RUN hasta que veo el Ok. En un segundo hay 50 frames.

Así, la versión original tarda desde el frame 239 de mi video hasta el 3782, es decir, 70.86 segundos, o 1 minuto, 10.86 segundos.
La misma versión, pero sin E/S, es decir, sin PRINT, tarda desde el frame 4524 hasta el 7351, es decir, 56.54 segundos.

Bueno, no es "mi benchmark" simplemente he transcrito el código tal cual de los vídeos, también habría que ver si para CPC y C64 se hubiera podido optimizar, supongo que se busca una igualdad de condiciones más que una optimización.
El Mallard BASIC veo que mucho más rápido, algo que dignifica al spectrum.

[radastan]

Por cierto, no he encontrado el "Crysis" que comentas. ¿Que es?

Una payasada en BASIC que hace uso de un motor 3D:
http://reptonix.awardspace.co.uk/sinclair/csscgc2008/games.htm



Realmente se podía haber puesto más tamaño de pantalla, no iba a ser mucho más lento, pero lo dejé así. No está compilado ni nada, es BASIC puro y duro, sólo hace uso de una triquiñuela con los GOTO para acelerar la representación 3D. Y porque no usé GDUs, que entonces el resultado habría sido espectacular.