Re: Snes - megadrive - pc engine vs Neo geo

[Invité]

Dans mon cas buf est juste un buffer de données que je vais traiter et le bout de code que je t'ai montré s'applique un fois au début du traitement et une fois à la fin (en gros).
Je charge donc "buf" en amont dans un registre qui pointe dessus, j'imagine que tu peux en faire autant sur le 6502, comme lorsque tu veux traiter un large buffer de donnée.
Donc évidement il serait plus logique que tu utilise un logique d'index (X ou Y ?) préchargé pour ça.

C'est pour ca que je précise "tout dépend de ce que représente *buf" ..
Effectivement si c'est un pointeur vers un tableau j'utiliserai un index X,Y qui du coup me ferait gagner des cycles .
La j'ai volontairement pris un cas général, ou *buf peut pointer sur n'importe quoi .

Sinon voici le code sans rien préchargé à la dure :

Code:


    move.b buf,%d0        // 12
    and.b  #0xF0,%d0      // 8
    move.b col,%d1        // 12
    and.b  #0x0F,%d1      // 8
    or.b  %d1,%d0          // 4
    move.b %d0,buf        // 12


56 cycles...

Déjà mieux

Ton code me semble bien compliqué cela dit, par exemple tu stocke le resultat de l'opération (col & 0x0F) dans col or on s'en fiche, le but c'est de modifier buf.
Edit: bon en fait j'ai voulu faire un code 6502 plus optimisé mais je me rend compte que c difficilement possible, c'est quoi ce CPU incapable de faire une opération entre 2 registres X'D
J'ai vraiment pas l'habitude de ça et je trouve ça insupportable mais j'imagine que c'est juste une histoire d'habitude ^^ Enfin du coup, heureusement que le nombre de cycles / instruction est réduit ! Voilà le nombre d'instruction nécessaires pour faire une bête opération !

Les 65xx ne peuvent faire des opérations que dans l'accumulateur (reg A), ou la mémoire .
X et Y, ne servent en général que d'index,donc je suis obligé de stocker le calcul de col quelque part .
C'est une architecture rapide (en ASM), et peu coûteuse, qui a évidemment pas que des avantages .
Donc tu comprends bien pourquoi j'insiste, sur le fait que tu dois compter la mise en mémoire, sinon c'est pas du jeu
Si tu trouves ça pas optimal, c'est normal, l'archi du 68000 ou du Z80 est complètement différente, mais tu auras le même sentiment que les personnes qui viennent du 65xx vers le 68000/z80 ..
Moi je trouve justement que ça simplicité malgré tout est sa force, les instructions que j'ai utilisé sont somme toutes basiques ..

Peux tu me donner le nombre d'octets que prend ta version 56 cycles stp ??
Juste pour voir ..

Mais oui mais l'idée c'est de montrer en pratique comment on peut optimiser le code. Je sais que je vais executer plusieurs fois mon morceau de code donc forcément je "précalcule" certaines choses ! Bien sur tu le fais selon les registres que tu as à disposition et un des grands avantages du 68000 est qu'il en possède un bon paquet (en gros 8 pour le traitement et 8 pour les accès mémoire).
Je me rend compte que cette notion d'optimisation par "cache" ou "précalcul" est totalement absente sur 6502 car tu n'as aucun registre de stockage ! tu dois toujours travailler avec la mémoire et faire des aller/retour avec lda/sta, je trouve ça terriblement pas optimal comme manière de programmer, ça te génère un code long et très répétitif au possible...
Enfin bon c'est ce qui a permis de rendre ce CPU si bon marché.

Je suis d'accord, mais ça biaise les résultats, car on compare 2 archi ,totalement différentes .
Le 68000 fonctionne un peu comme le Z80, c'est a dire qu'il faut utiliser le plus les registres pour être éfficace .
les 65xx, n'ont que 3 registres, dont 1 seul qui peut faire des opérations, du coup on utilise les 256 premier octet de la mémoire(la zero page), comme registres .
Avec un 4 cycles de lecture/écriture par byte .
Donc tu disposes virtuellement de 256 registres, mais moins rapides que de vrais .

5/6 cycles x2000 par frame (par exemple) je pense que c'est plus important que 128 octets Dans un jeu comme dans une démo...

Pourquoi x2000 ??
Tu t'amuses à unroller toutes tes boucles dans un jeu ???
Je te dis pas la place que tu perds .
et 1200 cycles, sur plus de 100 000, c'est pas la mort, faut vraiment en avoir besoin .
Ca peut être utile dans des interruptions, notamment hsync pointilleuses, ou TIMER, mais sinon ..

Et n'oublies pas que le unrolling, n'est pas réservé qu'au 68000

[Stef]

C'est pour ca que je précise "tout dépend de ce que représente *buf" ..
Effectivement si c'est un pointeur vers un tableau j'utiliserai un index X,Y qui du coup me ferait gagner des cycles .
La j'ai volontairement pris un cas général, ou *buf peut pointer sur n'importe quoi.

Je l'avais appelé "buf" pour laisser entendre qu'il s'agissait d'un buffer à traiter

56 cycles...

Déjà mieux

Pas vraiment, autant te dire que ce code est mauvais pour du code 68000... tu fais ça uniquement si tu dois faire l'opération une seule fois (et encore), et dans ce cas que ton code soit lent, osef !

Les 65xx ne peuvent faire des opérations que dans l'accumulateur (reg A), ou la mémoire .
X et Y, ne servent en général que d'index,donc je suis obligé de stocker le calcul de col quelque part .
C'est une architecture rapide (en ASM), et peu coûteuse, qui a évidemment pas que des avantages .

Pourtant je me souvenais que seul l'accumulateur peut servir pour les
opérations mais disons que je n'avais pas mesuré à quel point c'était... "limitant"

Donc tu comprends bien pourquoi j'insiste, sur le fait que tu dois compter la mise en mémoire, sinon c'est pas du jeu

Ben oui et non justement, le fait de compter la mise en mémoire avantage sérieusement le 6502 qui lui ne fonctionne que comme ça (il n'y a pas le choix), je l'ai mis pour te faire plaisir mais il est évident que ce n'est pas comme ça que l'on code sur un 68000 (ou Z80 dans une moindre mesure).

Si tu trouves ça pas optimal, c'est normal, l'archi du 68000 ou du Z80 est complètement différente, mais tu auras le même sentiment que les personnes qui viennent du 65xx vers le 68000/z80 ..
Moi je trouve justement que ça simplicité malgré tout est sa force, les instructions que j'ai utilisé sont somme toutes basiques ..

Oui c'est simple, un peu trop même :p
Et clairement ca reduit énormément l'efficacité d'execution ! Encore une fois, heureusement que le ratio instruction/cycle est important sinon ce CPU ne serait bon à rien.

Peux tu me donner le nombre d'octets que prend ta version 56 cycles stp ??
Juste pour voir ..

Ca n'a aucun sens de te donner la taille de ce morceau de code car encore une fois ce n'est pas comme ça qu'on fait sur un 68000 mais si ça peut te faire plaisir : 22 octets si je ne me suis pas trompé.
Mais si tu veux tu peux optimiser pour la taille (avec préchargement) :

Code:


and.w %d1, (%a0)
or.w %d2,(%a0)


taille : 4 octets pour 32 cycles.

Et combien de cycle ça prend sur ton 6502 pour faire une copie de 4 octets d'un buffer source vers un buffer destination avec post incrementation ? surement plus que les 2 octets sur un 68000...

Je suis d'accord, mais ça biaise les résultats, car on compare 2 archi ,totalement différentes .
Le 68000 fonctionne un peu comme le Z80, c'est a dire qu'il faut utiliser le plus les registres pour être éfficace .
les 65xx, n'ont que 3 registres, dont 1 seul qui peut faire des opérations, du coup on utilise les 256 premier octet de la mémoire(la zero page), comme registres .
Avec un 4 cycles de lecture/écriture par byte .
Donc tu disposes virtuellement de 256 registres, mais moins rapides que de vrais .

Ben il faut comparer les architectures avec leurs propres spécificités, il est idiot de reproduire un code 6502 avec un 68000 quand ce dernier permet de faire un code bien plus efficace.
C'est pour ça que je te proposais y'a quelque temps de donner un exemple de code ou le 6502 était particulièrement efficace et ensuite j'essayais de te donner un équivalent adapté au 68000.

Pourquoi x2000 ??
Tu t'amuses à unroller toutes tes boucles dans un jeu ???

Mais non je voulais dire que si tu as une boucle qui s'execute 2000 fois, ton gain sera de 5/6 cycles x2000.

Je te dis pas la place que tu perds .
et 1200 cycles, sur plus de 100 000, c'est pas la mort, faut vraiment en avoir besoin .

6 cycles x2000 ça fait 12000, sur 100000 c'est loin d'être négligeable.
Bien évidemment je parle d'un cas ou tu aurais un traitement simple mais très souvent répété, genre une détection de collision sur 50 sprites fait en "brute force".

Et n'oublies pas que le unrolling, n'est pas réservé qu'au 68000

Heureusement ^^ j'ai parlé d'unrolling parce que tu as parlé du nombre élevé de cycles sur un 68000 pour effectuer un branchement conditionnel.

[Invité]

Pas vraiment, autant te dire que ce code est mauvais pour du code 68000... tu fais ça uniquement si tu dois faire l'opération une seule fois (et encore), et dans ce cas que ton code soit lent, osef !

Je déconnais pour le c'est mieux, juste parce que tu prends plus de cycles .

Pourtant je me souvenais que seul l'accumulateur peut servir pour les
opérations mais disons que je n'avais pas mesuré à quel point c'était... "limitant"

Non, c'est une question d'habitude, personne n'en est mort .

Ben oui et non justement, le fait de compter la mise en mémoire avantage sérieusement le 6502 qui lui ne fonctionne que comme ça (il n'y a pas le choix), je l'ai mis pour te faire plaisir mais il est évident que ce n'est pas comme ça que l'on code sur un 68000 (ou Z80 dans une moindre mesure).

Ben, a un moment faut bien mettre les données dans les registres non, ça se fait pas tout seul .
Juste que l'utilisation de la RAM,n'est pas aussi pénalisante que sur un 68000 ou Z80 .

Oui c'est simple, un peu trop même :p
Et clairement ca réduit énormément l'efficacité d'exécution ! Encore une fois, heureusement que le ratio instruction/cycle est important sinon ce CPU ne serait bon à rien.

C'est un choix,en assembleur il est très efficace, en C moins ..
Si on compare le Z80 au 68000, je suis sur qu'il se fait largement exploser (le Z80) ..

Ca n'a aucun sens de te donner la taille de ce morceau de code car encore une fois ce n'est pas comme ça qu'on fait sur un 68000 mais si ça peut te faire plaisir : 22 octets si je ne me suis pas trompé.
Mais si tu veux tu peux optimiser pour la taille (avec préchargement) :

18 pour ma part

Code:


and.w %d1, (%a0)
or.w %d2,(%a0)


taille : 4 octets pour 32 cycles.

Et combien de cycle ça prend sur ton 6502 pour faire une copie de 4 octets d'un buffer source vers un buffer destination avec post incrementation ? surement plus que les 2 octets sur un 68000...

Code:


tii @source,@dest,$4  // 17 + 24 soit 41 cycles et 7octets (instruction 6280 et pas 6502)

Ou

clx  // 2
lda  buf1,X  // 4
sta  buf2,X  // 4

inx  // 2

lda  buf1,X  // 4
sta  buf2,X  // 4

inx  // 2

lda  buf1,X  // 4
sta  buf2,X  // 4

inx  // 2

lda  buf1,X  // 4
sta  buf2,X  // 4

// 40 cycles



Ben il faut comparer les architectures avec leurs propres spécificités, il est idiot de reproduire un code 6502 avec un 68000 quand ce dernier permet de faire un code bien plus efficace.
C'est pour ça que je te proposais y'a quelque temps de donner un exemple de code ou le 6502 était particulièrement efficace et ensuite j'essayais de te donner un équivalent adapté au 68000.

Oui, mais faut bien à un moment que tu charges tes données dans les registres!!
Col, ou l'adresse de buf, il ne s'y mettent pas tout seul ..

Mais non je voulais dire que si tu as une boucle qui s'execute 2000 fois, ton gain sera de 5/6 cycles x2000.

J'avais compris, mais bon, à part avoir besoins absolu de ces cycles, tu te fais pas chier pour si peux dans un jeu,a moins d'y être obligé .

6 cycles x2000 ça fait 12000, sur 100000 c'est loin d'être négligeable.
Bien évidemment je parle d'un cas ou tu aurais un traitement simple mais très souvent répété, genre une détection de collision sur 50 sprites fait en "brute force".

Au temps pour moi, petite erreur de calcul ..
Pour éviter les boucles sur ce type de transfert, j'ai des instructions pour (transfert de bloc) .
style tii,tia,tin etc ..

Heureusement ^^ j'ai parlé d'unrolling parce que tu as parlé du nombre élevé de cycles sur un 68000 pour effectuer un branchement conditionnel.

Oui les branchements conditionnel, comme les sauts à une routine, y'a à pas que dans les boucles hein ..

[Invité]

Putain, les gars... vous faites mal à la tête avec vos hiéroglyphes etvos lignes de code. :lol:
Vous voulez pas passez en MP, les deux extraterrestres ?

[ryosaeba]

Putain, les gars... vous faites mal à la tête avec vos hiéroglyphes etvos lignes de code. :lol:
Vous voulez pas passez en MP, les deux extraterrestres ?

Non cela m'intéresse :)

[Invité]

Dsl les gars

[Lesarthois]

Juste pour savoir (tant qu'on est dans le HS) mon approximation des archis, avec l'exemple d'une autoroute, c'est valable (pour expliquer à un néophyte hein, pas à un programmeur :p ) ?

[Stef]

Ben, a un moment faut bien mettre les données dans les registres non, ça se fait pas tout seul .
Juste que l'utilisation de la RAM,n'est pas aussi pénalisante que sur un 68000 ou Z80 .
...
Oui, mais faut bien à un moment que tu charges tes données dans les registres!!
Col, ou l'adresse de buf, il ne s'y mettent pas tout seul ..

Bien sur, mais là j'ai isolé une ligne de code parmi un ensemble et on considère une seule execution ce qui ne correspond pas à un cas réel d'execution.
Sur le 6502 ça n'a aucune incidence du fait du l'architecture du CPU, que tu l'execute une fois ou 100 fois tu le feras quasiment de la même manière, tu n'as pas vraiment le choix. Avec un CPU "classique" (enfin un CPU qui a des registres ^^) tu vas nécessairement prendre en compte le nombre de fois que tu executes telle ou telle portion de code et du coup, préchargé des choses dans les registres.
Donc oui sur une execution d'un morceau spécifique qui manipule du byte et que tu vas faire une seule fois, un 6502 sera plus rapide qu'un 68000 mais la belle affaire ! car ça ne sera jamais le bottleneck dans le code.
Si on veut comparer de manière objective la performance des 2 CPU, il faut prendre un algorithme dans son ensemble sur une taille de données spécifié.

C'est un choix,en assembleur il est très efficace, en C moins ..
Si on compare le Z80 au 68000, je suis sur qu'il se fait largement exploser (le Z80) ..

Ca me surprend qu'un compilateur C soit si mauvais avec un 6502, son architecture simpliste devrait au contraire facilité la vie du compilo... Quel est le ratio de vitesse entre un code compilé en C (avec les optis à fond) et code optimisé à la main en assembleur ?
Sur un 68000, en utilisant GCC 3.6 (qui est une version pas trop mauvaise pour un 68000), la différence de performance entre C optimisé et ASM va de 20% à 60%.
Ca peut monter bien plus haut quand t'as des opérations spécifiques optimisables en assembleur...
Sinon c'est sur à fréquence égale il est évident qu'un Z80 aura bien du mal, mais le Z80 est fait pour tourner plus vite (au moins 2x) et dans ce cas, je pense qu'un code bien optimisé sera aussi performant.

18 pour ma part

C'est franchement beaucoup, je m'attendais à bien moins...

Code:


tii @source,@dest,$4  // 17 + 24 soit 41 cycles et 7octets (instruction 6280 et pas 6502)

Ou

clx  // 2
lda  buf1,X  // 4
sta  buf2,X  // 4

inx  // 2

lda  buf1,X  // 4
sta  buf2,X  // 4

inx  // 2

lda  buf1,X  // 4
sta  buf2,X  // 4

inx  // 2

lda  buf1,X  // 4
sta  buf2,X  // 4

// 40 cycles


C'est quand même beaucoup plus que les 2 octets et 20 cycles du 68000 :p

Au temps pour moi, petite erreur de calcul ..
Pour éviter les boucles sur ce type de transfert, j'ai des instructions pour (transfert de bloc) .
style tii,tia,tin etc ..

Oui mais s'il ne s'agit pas d'un simple transfert, tu auras un sacré avec le unrolling.. enfin on s'écarte là.

Oui les branchements conditionnel, comme les sauts à une routine, y'a à pas que dans les boucles hein ..

Oui oui mais encore une fois, tu as toujours des méthodes d'optimisations pour ce genre de cas. Si tu appelles une méthode 10000 par seconde, le coup d'appel et de retour de fonction commence à couter quelque chose et dans ce cas tu vas inliner, on peut toujours aller plus loin

[Stef]

Juste pour savoir (tant qu'on est dans le HS) mon approximation des archis, avec l'exemple d'une autoroute, c'est valable (pour expliquer à un néophyte hein, pas à un programmeur :p ) ?

Je trouve que c'est une bonne image en effet, un CPU 16 bits dispose d'un bus de données 16 bits, qui transporte donc 2 fois plus de données à la fois qu'un CPU 8 bits... l'image est tout à fait pertinente.

[Invité]

C'est toujours pareil, tu prends juste l'exécution des instructions, c'est comme si je mettais pas les 17 cycles d'init des instructions de transfert, et que je mette juste les cycles pour transferer ..

Comment tu fais pour transférer 4 octets en 2 octes et 20 cycles ???
Je suppose que tu squizzes encore l'intit des registres ??

Sinon, un CPU 64 bit d'aujourd'hui n'est en rien 2x plus rapide qu'un 32, juste 15 % dans le meilleurs des cas ..

Bien sur si on fait le raccourci 16 = 2x 8bit, bien sur .

[Stef]

C'est toujours pareil, tu prends juste l'exécution des instructions, c'est comme si je mettais pas les 17 cycles d'init des instructions de transfert, et que je mette juste les cycles pour transferer ..

Comment tu fais pour transférer 4 octets en 2 octes et 20 cycles ???
Je suppose que tu squizzes encore l'intit des registres ??

Mais bien sur, je comprends pas que ça te choque... je t'ai déjà expliqué plusieurs fois pourquoi il est normal de comparer de cette manière si tu veux comparer les perfs brutes des différents CPU. Les temps d'init sont cachés donc on s'en fout...
sur le 6280 on vire aussi le temps d'init, on obtient alors :

6502 : 10 cycles par octet
6280 : 6 cycles par octet
68000 : 4.3 cycles par octet (on tend vers 4 cycles mais dans la pratique on pas descendre en dessous de ~4.3).

Il faut reconnaitre que le 6280 se défend bien quand il s'agit de recopier un bloc mémoire.

Sinon, un CPU 64 bit d'aujourd'hui n'est en rien 2x plus rapide qu'un 32, juste 15 % dans le meilleurs des cas ..

Bien sur si on fait le raccourci 16 = 2x 8bit, bien sur .

Oui mais le problème des architectures 64 bits, c'est que dans la pratique le 32 bits est encore suffisant pour la plupart des traitements classiques d'où une si faible différence...
Par contre dés que tu vas faire un traitement lourd (une compression de vidéo par exemple...) et que ton algo tient compte du 64 bits, alors tu te retrouves avec un gain proche du x2.

[Invité]

Mais bien sur, je comprends pas que ça te choque... je t'ai déjà expliqué plusieurs fois pourquoi il est normal de comparer de cette manière si tu veux comparer les perfs brutes des différents CPU. Les temps d'init sont cachés donc on s'en fout...

Justement, c'est ça que j'essai de t'expliquer, y'a pas de temps d'init sur les 65xx contrairement au 68000 .
Il sont pas cachés, un lda buf(ZP) prend 4 cycles, un lda #$FF 2 cycles, et rien de plus ..
Les seules pénalités que tu peux avoir, c'est lorsque un saut par exemple,se fait entre 2 pages, tu prends 1 cycle sup.
Ca marche pas comme sur 68000, on précache pas le chargement des registres, vue que tu n'as qu'un seul registre pour faire les calculs ..
Un fois ton registre chargé, les opérations en général prennent entre 2 et 4 cycles .

sur le 6280 on vire aussi le temps d'init, on obtient alors :
6502 : 10 cycles par octet
6280 : 6 cycles par octet
68000 : 4.3 cycles par octet (on tend vers 4 cycles mais dans la pratique on pas descendre en dessous de ~4.3).

Il faut reconnaitre que le 6280 se défend bien quand il s'agit de recopier un bloc mémoire.

Maintenant si tu parles des instructions de transfert de blocs pour les 6 cycles, seul le 6280 les a, pas les 65xx .
Ensuite elles sont utilses pour transférer au moins 4 octets, en dessous on le fera de manière classique .
Et puis si je squizze les 17 cycles d'init pour ces instructions particulières, ca fausse les calculs, car elles sont bien présentes, sinon effectivement, je prends juste
24 cycles pour copier 4 octets ..
Pour le 65xx,en version classique, tout dépend ou sont les buffers, si on prend pas l'init(chargement dans le registre), ça prend 4 cycles/min pour 1 octets .

Video à voir sur le 68000 .

Oui mais le problème des architectures 64 bits, c'est que dans la pratique le 32 bits est encore suffisant pour la plupart des traitements classiques d'où une si faible différence...
Par contre dés que tu vas faire un traitement lourd (une compression de vidéo par exemple...) et que ton algo tient compte du 64 bits, alors tu te retrouves avec un gain proche du x2.

Bah non, tu as plein de programmes 64 bit , et tu n'as jamais(n'auras jamais) de gain x2, au plus 10/15% et encore ..
Prends n'importe quel site d'info, tu verras les benchs .

[Stef]

Justement, c'est ça que j'essai de t'expliquer, y'a pas de temps d'init sur les 65xx contrairement au 68000 .
Il sont pas cachés, un lda buf(ZP) prend 4 cycles, un lda #$FF 2 cycles, et rien de plus ..
Les seules pénalités que tu peux avoir, c'est lorsque un saut par exemple,se fait entre 2 pages, tu prends 1 cycle sup.

Mais je le sais bien. Le 6502 de part sa simplicité, effectue une opération toujours de la même manière, tu n'as pas le choix. En gros il est rapide si tu effectues l'opération une seule fois, il devient lent (comparé aux autres CPU) quand il s'agit d'effectuer la même opération N fois... et et en général dans un programme y'a beaucoup de choses que tu fais N fois

Un fois ton registre chargé, les opérations en général prennent entre 2 et 4 cycles .

Mais oui, mais le problème c'est que sur le 6502, si tu fais N fois une même opération, tu es obligé de refaire toutes les opérations alors que sur un 68000 bon nombre d'opérations peuvent être faites une seule fois au début et ensuite tu gardes des valeurs en registre. Si on veut comparer les CPU on ne peut pas se contenter de comparer instruction par instruction et cycle à cycle, ça n'a aucun intérêt car ne reflète pas du tout une utilisation normale...

PS: je sais pas d'ou tu sors ces cycles pour les 65xx et 6280
tu peux voir les cycles de 65xx ici : http://www.defence-force.org/computing/oric/coding/annexe_2/index.htm

Tu verras qu'aucune instruction ne prend 10 cycles .

!!??
J'ai donné le temps minimum de copie d'un octet en mémoire (d'une source vers une destination) ! Sur 6502 y'a pas moyen de le faire en une seule instruction d'ou les 10 cycles... et évidemment j'ai virer les temps d'init car pas interessant.
Grace à ces temps tu sais que pour copier un bloc de 1 Ko (1024 octets) tu vas utiliser :

~10240 cycles sur le 6502
~6000 cycles sur le 6280
~4300 cycles sur le 68000

et c'est ça qui est important quand tu veux tirer le max d'un CPU.
C'est ces chiffres de puissance brute que j'ai utilisé pour faire ma démo Bad Apple car je savais, qu'en théorie, le 68000 était capable de décompresser tant à la seconde, de transférer tant et donc c'était possible... si dés le début, tu t’aperçois qu'avec les chiffres tu n'y arriveras pas, il faut que tu changes de méthode.

Bah non, tu as plein de programmes 64 bit , et tu n'as jamais de gain x2, au plus 10/15% et encore..
Prends n'importe quel site d'info, tu verras les benchs .

En effet tu as raison, l'écart est souvent de 15/20% maximum...
Ca vient du fait que tout n'est pas optimisable en 64 bit et puis surtout là ou le 64 bits pourraient aider (transfert mémoire etc...) c'est des composants externes comme la mémoire qui vont faire la différence (la mémoire des PC est 64 bits / 128 bits depuis longtemps).
Dans 10 ans peut être que l'architecture 64 bits sera quasi 2x plus rapide que la 32 bits, aujourd'hui elle est encore assez sous exploitée.
Pour dire je pense qu'on ira jamais au delà d'une architecture interne 64 bits, 64 bits permet de définir une plage mémoire plus que nécessaire pour encore bien bien longtemps.
Le 32 bits a tenu très longtemps mais il arrive enfin à ses limites.

[Invité]

Mais je le sais bien. Le 6502 de part sa simplicité, effectue une opération toujours de la même manière, tu n'as pas le choix. En gros il est rapide si tu effectues l'opération une seule fois, il devient lent (comparé aux autres CPU) quand il s'agit d'effectuer la même opération N fois... et et en général dans un programme y'a beaucoup de choses que tu fais N fois

Je sais bien, mais c'est au cas par cas, come toi, tu vas utiliser la meilleure façon pour le faire, moi aussi ..

Mais oui, mais le problème c'est que sur le 6502, si tu fais N fois une même opération, tu es obligé de refaire toutes les opérations alors que sur un 68000 bon nombre d'opérations peuvent être faites une seule fois au début et ensuite tu gardes des valeurs en registre. Si on veut comparer les CPU on ne peut pas se contenter de comparer instruction par instruction et cycle à cycle, ça n'a aucun intérêt car ne reflète pas du tout une utilisation normale...

Non tu recharges pas à chaque fois ..
tu peux transfèrer un résultat à garder dans x ou y, c'est plus rapide .
Sinon, un fois chargé dans A, tu fais tout les traitements que tu veux sans recharger quoi que ce soit .

Par contre j'arrive toujours pas à comprendre comment tu fais pour avoir 4,3 cycles (déjà) en faisant une lecture/éctiture dans 2 buffers, même avec des adresses prefetchées .

une copie d'un (An)+ -> (An)+ pend 12 cycles pour un long, c'est ça ?? .
Ah non c'est pour des bytes/words, les L c'est 20 .
Donc 20/4 = 5 cycles par octets, j'ai toujours pas les 4.3 cycles .

Car c'est comme dire qu'une voiture fait 500 m en 10 seconde, par rapport à une autre qui le fait en 15 seconde .
En disant 'oui mais on commence à compter quand on est déjà à 100 km/h", alors qu'il lui à fallut 10 seconde pour y arriver, alors que l'autre 5 .
Donc si on compte que les chiffres qui arrangent le 68000, forcement, tu gagnes (et encore)
Car effectivement c'est négligeable dans un gros transfert (style celui de 1024), mais pour quelques octets non .

J'ai donné le temps minimum de copie d'un octet en mémoire (d'une source vers une destination) ! Sur 6502 y'a pas moyen de le faire en une seule instruction d'ou les 10 cycles... et évidemment j'ai virer les temps d'init car pas interessant.
Grace à ces temps tu sais que pour copier un bloc de 1 Ko (1024 octets) tu vas utiliser :

~10240 cycles sur le 6502
~6000 cycles sur le 6280
~4300 cycles sur le 68000

et c'est ça qui est important quand tu veux tirer le max d'un CPU.
C'est ces chiffres de puissance brute que j'ai utilisé pour faire ma démo Bad Apple car je savais, qu'en théorie, le 68000 était capable de décompresser tant à la seconde, de transférer tant et donc c'était possible... si dés le début, tu t’aperçois qu'avec les chiffres tu n'y arriveras pas, il faut que tu changes de méthode.

Oui mais comme pour tout le reste, tu fais pas des copies de ce genre tout le temps .
C'est pour ça que je dis qu'en moyenne le CPU de la nec vaut celui de la MD ..
C'est dans un jeu complet,car même avec ces chiffres on est loin du 68000 = 2x le 6280 (16 bit vs 8 bit) ..

Bien sur le 68000 excelle dans la polyvalence, là c'est clair qu'il y a pas photo .
C'est pour ça aussi, que dire que le CPU de la snes est un vaux car "juste à 3.58 mhz" est un peu faux, un bon codeur 65xx, pourra facilement faire des prouesses dessus .
voir le C64,la nes, ou super aleste sur snes ..
On à trop tendance à juste voir la fréquence d'un CPU .

En effet tu as raison, l'écart est souvent de 15/20% maximum...
Ca vient du fait que tout n'est pas optimisable en 64 bit et puis surtout là ou le 64 bits pourraient aider (transfert mémoire etc...) c'est des composants externes comme la mémoire qui vont faire la différence (la mémoire des PC est 64 bits / 128 bits depuis longtemps).
Dans 10 ans peut être que l'architecture 64 bits sera quasi 2x plus rapide que la 32 bits, aujourd'hui elle est encore assez sous exploitée.
Pour dire je pense qu'on ira jamais au delà d'une architecture interne 64 bits, 64 bits permet de définir une plage mémoire plus que nécessaire pour encore bien bien longtemps.
Le 32 bits a tenu très longtemps mais il arrive enfin à ses limites.

Oui bien sur faut pas rester dans le passé, mais le gain n'est pas si important que ça .
Tout comme un bi CPU ne va pas 2x plus vite qu'un seul CPU
Même dans les applis multitread, t'auras jamais 100% de gain, dans des gens de CPU similaires ..

[Stef]

Non tu recharges pas à chaque fois ..
tu peux transfèrer un résultat à garder dans x ou y, c'est plus rapide .
Sinon, un fois charger dans A, tu fais tout les traitements que tu veux sans recharger quoi que ce soit .
...
Par contre j'arrive toujours pas à comprendre
comment tu fais pour avoir 4,3 cycles (déjà) en faisant une
lecture/éctiture dans 2 buffers, même avec des adresses prefetchées .

Ok tu peux utiliser X ou Y pour stocker temporairement un résultat et tu peux effectuer toute tes opérations d'un coup sur A, du coup toute l'optimisation (quand elle est possible) consiste à enchainer au max les opérations sur A et à utiliser au mieux X et Y comme stockage temporaire... c'est comment dire... très limité ^^
Mais je ne doute pas que quelqu'un de douer avec ce CPU puisse faire des prouesses.

Pour le 4.3, tu l'obtiens en utilisant l'instruction movem (dont je t'ai déjà parlé la dernière fois). Plus tu vas transférer de registre à la fois, plus tu vas tendre vers un débit de 4 cycles par octet transféré

Oui mais comme pour tout le reste, tu fais pas des copies de ce genre tout le temps .
C'est pour ça que je dis qu'en moyenne le CPU de la nec vaut celui de la MD ..
C'est dans un jeu complet,car même avec ces chiffres on est loin du 68000 = 2x le 6280 (16 bit vs 8 bit) ..

Non il n'y a clairement pas un rapport de 2x, il faut bien voir que le 6502 dont le 6280 hérite ont un très bon ratio instruction / cycle ce qui les rend plus performant à fréquence égale qu'un CPU "classique" de la même catégorie (comme le Z80).
Sinon dans la moyenne des développements je dirais qu'un 6280 doit être quasiment équivalent à un 68000, pourquoi pas... mais quand il s'agit d'exploiter au mieux le CPU je pense que le 68000 prend nettement l'avantage :o

Bien sur le 68000 excelle dans la polyvalence, là c'est clair qu'il y a pas photo .
C'est pour ça aussi, que dire que le CPU de la snes est un vaux car "juste à 3.58 mhz" est un peu faux, un bon codeur 65xx, pourra facilement faire des prouesses dessus .
voir le C64,la nes, ou super aleste sur snes ..
On à trop tendance à juste voir la fréquence d'un CPU .

C'est sur la fréquence ne fait pas tout... mais la SNES a bien d'autre tares qui fait que c'est un veau quand même, déjà selon les banks accédées le CPU tourne à 1.7, 2.5 ou 3.6 Mhz et justement ce système de bank t'oblige à compliquer le code ce qui le rend moins performant qu'avec un adressage continue. Puis les trucs genre pas d'instruction de multiplication ou de division sur le CPU ce qui t'oblige à passer par une unité externe.
Tiens d'ailleurs sur PCE tu fais comment pour faire une multiplication ou une division ? t'es obligé de la coder toi même ? il me semble pas que le 6280 soit pourvu de telles instructions.

Oui bien sur faut pas rester dans le passé, mais le gain n'est pas si important que ça .
Tout comme un bi CPU ne va pas 2x plus vite qu'un seul CPU
Même dans les applis multitread, t'auras jamais 100% de gain, dans des gens de CPU similaires ..

Là encore ça dépend des traitements :p
A mon boulot je bosse sur un application de traitement d'image et le gain entre 1 ou 2 CPU peut arriver à 100% selon l'algo (une FFT par exemple).

[Invité]

Ok tu peux utiliser X ou Y pour stocker temporairement un résultat et tu peux effectuer toute tes opérations d'un coup sur A, du coup toute l'optimisation (quand elle est possible) consiste à enchainer au max les opérations sur A et à utiliser au mieux X et Y comme stockage temporaire... c'est comment dire... très limité ^^
Mais je ne doute pas que quelqu'un de douer avec ce CPU puisse faire des prouesses.

Ah ça on est d'accord, malgré que ce soit très simple comme approche, c'est quelques fois chiant .
Mais y'a bien aussi des aspects chiant sur 68000 ..

Pour le 4.3, tu l'obtiens en utilisant l'instruction movem (dont je t'ai déjà parlé la dernière fois). Plus tu vas transférer de registre à la fois, plus tu vas tendre vers un débit de 4 cycles par octet transféré

Ok, j'avais compris pour le movem, mais j'ai du mal à comprendre le tableau des cycles du 68000, c'est pour ça .
Mais c'est marqué où ???, parce que même comme ça je vois que du 20 cycles/word ..
Et j'oubliais, tu as bien une boucle aussi pour copier tes 1024 octets,car ton movem il copie que 2,ou 4 octets ??
A chaque exécution de ton movem, le CPU reprefetch les adresses ou pas ??
Car si je comprends bien, tu peux pas copier (An)+ -> (An)+ avec ça ??,donc tu as un seul registre d'adresse pos incrémenté, l'autre faut le faire à la main ??

Non il n'y a clairement pas un rapport de 2x, il faut bien voir que le 6502 dont le 6280 hérite ont un très bon bon ratio instruction / cycle ce qui les rend plus performant à fréquence égale qu'un CPU "classique" de la même catégorie (comme le Z80).
Sinon dans la moyenne des développements je dirais qu'un 6280 doit être quasiment équivalent à un 68000, pourquoi pas... mais quand il s'agit d'exploiter au mieux le CPU je pense que le 68000 prend nettement l'avantage :o

Pas convaincu , mais le 68000 reste quand même un très bon CPU, bien meilleurs qu'un Z80 ..

C'est sur la fréquence ne fait pas tout... mais la SNES a bien d'autre tares qui fait que c'est un veau quand même, déjà selon les banks accédées le CPU tourne à 1.7, 2.5 ou 3.6 Mhz et justement ce système de bank t'oblige à compliquer le code ce qui le rend moins performant qu'avec un adressage continue. Puis les trucs genre pas d'instruction de multiplication ou de division sur le CPU ce qui t'oblige à passer par une unité externe.
Tiens d'ailleurs sur PCE tu fais comment pour faire une multiplication ou une division ? t'es obligé de la coder toi même ? il me semble pas que le 6280 soit pourvu de telles instructions.

Oui, je parlais juste de CPU, évidemment la SNES, a certaines limitations pénibles .
Pour la division sur pce tu dois la coder, elle existe pas, mais vu que ça prend 140/158 cycles (voire plus) sur 68000, je suis sur que pour la majorité des cas (entiers/16 bit max), je pense faire mieux à la main sur le 6280 .
Après perso (enfin jusqu'à présent) j'ai pas eu besoin de divs ou grosse multiplications, autre qu'avec des décalages .

[Invité]

Pendant ce temps à Vera Cruz...

[Invité]

Lol, dsl pour vous, mais c'est intéressant là putin ..

[Lesarthois]

Je bite pas le tiers de ce que vous racontez mais effectivement de ce que j'arrive à comprendre, c'est passionnant

[Invité]

Lol, dsl pour vous, mais c'est intéressant là putin ..

Je le conçois. Mais pourquoi ne pas créer un nouveau topic dans ce cas ou passer en MP ? Parce que là, même si je ne vous en tiens absolument pas rigueur, notez-le bien, vous n'êtes plus que deux à animer le topic "SNES-MD-PC Engine vs Neo Geo". C'est un peu dommage, non ?

[Stef]

Mais y'a bien aussi des aspects chiant sur 68000 ..

Oui ça peut arriver, comme le cas dont j'ai parlé plus haut... je m'en sors quand même mais ça me bouffe pas mal de registres pour être optimisé et c'est pas très rapide quoiqu'il arrive.

Ok, j'avais compris pour le movem, mais j'ai du mal à comprendre le tableau des cycles du 68000, c'est pour ça .
Mais c'est marqué où ???, parce que même comme ça je vois que du 20 cycles/word ..
Et j'oubliais, tu as bien une boucle aussi pour copier tes 1024 octets,car ton movem il copie que 2,ou 4 octets ??
A chaque exécution de ton movem, le CPU reprefetch les adresses ou pas ??

la syntaxe du movem est la suivante :

Code:


movem.w (%ax), reglist          // 12+4n
movem.l (%ax), reglist          // 12+8n

ou

movem.w reglist, (%ax)          // 8+4n
movem.w reglist, (%ax)          // 8+8n


Normalement tu utilises cette instruction pour sauvegarder tes registres en début d'appel d'une fonction et les restaurer à la fin.

Tu vois que pour la première instruction movem qui va copier depuis la mémoire dans une liste de registre, tu as un temps d'init de 12 cycles, ensuite n est le nombre de registre écrits.
Quand tu écrit en word (16 bits) tu as 4 cycles par registre copié et 8 cycles quand tu es en long (32 bits).

Pour la seconde instruction movem le temps d'init est de 8 cycles, ensuite pareil tu as 4 cycles par registre transféré en mémoire si t'es en word et 8 cycles si t'es en long.

La liste de registre que tu transfert lors d'un movem est paramétrable, tu peux transférer un seul registre tout comme tu peux transférer les 16 d'un coup.
En réalité tu es obligé de conserver 2 à 3 registres pour le stack et pour les pointers sources et destinations... du coup au moins tu transfert 13 registres au maximum d'un coup ce qui te fait :

12 + (13*8) pour lire 52 octets depuis la mémoire et les copier dans les registres
8 + (13*8) pour copier les 13 registres 32 bits (soit 52 octets) en mémoire.

Du coup tu as transféré 52 octets en 12 + 8 + (13 * 8) + (13 * 8) = 228 cycles
228 / 52 = 4.38 cycles par octet.

(et on voit que je me suis planté dans mon calcul, c'est plutot 4.4 que 4.3 :p)

Oui, je parlais juste de CPU, évidemment la SNES, a certaines limitations pénibles .
Pour la division sur pce tu dois la coder, elle existe pas, mais vu que ça prend 140/158 cycles (voire plus) sur 68000, je suis sur que pour la majorité des cas (entiers/16 bit max), je pense faire mieux à la main sur le 6280 .
Après perso (enfin jusqu'à présent) j'ai pas eu besoin de divs ou grosse multiplications, autre qu'avec des décalages .

Sur megadrive, la division prend jusqu'à 140/158 cycles, l'instruction peut prendre moins selon le nombre de bits à positionné à 1 dans tes opérandes.
Et puis il s'agit d'une division type 32 bits / 16 bits = 16 bits quotient : 16 bits remainder
Ca te prendrait *beaucoup plus* que 150 cycles de le refaire à la main, même avec un 6280.
Mais il est évident que c'est une instruction que tu évites d'utiliser sur MD dans la mesure du possible (tout comme la multiplication) vu que ça reste très couteux.

[Stef]

Lol, dsl pour vous, mais c'est intéressant là putin ..

Je le conçois. Mais pourquoi ne pas créer un nouveau topic dans ce cas ou passer en MP ? Parce que là, même si je ne vous en tiens absolument pas rigueur, notez-le bien, vous n'êtes plus que deux à animer le topic "SNES-MD-PC Engine vs Neo Geo". C'est un peu dommage, non ?

En MP ça serait dommage car c'est le genre de discussion qui peut interesser d'autre personnes :p
Mais je suis d'accord qu'on devrait créer un topic special "ze topic débat technique sur les 16 bits" plutot que de polluer les topics sur lesquels on intervient :o

[Invité]

Lol, dsl pour vous, mais c'est intéressant là putin ..

Je le conçois. Mais pourquoi ne pas créer un nouveau topic dans ce cas ou passer en MP ? Parce que là, même si je ne vous en tiens absolument pas rigueur, notez-le bien, vous n'êtes plus que deux à animer le topic "SNES-MD-PC Engine vs Neo Geo". C'est un peu dommage, non ?

En MP ça serait dommage car c'est le genre de discussion qui peut interesser d'autre personnes :p
Mais je suis d'accord qu'on devrait créer un topic special "ze topic débat technique sur les 16 bits" plutot que de polluer les topics sur lesquels on intervient :o

J'ai résolu le problème en vous créant un topic les copains !

https://www.gamopat-forum.com/t51209-technique-debat-code-autour-de-nos-bien-aimees-16-bit#1276280

[Invité]

la syntaxe du movem est la suivante :

Code:


movem.w (%ax), reglist          // 12+4n
movem.l (%ax), reglist          // 12+8n

ou

movem.w reglist, (%ax)          // 8+4n
movem.w reglist, (%ax)          // 8+8n


Normalement tu utilises cette instruction pour sauvegarder tes registres en début d'appel d'une fonction et les restaurer à la fin.

Tu vois que pour la première instruction movem qui va copier depuis la mémoire dans une liste de registre, tu as un temps d'init de 12 cycles, ensuite n est le nombre de registre écrits.
Quand tu écrit en word (16 bits) tu as 4 cycles par registre copié et 8 cycles quand tu es en long (32 bits).

Pour la seconde instruction movem le temps d'init est de 8 cycles, ensuite pareil tu as 4 cycles par registre transféré en mémoire si t'es en word et 8 cycles si t'es en long.

La liste de registre que tu transfert lors d'un movem est paramétrable, tu peux transférer un seul registre tout comme tu peux transférer les 16 d'un coup.
En réalité tu es obligé de conserver 2 à 3 registres pour le stack et pour les pointers sources et destinations... du coup au moins tu transfert 13 registres au maximum d'un coup ce qui te fait :

12 + (13*8) pour lire 52 octets depuis la mémoire et les copier dans les registres
8 + (13*8) pour copier les 13 registres 32 bits (soit 52 octets) en mémoire.

Du coup tu as transféré 52 octets en 12 + 8 + (13 * 8) + (13 * 8) = 228 cycles
228 / 52 = 4.38 cycles par octet.

(et on voit que je me suis planté dans mon calcul, c'est plutot 4.4 que 4.3 :p)

Merci, du coup là c'est plus clair .
Mais tes registres de destinations, tu dois les initialiser avant (pour qu'ils pointent sur ta destination) ..
Et une fois que les 52 octest sont copiés, es ce que tu dois initialiser de nouveau tes registres de destination ou sources(je pense que oui,car 1 des 2 est non auto incrementé),pour la copie de 52 octets suivants ??
Parce que moi c'est tii @source,@dest,#1024, et c'est tout, pas de boucles, pas de cycles sup, rien, sauf 17+(6*1024) cycles .

Parce que là,si on prend 1024 octets, soit 1024/52 = 19,692, bah ça marche plus trop ton truc
et ça il faut que tu le gères aussi, donc entre les inits, la gestion du nobre à copier etc, finalement on en arrive au même taux de transfert que sur le 6280, seulement moi ça prend juste 7 octets .

Mais c'est vrai que cette façon d'utiliser les registres pour la copie est intéressante, et effectivement un simple 65xx ne fait pas le poid dans la copie de bloc de données .
Même le 65816 d'ailleurs .
le 6280 s'en sort grâce aux instructions de copie de blocs .
Ce que je veux juste montrer, c'est que 8 bit ne veux pas dire forcement 2x plus lent qu'un 16, ou qu'un 16 traite 2 fois plus de données qu'un 16 .
Tout dépend des CPU .

Sur megadrive, la division prend jusqu'à 140/158 cycles, l'instruction peut prendre moins selon le nombre de bits à positionné à 1 dans tes opérandes.
Et puis il s'agit d'une division type 32 bits / 16 bits = 16 bits quotient : 16 bits remainder
Ca te prendrait *beaucoup plus* que 150 cycles de le refaire à la main, même avec un 6280.
Mais il est évident que c'est une instruction que tu évites d'utiliser sur MD dans la mesure du possible (tout comme la multiplication) vu que ça reste très couteux.

Oui c'est pour ça que je dis, div limitée aux entiers et sur 16 bit max, après c'est clair que je suis au dessus ..
L'instruction div du 68000, est plus complète , moi je ferrais selon les cas, donc plus rapide selon ce que je dois traiter .
ex div entière sur 8 bit .
Mais j'en ai pas l'utilité (pour le moment), donc pas de soucis