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 20:03 zmieniony
       
      @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 21:03 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 21:03 zmieniony
       
      @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 22:03 zmieniony
       
      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 23:03
       
      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 23:03 zmieniony
       
      @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 08:03 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 10:03 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 10:03
       
      Co ciekawe, w dokumentacji FreePascala ->link<- jest, że na platformy 8bit miewa 8bit :)
      • 10: CommentAuthorzbyti
      • CommentTime9 Mar 2020 10:03 zmieniony
       
      @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 12:03 zmieniony
       
      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 13:03
       
      @zbyti - i Millforka ;)
      • 13: CommentAuthorzbyti
      • CommentTime9 Mar 2020 13:03 zmieniony
       
      @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 13:03
       
      Jest też KickC - ->link<- warty sprawdzenia.
      • 15: CommentAuthorzbyti
      • CommentTime9 Mar 2020 14:03 zmieniony
       
      KickC - fajna dokumentacja, ładnie to zorganizowane ale niech wyjdzie z bety ;)
      • 16: CommentAuthorzbyti
      • CommentTime9 Mar 2020 22:03
       
      Fake Sieve ma długą brodę ;)

      Byte Magazine 1981 ->link<-

      Byte Magazine 1983 ->link<-
      • 17: CommentAuthorilmenit
      • CommentTime10 Mar 2020 10:03 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 12:03 zmieniony
       
      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 12:03 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 12:03 zmieniony
       
      @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 13:03 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 13:03
       
      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 13:03
       
      Ale w tym miejscu nawet kody dla FreePascala mówią, że to wylicza "odd numbers" ;)
      ->link<-
      • 24: CommentAuthorzbyti
      • CommentTime10 Mar 2020 13:03 zmieniony
       
      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 14:03
       
      i tak Ilmenit uratował benchmark ;)
      • 26: CommentAuthorzbyti
      • CommentTime10 Mar 2020 14:03
       
      :D
      • 27: CommentAuthorzbyti
      • CommentTime10 Mar 2020 14:03 zmieniony
       
      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 16:03 zmieniony
       
      // 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 12:03 zmieniony
       
      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 12:03 zmieniony
       
      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 11:03
       
      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 12:03 zmieniony
       
      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 20:04 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 20:04
       
      i jeszcze grafika poglądowa
      • 35: CommentAuthorzbyti
      • CommentTime15 Apr 2020 20:04
       
      @Cyprian dzięki! Chętnie obadam po dzisiejszym KWASie ;)
      • 36:
         
        CommentAuthorKaz
      • CommentTime16 Apr 2020 08:04
       
      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 10:04
       
      dzięki
      • 38: CommentAuthorzbyti
      • CommentTime16 Apr 2020 10:04 zmieniony
       
      @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 10:04
       
      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 10:04
       
      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 10:04
       
      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.
    1.  
      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 10:04
       
      Nic prostszego jak uruchomić kod testów jakie pisałem na emulatorze (te z synchronizacją zegara z ramką) na emulatorze i na Real Atari.
    2.  
      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 11:04 zmieniony
       
      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 11:04
       
      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 11:04 zmieniony
       
      @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 12:04
       
      mam x64sc.exe wersję GTK3VICE-3.4-win64-r37296
      Czy to jest ok?
      • 49: CommentAuthorzbyti
      • CommentTime16 Apr 2020 12:04 zmieniony
       
      @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 17:04
       
      poprawiłem beep, teraz działa też z SID 8580