Niezalogowany (Zaloguj się)

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.

szybkość 6502 vs m68000

Od 1 do 29 z 29

- 1: CommentAuthorurborg
- CommentTime3 Jul 2010 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: CommentAuthorjury
- CommentTime3 Jul 2010
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: CommentAuthor0xF
- CommentTime3 Jul 2010
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: CommentAuthoras
- CommentTime3 Jul 2010
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: CommentAuthor0xF
- CommentTime3 Jul 2010
Klasyka. 68k z rejestrem 32-bit by nie przebił.
- 6: CommentAuthorxxl
- CommentTime3 Jul 2010
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: CommentAuthormgah
- CommentTime4 Jul 2010
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: CommentAuthor0xF
- CommentTime5 Jul 2010
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:
  
  CommentAuthorKaz
- CommentTime5 Jul 2010 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: CommentAuthorxxl
- CommentTime5 Jul 2010
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: CommentAuthorxxl
- CommentTime9 Jul 2010
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: CommentAuthorKonop
- CommentTime10 Jul 2010
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: CommentAuthortebe
- CommentTime10 Jul 2010
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: CommentAuthorxxl
- CommentTime10 Jul 2010
zgadza sie, zle policzylem cykle dla 6502, teraz roznica na korzysc 68000 jest jeszcze wieksza.
- 15: CommentAuthorrudla
- CommentTime10 Jul 2010
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: CommentAuthorKonop
- CommentTime10 Jul 2010
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: CommentAuthortebe
- CommentTime10 Jul 2010
przekraczanie strony zostało uwzględnione - dwa ostatnie przykłady
- 18: CommentAuthorKonop
- CommentTime10 Jul 2010
_go lda (src),y (5)
sta (dst),y (6)
iny (2)
bne _go (4)

(17*255 = 4335) > 4117, więc nie zostało.
- 19: CommentAuthorxxl
- CommentTime10 Jul 2010
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: CommentAuthor0xF
- CommentTime10 Jul 2010
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: CommentAuthorKonop
- CommentTime10 Jul 2010
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: CommentAuthorrudla
- CommentTime11 Jul 2010 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: CommentAuthor0xF
- CommentTime11 Jul 2010
Counting cycles instead of watching World Cup Final, wow. :)
- 24: CommentAuthorKonop
- CommentTime11 Jul 2010
rudla: There is no post-increment addressing mode for register to memory transfers.
- 25:
  
  CommentAuthorKaz
- CommentTime12 Jul 2010
Fox - he knew results of World Cup thanks to octopus Paul, so counting cycles was more interesting :D
- 26: CommentAuthorrudla
- CommentTime12 Jul 2010
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:
  
  CommentAuthorKaz
- CommentTime2 Jan 2020 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: CommentAuthorzbyti
- CommentTime2 Jan 2020
@Kaz takie testy to raczej mierzą wydajność danej implementacji BASICa niż szybkość CPU.
- 29:
  
  CommentAuthorKaz
- CommentTime2 Jan 2020 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

Od 1 do 29 z 29