atarionline.pl Języki programowania - testy - Forum Atarum

Jeśli chcesz wziąć udział w dyskusjach na forum - zaloguj się. Jeżeli nie masz loginu - poproś o członkostwo.

  • :
  • :

Vanilla 1.1.4 jest produktem Lussumo. Więcej informacji: Dokumentacja, Forum.

    • 1: CommentAuthorzbyti
    • CommentTime8 Mar 2020 zmieniony
     
    N I E A K T Y W N Y
    @robert OK, przez nieuwagę usunąłem Twoją zmianę.

    Po przywróceniu jest 178 ramek :]

    Monte-Carlo PI Zero Page MADS 2.1.0
    org $2000

    .var time .word
    .var i,b,radius,n .word = $80
    .var fac1,fac2 .byte = $e0
    .var result .word =$e0

    mwa #16129 radius
    mwa #0 i
    mwa #0 b

    wait
    mwa #0 $13

    loop #while .word i < #10000

    inw i

    lda $d20a
    and #$7f
    sta fac1
    sta fac2
    imulCL
    mwa result n

    lda $d20a
    and #$7f
    sta fac1
    sta fac2
    imulCL
    adw n result

    sbw n radius
    bcs loop
    inw b

    #end

    mva #0 n
    lda b+1
    sta fac1
    lda #4
    sta fac2
    imulCL
    mva result n+1

    lda b
    sta fac1
    lda #4
    sta fac2
    imulCL

    adw n result

    mva $14 time
    mva $13 time+1

    jsr printf
    .by 'pi %',$1e,$1e,$1e,$1e,$ff,$2c,$9b
    .by 'fps % ',$9b,0
    dta a(n)
    dta a(time)

    jmp *

    .proc wait
    lda:cmp:req $14
    rts
    .endp

    .proc imulCL
    ldy #8
    lda #0
    lsr fac1
    @L0: bcc @L1
    clc
    adc fac2
    @L1: ror @
    ror fac1
    dey
    bne @L0
    sta fac2
    rts
    .endp

    .link 'printf.obx'
    • 2: CommentAuthorrobert
    • CommentTime8 Mar 2020 zmieniony
     
    W kolejnym tescie zdaje sie brakuje
    mwa #0 $13
    za wait tak jak w tescie na PI
    albo
    mva #0 $14
    • 3: CommentAuthorzbyti
    • CommentTime8 Mar 2020 zmieniony
     
    N I E A K T Y W N Y
    @robert jakbym liczył ramki to by się wynik nie zmienił, tutaj faktycznie będzie wyższy jak wyzeruję $14.

    EDIT: tak, teraz jest identyczny jak w MadP.

    Dzięki @robert. Piszę, testuję ale coś nie mam dziś głowy do szczegółów a one w tych testach ważą na wszystkim. Dobrze, że czuwasz :]

    To jeszcze jeden test i zamykam temat. Ale Mad Pascal ostro broni swojej pozycji na polu wydajności, naprawdę jestem pod wrażeniem.
    • 4: CommentAuthorzbyti
    • CommentTime8 Mar 2020 zmieniony
     
    N I E A K T Y W N Y
    CC65 przegrywa w teście Monte-Carlo Pi ponieważ dla mnożenia dwóch liczb typu unsigned char jego kompilator wybiera procedurę:

    ; 8x16 routine with external entry points used by the 16x16 routine in mul.s
    tosmula0:
    tosumula0:
    sta ptr4
    mul8x16:jsr popptr1 ; Get left operand (Y=0 by popptr1)

    tya ; Clear byte 1
    ldy #8 ; Number of bits
    ldx ptr1+1 ; check if lhs is 8 bit only
    beq mul8x8 ; Do 8x8 multiplication if high byte zero
    mul8x16a:
    sta ptr4+1 ; Clear byte 2

    lsr ptr4 ; Get first bit into carry
    @L0: bcc @L1

    clc
    adc ptr1
    tax
    lda ptr1+1 ; hi byte of left op
    adc ptr4+1
    sta ptr4+1
    txa

    @L1: ror ptr4+1
    ror a
    ror ptr4
    dey
    bne @L0
    tax
    lda ptr4 ; Load the result
    rts

    Czy ktoś się orientuje jak na kompilatorze wymusić
    ; 8x8 multiplication routine

    mul8x8:
    lsr ptr4 ; Get first bit into carry
    @L0: bcc @L1
    clc
    adc ptr1
    @L1: ror
    ror ptr4
    dey
    bne @L0
    tax
    lda ptr4 ; Load the result
    rts ; Done

    czyli dokładnie takie samo cudo jakie jest w Mad Pascalu i napisanym przeze mnie ASM?

    Jeżeli kompilator CC65 w takiej sytuacji nie wybiera mnożenia 8x8 to w jakiej w ogóle?!
    • 5: CommentAuthortebe
    • CommentTime8 Mar 2020
     
    pętla WHILE w CC65 i MP164 wygląda inaczej niż #WHILE w MADS

    ;while

    jmp test_warunku

    while_loop
    ...
    ...
    ..

    test_warunku

    if i < 10000 then
    goto whileloop
    else
    wyjscie z petli WHILE



    w większości przypadków taka organizacja jest wydajniesza od wersji gdzie test_warunku jest na początku pętli WHILE
    • 6: CommentAuthorzbyti
    • CommentTime8 Mar 2020 zmieniony
     
    N I E A K T Y W N Y
    @tebe dzięki, postaram się zapamiętać tę informację. Rozumiem, że to rzutuje na Monte PI.

    W YoshPlus MadP, CC65 i to co napisałem w ASM dało ten sam wynik z dokładnością co do iteracji, czyli 41933.
    • 7: CommentAuthorilmenit
    • CommentTime9 Mar 2020 zmieniony
     
    @zbyti - ale w kodzie CC65 zapisujesz wynik mnożenia do "unsigned int", więc kompilator prockę wybiera poprawnie (niezależnie od tego, że tak mówi standard języka odnośnie promocji do int przy arytmetyce). To nie błąd raczej w MadPascalu? ;)

    Jeszcze dodatkowe informacje - standard języka C definiuje, że podstawowym typem do obliczeń jest 'int', który ma różną wielkość na różnych platformach, ale jest zwykle "najszybszym typem" do operacji arytmetycznych na danym procesorze. Dlatego na x86 ma 32 bity a na x64 ma 64bity.
    Przy operacjach arytmetycznych lub bitowych następuje 'promocja do int' ->link<-
    Standard języka definiuje, że 'char' jest typem znakowym (nawet niekonecznie mającym 8bitów), zaś 'int' jest do obliczeń. No i tu mamy problem :-) "C89" został zdefiniowany, kiedy na rynku już było Atari ST, Amiga 500 czy procesor 386... zastem 'int' ma minimum 16bitów. Biorąc pod uwagę "promocję do int", dowolne operacje w C na typie 'char' powinny być najpierw przerzutowane do 'int', co na 6502 znaczy koszmarną wydajność. Niektóre kompilatory 8bit dla C mają z tego powodu 'int' jako 8bitów, co jednak powoduje niekompatybilność z istniejącymi kodami. CC65 stara się rozpoznawać intencje użytkownika i zwykle gdy oczekiwany wynik operacji jest jako 8bit, operacje na typie 'char' robi bez promocji na 'int'. A czy to problem? Według mnie nie, ponieważ w time-critical kodzie mnożenie, którego wynik ma się zmieścić w zakresie 0-255 i tak bym jako lookup table.

    Niestety, nie mam teraz czasu aby sprawdzić w jaki sposób można wymusić mul8x8 w CC65 dla takiego mnożenia - w wolniejszech chwili.
    • 8: CommentAuthortebe
    • CommentTime9 Mar 2020 zmieniony
     
    MP rozszerza typ dla operacji mnożenia i innych, dla u8xu8 zakłada wynik 16b, dopiero dalej podczas optymalizacji zacznie odrzucać nadmiarowe operacje

    /*

    ;
    ; Ullrich von Bassewitz, 2009-08-17
    ;
    ; CC65 runtime: 8x8 => 16 unsigned multiplication
    ;

    */

    .proc imulCL
    ptr1 = ecx
    ptr4 = eax

    ldy #8
    lda #0

    lsr ptr4 ; Get first bit into carry
    @L0: bcc @L1
    clc
    adc ptr1
    @L1: ror @
    ror ptr4
    dey
    bne @L0
    sta ptr4+1

    rts
    .endp

    wynik zapisywany jest do eax, eax+1 (16b)

    procka w testach okazała się szybsza o kilka linii skaningowych od wcześniej stosowanej
    .proc	imulCL

    lda #$00

    LDY #$09
    CLC
    LOOP ROR @
    ROR eax
    BCC MUL2
    CLC ;DEC AUX above to remove CLC
    ADC ecx
    MUL2 DEY
    BNE LOOP

    STA eax+1

    RTS
    .endp
    • 9: CommentAuthorilmenit
    • CommentTime9 Mar 2020
     
    Co ciekawe, w dokumentacji FreePascala ->link<- jest, że na platformy 8bit miewa 8bit :)
    • 10: CommentAuthorzbyti
    • CommentTime9 Mar 2020 zmieniony
     
    N I E A K T Y W N Y
    @ilmenit dzięki za obszerne wyjaśnienie.

    Jednak z tego wnika dziwna dla mnie rzecz, procedura mnożenia 8x8 gdzie produktem jest liczba 16-bit nigdy nie zostanie przez kompilator CC65 użyta.

    Bo jeżeli miałbym produkt zapisywać w typie char bez znaku to jestem skazany na mnożenie liczb nie większych niż 16, a wtedy procedura 8x8 nie potrzebuje dwóch komórek pamięci na wynik.

    Skoro produktem 8x8 jest liczba dwubajtowa to jak najbardziej sensowne wydaje mi się to co robi MadP czyli:

    word: x = byte: n * byte: n

    Także w teście Monte Cali PI CC65 jest na ten moment bez szans.

    EDIT: aaa... @tebe zdążył napisać zanim skleiłem posta. Czyli MadP po prostu dobrze optymalizuje!
    • 11: CommentAuthorzbyti
    • CommentTime9 Mar 2020 zmieniony
     
    N I E A K T Y W N Y
    MEMO
    ---------------------------------------------------------
    To taka uwaga dla mnie a nie polemiczna.
    ---------------------------------------------------------

    Test YoshPlus. Między tym co "potrafię" w ASM a wynikami MadP i CC65 nie ma różnicy, są identyczne.

    Monte-Carlo PI. Różnica między tym co "potrafię" w ASM a MadP to 4 ramki na korzyść ASM. 178 fps Vs. 182 fps.

    Skoro nie mam ambicji pisania gier arcade to tak niewielka utrata wydajności jest nieistotna. Przy super znajomości ASM (i to nie w każdym przypadku) zyskać mogę góra 30%.

    Czytelność kodu w MadP/CC65 zazwyczaj bardzo wysoka, w ASM zależy od znajomości tematu i platformy ale przeważnie niższa, co odzwierciedla nazwa "języki wysokiego poziomu" :D

    WNIOSEK: nauczyć się podstaw ML i platformy A8 a pisać w MadP/CC65. Te języki nie są fanaberią ich twórców tylko bardzo wydajnymi narzędziami :]

    PS. No i obadać jeszcze to K65 :]
    • 12: CommentAuthorilmenit
    • CommentTime9 Mar 2020
     
    @zbyti - i Millforka ;)
    • 13: CommentAuthorzbyti
    • CommentTime9 Mar 2020 zmieniony
     
    N I E A K T Y W N Y
    @ilmenit ale jak sam się przekonałeś zgłaszając autorowi języka jakiś problem (chyba nie mieściłeś się w pamięci z tablicą) Atari jest w tej chwili wspierane rykoszetem a C64 jest targetem ;)

    Do tego nie do końca wierzę w projekty które jednocześnie chcą wspierać Z80 i 6502. No chyba, że jest wielu programistów w projekcie wyspecjalizowanych w danym CPU.

    Musiał by do niego dołączyć ktoś kto zna dobrze platformę A8.

    Czas mojego skakania po językach się już kończy, w końcu skupię się na jednym a Millfork jest jeszcze w powijakach.

    Na ten moment @tebe za każdym razem pozytywnie zaskakuje z Mad Pascalem, jego optymalizacja przy mnożeniu, czyli wybranie 8x8, to pstryczek w nos dla optymalizatora CC65 ;)

    Legendarny ;) KK też pewnie mógłby podrasować swojego K65 ale jak już ustaliliśmy wydaje się on niestały w uczuciach i raczej do projektu nie wróci. Tu trzeba podejścia @tebe ;)
    • 14: CommentAuthorilmenit
    • CommentTime9 Mar 2020
     
    Jest też KickC - ->link<- warty sprawdzenia.
    • 15: CommentAuthorzbyti
    • CommentTime9 Mar 2020 zmieniony
     
    N I E A K T Y W N Y
    KickC - fajna dokumentacja, ładnie to zorganizowane ale niech wyjdzie z bety ;)
    • 16: CommentAuthorzbyti
    • CommentTime9 Mar 2020
     
    N I E A K T Y W N Y
    Fake Sieve ma długą brodę ;)

    Byte Magazine 1981 ->link<-

    Byte Magazine 1983 ->link<-
    • 17: CommentAuthorilmenit
    • CommentTime10 Mar 2020 zmieniony
     
    @zbyti - dzięki za te artykuły. Jakoś nie wierzyłem, że tyle lat nikt tego nie sprawdził. Artykuły pozwoliły mi zrozumieć, że ten algorytm nie jest FAKE (!), ale nie było jasne co znaczą wyliczone flagi. Poniżej kod w C. A co znaczą flagi, jest w artykule ->link<- - zerknij na ramkę w prawym dolnym rogu. W skrócie - flagi mówią o tym, czy każda druga liczba zaczynając od 3 jest pierwsza :)
    #include <stdio.h>
    #include <string.h>

    #define true 1
    #define false 0
    #define size 8190
    #define sizepl 8192

    unsigned char flags[sizepl];

    unsigned char is_prime(unsigned int n)
    {
    register unsigned int i;
    for (i = 2; i <= n / 2; ++i)
    {

    // condition for non-prime
    if (n % i == 0)
    return 0;
    }
    return 1;
    }

    int main()
    {
    register unsigned int i, prime, k, count;

    memset(flags, true, sizeof(flags));
    for (i=0;i<=size;++i)
    {
    if (flags[i])
    {
    prime = i*2 + 3;
    k = i + prime;
    while (k <= size) {
    flags[k] = false;
    k += prime;
    }
    ++count;
    }
    }
    i=3; // starting from 3
    for (prime=0;prime<=size;++prime)
    {
    printf("Num %d by 'fake':%d, real:%d\n", i, (int) flags[prime], is_prime(i));
    i+=2;
    }
    inf:
    goto inf;
    return 0;
    };
    • 18: CommentAuthorzbyti
    • CommentTime10 Mar 2020 zmieniony
     
    N I E A K T Y W N Y
    Tak tylko, że ten algo zawsze występował w takiej postaci jak sam napisałeś wcześniej:

    /* Eratosthenes Sieve benchmark */

    #include <peekpoke.h>
    #include <stdio.h>
    #include <string.h>

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

    unsigned char flags[sizepl];

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

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

    wait();

    printf("10 iterations\n");

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

    for (iter = 1 ; iter <= 10; ++iter)
    {
    count = 0;
    memset(flags, true, sizeof(flags));
    for (i=0;i<=size;++i)
    {
    if (flags[i]) {
    prime = i*2 + 3;
    k = i + prime;
    while (k <= size) {
    flags[k] = false;
    k += prime;
    }
    ++count;
    }
    }
    }
    i=PEEK(0x14)+PEEK(0x13)*256;
    printf("%d primes\n", count);
    printf("%d ticks\n", i);

    asm(" jmp *");

    return 0;
    }

    W każdym przypadku gdzie użyty był ten algorytm (a wypisałem je w wątku o Action!) co powyżej kończono go wypisaniem tego co zliczono w count czyli 1899 pod etykietą primes a to nie jest poprawna ilość liczb pierwszych w zakresie od 0-8191.

    Nikt nie przeczesywał jeszcze raz tablicy tak jak Ty by podać prawidłowy wynik 1028, dlatego w postaci jakiej funkcjonował był/jest fejkiem ;)

    Fajnie, że zechciało Ci się jednak przyjrzeć jaki był oryginalny zamysł autora kodu, który stał się podwaliną pod benchmarki :]
    • 19: CommentAuthorilmenit
    • CommentTime10 Mar 2020 zmieniony
     
    ja go tylko poprawiłem wydajnościowo z tego, co kiedyś napisał Tebe na AtariAge jako porównanie z MadPascalem, o tu ->link<- ;)
    • 20: CommentAuthorzbyti
    • CommentTime10 Mar 2020 zmieniony
     
    N I E A K T Y W N Y
    @ilmenit sorry bo wyglądało jak przytyk, wiem, że to była konwersja wprost by pomiar był adekwatny, mogłem wkleić ten z Action ale chciałem też w C ;)

    I tak podziwiam, że chciało Cię w to zagłębić, ja jak w BYTE zobaczyłem znajomy kod to nie wgłębiałem się w jego istotę.

    Jednak osoby powielające przez lata ten benchmarak chyba zatraciły wiedzę z tej ramki, co nie?
    • 21: CommentAuthorilmenit
    • CommentTime10 Mar 2020 zmieniony
     
    u niektórych się pewnie straciło (kody Madsa i MP), ale czy rzeczywiście?
    Na Wikipedii opis tego jest ->link<- jest napisane dokładnie, co to robi "The provided implementation calculated odd primes only, so the 8191 element array actually represented primes less than 16385.".
    EDIT: Już widzę, kod wzięty właśnie z Wikipedii, gdzie jest napisane powyżej co robi.
    • 22: CommentAuthorzbyti
    • CommentTime10 Mar 2020
     
    N I E A K T Y W N Y
    Ha! No to w ogóle zmienia postać rzeczy! :D

    Polecam jednak kod do SIEVE brać z tego miejsca ->link<-
    • 23: CommentAuthorilmenit
    • CommentTime10 Mar 2020
     
    Ale w tym miejscu nawet kody dla FreePascala mówią, że to wylicza "odd numbers" ;)
    ->link<-
    • 24: CommentAuthorzbyti
    • CommentTime10 Mar 2020 zmieniony
     
    N I E A K T Y W N Y
    No to ja pierwotnie nie zrozumiałem zamysłu tego kodu, ale czy tylko ja? ;)

    Za to ten z Atalan rozumiem i oddaje on to czego należy się po nim spodziewać :]
    • 25: CommentAuthortebe
    • CommentTime10 Mar 2020
     
    i tak Ilmenit uratował benchmark ;)
    • 26: CommentAuthorzbyti
    • CommentTime10 Mar 2020
     
    N I E A K T Y W N Y
    :D
    • 27: CommentAuthorzbyti
    • CommentTime10 Mar 2020 zmieniony
     
    N I E A K T Y W N Y
    Dla nie mających czasu dokładnie śledzić co tu się wydarzyło.

    Reasumując:

    To co robi kod który nazwałem FAKE to coś na wzór poprawki wniesionej przez @emka (opuszczał parzyste) do tego co nazwałem REAL :D

    1899 to prawidłowa liczba liczb pierwszych tylko z ~2x większego zakresu niż 8191.

    Jest to bardzo efektywny algorytm, szybszy od tego, który nazwałem REAL.

    Ergo: jak się komentuje kod którego się nie rozumie to tak jest ;)

    Pokrzepiam się myślą, że chyba nie tylko ja ;) Bo chwaliłem się tym niepoprawnym wnioskiem w wielu miejscach a dopiero @ilmenit to dziś sprostował :]

    @ilmenit popraw mnie jeżeli coś pokręciłem :]
    • 28: CommentAuthorzbyti
    • CommentTime10 Mar 2020 zmieniony
     
    N I E A K T Y W N Y
    // Eratosthenes Sieve Benchmark

    uses crt;

    {$define FAST}

    const
    size = 16380;
    sqr_count = 128;

    var
    flags: array [0..size] of boolean;
    rtClock: byte absolute $14;

    {$ifdef FAST}
    n: word absolute $e0;
    k: word absolute $e2;
    count: word absolute $e6;
    {$else}
    n, k, count: word;
    {$endif}

    begin
    writeln('Mad Pascal');
    writeln('Eratosthenes Sieve Benchmark');

    rtClock := 0;
    fillchar(flags, sizeof(flags), true);
    for n := 2 to sqr_count do begin
    if flags[n] then begin
    k := n shl 1;
    while k <= size do begin
    flags[k] := false;
    Inc(k,n);
    end;
    end;
    end;
    writeln(rtClock, ' ticks');

    count :=0;
    for n := 2 to size do begin
    if flags[n] then Inc(count);
    end;

    writeln(count, ' primes');
    repeat until keypressed;
    end.

    Wolniej o 20 ramek od oryginału z BYTE.
    • 29: CommentAuthorzbyti
    • CommentTime22 Mar 2020 zmieniony
     
    N I E A K T Y W N Y
    O proszę, film z przed tygodnia, czyli jakiś tydzień po tym jak się zainteresowałem PI.



    Great minds thinks alike ;)
    • 30: CommentAuthorzbyti
    • CommentTime22 Mar 2020 zmieniony
     
    N I E A K T Y W N Y
    Na początku wcześniej zamieszczonego filmu o wyznaczaniu PI widać jak C64 wylicza tę wartość dla zadanej ilości cyfr po przecinku.

    Jeżeli komuś nie imponuje szybkość 8-bit to przyklejam cytat z 2 rozdziału książki którą właśnie czytam Steward Ian - Krótka historia wielkich umysłów.

    Co prawda inny algorytm ale to co wypluwa z siebie w sekundę 6502 kiedyś wprawnemu człowiekowi zajmowało dzień ;)

    W swoim komentarzu do Jiuzhang Liu Hui wskazał, że tradycyjna zasada „π = 3” jest
    błędna: zamiast długości okręgu daje ona obwód wpisanego weń sześciokąta, który jest
    w widoczny sposób mniejszy. Następnie obliczył dokładniejszą wartość długości okręgu (i,
    domyślnie, wartość π). W istocie poszedł dalej, opisując metodę obliczeniową pozwalającą
    oszacować wartość π z dowolną dokładnością.

    Jego podejście było podobne do sposobu Archimedesa: przybliżanie koła za pomocą wpisanych w nie wielokątów foremnych o 6, 12, 24, 48, 96... bokach. Stosując metodę wyczerpywania, Archimedes wykorzystał ciąg
    wielokątów wpisanych w koło i drugi ciąg wielokątów opisanych na kole. Liu Hui posłużył
    się tylko ciągiem wielokątów wpisanych w koło, jednak na zakończenie obliczeń zastosował
    dowód geometryczny, nakładając na prawdziwą wartość π ograniczenie górne i dolne. Taka
    metoda prowadzi do wyznaczenia wartości π z dowolną dokładnością, bez konieczności
    posługiwania się czymkolwiek trudniejszym niż pierwiastki kwadratowe. Obliczenia można
    prowadzić w sposób systematyczny – metoda jest mozolna, ale stopniem komplikacji nie przewyższa długiego mnożenia. Wprawny arytmetyk może uzyskać dziesięć cyfr
    rozwinięcia dziesiętnego liczby π w ciągu jednego dnia.


    Później, około roku 469 n.e., Tsu Ch’ung Chih udoskonalił obliczenia, wykazując, że
    3,1415926 < π < 3,1415927.

    Liu Hui
    Działalność: Cao Wei, Chiny, trzeci wiek n.e.
    • 31:
       
      CommentAuthorKaz
    • CommentTime23 Mar 2020
     
    Offtop, ale to dla podbicia powyższego, ciekawego wątku :) - porównanie współczesnych najpopularniejszych języków programowania w czasie.

    • 32: CommentAuthorzbyti
    • CommentTime23 Mar 2020 zmieniony
     
    N I E A K T Y W N Y
    Ha! Lepsze by było jakby pokazali ile płacili na przestrzenie lat za programowanie w danym języku.

    PHP-owcy długo byli najtańsi ale w 2016 już seniorzy PHP mieli niezły szmal. A teraz chyba poprzenosili się na inne języki.

    10-12 lat temu za JAVE płacili czystym złotem a teraz to nie wiem ;)

    Obecne to...?! Scala, Go, języki oparte o node.js?

    Z C#, F# nigdy nie miałam nic wspólnego to nie wiem.

    W Pythonie ktoś w Polsce zarabia? Zawsze jawił mi się jako język narzędziowy, taki lepszy bash ;)
    • 33: CommentAuthorCyprian
    • CommentTime15 Apr 2020 zmieniony
     
    Hej,
    w załaczniku mój test procesora XL vs C64.
    Rzućcie okiem czy jest ok, a może czegoś brakuje?

    Jakby co to prawie 30 lat nie pisałem w 6502. Do tej pory mam oryginalną dyskietkę QuickAssembler.

    --edycja---
    zapomniałem dopisać że czas mierzę w Audiacity. Program puszcza pik na początku i końcu testu.
    • 34: CommentAuthorCyprian
    • CommentTime15 Apr 2020
     
    i jeszcze grafika poglądowa
    • 35: CommentAuthorzbyti
    • CommentTime15 Apr 2020
     
    N I E A K T Y W N Y
    @Cyprian dzięki! Chętnie obadam po dzisiejszym KWASie ;)
    • 36:
       
      CommentAuthorKaz
    • CommentTime16 Apr 2020
     
    Cyprian - temat jest ciekawy i warty założenia osobnego wątku. W dziale "Ciekawostki" takie tematy za szybko są przysłaniane kolejnymi.
    • 37: CommentAuthorCyprian
    • CommentTime16 Apr 2020
     
    dzięki
    • 38: CommentAuthorzbyti
    • CommentTime16 Apr 2020 zmieniony
     
    N I E A K T Y W N Y
    @Kaz to nie jest wątek "Ciekawostki" tylko wątek testom przeznaczony, tyle że językom/kompilatorom. Ale testy wydajności platform też mile widziane :]
    • 39:
       
      CommentAuthorKaz
    • CommentTime16 Apr 2020
     
    O kurcze - faktycznie! Otworzyłem kilka wątków i widocznie pomyliłem okienko :D. To usuwam nadmiarowy wątek, bo niepotrzebny. Tu będzie ok!
    • 40:
       
      CommentAuthorKaz
    • CommentTime16 Apr 2020
     
    To przekleję tylko pytanie od kosa0:

    kosa0:

    W zwiazku ze sie nieznam to sie wypowiem :-)

    Czy takie testy mozna przeprowadzic na emulatorach ? czy nie zafalszuja one wynikow ?
    • 41: CommentAuthorzbyti
    • CommentTime16 Apr 2020
     
    N I E A K T Y W N Y
    Zależy od "dokładności" emulatora.

    Jak już iść w tym kierunku to @Cyprian do testu odpalił nie tę wersję VICE. O ile pamiętam tam jest jakaś biorąca więcej CPU od tej którą używa się na co dzień bo ma większą "dokładność" emulacji C64.

    Generalnie można takie testy przeprowadzać na emulatorach - w końcu w teorii powinny być softwarowym odpowiednikiem realnego sprzętu.
    • 42: CommentAuthorkosa0
    • CommentTime16 Apr 2020
     
    Moje pytanie bardzij jest z kategorii

    czy testujemy emulator :-) czy procesor :-).

    Zgodze sie ze ze powinny byc odpowiednikiem sprzetu.

    NIe wiem nic o tym emulatorze c64 jak jest napisany

    Ciekawi mnie czy wyniki odpalone na czystm cpu beda takie same

    Dodatkow zaciekawilo mnie na ile procesory atari c64 byly dokladne wykonane- czy wszytkie mialy dokladnie taka sama czestotliwosc czy byly jakies wachania +/- 1%
    • 43: CommentAuthorzbyti
    • CommentTime16 Apr 2020
     
    N I E A K T Y W N Y
    Nic prostszego jak uruchomić kod testów jakie pisałem na emulatorze (te z synchronizacją zegara z ramką) na emulatorze i na Real Atari.
    • 44: CommentAuthorkosa0
    • CommentTime16 Apr 2020
     
    Tak tutaj mozna to przetestowac

    na emulatorze i na kliku stockowych 65/130

    To dla Atari

    Trzeba by bylo jeszcze odpalic jakies testy na C64
    • 45: CommentAuthorzbyti
    • CommentTime16 Apr 2020 zmieniony
     
    N I E A K T Y W N Y
    Napisałem Monte Carlo PI na A8 i na C64, więc proszę bardzo.

    Chociaż to nie jest miarodajne bo if-y zależą od generatora liczb pseudolosowych ale możesz kod zmodyfikować tak by zawsze działało to tak samo.
    • 46: CommentAuthorCyprian
    • CommentTime16 Apr 2020
     
    Dla uściślenia, test mierzy wpływ różnych koncepcji dostępu do pamięci na procesor.


    @kosa0, dobre pytanie. Teoretycznie emulatory powinny być docyklowane. Niestety nie mam C64, więc nie jestem w stanie sprawdzić na realnym sprzęcie.

    Czas wykonania na najnowszym WinVice jest taki sam jak na starszej wersji.
    Niestety nowa wersja mocno zamula mi system. Dużo bardziej niż inne docyklowane emulatory Hatari/Steem/Altirra czy WinUAE.

    Okazuje się że generowanie piku działa na ustawieniu "6581 (ReSID)" a dla "8580 (ReSID)" już nie. Jest on kluczowy dla pomiaru.
    • 47: CommentAuthorzbyti
    • CommentTime16 Apr 2020 zmieniony
     
    N I E A K T Y W N Y
    @Cyprian użyłeś x64sc.exe? Bo to ten ma większą zgodność. Nie śledzą jak ten emulator się rozwija na Windows, ale kiedyś to była osobna kompilacja, bardziej wierna ale zabierająca więcej CPU.

    x64 is the continuation of the old x64, and x64sc is the new (slower, but more accurate) emulator.

    Może już teraz nie ma x64 na Windows?
    • 48: CommentAuthorCyprian
    • CommentTime16 Apr 2020
     
    mam x64sc.exe wersję GTK3VICE-3.4-win64-r37296
    Czy to jest ok?
    • 49: CommentAuthorzbyti
    • CommentTime16 Apr 2020 zmieniony
     
    N I E A K T Y W N Y
    @Cyprian tak, sprawdziłem, nie ma już rozwijanego x64 jest już tylko x64sc a on faktycznie ma większe wymagania niż emu Amigi ;)

    A... Gratuluję udanego powrotu po 30 latach do programowania na 6502! :]
    • 50: CommentAuthorCyprian
    • CommentTime16 Apr 2020
     
    poprawiłem beep, teraz działa też z SID 8580