samedi 10 septembre 2016

Le PPC c'est nul

Lorsque j'affirme haut et fort sur les forums que le PowerPC est d'une nullité totale et absolue, certaines personnes voulaient des preuves, ce qui est bien naturel !

Moi aussi j'ai été berné à l'époque de la BlizzardPPC : ADoomPUP tournant à 35/36 fps était très impressionnant. Je croyais aussi que les PPC était mieux que les 68k, et qu'ils étaient l'évolution de la gamme 68000...

C'est alors que je commença a étudier le PowerPC de plus près, allant même jusqu'à imprimer les .pdf dans des classeurs...

Je suis tombé de très haut : le PPC est bien inférieur aux 68k, mis à part peut-être la partie Fpu qui apporte quelques nouveautés positives. Il faut être codeur pour voir et comprendre cela.

Bref, j'ai perdu beaucoup de temps et d'argent (les .pdf étaient imposants...) : tout cela pour m'enfermer (moi et tous les autres programmeurs...) dans un nouvel univers PPC sans aucun avenir, ce nouveau CPU étant d'une nullité affligeante et n'activant en RIEN la passion comme les 68k la déclenchait. Seule la carotte de l'argent peut forcer les programmeurs à produire des logiciels pour PPC, rendre tout commercial en quelque sorte...

L'équipe Phase5, surtout leurs codeurs qui savaient que le PPC était beaucoup moins bien que les 68k, voulaient mettre les utilisateurs de PPC dans une voie sans issue, de façon à les détourner du 68k afin de bloquer toute évolution des Classics : détruire l'ancien génial 68k pour vendre alors la nouvelle camelote PPC aux utilisateurs... Peu importe que ça soit de la merde, seul compte le profit ! Diviser la communauté pour mieux régner.

Empêcher par tous les moyens possibles l'évolution des 68k, software comme hardware d'ailleurs, la vieille stratégie du détournement de l'énergie dans une voie voulue sans aucune issue... Le tout pour faire plaisir à la concurrence qui veut le monopole, d'ailleurs d'où vient l'argent de Bill Buck et de Trevor Dickinson ?

Prenons un exemple très simple, une fonction de l'exec.library : Forbid. Elle est minuscule, très simple à comprendre :

Elle pèse 6 octets (6 * 8 = 48 bit) dans le Kickstart et utilise deux instructions.

Cette fonction 68000 effectue :
  • une addition (TDNestCnt + a6)
  • une lecture dans la mémoire
  • une addition (1 + le contenu de TDNestCnt(a6))
  • une écriture dans la mémoire (TDNestCnt(a6))
  • et un retour (rts)
  • n'utilise qu'un seul registre (a6)

Maintenant voyons l'équivalent PowerPC dans OS4, vous savez le CPU soit disant no-risc/no-fun :

Elle pèse maintenant 20 octets (20 * 8 = 160 bit) et utilise 5 instructions.

Cette fonction PPC effectue :
  • une lecture de 16(r3) dans r11
  • une lecture de TDNestCnt(r11) dans r9
  • une addition de 1
  • une écriture du résultat r9 dans TDNestCnt(r11)
  • et un retour (blr)
  • utilise 3 registres (r3, r9 et r11)

Vous montrez ça à n'importe quel codeur, il se mets à hurler devant tant de nullité...
   
Le PPC n'est en rien une évolution du 68k comme Phase5 et compagnie voulait le faire croire, c'est en réalité tout le contraire... En rien un "power up", ils jouent avec les opposés et les inverses : faire croire que c'est bien alors que c'est nul... Rattraper la daube avec des fréquences plus hautes...
  
Bref, leur objectif principal était d'empêcher une nouvelle fantastique machine de voir le jour, à base de 68k rapide et de AAA dans la continuité logique des ingénieurs de Commodore : des dizaines de millions d'euros volontairement engouffrer dans du vent depuis 16 ans (Efika, Pegasos 1, Pegasos 2, AmigaOne PCI, AmigaOne, micro AmigaOne, Sam, X1000, X5000, Tabor...) qui n'iront pas dans un Amiga Classic plus évolué...
  

11 commentaires:

  1. Suis d'accord, le PPC n'a rien à faire dans l'Amiga qui doit rester un ordinateur 68k.

    RépondreSupprimer
    Réponses
    1. Oui, il nous faut un 68k rapide à 400 Mhz (équivalent en gros à un PPC ou x86 à 1 Ghz) et un AGA bien amélioré : l'ordinateur quasi-parfait en somme !

      Supprimer
    2. 68K@400Mhz == x86@1GHz ??? je ne sais pas d'où tu tiens cet argument. Pour rappel le x86 et le 68k ont en commun une ISA CISC. La différence, c'est que le véritable coeur du x86 n'est plus un CISC : il a l'avantage de la compression des instructions et l'avantage du nombre de MIPS des RISC out-of-order. Je suis a peu près certain que si ou pouvait reprendre le vrai coeur d'un X86 actuel et lui donner à décoder du 68K au lieu du x86, on obtiendrait des performances très similaires qui blasteraient le PPC, le 68080 de Vampire et cie : on garderait la compacité du code 68K et la vélocité d'un RISC out-of-order. Le CISC a lui tout seul ne suffira pas.

      Supprimer
    3. C'est une évaluation de ma part "à la louche", bon qui vaut ce qu'elle vaut : c'est faiblard le microcode x86, peu de registres, beaucoup d'accès à la pile, des caches à flusher...

      Supprimer
    4. [NOTE: attention je ne cherche pas à convertir qui que ce soit ou à créer une guerre religieuse sur qui est le meilleur - ce n'est absolument pas mon propos]

      Je ne sais pas quelle est ta connaissance de l'ISA x86. Ce que tu décris comme faiblard, c'est peut-être le code 16-bit d'antan.
      - En 64-bit, tu as quand même 16 x 8/16/32/64-bit GPR et 16 x 128/256-bit VPR (32 x 128/256/512-bit si le CPU embarque de l'AVX512). Avec un nombre d'instructions par cycle horloge et par coeur entre 8 et 10. Pour comparaison, le 68060 fait 1,3.
      - Les arguments de fonction vont dans les registres en priorité (et encore ce n'est qu'un question d'ABI : tu peux le faire à ta sauce).
      - Le FPU x87/MMX bien que toujours présent est "abandonné" au profit du SSE/AVX. De plus, avec le SSE/AVX, tu peux faire des opérations parallèles sur des éléments en 8/16/32/64-bit (entier ou réel).
      - Les caches à flusher ? jamais vu ça. Le flush est automatique (sauf à l'interdire pour certaines adresses MMIO par exemple) : un autre coeur peut lire ce qu'un coeur a écrit sans flush explicite - de préférence en protégeant l'accès avec un préfixe LOCK dans le cas d'un accès concurrentiel entre les coeurs.
      - Alors oui, il y a les préfixes qui peuvent allonger le nombre d'octet par instruction. Mais ça n'a pas d'incidence sur le cycle d'exécution. Seul incidence sur le I-cache peut-être mais encore vu leur taille. En fait, la taille en octet et le nombre d'instructions auront beaucoup moins d'incidence que sur un 68060.

      Une implémentation réelle en CISC n'est plus possible si on veut augmenter les fréquences et l'IPS. Tu reprends l'implémentation d'un coeur Intel/AMD et tu remplaces le décodeur X86 par celui d'un 68K, les fans du 68K seraient aux anges. Mais voilà il n'y a pas d'enjeu économique à le faire.

      Supprimer
    5. D'une façon "globale" avec Windows l'OS obèse, ma comparaison d'avec un WB 3.9 s'approche du 400 Mhz / 1 Ghz...

      Difficile de comparer de toutes les façons, machines trop différentes...

      Après, le microcode x86 est totalement nul : c'est du vitefaitmalfait de A à Z : aucune envie d'avoir des connaissances là-dedans, c'est trop médiocre...

      La plupart des CPUs même si je ne les connais que de très loin ont été créé par des ingénieurs qui ne connaissent rien à la programmation : ça se voit de suite avec le PPC par exemple.

      Et le problème est bien là : il faudrait plutôt que ça soit les bons coders qui pondent les CPUs... Ou plutôt les GPUs maintenant qui sont devenus plus importants que les CPUs...

      Bref, pour moi, seuls les 68k sortent du lot : simple à apprendre, facile à retenir après un temps d'apprentissage, un grand plaisir à programmer en asm et surtout une foule d'optimisations en tout genre à trouver pour ceux qui savent chercher : le paradis quoi !

      Supprimer
  2. Cosmos, en plus de la cpu plus rapide, le reste aussi: controleur memoire, bus avec les divers controleurs...

    RépondreSupprimer
  3. La seule vraie question qui devrait être posée : combien de cycles d'horloges sont nécessaires dans les deux cas ?

    RépondreSupprimer
    Réponses
    1. Aucune importance : j'explique la différence entre un CPU passionnant & simple à coder et un autre déprimant & difficile à programmer...

      Pour qu'une machine vive, il faut des coders : donc, plus le CPU est bien fait, plus il y aura de programmeurs, plus il y aura de logiciel, et plus les utilisateurs seront ravis !

      Supprimer
  4. On peut en effet voir les choses comme ça, même si le code PPC ne doit pas tomber bien loin du microcode 68K qui correspond au add quick. Bonne continuation.

    RépondreSupprimer

Posté vos remarques :