Et si....
Modérateurs : Papy.G, fneck, Carl
- Totor le Butor
- Messages : 2235
- Inscription : 07 sept. 2011 16:14
- Localisation : Paris - Mezels
Re: Et si....
J'ai un Mac 2CI avec carte cache de 32K et ben y a pas photo, à vue de pif je dirais 30% plus rapide que sans cache .
Born to bricole
[Rch] Vieux composants électroniques et circuits intégrés toute époque et vieilles cartes .
[Rch] Vieux composants électroniques et circuits intégrés toute époque et vieilles cartes .
Re: Et si....
Ça ne sert à rien, de la mémoire cache si, d'une part il n'y a pas le circuit pour la gérer, et si d'autre part la vitesse du processeur n'est pas suffisamment élevée pour qu'il puisse faire la différence en matière de temps d'exécution entre de la mémoire courante et de la mémoire rapide.
Notator est le nom d'un programme séquenceur Midi et notation musicale pour Atari ST(e) (puis Mac).
Re: Et si....
Bein ça va de soit qu'en disant "Cache ou pas", la gestion hardware est là..
Mais donc, si nos machines avaient eus un cache avec gestion du cache.
le tout avec le reste de l'architecture en l'état, je pense notamment à la même cadence CPU de l'époque pour chaque machine.
Mais donc, si nos machines avaient eus un cache avec gestion du cache.
le tout avec le reste de l'architecture en l'état, je pense notamment à la même cadence CPU de l'époque pour chaque machine.
Re: Et si....
A partir du 68020 il y a du cache data et instructions
Commodore (64/128/Amiga), HP (28/41/48/50/71/75/200/Prime) et autres (Ti, Canon X07, Psion, Casio, Palm, Thomson, Exl, Amstrad)
Re: Et si....
Difficile de dire si un cache était réalisable sur des Z80, car sur certaines machines, la vidéo était gérée et synchronisée par le CPU.
Mais, si tu nous parles de "cache" sur le ZX81, la fonction "FAST" pouvait découpler le rafraichissement de l'écran… en affichant un écran noir et en allouant les cycle CPU au traitement de la programmation pur.
Donc, techniquement, il n'y a pas de buffer en RAM, mais une utilisation complète des ressources CPU pour privilégier la puissance de calcul.
Même chose pour la désactivation des IRQs et autres interruptions cyclophages…
Mais à cette époque, il était plus logique de sous-traiter les instructions numériques grâce à des coprocesseurs arithmétiques.
Le passage d'un XT à un DX était moins chère que l'ajout d'une RAM rapide… hors de prix.
Autre problème qui a été résolu par la suite, était la synchronisation du CPU, de la RAM cache et du BUS pour la carte vidéo.
Dans tous les cas, ces systèmes étaient des goulots d'étranglement qui ralentissaient la configuration.
Mais, si tu nous parles de "cache" sur le ZX81, la fonction "FAST" pouvait découpler le rafraichissement de l'écran… en affichant un écran noir et en allouant les cycle CPU au traitement de la programmation pur.
Donc, techniquement, il n'y a pas de buffer en RAM, mais une utilisation complète des ressources CPU pour privilégier la puissance de calcul.
Même chose pour la désactivation des IRQs et autres interruptions cyclophages…
Mais à cette époque, il était plus logique de sous-traiter les instructions numériques grâce à des coprocesseurs arithmétiques.
Le passage d'un XT à un DX était moins chère que l'ajout d'une RAM rapide… hors de prix.
Autre problème qui a été résolu par la suite, était la synchronisation du CPU, de la RAM cache et du BUS pour la carte vidéo.
Dans tous les cas, ces systèmes étaient des goulots d'étranglement qui ralentissaient la configuration.
Re: Et si....
Ce qui est amusant c'est genre un 386 ou un 486 sans cache...
Croyez moi, ça vaut le coup d'oeil. C'est... impressionnant. Perso je m'en servais (de le désactiver), pour jouer a des jeux DOS trop vieux devenus injouables sous 486. Et je vous dis pas les bench étaient parlant. La claque que se prenait la machine achetée 12000 francs à l'époque (486 DX2-66)
Croyez moi, ça vaut le coup d'oeil. C'est... impressionnant. Perso je m'en servais (de le désactiver), pour jouer a des jeux DOS trop vieux devenus injouables sous 486. Et je vous dis pas les bench étaient parlant. La claque que se prenait la machine achetée 12000 francs à l'époque (486 DX2-66)
- Papy.G
- Modérateur
- Messages : 3051
- Inscription : 10 juin 2014 13:40
- Localisation : Haute-Garonne/Gers
Re: Et si....
Je suis de l'avis de Xavier, si tout n'est pas homogène, c'est la maÿrde, mon expérience m'a démontré que les systèmes avec cache L2 en profitent pour avoir de la RAM plus lente, ce qui crée des contre-temps d'attente, il aurait mieux valu rester toujours sur des systèmes avec mémoire totalement synchrone.
Ayant utilisé des Macs depuis longtemps, j'ai pu observer que le LCIII était très réactif (même avant son OC à 33MHz), comparé à un IIvx (68030+68882@2x16MHz), ensuite, des essais sur la carte 604/132 de mon 7600 à 2*60MHz (sans la mémoire cache) m'ont confirmé cette impression, malgré une vitesse processeur inférieure à celle d'origine.
Après, chaque processeur est spécifique, et certains ont des instructions plus rapides pour aller dans une plage plus restreinte de la mémoire et y accomplir des tâches particulières (Page0 pour le 6502, instructions courtes des 8051 avec adressage 13bits…), mais dans ces architectures-là, on arrivait en général facilement à obtenir de la RAM assez rapide sans être hors de prix. Les optimisations étaient encore possibles sur les ratios cycle horloge/cycle instruction.
Donc, en fait, si c'est géré intelligement, c'est intéressant quand-même, et sur les architectures récentes, c'est indispensable, mais il reste des champs d'optimisations bien plus importants à l'heure actuelle (retour d'une programmation bas niveau…) et bien plus préoccupants pour l'avenir de l'informatique.
Xavier> Par contre, je ne trouve pas en quoi l'utilisation d'interruptions est cyclophage, bien au contraire, une entrée clavier ne coûtera du TM que lorsqu'elle a réellement eu lieu, contrairement à un polling systématique, qui, lui, coûte énormément de TM potentiellement pour rien. Si effectivement, dans un système, on utilise des interruptions pour générer un signal série bit par bit, une interruption de Watchdog ou pour la préemption d'un OS qui revient trop souvent, c'est n'importe quoi.
Ayant utilisé des Macs depuis longtemps, j'ai pu observer que le LCIII était très réactif (même avant son OC à 33MHz), comparé à un IIvx (68030+68882@2x16MHz), ensuite, des essais sur la carte 604/132 de mon 7600 à 2*60MHz (sans la mémoire cache) m'ont confirmé cette impression, malgré une vitesse processeur inférieure à celle d'origine.
Après, chaque processeur est spécifique, et certains ont des instructions plus rapides pour aller dans une plage plus restreinte de la mémoire et y accomplir des tâches particulières (Page0 pour le 6502, instructions courtes des 8051 avec adressage 13bits…), mais dans ces architectures-là, on arrivait en général facilement à obtenir de la RAM assez rapide sans être hors de prix. Les optimisations étaient encore possibles sur les ratios cycle horloge/cycle instruction.
Donc, en fait, si c'est géré intelligement, c'est intéressant quand-même, et sur les architectures récentes, c'est indispensable, mais il reste des champs d'optimisations bien plus importants à l'heure actuelle (retour d'une programmation bas niveau…) et bien plus préoccupants pour l'avenir de l'informatique.
Xavier> Par contre, je ne trouve pas en quoi l'utilisation d'interruptions est cyclophage, bien au contraire, une entrée clavier ne coûtera du TM que lorsqu'elle a réellement eu lieu, contrairement à un polling systématique, qui, lui, coûte énormément de TM potentiellement pour rien. Si effectivement, dans un système, on utilise des interruptions pour générer un signal série bit par bit, une interruption de Watchdog ou pour la préemption d'un OS qui revient trop souvent, c'est n'importe quoi.
Soyez exigeants, ne vous contentez pas de ce que l'on vous vend.
Demandez-en plus, ou faites-le vous-même.
Demandez-en plus, ou faites-le vous-même.
-
- Messages : 7964
- Inscription : 18 sept. 2010 12:08
- Localisation : Brest et parfois les Flandres
Re: Et si....
Et même le 68010 a eu un cache instruction rikiki permettant de "cacher" des boucles de 1 instruction:
Code : Tout sélectionner
loop:
move d0,(a0)+
dbra d1,loop
Samuel.
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
Re: Et si....
Vous n'y êtes pas trop les gars. Vous faites toujours référence à l'énorme chaîne hardware devant gérer le cache.
Ma question était un pur plan sur la comète, un "et si" donc.
Parce que ce plan est impossible à l'époque, on le sait tous. Des machines 8bits à prix exorbitant et des fois moins (Thomson, ZX, Alice etc) avait déjà du mal avec le prix des RAM, alors avec du cache... mais pire, avec le reste de la chaîne hardware pour gérer le cache donc... Alors mon truc ne peut pas exister (je veux dire, c'était pas une erreur stratégique, c'était tout bonnement irréalisable, impossible)
C'était juste sur : "Bein il aurait donné quoi un TO7 avec un cache ?" On aurait eus "autre chose" niveau production software ? Je sais pas, une machine plus fluide, tel jeu ou tel jeux radicalement différent ? (je pense au scrolling de Slap Fight par exemple. Etc)
Ce n'est que de la pure chimère. Après ce qui est intéressant, c'est de lire "Par contre sur les 8bits à quelques mhz le cache ne sert à rien car il n'y a pas de latence entre le cpu et la mémoire."
Grosso modo : cache ou pas cache, y aurait pas eus de gain dans tout les cas.
Intéressant non ? Au moins pour la projection...
Ma question était un pur plan sur la comète, un "et si" donc.
Parce que ce plan est impossible à l'époque, on le sait tous. Des machines 8bits à prix exorbitant et des fois moins (Thomson, ZX, Alice etc) avait déjà du mal avec le prix des RAM, alors avec du cache... mais pire, avec le reste de la chaîne hardware pour gérer le cache donc... Alors mon truc ne peut pas exister (je veux dire, c'était pas une erreur stratégique, c'était tout bonnement irréalisable, impossible)
C'était juste sur : "Bein il aurait donné quoi un TO7 avec un cache ?" On aurait eus "autre chose" niveau production software ? Je sais pas, une machine plus fluide, tel jeu ou tel jeux radicalement différent ? (je pense au scrolling de Slap Fight par exemple. Etc)
Ce n'est que de la pure chimère. Après ce qui est intéressant, c'est de lire "Par contre sur les 8bits à quelques mhz le cache ne sert à rien car il n'y a pas de latence entre le cpu et la mémoire."
Grosso modo : cache ou pas cache, y aurait pas eus de gain dans tout les cas.
Intéressant non ? Au moins pour la projection...
Re: Et si....
Ben le TO7, il n'aurait rien donné de plus.Ythunder a écrit : ↑12 févr. 2020 13:03 C'était juste sur : "Bein il aurait donné quoi un TO7 avec un cache ?" On aurait eus "autre chose" niveau production software ? Je sais pas, une machine plus fluide, tel jeu ou tel jeux radicalement différent ? (je pense au scrolling de Slap Fight par exemple. Etc)
C'est quoi, le 'cache' ? C'est de la mémoire rapide.
Et le TO7, c'est un 6809 à 1 MHz ; donc on aurait pu lui mettre de la mémoire hyper-hyper-rapide, ce n'est pas pour autant qu'il aurait tourné plus vite.
Il aurait toujours tourné à 1 MHz, donc pas plus vite.
Et si ma tante en avait ?...
Notator est le nom d'un programme séquenceur Midi et notation musicale pour Atari ST(e) (puis Mac).
Re: Et si....
La vitesse CPU ne fait pas tout.
300000 Mhz avec goulot d'étranglement dê a une gestion mémoire lente, bein...
Tu vois, on peut encore imaginer, non ?
300000 Mhz avec goulot d'étranglement dê a une gestion mémoire lente, bein...
Tu vois, on peut encore imaginer, non ?
Re: Et si....
Oui sauf que pour des µprocosaures comme le Z80, 6502 ou 6800, c'est exactement l'inverse qu'on a : des RAM super rapides qui s'impatientent que le CPU leur répondent. Alors pourquoi mettre des caches si ça complexifie le SMC et n'apporte rien en performance d'accès des données côté CPU ?
Re: Et si....
Ah bein alors j'ai la réponse a ma spéculation. Si c'est le CPU qui est en lag, j'ai la réponse !
Quid du 68000 ? (ST, AMIGA)
Quid du 68000 ? (ST, AMIGA)
-
- Messages : 7964
- Inscription : 18 sept. 2010 12:08
- Localisation : Brest et parfois les Flandres
Re: Et si....
Le cpu n'est pas fait pour une machine (ST ou amiga) mais l'inverse. Ce sont les concepteurs des machines qui choisissent le CPU dont ils ont besoin. Les ST et Amiga 500/600 tournent à 8mhz ce qui est largement en phase avec la vitesse de réponse de la mémoire de l'époque dont l'accès pouvait être même partagé avec d'autres chips sans soucis.
Le cache ne commence à être utile que si on rencontre un goulet d'étranglement lors des accès à la ram. Par exemple lorsque le DMA bloque cette dernière trop longtemps ou que le protocole sur bus de donnée est plus lent que ce que cpu attends. Par exemple: le 68020+ peut charger 32bits par cycle, or la ram des 500/600 se fait sur le bus zorro2 qui est 16 bits et qui introduit des latences de 1 cycle ou plus (les autres chipsets ont prorité sur le cpu). Pour éviter cela, le cache data et instruction du 68020+ est donc le bienvenu sur amiga dont l'accès à la mémoire est "mal foutu" du point de vue matériel (il a été concu pour le 68000 à 8mhz mais inadapté aux 020 à 14Mhz+).
Maintenant, si on veut chipoter, 256 octets c'est vraiment pas bezef comparé à ceux des intel en face. Globalement les mc680x0 n'ont jamais eu de gros caches ou plusieurs niveaux de caches. Il faut dire que c'est un cpu avec pleins de registres, et tout codeur qui se respect sait que le cpu ne va jamais aussi vite que lorsqu'il utilise ses registres internes en lieu et place de la mémoire. C'est là qu'on voit que les intels souffrent de leur coté de ce manque de registres et utilisent intensivement la mémoire d'où la nécessité d'avoir de gros caches, et même plusieurs niveaux sur ces machines. Les 68k n'ont pas ce défaut.
Une autre game de machine a fait le choix d'éviter les cache mémoire en privilégiant les registres. Ce sont les cpu ARM de l'époque. A ce propos voici une interview d'un des concepteurs de l'ARM:
On y apprends, si je me souviens bien, que leur façon de concevoir le cpu était d'optimiser au mieux les accès à la mémoire car c'était elle qui était sous-exploitée à l'époque (on est vers le milieu des années 80 je crois).
Le cache ne commence à être utile que si on rencontre un goulet d'étranglement lors des accès à la ram. Par exemple lorsque le DMA bloque cette dernière trop longtemps ou que le protocole sur bus de donnée est plus lent que ce que cpu attends. Par exemple: le 68020+ peut charger 32bits par cycle, or la ram des 500/600 se fait sur le bus zorro2 qui est 16 bits et qui introduit des latences de 1 cycle ou plus (les autres chipsets ont prorité sur le cpu). Pour éviter cela, le cache data et instruction du 68020+ est donc le bienvenu sur amiga dont l'accès à la mémoire est "mal foutu" du point de vue matériel (il a été concu pour le 68000 à 8mhz mais inadapté aux 020 à 14Mhz+).
Maintenant, si on veut chipoter, 256 octets c'est vraiment pas bezef comparé à ceux des intel en face. Globalement les mc680x0 n'ont jamais eu de gros caches ou plusieurs niveaux de caches. Il faut dire que c'est un cpu avec pleins de registres, et tout codeur qui se respect sait que le cpu ne va jamais aussi vite que lorsqu'il utilise ses registres internes en lieu et place de la mémoire. C'est là qu'on voit que les intels souffrent de leur coté de ce manque de registres et utilisent intensivement la mémoire d'où la nécessité d'avoir de gros caches, et même plusieurs niveaux sur ces machines. Les 68k n'ont pas ce défaut.
Une autre game de machine a fait le choix d'éviter les cache mémoire en privilégiant les registres. Ce sont les cpu ARM de l'époque. A ce propos voici une interview d'un des concepteurs de l'ARM:
On y apprends, si je me souviens bien, que leur façon de concevoir le cpu était d'optimiser au mieux les accès à la mémoire car c'était elle qui était sous-exploitée à l'époque (on est vers le milieu des années 80 je crois).
Samuel.
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos