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

• Zapomniane hasło?
• Poproś o członkostwo

1. • 1: CommentAuthorurborg
   • CommentTime3 Jul 2010 14:07 zmieniony

    
   Tak się właśnie zastanawiłem o jaki rząd wielkości procesor w Atari ST był szybszy od tego w małym Atari. Jak zerknąłem do Wikipedii to na początku się nieco zdziwiłem. Tabela w Wikipedii mówi, że IPS czyli liczba instrukcji na sekundę to odpowiednio 0.5 MIPSów dla 6502 1MHz, zaś dla M68000 8MHz to zaledwie 1 MIPS. to by znaczyło że Atarowski procesor 1,77MHz niemalże dorównuje STekowskiej Motoroli. Oczywiście nie jest to prawdą bo liczy się nie tylko ilość instrukcji, ale i jakość. M68000 to CISC i to 16-bitowy więc jedną instrukcją może zrobić to na co 6502 potrzebuje kilku. Co więcej domyślam się że ten wynik 6502 może być wynikiem szybkich operacji na stronie zerowej, co jak wiadomo wiąże się z pewnymi ograniczeniami. Zatem pytanie jak mniej więcej ma się do siebie wydajność tych dwóch procków. Wiem, że nie da się tego porównać wprost, ale tak z ciekawości chciałbym chociaż móc oszacować rząd wielkości.
   
   Tutaj link do Wikipedii:
   ->link<-
2. • 2: CommentAuthorjury
   • CommentTime3 Jul 2010 16:07

    
   nie bardzo wyznaję się w temacie :) ale jakiś czas temu trafiłem na podobny dylemant na youtube'ie:
   
   

   
   
   nie skomentuję tego bo się nie znam :D
3. • 3: CommentAuthor0xF
   • CommentTime3 Jul 2010 17:07

    
   Lepiej zrobić konkretny benchmark. Np. skopiowanie 256 bajtów. Na 6502 3585 cykli:
   

   ldy #0
    mva:rne $8000,y $9000,y+
   

   
   Teraz nie ktoś to napisze na 68k i policzy cykle.
4. • 4: CommentAuthoras
   • CommentTime3 Jul 2010 18:07

    
   W jakiejś gazecie było porównanie prędkości XL 6502 z portfolio - intel @4.9MHz. Test to przekręcenie licznika 24 bitowego. 6502 okazał się szybszy.
5. • 5: CommentAuthor0xF
   • CommentTime3 Jul 2010 19:07

    
   Klasyka. 68k z rejestrem 32-bit by nie przebił.
6. • 6: CommentAuthorxxl
   • CommentTime3 Jul 2010 20:07

    
   z tego co pamietam:
   _go move.l d0,(a1)+
   cmpa.l a0,a1
   bcs _go
   w a0 mamy stop a w a1 start adresu wypelniania wartoscia w d0
   rozkaz zapisuje na raz 4 bajty (to nie jest optymalny program :-)
   
   a swoja droga takie testy nie maja sensu, spojrzcie na to z perspektywy sprzetu w ktorym taki proc pracuje a wtedy okaze sie ze program dla 6502 bedzie dlugi i nudny.
7. • 7: CommentAuthormgah
   • CommentTime4 Jul 2010 00:07

    
   0,5 MIPSa dla 6502 przy 1MHz to bardzo optymistyczne założenie ponieważ jest to prawdziwe tylko dla instrukcji które wykonują się w dwóch cyklach, a czas wykonania instrukcji 6502 to 2 do 7 cykli, więc przy 7 cyklach na instrukcję to zaledwie 0,14 MIPSa. Dla 6502 należało by przyjąć średnią wartość 0,3 MIPSa dla 1MHz. Z kolei 68000 niektóre instrukcje wykonuje w 4 cyklach co dla 8MHz dało by 2 MIPSy, nie wspominając o rozkazie dzielenia ze znakiem który zjada już 158 cykli. Reasumując 6502 0,3 MIPSa, 68000 1 MIPS. A biorąc pod uwagę efektywność instrukcji 68000 w pętlach i obliczeniach wydaje mi się, że można przyjąć, że 68000 jest około 20 razy szybszy w praktycznym zastosowaniu.
8. • 8: CommentAuthor0xF
   • CommentTime5 Jul 2010 10:07

    
   xxl: Wygląda mi to na memset, a miało być memcpy. No i ile to cykli? Co rozumiesz przez "nudny program" ? Porównujemy wydajność procesorów, a nie ich rozrywkowość.
   
   mgah: Twierdzenie, że instrukcje 6502 trwają średnio ok. 3 cykle jest jak najbardziej słuszne. Natomiast nie rozumiem skąd wziąłeś "około 20 razy".
9. • 9:
      
     CommentAuthorKaz
   • CommentTime5 Jul 2010 11:07 zmieniony

    
   Ten gosc, ktory zrobil ten filmik zrobil tez inny filmik o tym, jaka konsole zaprojektowalby w latach 80/90-tych:
   
   ->link<-
   
   Na CPU wybralby Hitachi 6309 5MHz, bo ponoc jest 2-3 razy efektywniejsze w liczbie cykli niz Motorola.
   
   6309 opiera sie na Motoroli 6809, ktora jest nastepca 6800 Motoroli i MOS 6502:
   
   ->link<-
   ->link<-
10. • 10: CommentAuthorxxl
    • CommentTime5 Jul 2010 11:07

     
    a fakt, no to prosciej:
    _go move.l (a0)+, (a1)+
    dbra d0,_go
    w d0 jest licznik. tak samo kopiowanie po 4 bajty prosty i przyjemny, tez nie optymalny i nie wiem ile to cykli. gdybys nie uzywal pseudorozkazow dla 6502 to zobaczsz co to znaczy dlugi i nudny program (procek ma malo rejestrow i zeby napisac wiekszy program trzeba 'sie opisac'). poza tym jak widze 'program testowy' to odrazu mozna sie kapnac pod jakiego proca byl pisany ;-) poza tym 680xx ma bardzo duzo rejestrow podzielonych na adresowe i danych czesto nawet nie trzeba komentarzy zeby mozna bylo czytac takie programy co sie nie zdaza zbyt czesto dla programoiw ktore musza dzialac na 3 rejestrach z czego jeszcze tylko jeden jest ogolnego przeznaczenia. juz 6809 jest lepszy pod tym wzgledem od 6502 tylko nie wiem jak u nich z szybkoscia...
    owszem 6502 jest osmiobitowy i takim go kochamy ale rzeczywisci nie zakrzywimy :-) 68000 jest wygodniejszy i ogolnie lepszy, ale zeby tez ktos tu sie nie pienil to TAK 6502 SZYBCIEJ ZALADUJE AKUMULATOR i w tym sensie jest szybszy ;-)
11. • 11: CommentAuthorxxl
    • CommentTime9 Jul 2010 21:07

     
    6502:
    _go lda adres1,y (4)
    sta adres2,y (4)
    iny (2)
    bne _go (3)
    
    256 * 13 = 3328
    
    68000:
    _go move.l (a0)+, (a1)+ (20)
    dbra d0,_go (10)
    
    64 * 30 = 1920
    
    niestety dla nas 6502 nie jest tu szybszy ale niech to ktos zweryfikuje.
    
    jeszcze jedna sprawa gdyby to mial byc 'zyciowy' przyklad to niestety roznica byla by jeszcze wieksza na korzysc 68000
12. • 12: CommentAuthorKonop
    • CommentTime10 Jul 2010 00:07

     
    Właściwsze w powyższym kodzie źródłowym byłoby dbf zamiast dbra, choć - rzecz jasna - nie zmienia sytuacji pod względem merytorycznym.
    
    W celu zachowania parametryzacji powinno napisać się taki kod:
    
    6502:
    ...
    _go lda (src),y (5+)
    sta (dst),y (6)
    iny (2)
    bne _go (3+)
    ...
    
    W przypadku chęci osiągnięcia najszybszego możliwego kopiowania mielibyśmy tak:
    
    lda (src),y (5+)
    sta (dst),y (6)
    iny 2
    
    lda (src),y (5+)
    sta (dst),y (6)
    iny 2
    
    ...
    
    czyli 13(+1) cykli na bajt.
    
    W przypadku MC60000:
    
    move.l (a0)+, (a1)+ (20)
    move.l (a0)+, (a1)+ (20)
    ...
    
    czyli 5 cykli na bajt, zamiast 7.5 poprzednio.
    
    Pominąłem koszt inicjacji pętli oraz dodatkowej kontroli skoków/testowania warunków wyjścia.
13. • 13: CommentAuthortebe
    • CommentTime10 Jul 2010 00:07

     
    n/w kod trwa 3585 cykli (tak jak Fox już napisał) a nie 3328 jak XXL sugeruje
    
    ldy #0
    _go lda adres1,y
    sta adres2,y
    iny
    bne _go
    
    
    natomiast ten n/w kod trwa 4117 cykli
    
    main mwa #$2000 src
    mwa #$4000 dst
    
    ldy #0
    
    _go lda (src),y
    sta (dst),y
    iny
    bne _go
    
    
    a ten n/w kod trwa 4245 cykli
    
    main mwa #$2080 src
    mwa #$4080 dst
    
    ldy #0
    
    _go lda (src),y
    sta (dst),y
    iny
    bne _go
14. • 14: CommentAuthorxxl
    • CommentTime10 Jul 2010 09:07

     
    zgadza sie, zle policzylem cykle dla 6502, teraz roznica na korzysc 68000 jest jeszcze wieksza.
15. • 15: CommentAuthorrudla
    • CommentTime10 Jul 2010 09:07

     
    MC68000 can access words(.w) and longs(.l) only on even adresses.
    So the code would have to use .b, if there was a possibility that the address will be even.
    
    However, this example, being trivial, proves nothing. Let's copy 256 bytes, or just 200 bytes from computed adress or basically ANY other change to the task.
    
    More instructions will be necesary on 6502 while the 68000 code will remain the same.
16. • 16: CommentAuthorKonop
    • CommentTime10 Jul 2010 14:07

     
    tebe: Uwzględnij fakt, że skok może zająć o jeden cykl więcej, gdy przekroczy granicę strony.
    
    6502:
    lda (src),y (5+1)
    sta (dst),y (6)
    iny (2)
    
    lda (src),y (5+1)
    sta (dst),y (6)
    iny (2)
    
    ...
    
    68000:
    move.b (a0)+, (a1)+ (12)
    move.b (a0)+, (a1)+ (12)
    ...
    
    Zatem po korekcie mamy 12 cykli na bajt dla MC68000 oraz 13(+1) dla 6502. Rolka niewiele szybsza od 6502.
    
    rudla: Those 6502 instructions you are mentioning for controlling the overall process does not affect the final efficiency calculation much.
17. • 17: CommentAuthortebe
    • CommentTime10 Jul 2010 16:07

     
    przekraczanie strony zostało uwzględnione - dwa ostatnie przykłady
18. • 18: CommentAuthorKonop
    • CommentTime10 Jul 2010 19:07

     
    _go lda (src),y (5)
    sta (dst),y (6)
    iny (2)
    bne _go (4)
    
    (17*255 = 4335) > 4117, więc nie zostało.
19. • 19: CommentAuthorxxl
    • CommentTime10 Jul 2010 19:07

     
    a nie jest tak, ze jesli z scr wskazyje jedna strone pmieci a po dodaniu indeksu pobieramy z innej strony to rozkaz ma jeden cykl wiecej? nie wiem pytam.
    
    czyli lda (scr),y (6) w skranym przypadku:
    18 * 255 + 17 = 4607 ?
20. • 20: CommentAuthor0xF
    • CommentTime10 Jul 2010 21:07

     

    Konop:

    W celu zachowania parametryzacji powinno napisać się taki kod

    
    Założyłem, że kod jest w RAM, więc adresy absolutne można zmodyfikować.
    
    Chodziło mi o zgrubne porównanie wydajności 6502 z 68k, lepsze niż MIPS, z których ktoś mógłby wywnioskować, że wydajność ST i XL jest zbliżona. W podanym przykładzie ST jest ok. 9 razy szybszy.
21. • 21: CommentAuthorKonop
    • CommentTime10 Jul 2010 22:07

     
    xxl: Tak, w ogólności należy dodać cykl, ale we fragmencie Tebe'go, do którego się odnosiłem, to nie wystąpi, gdyż wskaźnik src został ustawiony ma $XX00 (main mwa #$2000 src). W niektórych przykładach pisałem (5+). Ten plus odnosi się właśnie do tej sytuacji, o której piszesz.
    
    0xF: Ok. Ciekawe jest także porównanie architektury przy tym samym zegarze. Do tego należałoby wytypować jeszcze parę innych testów, przy różnym rozmiarze argumentów, oraz różne funkcje, np. memset, accumulate, itp.
22. • 22: CommentAuthorrudla
    • CommentTime11 Jul 2010 21:07 zmieniony

     
    If we are willing to ignore complexity and just count the most efficient cycles, we should look at
    
    movem.l instruction:
    
    movem.l (a0)+, d0-d7/a2-a6
    movem.l d0-d7/a2-a6, (a1)+
    
    copies 52 bytes at once 2 * (12 + 8 * 13) = 232 cycles
    
    This means 4.4 cycles per byte.
23. • 23: CommentAuthor0xF
    • CommentTime11 Jul 2010 22:07

     
    Counting cycles instead of watching World Cup Final, wow. :)
24. • 24: CommentAuthorKonop
    • CommentTime11 Jul 2010 23:07

     
    rudla: There is no post-increment addressing mode for register to memory transfers.
25. • 25:
       
      CommentAuthorKaz
    • CommentTime12 Jul 2010 12:07

     
    Fox - he knew results of World Cup thanks to octopus Paul, so counting cycles was more interesting :D
26. • 26: CommentAuthorrudla
    • CommentTime12 Jul 2010 17:07

     
    konop: You are right, I forgot. I has benn some time since I programmed 68000 :-) We would have to use
    
    movem.l d0-d7/a2-a6, (a1)
    lea 52(a1), a1
    
    And there would +8 cycles.
    
    So 240 cycles. Cca. 4.6 cycles per byte.
27. • 27:
       
      CommentAuthorKaz
    • CommentTime2 Jan 2020 11:01 zmieniony

     
    W tym przypadku (pismo "Moje Mikro" 10/1984) do oceny szybkości kompów mamy prosty algorytm w Basicu i zestawienie czasów i dokładności jego liczenia na wielu różnych platformach. Na szczycie ówczesny król czyli Cray-1. A niżej między innymi:
    
    Atari 800, 1200 (MBasic) 1:35 / 0.150879 / 2.1
    Commodore VIC20 1:48 / 0.0010414235 / 23.7
    Commodore 64 1:53 / 0.0010414235 / 8.9
    Atari 2600 Graduate 2:15 / 0.000224679700 / 7.9
    Atari 800 (fastchip) 2:23 / 0.006875 / 7.0
    Atari 1200 XL 6:45 / .013959 / 5.2
    Atari 400/800 6:48 / 0.012959 / 22.8
    
    U mnie wyszło tak:

    • atari_emulator_65xe.png
      
      
      
      
    • MM_84_10_035.jpg
      
      
      
      
28. • 28: CommentAuthorzbyti
    • CommentTime2 Jan 2020 12:01

     
    @Kaz takie testy to raczej mierzą wydajność danej implementacji BASICa niż szybkość CPU.
29. • 29:
       
      CommentAuthorKaz
    • CommentTime2 Jan 2020 12:01 zmieniony

     
    Ja to wiem. Ale takie właśnie testy uznawane były w swoim czasie za poważne testy komputerów :). W "Bajtku" też mieliśmy takie serie artykułów porównujących różne implementacje Basica i sugerowanie, że to szybkość komputera. A niektóre produkty były wręcz zachwalane przez szybkość Basica, który bywał podstawowym narzędziem pracy z kompem, np. w instrukcji do Basic XE:
    
    

    Nowe procedury operacji zmiennopozycyjnych w połączeniu z
    instrukcją FAST zapewniają bardzo szybkie wykonanie programu.
    BASIC XE jest ok. dwa do sześciu razy szybszy niż standardowy
    Atari BASIC, ponad dwukrotnie szybszy niż BASIC dla Commodore
    64 i dla IBM PC Junior.

    
    
    Tutaj jeszcze nieco inne ujęcie wydajności i wartości sprzętów, trochę uznaniowa, ale warto wiedzieć jak to widziano. No i takiego wykresu nie widziałem wcześniej:

    • MMS_84_06_034.jpg
      
      
      
      
    • MMS_84_06_035.jpg