Quand je mourrai, j'espère qu'il restera mon blog Amiga ! En attendant, voici quelques unes de mes techniques d'amélioration de code, que mes expériences servent à d'autres, serait dommage que tout cela se perde...
Rassurez-vous, les 68k sont éternels, car trop bien. Les V2 et V4 ont été développées pour empêcher tout retour des vrais CPUs mythiques, pomper l'énergie de la communauté Amiga Classic, et bien sûr mettre leur éventuel futur sous contrôle des franc-maçons/illuminati de l'Apollo Team. Le tout pour obliger l'achat de leur carte V2 et ainsi forcer les acheteurs à devenir complice de cette trahison qui ne mènera nulle part, tout comme d'ailleurs MorphOS, OS4, Aros... Des voies sans issue voulues depuis le tout début...
Bref, voici la routine RTG d'AmiQuake2 générée par gcc :
L'air de rien, il y a à faire. Commençons par les disgracieux link a5/unlk qui peuvent aisément être remplacer par des accès directs à la pile. Il suffit d'inverser en commençant par la fin :
Ensuite, les deux move/muls peuvent être remplacés par un move.l #320x200,d0 puisque nous savons que l'unique écran RTG disponible pour le jeu fait 320x200 pixels. Récupérons aussi le pointeur de _LockBitMapTagList sur la pile pour éliminer définitivement a5 :
Ensuite, il est tout à fait possible et conseillé d'inliner le _CopyMemQuick et de ce fait supprimer le chargement de l'ExecBase dans a6. Ensuite, le __CyberGraphXBase,a6 peut être éliminé. d2 également, plus besoin puisque le résultat d0 est toujours dans d0 :
Voilà le résultat des courses avec tout de même 34 octets de code à la poubelle. Et avec le _CopyMemQuick supprimé qui permet de gagner encore de nombreux octets :
Cette routine est maintenant épurée de tout l'inutile. Il est possible peut-être de gagner quelques cycles en préloadant 4 lignes de data cache pour ensuite faire les copies. J'ignore si le gain est négligeable ou important :
Alors, dans le code réel, est-ce qu'un speed up est observable pour l'oeil humain ou dans quelques benchmarks ? Difficile de répondre à cette question, car de nombreux paramètres software et hardware entrent en jeu. Le principal but de cet article est aujourd'hui ici surtout pédagogique...
EDIT : mon testeur me donne un nouveau screenshot avec un gain de seulement 0.1 fps avec cette nouvelle routine, ce qui est fort peu ! Et même résultat avec le preload :
Sa config : A3000T avec CyberStormPPC 060@72 et Prometheus avec Voodoo3
Nous sachons !
RépondreSupprimerTu es sérieux sur ce que tu écris sur cette page.
RépondreSupprimer0.1 fps est ridicule.
Oui c'est très peu, et alors ?
SupprimerL'important c'est la qualité du code dans cet article.
Modifier un code pour avoir 0.1 fps de performance sur une architecture CISC 16/32 des années 1979 à 1990 par Motorola dans une plage de fréquence 2 MHz à 12 MHz.
SupprimerAu niveau performance, c'est pas vraiment sérieux.
Le 68K a une limite de 68 000 transistors, d'ou son nom.
Sachant qu'en 1989, un processeur embarqué 1 200 000 transistors sur une plage de fréquence 16 à 100 MHz.
Par conséquent, il était impossible de penser qu'il aurait pu continuer d’être produit après les années 90.
Aujourd'hui, un processeur est cadencé à 5Ghz et atteint 1 TFLOP avec 64 blocs de calcul.
Le 68060 a une limite de 1 000 Flops contre de 1 000 000 000 000 Flops en 2019.
En 2018, un processeur disposé de plus de 10 milliards de transistors.
Le 68000 est du passé et plus que dépassé.
Croire autre chose est une illusion.
Tu as un niveau de conscience bas déjà : cherche à l'élever !
RépondreSupprimerEnsuite, j'ai clairement écrit que le but de cet article est éducatif : nous avons maintenant une routine _CopyToScreen parfaite, ce qui n'était pas du tout le cas avant avec gcc. Peu importe le résultat de 0.1 fps...
Ce 0.1 fps est dû au fait de la faible importance de cette routine dans le programme global. D'autres routines dans mon source désassemblé d'environ 400 000 lignes sont bien plus cruciales que celle-ci, bien entendu, comme les sinus/cosinus par exemple... J'ai pris cette _CopyToScreen car elle était toute petite et s'optimisait plutôt bien...
Cherche à comprendre avec tes 3 neurones au lieu de raconter et de croire n'importe quoi : c'est pitoyable de ta part ! Relis ce que tu écris avant de poster... Tu te ridiculises toi-même...
Pour finir avec ton PC : tu ne connais que très peu l'informatique côté technique, ça se voit de suite. Par exemple, quand je vois qu'il faut 3 Ghz de CPU pour lire une vidéo et faire fonctionner Windows 10 correctement, je rigole...
@ Anonyme :
RépondreSupprimer0.1 sur 8fps, ça fait quand même 1.25%.
Si ce chiffre n'est rien, demande aux impôts de te prélever 1.25% de plus et on en reparle :-)
En fait cet article, c'est surtout pour montrer qu'une toute petite routine en apparence anodine peut être bien retravaillée, car 34 petits octets de gagnés ici, c'est beaucoup en réalité...
Supprimer