Y el equipo con el BASIC más rápido es...

[mcleod_ideafix]

Por cierto, hablando de MSX... El TurboR se come con patatas a todos los anteriores...

saxpy_msxturbor.png (34.93 KiB) Visto 8267 veces

Y eso que estoy asumiendo que TIME se usa igual que en el resto de máquinas MSX (PAL). Siendo el TurboR un chisme que sólo existió en modelos japoneses, no sería extraño que el comando TIME estuviera calibrado para 60Hz en lugar de 50, en cuyo caso el tiempo medido sería menor que el que aparece aquí.

[mcleod_ideafix]

Por cierto... el ordenador de Radastan, si lo pone a 14MHz y sin contienda, como mostré en su hilo, y suponiendo que portara el OpenSE, que es más o menos como el BASIC del Spectrum, daría este resultado:

saxpy_microradastan.png (8.86 KiB) Visto 8265 veces

[makinavaja]

Solo un detalle:
No me fiaría mucho (por no decir nada) de los emuladores de MSX para hacer este tipo de pruebas: Ya ha quedado demostrado que van a su bola.

[dancresp]

Coincido con makinavaja, y por eso hice las pruebas en los equipos reales.

Hay emuladores que son super-exactos, pero hay otros que no.

[radastan]

Por cierto... el ordenador de Radastan, si lo pone a 14MHz y sin contienda, como mostré en su hilo, y suponiendo que portara el OpenSE, que es más o menos como el BASIC del Spectrum, daría este resultado:

Mi idea es que el BASIC se cargue aparte, aunque eso suponga menos RAM de usuario, ya que la ROM quiero que tenga rutinas que faciliten la vida a los programadores y hagan que sea posible un desarrollo rápido de aplicaciones y juegos.

[scooter]

En su época hice probaturas de velocidad respecto a lo publicado en alguna revista. El basic del c128 era bastante lento, pero en modo fasr 2MHz era el mas rápido de todos, se perdía el vic pero no el vdc (cosas de tener dos chips de video independientes).
Eso si la pruebas de potencias era un truño, resultaba ser mucho mas rápido hacer un bucle for para multiplicar n veces que elevar a n.
Se ve que commodore puso un cutrebasic en el c64, ya tenía versiones mejores, porque por el basic v2.0 no tenía que pagar a microsoft, tenía un contrato de "tarifa plana" sobre esa versión.... habida cuenta de la animalada de c64 que hizo ahorró una pasta gansa, los usuarios nos volvimos tontos a pokearlo todo pero bueno...

[josepzin]

habida cuenta de la animalada de c64 que hizo ahorró una pasta gansa, los usuarios nos volvimos tontos a pokearlo todo pero bueno...

¿pero y lo que aprendías usando esos POKEs?! nadie piensa en eso?!

[mcleod_ideafix]

Solo un detalle:
No me fiaría mucho (por no decir nada) de los emuladores de MSX para hacer este tipo de pruebas: Ya ha quedado demostrado que van a su bola.

He usado BlueMSX, que según la Wikipedia, es "cycle accurate".
http://en.wikipedia.org/wiki/BlueMSX

De hecho, un emulador que no sea preciso a nivel de ciclo de reloj de CPU, tendrá problemas con muchos juegos y demos, en los que se hacen bucles de retardo basándose únicamente en la velocidad del procesador. De todas formas, trataré de replicar los resultados de los tests de Dancresp con estos mismos emuladores, y así me hago una idea de si son exactos o no. A ver qué sale...

[dancresp]

De todas formas, trataré de replicar los resultados de los tests de Dancresp con estos mismos emuladores, y así me hago una idea de si son exactos o no. A ver qué sale...

Piensa que no soy un cyborg, y no se los emuladores pero el tiempo de reacción de mis dedos llevan su tiempo...

[mcleod_ideafix]

Piensa que no soy un cyborg, y no se los emuladores pero el tiempo de reacción de mis dedos llevan su tiempo...

Ya me he dado cuenta de que los resultados difieren un poco... es por eso que comentaba al principio la conveniencia de que sea la propia máquina la que se cronometre. Aun así, obtengo con BlueMSX unos resultados muy similares a los tuyos (varía en 2-3 décimas de segundo, lo cual es lógico por aquello del tiempo de reacción).

Test con variables reales

msx_dancresp_test2_float.png (30.78 KiB) Visto 8239 veces

Test con variables enteras

msx_dancresp_test2_integer.png (10.85 KiB) Visto 8239 veces