1 Ostatnio edytowany przez tebe (2006-07-06 08:02:45)

oto test który udowadnia że emulator jest szybszy od emulowanej maszyny

/* Eratosthenes Sieve benchmark */

#include <peekpoke.h>

#define true 1
#define false 0
#define size 8190
#define sizepl 8191
#define tick 0x14
#define tack 0x13

char flags[sizepl];


void wait(void)
{
 unsigned char a=PEEK(tick);
 while (PEEK(tick)==a) { ; }
}


int main()
{
    int i, prime, k, count, iter;    

    wait();

    POKE(tick,0x00);
    POKE(tack,0x00);

    printf("10 iterations\n");

    iter = 1;
    while (iter <= 10) {
        count = 0;
        i = 0;
        while (i <= size) {
            flags[i] = true;
            i++;
        }
        i = 0;
        while (i <= size) {
            if (flags[i]) {
                prime = i + i + 3;
                k = i + prime;
                while (k <= size) {
                    flags[k] = false;
                    k = k + prime;
                }
                count++;
            }
            i++;
        }
        iter++;
    }

    printf("\n%d primes\n", count);
    
    i=PEEK(tick)+PEEK(tack)*256;

    printf("\n%d fps\n", i);
    
    exit(0);
}

wyniki w ramkach FPS


atari800win: 4012 fps


prawdziwe Atari z procesorem 65816

tryb 6502:  4015 fps
tryb 65816: 3857 fps


dopałka Pasia F7:

tryb 6502:   554 fps
tryb 65816: 533 fps


p.s.
przeprowadze jeszcze z ciekawości test z programem w asm bez optymalizowania szybkosci kodu z duza iloscia procedur itp. na razie się pisze

*- TeBe/Madteam
3x Atari 130XE, SDX, CPU 65816, 2x VBXE, 2x IDE Plus rev. C

2

Odpowiednio dobranym testem można udowodnić wiele. Jeszcze brakuje tylko komentarza, że emulator jest szybszy, więc lepszy. ;) ;)

Poważnie: której wersji emulatora użyłeś; ile razy powtarzałeś pomiary; jak zapewniłeś, że OS jest identyczny; jak zapewniłeś, że procedury OS działają identycznie (chociażby identyczne HATABS, bo jak widać używasz CIO).

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

3

według tego posta cc65 nie ma supportu dla 65c816. Jakim zatem sposobem sprawiłeś, że w trybie 65816 jest szybszy?

4

MADS'em zapewne :P

Kontakt: pin@usdk.pl

5

magicznym zakleciem Laoo ;)

cc65 -O --cpu 65816 -t atari %1 -o %1.s
ca65 --cpu 65816 -t atari %1.s -o %1.o
ld65 -t atari -o %1.xex atari.o %1.o atari.lib

Fox jak zwykle masz racje

*- TeBe/Madteam
3x Atari 130XE, SDX, CPU 65816, 2x VBXE, 2x IDE Plus rev. C

6

Pasiu był tak miły i zapuścił ten benchmark na swojej dopałce, jak pisze ciut powyżej 14Mhz

6502:   554 fps
65816: 533 fps

*- TeBe/Madteam
3x Atari 130XE, SDX, CPU 65816, 2x VBXE, 2x IDE Plus rev. C

7

W wersji 2.9.3 jaką "najnowszą" miałem to nie szło, ale w świeżo ściągniętej 2.11.0-1 już działą. No nieźle :)

8

w/w benchmark przyspieszy (dla 6502 wyjdzie wynik 2950 fps) jesli zadeklarujemy nasze zmienne jako "unsigned int" w w/w wersji jest bardziej obciążający CPU

*- TeBe/Madteam
3x Atari 130XE, SDX, CPU 65816, 2x VBXE, 2x IDE Plus rev. C

9

ile b ma kod wynikowy?

http://atari.pl/hsc/ad.php?i=1.

10 Ostatnio edytowany przez tebe (2006-07-06 20:30:29)

nowa wersja cc65 generuje dłuższy kod i wolniejszy, aktualna długość kodu 3914b (wersja 2.11), poprzednio 3887b (wersja 2.10) , może biblioteki się rozrosły czy coś

*- TeBe/Madteam
3x Atari 130XE, SDX, CPU 65816, 2x VBXE, 2x IDE Plus rev. C

11

od pewnego czasu tworze sobie biblioteke funkcji, operacji na tablicach, petli c przepisana na asemblera, to pomaga.. mozna ukladac sobie program z 'klockow' - sprobowalem z tym programikiem i wyszlo mi ze kod wynikowy ma troszke ponad 260 bajtow a fps: 3084 co pozwala domyslac sie ze raczej dziala poprawnie - zachowane typy danych i zero optymalizacji, oczwiscie nie o to chodzi... chodzi o to ze cc65 generuje strasznie duzy kod. DLACZEGO

http://atari.pl/hsc/ad.php?i=1.

12

Bo pewnie samo printf zajmuje z 1KB.

Czy możecie wyjaśnić, Stirlitz, dlaczego wasz służbowy adres stirlitz@rsha.gov.de ma aliasa justas@gru.su?
Nie czytam PM. Proszę używać e-mail.

13

260 bajtów jak na taki program w asmie to sporo. cc65 generuje dobry kod, oczywiście jeśli włączy się optymalizację. Dużo zajmuje printf i dużo zajmuje przeparsowanie linii poleceń z uwzględnieniem megzotycznych DOSów, m.in. DOSa XL.

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

14

duzo, gadza sie, ale jak mowilem, powklejane czesci kodu linijka w linijke BEZ optymalizacji

http://atari.pl/hsc/ad.php?i=1.

15 Ostatnio edytowany przez tebe (2006-07-10 07:27:22)

ja też staram się ułatwiać sobie życie, dlatego wprowadziłem do mads-a (jeszcze nie udostępniony) automatyczne generowanie kodu dla pętli WHILE, kod wynikowy ma długość 375b, fps 1036


/* Eratosthenes Sieve benchmark */

true    = 1
false    = 0
size    = 8190
sizepl    = 8191

flags    = $8000


    org $2000

;void wait(void)
;{
; unsigned char a=PEEK(tick);
; while (PEEK(tick)==a) { ; }
;}

.proc wait
    lda:cmp:req 20
    rts
.endp


main

;int main()
;{
;    unsigned int i, prime, k, count, iter;
    .var i, prime, k, count, iter .word
    
;    wait();
    wait

    mwa #0 $13

;    printf("10 iterations\n");

;    iter = 1;
    mwa #1 iter

;    while (iter <= 10) {
p0    .while .word iter <= #10    ;0

;        count = 0;
        mwa #0 count

;        i = 0;
        mwa #0 i

;        while (i <= size) {
p1        .while .word i <= #size        ;1

;            flags[i] = true;

            lda <flags
            clc
            adc i
            sta adr
            lda >flags
            adc i+1
            sta adr+1

            lda #true
            sta $ffff
        adr:    equ *-2
        
;            i++;
            inw i
;        }
        .endw

;        i = 0;
        mwa #0 i
        
;        while (i <= size) {
p2        .while .word i <= #size        ;2

;            if (flags[i]) {

            lda <flags
            clc
            adc i
            sta adr2
            lda >flags
            adc i+1
            sta adr2+1

            lda $ffff
        adr2:    equ *-2

            beq skip

;                prime = i + i + 3;
                lda i
                clc
                adc i
                sta prime
                lda i+1
                adc i+1
                sta prime+1

                lda prime
                clc
                adc #3
                sta prime
                scc
                inc prime+1                
                
;                k = i + prime;

                lda i
                clc
                adc prime
                sta k
                lda i+1
                adc prime+1
                sta k+1

;                while (k <= size) {
p3                .while .word k <= #size        ;3

;                    flags[k] = false;

                    lda <flags
                    clc
                    adc k
                    sta adr3
                    lda >flags
                    adc k+1
                    sta adr3+1

                    lda #false
                    sta $ffff
                adr3:    equ *-2

;                    k = k + prime;

                    lda k
                    clc
                    adc prime
                    sta k
                    lda k+1
                    adc prime+1
                    sta k+1

;                }
                .endw

;                count++;
                inw count

;            }
        skip:

;            i++;
            inw i

;        }
        .endw

;        iter++;

        inw iter

;    }
    .endw
    
;    printf("\n%d primes\n", count);
    
;    i=PEEK(tick)+PEEK(tack)*256;

;    printf("\n%d fps\n", i);
    
;    return 0;
;}

    mwa $13 $600
    mwa count $602

    mva #$80 712
    jmp *


    run main
*- TeBe/Madteam
3x Atari 130XE, SDX, CPU 65816, 2x VBXE, 2x IDE Plus rev. C

16

Ten sam kod napisany w Action! osiąga 1015 fps. Rozumiem dlaczego cc65 jest wolne, ale dlaczego podobne wyniki osiąga mads? Wydaje mi się, że sito napisane w assemblerze powinno wykonywać się szybciej.

; SIEVE.ACT - ERATOSTHENES SIEVE BENCHMARK



DEFINE
  true   = "1",  
  false  = "0",
  size   = "8190",
  sizepl = "8191",
  tick   = "$14",
  tack   = "$13" 




CHAR ARRAY flags(sizepl)



PROC wait()
    
  CHAR a
  a=Peek(tick)
  WHILE  Peek(tick) = a DO OD

RETURN

PROC main()

INT
  i,j,k,
  prime,
  count,
  iter    
      
  wait()

  Poke(tick,0) 
  Poke(tack,0)   

  PrintE("10 iterations")
        
  iter = 1
  WHILE iter <= 10 
  DO
    count = 0
    i = 0
    WHILE i <= size 
    DO
     flags(i) = true
     i==+1
    OD
    i = 0 
    WHILE i <= size 
    DO
     IF flags(i)=true THEN
      prime = i + i + 3
      k = i + prime
      WHILE k <= size 
      DO
       flags(k) = false
       k = k + prime
      OD
      count==+1
     FI
    i==+1     
    OD
  iter==+1  
  OD

PrintI(count)
PrintE(" primes")
i = Peek(tick)                    
j = Peek(tack)
i=i+256*j
PrintI(i)
PrintE(" fps")

RETURN
Byl hrozný tento stát, když musel jsi se dívat, jak zakázali psát a zakázali zpívat,
a bylo jim to málo, poručili dětem modlit se jak si přálo Veličenstvo Kat.

17 Ostatnio edytowany przez tebe (2006-07-09 23:02:18)

ILR a ile masz PRIMES, bo nie mam jak sprawdzic ACTION

pozatym XXL otrzymal podobny wynik dla ASM, tak ze w asm zostało napisane toto podobnie

*- TeBe/Madteam
3x Atari 130XE, SDX, CPU 65816, 2x VBXE, 2x IDE Plus rev. C

18

Wychodzi mi 1899 pierwszych.  Oglądałem już ten kod w Action! kilka razy, żeby znaleźć ewentualny błąd, ale nic mi w oczy nie wpadło. Niech ktoś rzuci świeżym okiem, to może coś znajdzie.

Byl hrozný tento stát, když musel jsi se dívat, jak zakázali psát a zakázali zpívat,
a bylo jim to málo, poručili dětem modlit se jak si přálo Veličenstvo Kat.

19 Ostatnio edytowany przez tebe (2006-07-10 07:47:01)

jest OK, okazuje sie że podałem wynik FPS odczytując bajty odwrotnie

przepisuje bajt $13 pod $600, bajt $14 pod $601 i podałem go w kolejnosci $14$13 zamiast $13$14, przez co wynik FPS "podskoczył"

prawidłowo odczytany wynik dla MADS-a to 1036 FPS, czyli ACTION tez jest wiarygodny :) wybaczcie pomyłkę

*- TeBe/Madteam
3x Atari 130XE, SDX, CPU 65816, 2x VBXE, 2x IDE Plus rev. C

20

dla programu w CC65 trzeba dopisać jednak jeszcze po wywołaniu wait()

    asm(" lda #0");
    asm(" sta $13");
    asm(" sta $14");

teraz wynik jest lepszy, 2455 FPS

*- TeBe/Madteam
3x Atari 130XE, SDX, CPU 65816, 2x VBXE, 2x IDE Plus rev. C

21

tebe napisał/a:

ja też staram się ułatwiać sobie życie, dlatego wprowadziłem do mads-a (jeszcze nie udostępniony) automatyczne generowanie kodu dla pętli WHILE

Ta, WHILE a z drugiej strony CLC i ADC. No ale Tebe już chyba rozumie MWA. :)

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

22

hehe. czeskie bledy, tez musze sprawdzic kolejnosc odczytu :-)

@ilr: w action! nie uzywa sie peek i poke tylko adresowania zmiennych, kod jest krotki i szybszy

http://atari.pl/hsc/ad.php?i=1.

23 Ostatnio edytowany przez ilr (2006-07-10 11:12:16)

Owszem, ale zależało mi na tym, żeby kod wyglądał jak ten w C, a i szybkość w tym wypadku polepszy się może o 1 fps. Natomiast kod jest niezaprzeczalnie krótszy.

Byl hrozný tento stát, když musel jsi se dívat, jak zakázali psát a zakázali zpívat,
a bylo jim to málo, poručili dětem modlit se jak si přálo Veličenstvo Kat.

24

mozliwe, dawno juz nie grzebalem w action ale z tego co pamietam, uzywajac poke nie mozna bylo pisac przerwan dli natomiast korzystajac z zmiennych adresujacych bylo to mozliwe z czego wnosze, ze jednak musialo to byc szybsze conieco. nie pamietam dobrze ale chyba poke bylo wolniejsze wiecej jak 10 cykli a robiac jak mowie kod wyglada tak: lda #xx; sta $xxxx.

http://atari.pl/hsc/ad.php?i=1.

25

Ten jeden fps wyszedł mi na emulatorze, dlatego przypuszczam, że na oryginale będzie tak samo. Natomiast kod skrócił sie o 64 bajty. Myślę, że gdyby te peeki i poki były w pętli to narzut byłby znaczący.

Byl hrozný tento stát, když musel jsi se dívat, jak zakázali psát a zakázali zpívat,
a bylo jim to málo, poručili dětem modlit se jak si přálo Veličenstvo Kat.