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

[mcleod_ideafix]

A modo de curiosidad, y "fuera de concurso", he hecho el mismo test SAXPY en el Spectrum, pero usando código máquina en lugar de BASIC. En realidad el cálculo se sigue haciendo como en BASIC, es decir, usando el calculador de la ROM. Lo que gano ahora en velocidad es debido a que el intérprete no es ahora quien determina qué instrucción se ejecuta a continuación, ni tiene que cuidar de bucles ni nada. Tampoco tiene que pararse a evaluar expresiones, ya que la expresión está ya convertida a la notación polaca inversa y el programa sólamente mete los operandos en el stack del calculador.

Para comprobar que los cálculos son idénticos he metido, en una de las versiones de esta rutina, una llamada a PRINT_FP para que vaya imprimiendo el valor de cada elemento del vector Y en pantalla a medida que se va calculando. Pedirle que imprima un número en punto fltoante es una tarea que consume bastante tiempo, como podreis ver.

El programa (sensiblemente más largo que su versión en BASIC, claro está) es éste:

Código: Seleccionar todo

                        ;Bucle SAXPY en ensamblador usando el
                        ;calculador de la ROM

                        ;(C)2012 Miguel Angel Rodriguez Jodar (mcleod_ideafix)
                        ;GPL licensed.

N                       equ 100
STACK_NUM               equ 33b4h
STK_STORE               equ 2ab6h
STK_FETCH               equ 2bf1h
PRINT_FP                equ 2de3h

DEBUG                   equ 0   ;1 para imprimir vector Y por pantalla

                        org 50000

                        di
                        ld a,253
                        ld i,a
                        im 2     ; poner cronometro

                        ld ix,X
                        ld iy,Y
                        ld b,1
                        ld de,5
BucleRellena            ld a,N
                        sub b
                        ld (ix+0),0
                        ld (ix+1),0
                        ld (ix+2),b  ;x(i)=i
                        ld (ix+3),0
                        ld (ix+4),0
                        ld (iy+0),0
                        ld (iy+1),0
                        ld (iy+2),a  ;y(i)=N-i
                        ld (iy+3),0
                        ld (iy+4),0
                        add ix,de
                        add iy,de
                        inc b
                        ld a,b
                        cp N+1
                        jr nz,BucleRellena

                        ld b,N
                        ld ix,X
                        ld iy,Y

                        ld hl,0
                        ld (FRAMES),hl   ; cronometro a 0
                        ei               ; Comienza a medir el tiempo ahora!

BucSAXPY                push bc
                        push iy
                        pop hl
                        call STACK_NUM  ; y(i) -> stack
                        ld a,130        ;
                        ld e,72         ; Estos 5 numeros son
                        ld d,245        ; el valor 3.14 codificado
                        ld c,194        ; en coma flotante del Spectrum
                        ld b,143        ;
                        call STK_STORE   ; 3.14 (a) -> stack
                        push ix
                        pop hl
                        call STACK_NUM   ; x(i) -> stack
                        rst 28h   ; calculador de la ROM
                        db 04h    ; multiplica: a*x(i) -> stack
                        db 0fh    ; suma: a*x(i)+y(i) -> stack
                        IF DEBUG
                          db 31h    ; dup: una copia para imprimirla
                        ENDIF
                        db 38h    ; fin calculos
                        call STK_FETCH   ; recuperar resultado del stack
                        ld (iy+0),a
                        ld (iy+1),e
                        ld (iy+2),d
                        ld (iy+3),c
                        ld (iy+4),b    ; y se guarda en y(i)
                        ld de,5
                        add ix,de
                        add iy,de
                        IF DEBUG
                          push iy
                          ld iy,5c3ah
                          call PRINT_FP
                          ld a,32
                          rst 10h
                          pop iy
                        ENDIF
                        pop bc
                        djnz BucSAXPY

                        ld bc,(FRAMES)
                        im 1
                        ret

X                       ds N*5
Y                       ds N*5
FRAMES                  dw 0

                        org 65023
                        dw NuevaIM2
NuevaIM2                push hl
                        ld hl,(FRAMES)
                        inc hl
                        ld (FRAMES),hl
                        pop hl
                        ei
                        reti

                        end


La versión con DEBUG=0 (sin impresión en pantalla), está en el fichero "saxpy_rom_noprint.sna". La rutina se llama con PRINT USR 50000 y devuelve como resultado el número de retrazos que ha tardado la rutina (un retrazo = 1/50 s). En el snapshot basta con ejecutar con RUN.
La versión con DEBUG=1 imprime en pantalla a medida que se calcula Y. Esta en el fichero "saxpy_rom_print.sna". Ahí vereis que también está la versión en BASIC. Ejecutando con RUN sale esta versión (mucho más lenta por culpa de los PRINT's). El último valor que sale en realidad es el tiempo en segundos medido. Haciendo PRINT 0.02*USR 50000 se ejecutará la versión en C/M, también imprimiendo valores en pantalla (que deben ser idénticos a la versión BASIC) y por último, el tiempo empleado.

Para los que no quieran ejecutar los snapshosts, diré que la versión en C/M sin impresión, tarda 0.28 segundos, frente a la que hice en BASIC, que recordemos tardaba 1.94 segundos. La versión C/M con impresión tarda 1.38 segundos, frente a su correspondiente en BASIC, que tarda 3.6 segundos.

[mcleod_ideafix]

Por cierto... esto mismo se hizo en la BBC hace ya tela de tiempo. Curioso que el presentador le dice al tío que hace los benchmarks que cómo es que usa un cronómetro, con lo poco preciso que es eso, cuando estos ordenadores tienen temporizadores internos. El tío le contesta que no todos los equipos tienen ese temporizador (???)

[dancresp]

La virgen de los alicates !!!

mcleod, parece que te lo has tomado en serio.

A ver esos resultados...

[mcleod_ideafix]

¡Y tanto! Te cuento por qué:

Este hilo, que iniciaste en RW y que has seguido aquí, tiene más chicha de la que parece. Es cierto que categorizar la rapidez de un equipo por la rapidez de su intérprete de BASIC le hace poca justicia a muchos de ellos, pero es que resulta que para muchos de nosotros, cuando en su época buscábamos un microordenador para iniciarnos en la informática, pesaban este tipo de factores: ¿cuál es el "más rápido"? Y dado que la puerta de entrada a hacer cosas con el micro es su lenguaje integrado en el sistema, la pregunta se convería en "cuál tiene el BASIC más rápido"?

Tannembaum, en uno de sus libros de Sistemas Operativos, habla al principio de que un ordenador no es más que una serie de capas de máquinas virtuales, cada una apilada encima de otra (aquí lo de "máquina virtual" es más un concepto que una pieza de software concreta, como podría serlo la JAva Virtual Machine que existe en los PC's y smartphones), y que según cómo lo usemos, vemos una máquina virtual u otra. Por ejemplo: un programador que use C verá la "máquina virtual C", en la que las variables, bucles, etc se manejan de una cierta forma. El programador de ensamblador verá otra máquina virtual, con sus propias reglas. El paradigma de las máquinas virtuales especifica que es posible en un ordenador cambiar una máquina virtual por otra que haga el mismo trabajo, de forma que dos ordenadores diferentes en arquitectura, fabricante, etc, a un cierto nivel se comporten igual. Un ejemplo: el Commodore 128, el Amstrad CPC6128, el Spectrum +3 y el MSX-2 se parecen... ¡en nada!. Sin embargo es posible verlos desde la perspectiva de la máquina virtual "CP/M". Esta es una máquina virtual de bajo nivel. A más alto nivel tienes otra máquina virtual presente en todos ellos: el BASIC.

Así que esto de las máquinas virtuales se cumple perfectamente con nuestros retrocacharros. Independientemente del padre y madre de cada uno de ellos, (casi) todos presentan al programador una máquina virtual que llamamos intérprete de BASIC. Tus benchmarks, el mío, y los del colega de la BBC del video de antes, lo que han evaluado es esa máquina virtual común y presente en todos los micros evaluados.

Tener una batería de benchmarks (que permitan medir algún parámetro del intérprete en concreto, o varios, o todo el intérprete en su conjunto) ejecutados en todos los micros posibles (en el micro real a ser posible para despejar dudas), nos va a dar unos números muy interesantes, de forma que cualquiera que se plantee introducirse en el mundo de la programación retro (sin meterse en C/M) pueda saber feacientemente y de manera objetiva, qué microordenador le vendrá mejor para iniciarse. Por ejemplo: alguien que se plantee escribir una aventura conversacional, en la que hay que trabajar mucho con cadenas, funciones de cadenas, string slicing, etc, le interesará saber qué micro tiene el soporte de cadenas más rápido.

Esto también me ha recordado a lo que se hace a nivel "serio" para categorizar a los supercomputadores más rápidos del mundo. Hay una lista, el TOP500, que ordena a estos supercomputadores comenzando por el más rápido, y que aglutina a los 500 supercomputadores más rápidos del mundo. Para evaluarlos se usa un benchmark que tiene en cuenta la velocidad de la(s) CPU's, la memoria de cada nodo, y las comunicaciones. El benchmark está basado en unas librerías de álgebra llamadas BLAS, y curiosamente, una de las rutinas principales del BLAS es precisamente el bucle SAXPY. Así que este test que he ejecutado en las máquinas (emuladores más bien) ha sido como nuestro benchmark del Top500 particular.

PD: en los equipos en los que puede ejecutarse CP/M se podría por tanto usar otro benchmark (que podría ser de nuevo el bucle SAXPY u otra cosa) y medir la eficiencia ya no relativa a lo bueno que es su BASIC, sino otros factores: cuán rápido es su acceso a disquete, su E/S a consola, su velocidad procesando datos en memoria o procesando datos numéricos.

[e_sedes]

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í.

TIME se actualiza a cada interrupción, por lo que depende de si el ordenador está puesto a 50Hz o a 60Hz.

Mola esta comparación!

[JMV]

Fantástico hilo, felicidades a todos.

[tteclad]

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.

Rememorando viejas "batallitas", eh?

AmigaBasic - Wikipedia

An unusual feature of the language is that it theoretically allowed the calling of handwritten assembly language subprograms; however, this feature never worked because of a bug that failed to align the assembly language instructions correctly on a word boundary, as required by the Amiga's native MC68000 processor.

Resumiento, que lo que si hacia el GFA Basic, incluso en la versión de Amiga, como era meter ASM en el Basic para ejecutarlo/compilarlo, petaba de manera escandalosa por un error de interprete del AmigaBasic, y es que no somoa nada si no sabemos "interpretar" el sentido de la vida

[zup]

¿Y no comparáis con un PC? Por curiosidad estaría bien saber qué resultados arroja un IBM 5150 usando el BASIC de la ROM.

Por otra parte me parecen unos test algo "light". Estaría bien hacer algo que mantenga ocupado más tiempo al equipo (como poco 30s) y poder usar un cronómetro... a fin de cuentas, no todos los equipos tienen temporizadores, y se elimina la cuestión del tiempo que le cuesta leer al equipo el temporizador (aunque sobre 30 segundos, no va a ser algo determinante).

[mcleod_ideafix]

¿Y no comparáis con un PC? Por curiosidad estaría bien saber qué resultados arroja un IBM 5150 usando el BASIC de la ROM.

Por otra parte me parecen unos test algo "light". Estaría bien hacer algo que mantenga ocupado más tiempo al equipo (como poco 30s) y poder usar un cronómetro... a fin de cuentas, no todos los equipos tienen temporizadores, y se elimina la cuestión del tiempo que le cuesta leer al equipo el temporizador (aunque sobre 30 segundos, no va a ser algo determinante).

Pues si quieres proponer tú un test más "heavy" y probarlo, sírvete tú mismo ... Por otra parte, yo no tengo ningún IBM 5150, ni conozco ningún emulador "cycle-accurate" del IBM 5150, así que no puedo correr ningún test en esa máquina.

[zup]

No creo que sea necesario un test diferente... quizás repetir 20 o 30 veces ese test bastaría para alargar los resultados y usar un cronómetro.

En cuanto al 5150, los únicos que conozco son MESS y PCem. Supuestamente, MESS apunta a ser cycle acurate, pero eso depende también del nivel de desarrollo del driver. PCem lo tengo pendiente.