1

In reply to: ASM: Peut-on utiliser r2 ?

#32098

krabob a écrit :

les 680×0 et les PowerPC ont des fonctionnement suffisament différents pour bouleverser des régles d’optimisations.

C’est tout à fait exact.

Les optimisations qui était trés effective en 680×0 le sont moins ou plus du tout en PowerPC. Je suis géné par le grapillage de r2, car c’est un raisonnement vraiment ‘68000’, comme le dit crisot le gain va être de l’ordre du 0.002%, alors que se concentrer sur des optimisation de structurations mémoire te fera facile des gains de 10% ou 40%.

C’est généralement vrai aussi. Je dis généralement parce que dans le cas qui m’interresse, très particulier, le gain peut être notable.

aligne tes structures, et rassemble les champs qui sont en méme temps en lecture sur des lignes de caches, et ceux en écriture sur d’autres( selon la passe), utilise dcbz, etc…

C’est classique, mais cela ne concerne pas du tout l’algo dont il est question.

En powerPc (ou intel), parfois plus d’instruction assembler = plus de vitesse. sur mes textures mapping, j’avais 4 instructions en plus par accés texture pour scrambler la mémoire de celui-ci, plus une gestion de mip mapping et ça allait 40%plus vite comme ça (cache plus effectif) , pasque simplement ça fluidifiait les accés mémoire ! pourtant ya 4 ou 5 pages d’instructions en plus, et là les GPR ils tournent. Ben si si, 40%.

Cette méthode permet aussi d’améliorer le degré de parallélisme du code, et donc de profiter au mieux de l’architecture superscalaire. C’est d’ailleurs la raison du “software pipelining” massif utilisé pour implémenter l’algo dont il est question.

Sinon , quand on en est a grapiller comme ça en asm,

ça devient pathologique. Il y a forcement une meilleure maniére pour optimiser ton algo, mais pas celle là. En plus tu ne pourras jamais mesurer le micro-gain, et pour une bonne raison: il n’a aucun sens par rapport au fonctionnement réel.

Si on veut. Ceci dit, l’utilisation de l’asm n’a qu’un seul but : obtenir les performances maximales. C’est la seule justification valable (en dehors du cas très particulier d’un BIOS, par exemple). Si une fonction asm n’apporte qu’un gain négligeable, elle ne mérite pas d’être écrite en assembleur, parce que c’est une perte de temps inutile. En revanche, si le gain est conséquent, l’effort consenti mérite d’être poussé jusqu’à son terme pour justifier pleinement ce choix. Si on se contente d’une optimisation “moyenne”, on peut se poser la question de savoir si l’absence de gain est tolérable et donc remettre en cause la nécessité d’utiliser l’asm.

Sinon j’ai écris 2 articles sur gurumed là dessus.

Je me permet de dire de vous que vous êtes pathétique, car tout ça, c’est pour casser des clefs machin: c’est du mesurage de bite entre male, et ça ne sert a rien d’autre qu’a faire perde du temps à des gens débousolé.

Faire un encodeur MPEG-A qui va plus vite que les autres, c’est aussi du mesurage de bite. Vu sous cet angle, toute optimisation tend vers le même but : avoir mieux que le voisin.

Ceci dit, je ne te permets pas de critiquer un projet sous le seul prétexte qu’il ne t’interresse pas. Et si casser des clés semble inutile, il n’en demeure pas moins que le classement de la Team Amiga lui fait un sacré coup de pub.

Mais tout ceci est hors sujet. La question initiale était pourtant claire, et je ne vois pas du tout pourquoi même les sujets les plus simples partent en vrille aussi rapidement. Ca c’est pathétique !

In reply to: ASM: Peut-on utiliser r2 ?

#32092

@krabob

Si c’est pour le prendre sur ce ton, ça va être vite réglé : quand tu aura 25 ans de programmation en assembleur derrière toi, tu pourra peut-être essayer de m’expliquer quelque chose.

Ce que j’explique, mais que tu t’obstine à ne pas comprendre, c’est qu’avoir un registre de moins coute quelque chose. A titre d’exemple, il suffit de perdre 1 cycle sur un core G4 (AltiVec) tournant à 1.25 GHz pour perdre l’équivalent d’un 68040/40.

Par rapport aux performances brutes d’un G4, c’est négligeable (0,25%). Mais négliger ce gain revient à insulter ceux qui utilisent leur 68040 pour participer au même projet puisque leur contribution se voit rabaissée au rang de quantité négligeable, en plus de renier l’interêt initial qui est d’obtenir les performances maximales.

Quand on fait de l’assembleur, on le fait bien ou on ne le fait pas. Et le faire bien, ça veut dire jusqu’au bout (performance) et en respectant les régles élémentaires (si r2 est réservé, on n’y touche pas <== ça c'est pour Crisot).

In reply to: ASM: Peut-on utiliser r2 ?

#32090

@krabob

Ca ne m’amuse pas vraiment de n’avoir que 30 registres (vu que r1 et r2 sont réservés à autre chose) lorsqu’il m’en faudrait au bas mot une soixantaine. Un registre de moins, c’est automatiquement un load et un store en plus (au minimum).

Et on ne peut pas faire autrement. Le code est constitué d’une boucle dépliée, laquelle enchaine 74 blocs composés de 6 instructions dont l’ordre est immuable (dépendances entre instructions, voulues par l’inventeur de l’algo). L’essai de décodage avec une clé RC5 suppose la manipulation de 29 données 32-bit, auquelles s’ajoutent des variables annexes (peu nombreuses, mais on est déjà à la limite).

Du fait des dépendances entre instructions, le code basique (tel que généré par GCC) n’utilise pratiquement qu’un seul pipeline, alors qu’il est possible d’exploiter 2 IU simultanément (sur 603e/604/750) pour doubler les perfs. Cette solution suppose qu’on teste 2 clés en parallèle pour faire sauter les dépendances et autoriser l’exécution dans 2 pipelines (software pipelining), ce qui double le nombre de registres nécessaires. Cette optimisation est déjà exploitée par le core G2/G3, mais pas forcément de façon optimale.

Dans ces conditions, un registre de moins est synonyme de performances dégradées. Et ça, j’aime pas

In reply to: ASM: Peut-on utiliser r2 ?

#32085

Ok, vous fâchez pas !

Le fait est que r2 n’est pas utilisé sous Mac OS X (pas de TOC), et est donc libre d’emploi (documenté comme tel). Je sais que d’autres ABI réservent ce registre pour pointer la TOC. Dans ce cas de figure, comme il s’agit d’une leaf procedure n’ayant aucun besoin de cette TOC, on peut imaginer pouvoir utiliser ce registre (à condition de sauvegarder son contenu).

D’un autre côté, ce même registre étant explicitement documenté comme étant réservé pour le système (par ces ABI), j’ai vite pensé qu’une interruption pouvait en avoir besoin, d’où un conflit d’interêt.

Quoiqu’il en soit, GCC n’est pas la réponse. Il s’agit de code ASM écrit à la main de façon à être le plus performant possible (GCC est totalement incapable de générer un code aussi efficace, et de loin). Je vais donc envisager une version n’utilisant pas r2, mais elle sera un poil moins performante

Pour info, j’essaye de voir si je ne peux pas optimiser un peu plus les cores RC5 (d’où l’inefficacité de GCC)

In reply to: iDefrag (arghhhhhhhhhhhhhh)

#31808

Mac OS X défragmente à la volée la plupart des fichiers (ça dépend de leur taille et du nombre de fragments). De mémoire, il faut plus de 8 fragments pour qu’un fichier soit pris en compte. Je ne me souviens plus de la taille maximale par contre (quelques Mo ?).

Ceci dit, la défragmentation automatique des fichiers ne résoud pas le problème du morcellement de l’espace libre. Seul un outil dédié permet de déplacer les fichiers de façon à obtenir un espace libre monobloc.

In reply to: choper les stackoverflow sous morphos/gcc

#28951

Lanza a écrit :

Heuu, quand tu appelles une fonction Intuition telle qu’OpenScreen(), même si le code est celui de la lib, la tâche en cours reste la tienne et a donc accès à ses données privées. Libre ensuite à OpenScreen() d’en faire une copie en espace public pour les passer aux tâches du système. Ce qui est d’ailleurs plus ou moins déjà fait puisqu’elle te retourne une struct screen allouée par ses soins.

D’accord, mais cela ne résoud en rien le fait que la copie doit pouvoir prendre en compte les nombreux pointeurs vers d’autres objets (le problème général étant ces pointeurs). D’autre part, en l’état actuel des choses, le code de la bibliothèque (et accessoirement les données “privées” de celle-ci) est accessible par n’importe quelle tâche, ce qui remet en cause la protection de cette bibliothèque, et donc celle de l’OS au sens large.

La difficulté n’est pas de trouver une parade à un problème précis. Elle est de trouver une parade qui ne remet pas en cause les solutions apportées à d’autres problèmes, ce qui nécessite d’avoir une vision plus globale du système. Ainsi, si on veut vraiment protéger l’OS, il faut commencer par isoler les bibliothèques du contexte des tâches, faute de quoi la perte d’une bibliothèque entraîne les autres tâches clientes et l’OS dans sa chute. A partir de là, les solutions disponibles pour transmettre les informations entre différents contextes sont passablement réduites. Abuser de la mémoire publique remet en cause la protection d’un point de vue global, et ce n’est pas (à mon avis) la bonne solution. Il ne reste donc que la copie intégrale (dans la plupart des cas), laquelle est actuellement difficilement réalisable à cause des nombreux pointeurs qui “polluent” les différents objets manipulés, lesquels ne disposent pas de “constructeurs de recopie” susceptibles d’effectuer cette opération. D’autre part, la séparation des contextes impose d’avoir de nombreux accesseurs pour lire ou modifier des données “étrangères”.

Maintenant, tout dépend du but recherché. S’il est possible d’avoir une protection minimaliste sans trop d’efforts, une vraie protection n’est pas réalisable sans devoir changer tout un tas de choses. Et quand je dis protection minimaliste, je suis gentil…

In reply to: choper les stackoverflow sous morphos/gcc

#28947

krabob a écrit :

Hier soir j’ai pris vingt minutes pour parcourir exec.doc et ses .h Et je trouve que des choses évidentes apparaissent.

Rappel: exec a du être fait vers 1985 par sassenrath et à cette époque UNIX avait dejà la mémoire protégée. de plus

il est evident qu’amigaOS s’inspire d’UNIX dans son noyau. en 85, les 68000 n’avaient pas de MMU. il était évident que les 68000 évolueraient vers du MMU.

Je confirme qu’Exec pose les bases d’un tel système, du moins depuis le Workbench 2.0 (si ma mémoire est bonne, c’est à cette époque qu’est apparu le symbole MEMF_PUBLIC et les conseils d’utilisations associés). Néanmoins, la documentation liée à Exec (notament le RKRM) persiste à autoriser certaines choses incompatibles avec la protection mémoire. Je n’ai plus d’exemple précis en tête (ni les docs pour en retrouver), mais la simple présence des macros Forbid, Permit, Disable et Enable, entre autres, met en évidence le manque de rigueur. Ces macros suggèrent que la mémoire utilisée par l’exec.library doit être accessible par tout le monde, donc non protégée.

J’admets que l’exemple est simpliste, faute de mieux. S’il existe des fonctions encapsulant ces fonctionalités, il n’en demeure pas moins que des macros, documentées, permettent de s’en affranchir.

Partout on a la notion de “fabrique” (au sens des design pattern, gestionnaire encapsulé qui crée et détruit des objet.) comme dans un systeme protégé. Par exemple, pour créer un écran, tu donnes à OpenScreen() une description (taglist) privée, et on te renvoie un pointeur vers une mémoire publique, dont la logique

est d’etre en lecture seule pour la tâche. et on a une fonction de destruction: CloseScreen()

La notion de “fabrique” vient des systèmes orientés objets, et permet l’abstraction nécessaire à l’évolution sans douleur de l’OS (modification de l’objet fabriqué). L’exemple d’OpenScreen() me ramène au paragraphe précédent : IIRC, OpenScreen() demande une structure NewScreen, laquelle contient bon nombre de pointeurs vers différentes choses, dont une taglist optionnelle. Via cette fonction, on demande donc à l’intuition.library de construire un “écran” à partir de données réputés privées (celles adressées par ces pointeurs). A moins de décréter que ces objets doivent être alloués dans une zone publique, ce qui exclu d’office les objets statiques.

Le terme de mémoire publique signifie que les données sont accessibles par plusieurs tâches sans gestion particulière. Cela ne veut pas nécessairement dire que ces données sont seulement accessibles en lecture.

Je me suis interessé aux messages que tu dis si sensible: dans exec, on a CreateMsgPort() et DeleteMsgPort() pour créer des ports de gestion de message. On manipule juste leurs pointeurs: gestion encapsulé en public,et justement

les messages pointent ces ports. Et exec.doc nous met en garde de pas bricoler son port soit meme,comme par hazard.

Certe, mais un message ne contient généralement pas que cette structure. Il est souvent utilisé pour transmettre des données à une autre tâche, et ce sont ces données annexe qui posent un problème lorsqu’elles comportent des pointeurs (et ça, l’OS ne peut pas le deviner). Si on veut être certain que la tâche destinataire soit capable de récupérer l’ensemble des données, il faut tout mettre en mémoire publique (à défaut d’avoir un système autrement plus compliqué et capable de gérer ça tout seul grace à de vrais objets, au sens OO du terme).

Je me suis ensuite interessé a PutMsg() qui permet d’envoyer des messages alloués sois-meme en privée, donc qui

pourrait poser probléme. Je me suis d’abord aperçu qu’en 6 ans de prog systeme je ne l’ai jamais utilisé !

Il n’empêche que cette fonction est documentée, donc parfaitement utilisable. C’est le cas d’autres fonctions (les exemples ne manquent pas), et c’est l’un des aspects qui m’a fait dire qu’il fallait revoir en profondeur tout l’OS pour éliminer les fonctions incompatibles avec la mémoire protéger, revoir la documentation, etc.

Mais voilà, dans cette struct il faut forcément remplir nm_Length,

qui contient la taille de la structure. Cela permet potentiellement à l’OS de la copier vers une struct publique a l’execution de PutMsg().

D’accord, mais le système reste “bancal”. On ne peut pas effacer PutMsg() d’un coup de baguette magique (c’est toujours documenté), et ça ne résoud pas le problème des pointeurs contenus dans l’objet transféré par message. Le problème basique des pointeurs contenus dans des objets est soulevé dans toutes les docs traitant des systèmes orientés objets, d’où la nécessité des constructeurs de recopie en C++ par exemple. Ce type de constructeur n’existe pas au niveau des API.

Pourquoi les concepteurs amiga aurait spécifié de remplir ce champs depuis 1985 alors qu’il est inutile dans une contexte non protégé ? Parce qu’ils avaient prévu de basculer tout amigaOS en protection mémoire c’est évident. Tout les exemple utilisant PutMsg remplissent ce champ.

Je ne dis pas le contraire. Exec est certainement la partie la plus aboutie dans ce domaine, même si ce n’est pas suffisant. Sassenrah a débrousaillé le terrain, mais il reste beaucoup à (re-)faire y compris dans Exec.

Le problème principal est que ce système (recopier des msg) impose d’incessantes recopies de données lors

des communications entre tâches et accessoirement entre une tâche et l’OS (si nécessaire). C’est synonyme de ralentissement au niveau des API de communication inter-processus, et c’est la raison principale qui fait que l’AmigaOS et ses dérivés sont plus réactifs que les OS “protégés”

je ne suis pas d’accord du tout, tu résonnes en 68000,un cpu sans cache, ou meme le code executé devait passer systematiquement par le bus lors de l’execution, ou la moindre lecture/ecriture passait du cpu a la ram. Si les autres OS ne sont pas réactif, c’est à cause de leurs politiques de memoire virtuelle qui va meme cacher de la memoire video, avec des notions de priorité pas applicables (windows).

Heu… Je ne vois pas le rapport, étant donné que les caches n’ont rien à voir là-dedans pour la simple et bonne raison qu’on ne peut pas garantir que les données soient dans toujours dans le cache quand on en a besoin (une bête interruption au mauvais moment peut changer la donne radicalement).

Dans le cas de recopie de message: On a UNE SEULE COPIE DE STRUCTURE PAR CREATION DE MESSAGE vers une mem publique, pas plus !!, et ces structs sont de taille minimale ! le PowerPC quand il switche de contexte de tache ( un nombre important de fois par seconde,meme sans protection) doit empiler/depiler 384 octet de regsitres, et au moins la moitié a chaque saut de fonctions !!

ainsi Les flux mémoires du au simple fonctionnement du PPC sont énormément plus volumineux et fréquent qu’une copie de struct de temps en temps.

Je n’ai pas quantifié l’impact. Le fait est qu’avoir des opérations supplémentaires induit obligatoirement un ralentissement. En dehors de ça, tout est question d’argumentation, pour ne pas dire de polémique.

Les implications d’une protection mémoire vont bien au delà de ce simple problème de recopie.

et considérez ceci:

dans un systeme non protégé PowerPC, la lecture d’une struct en cache prend un certain temps (lecture).

La recopie de la méme struct vers une plage publique peut se faire avec dcbz (en interne): dans ce cas, la copie

prend PRESQUE AUTANT de temps que la lecture seule de la struct du message !!!

Oui, si on considère que cette structure est toujours dans le cache au moment où on en a besoin. Sinon, il faut la récupérer en RAM, et c’est BEAUCOUP plus lent.

La protection mémoire n’est pas l’ennemie de la réactivité !!! faut arreter de penser 68000 !!! La protection mémoire sous AMigaOS est possible et on l’aura !

Elle n’est pas l’ennemie de la réactivité, mais elle réduit nécessairement cette réactivité dans des proportions qui restent à déterminer. Tout dépend de quel niveau de protection on parle, et comment cette protection est globalement implémentée au niveau de l’OS.

En l’état actuel des choses, un embryon de système pourrait éventuellement être implémenté en ayant recours massivement à la mémoire publique (donc non protégée). Efficacité mitigée garantie puisque beaucoup de choses seraient alors accessibles par beaucoup de tâches différentes.

Pour une vraie protection, il faudrait impérativement débarrasser les APIs de toutes les fonctions posant un problème de fond (utilisation d’objets contenant des pointeurs vers d’autres objets), revoir la documentation pour en expurger la totalité des passe-droits (accès directs à certains membres) et donc ajouter des “accesseurs”. Il faudrait aussi se diriger vers une approche OO plus poussée, notament pour proposer des constructeurs de recopie adaptés. Il faudrait préciser les notions de propriété et de responsabilité envers les objets manipulés. Il faudrait revoir le principe des bibliothèques partagées (actuellement en mémoire publique), des “devices” et autres “handlers” pour les protéger des applications (faute de quoi n’importe quelle tâche peut faire écrouler l’OS). En bref, un énorme travail de fond lequel ne peut pas se faire sans casser des oeufs (compatibilité).

Au final, un tel OS serait tellement différent, avec des règles plus strictes et une nouvelle façon de programmer, qu’il n’aurait probablement qu’un rapport assez éloigné avec l’OS actuel (même s’il est possible d’en garder l’esprit).

In reply to: Upgrade 68040 -> 68060

#19499

Le MMU est indispensable pour pouvoir configurer correctement les caches en fonction des zones mémoire (CHIP RAM, espace Zorro II, espace I/O, etc). Si mes souvenirs sont bons, les version EC ne disposent que d’une paire de registres apte à “émuler” en partie un MMU en ce qui concerne le mode de fonctionnement des caches. En partie seulement parce que la granularité est de 16 Mo au lieu de 4 ou 8 Ko, et que l’OS n’utilise pas ces registres.

Néanmoins, il doit être possible de contourner ce problème en initialisant les registres ACR (baptisés TCR lorsqu’il y a un MMU) avant SetPatch (sous réserve qu’ils ne soient pas réinitialisés par SetPatch et la 68060.library) pour configurer le cache en Copy Back pour toute la RAM disponible, et à l’exclusion de toute autre zone. Faute de quoi, les caches doivent être inhibés pour éviter les problèmes d’I/O, ce qui nuit considérablement aux performances.

C’est pour cette raison qu’aucun 68EC040 ou 68EC060 n’a été employé par Commodore ou ses successeurs.

NB: Le MMU du 68k n’influence que le 68k. Il ne joue aucun rôle côté PPC.

In reply to: choper les stackoverflow sous morphos/gcc

#28943

@krabob

Qui dit OS protégé dit protection mémoire, et tant qu’à faire mémoire virtuelle. Le rêve de beaucoup d’Amigaïstes depuis longtemps.

Le problème principal est que ce système impose d’incessantes recopies de données lors des communications entre tâches et accessoirement entre une tâche et l’OS (si nécessaire). C’est synonyme de ralentissement au niveau des API de communication inter-processus, et c’est la raison principale qui fait que l’AmigaOS et ses dérivés sont plus réactifs que les OS “protégés” (a ce sujet, les modifications incessantes du “maping” par le scheduler induisent aussi une baisse des performances).

Ces copies posent un problème avec les pointeurs, vu qu’ils référencent un objet via son adresse logique (et non pas physique), adresse logique qui ne correspond plus à rien si elle est utilisée telle quelle par une autre tâche. Or, pour des raisons de performance, l’AmigaOS utilise les pointeurs de manière extensive, y compris au sein de structures de données, ce qui rend cette copie très délicate (voire impossible ou trop coûteuse en temps). Pour contourner ce problème épineux, il faudrait revoir l’ensemble des APIs (et donc casser la compatibilité ou ajouter une couche d’abstraction supplémentaire et dont l’utilisation serait obligatoire) pour optimiser l’ensemble du système et le rendre “compatible” avec une mémoire protégée.

En résumé, l’AmigaOS que vous connaissez n’est pas adapté à une quelconque protection de la mémoire, par construction. Il a été conçu pour être rapide, réactif et peu gourmand en ressources, et les choix faits à l’époque compliquent énormément les choses d’autant plus que ces choix perdurent par la force des choses (habitudes de programmation, compatibilité ascendante, nouvelles implémentations inspirées du design originel, etc). Par exemple, où s’arrête l’OS (protégé) et où commencent les applications lorsque la plupart du code et des données sont partagés (bibliothèques, pilotes, etc) ?

C’est loin d’être simple et à moins d’un revirement radical (énorme travail de fond sur le design, nouvelles règles d’utilisation des API, nouvelles API, redéfinition de certains principes, etc), je vois mal MorphOS ou AmigaOS 4 proposer un tel système, propre, stable, transparent et performant dans un avenir plus ou moins proche.

In reply to: choper les stackoverflow sous morphos/gcc

#28938

1. mea culpa : J’ai pensé qu’Henes voulait initialiser le premier élément de son tableau (ce que j’ai écrit), et je n’ai pas vu son “bug”.

2. Quoiqu’il en soit, le fait de déclarer un tableau dans une fonction provoque sont allocation sur la pile, ce qui induit l’écriture d’informations “en dessous” de l’adresse courante (back chain, entre autres choses), et donc l’allocation d’une nouvelle page ou un dépassement de pile.

3. Il est possible d’utiliser le MMU pour marquer la dernière page possible comme étant invalide. Tout accès dans cette page provoque alors une exception, détectable. Néanmoins, toute écriture en dehors de cette page n’est pas détectée, donc ça ne sert pas à grand chose même si c’est mieux que rien.

4. L’absence de détection fiable interdit d’avoir un système d’allocation automatique de nouvelles pages (ce qui serait faisable en utilisant un adressage logique des nouvelles pages, grace au MMU).

5. La seule solution est d’utiliser une adresse logique pour la totalité de la pile (pile à une adresse commune à toutes les tâches et dans une zone suffisament vaste pour pouvoir être étendue dynamiquement sans conflits) mais cela soulève plusieurs problèmes :

– La configuration MMU doit être modifiée chaque fois qu’on commute sur une autre tâche pour changer la relation adresses logiques->adresses physiques.

– Les données stockées sur la pile deviennent privées : il n’est plus possible de les transmettre à une autre tâche sans recopie.

La solution “adresse logique” est jouable sous certaines conditions :

– les API utilisées copient par précaution les données destinées à d’autres tâches (au cas où elles seraient stockées dans la pile par erreur).

– L’application considérée est conçue pour ne pas utiliser la pile pour des données réputées “publiques”.

– L’exécutable signale cette caractéristique ce qui permet à l’OS de mettre en place une pile auto-extensible pour cette application.

Tout ceci est quand même très théorique, et c’est une grosse bidouille.

Finalement, la solution la plus viable compte tenu des problèmes de compatibilité ascendante serait d’avoir un compilateur capable de générer du code destiné à vérifier l’état de la pile en temps réel. Puisque la taille de la pile augmente à chaque appel de fonction, il est possible :

– de s’assurer que la taille allouée est suffisante avant de rajouter une nouvelle trame.

– d’allouer une ou plusieurs nouvelle(s) page(s) (remappée(s) avec le MMU) si ce n’est pas le cas.

In reply to: choper les stackoverflow sous morphos/gcc

#28928

pour info la pile “recule” elle n’avance pas. ton exemple trashe la pile déjà alloué. tu as voulu dire:

char *a[PAGE_SIZE]; a[-1]=0;

Donc les gens qui ne se drogue pas et on une “réputation” informatique solide se trompent aussi tu vois.

Si je peux me permettre…

L’exemple d’Henes est le bon, même si initialiser le premier élément du tableau est de l’overkill puisque ça ne fait que dupliquer l’effet obtenu par la création d’une nouvelle trame sur la pile.

En revanche, écrire “a[-1]=0” est clairement un bug dont la finalité est d’écraser quelque chose, mais personne ne sait exactement quoi

In reply to: RAGEmem (Os4 memtest, OS4emu)

#28539

Non point, dans le cas du PegasosII, la vitesse de lecture est supérieure à la vitesse d’écriture avec Ragemem.

Pourquoi prendre ça en compte alors que ça sent le bug à plein nez (voir le post d’Henes et ce que je dis dans le post précédent) ?

C’est quand même incroyable que quasiment personne ne prend la peine de LIRE et que la plupart se contentent de camper sur leurs positions, quite à détourner le sens de certaines phrases en les sortant de leur contexte. Je ne vois pas en quoi ça fait avancer le débat !

En ce qui me concerne, je me contrefiche de savoir qui de l’AOne ou du Pegasos est le plus performant. D’abord parce que je n’en ai pas, ensuite parce que ça ne m’interresse pas, et enfin parce que les deux sont techniquement dépassés (hardware).

En revanche, les constatations faites à partir du benchmark de Crisot m’interressent parce qu’elles soulèvent un problème lié à l’architecture du PowerPC G4e, et il se trouve que j’ai deux de ces bestioles depuis plus de deux ans et certaines connaissances sur le sujet (dont plus de 20 ans de programmation en assembleur, du Z-80 au PPC en passant par tous les 68k).

Je ne viens pas ici pour attaquer qui que ce soit ou pour démolir telle ou telle plateforme, et encore moins pour me faire tirer dessus à boulet rouge sans raisons. Certaines personnes posent des questions pertinentes auquelles j’essaye de répondre par des explications techniques basées sur l’architecture et le fonctionnement particulier du G4e, dans la mesure de mes moyens. Avec ça, chacun est libre de se faire sa propre opinion, objectivement.

In reply to: RAGEmem (Os4 memtest, OS4emu)

#28537

Ta routine n’aligne pas la mémoire sur les lignes de cache. Pourquoi c’est moi qui suis obligé de le remarquer?

Du coup, ta série:

dcbz, stfd, stfd, stfd, stfd, dcbst

peut se transformer en quelque chose comme:

dcbz, stfd, dsbst, stfd, stfd, stfd

Si la boucle n’est pas alignée correctement, il est certain que les performances sont en chute libre (puisque le dcbz arrive trop tard, et que le dcbst provoque l’écriture d’une ligne de cache incomplète). Au final, chaque ligne de cache est lue depuis la mémoire (dcbz mal placé) puis écrite deux fois (via dcbst puis automatiquement)…

Quoiqu’il en soit, je ne parlais pas de ce cas particulier mais plutôt des différences entre les bandes passantes de chacune des plateformes, notament en lecture, différences mises en lumière par un outil tel que celui de Crisot (certains disaient alors que ça ne servait à rien). Si ces différences existent, elles ne peuvent venir que d’une configuration différente des processeurs, du chipset, ou du design général.

Malheureusement, je n’ai aucun moyen de tester par moi-même et j’en suis réduit aux seules informations fournies sur ce forum. Pour le moment, je n’ai rien vu permettant d’emettre l’hypothèse que le code de Crisot n’est pas correct (sauf en ce qui concerne le “bug” dcbz/pegasos en écriture), et encore moins de contre-exemples avec données chiffrées à l’appui.

Dans ces conditions, vu de l’extérieur, il est raisonnable de conclure que les performances annoncées par le benchmark sont globalement correctes et représentatives de la réalité, d’autant plus que certains aspects sont confirmés par la théorie (vitesse d’écriture > vitesse de lecture).

In reply to: RAGEmem (Os4 memtest, OS4emu)

#28529

Pourquoi les tests sur processeurs x86 ou ceux sur mon ancien 603e donnent-ils des résultats inverses dans ce cas ?

C’est une façon polie de remettre en doute ce que j’explique ?

Si oui, il aurait été plus sage d’essayer de comprendre comment ça fonctionne (ce que j’explique plus haut), et d’éviter de comparer les performances d’un G4 avec celles d’un x86 ou d’un 603e, qui plus est sur des plateformes fondamentalement différentes.

Je veux bien être gentil et faire avancer le débat calmement, si possible. Ces interventions stupides, sans aucune valeur technique ni argumentation valable, n’apportent rien de concret. J’ai franchement mieux à faire que de participer à ces gamineries. 😡

In reply to: RAGEmem (Os4 memtest, OS4emu)

#28526

Vous me permettrez d’avoir un avis différent

En dehors du fait que Crisot utilise l’instruction DCBZ (Data Cache Block Zero) pour optimiser les opérations d’écriture, le reste du code est tout ce qu’il y a de plus banal. Compte tenu du nombre d’octets transférés, qui est bien au delà de la capacité des caches, l’outil en question mesure effectivement la bande passante maximale permise entre le processeur et la mémoire. Autrement dit, sur chacune des configurations considérées, on ne peut pas aller plus vite ce qui signifie par la même occasion qu’on peut facilement aller moins vite.

Une petite parenthèse au sujet de DCBZ. Cette instruction permet de contourner un effet secondaire du mode Write Back qui veut que toutes les opérations de lecture/écriture passent par le cache. Sans cette instruction, le fait d’écrire une donnée provoque la lecture d’une ligne de cache depuis la mémoire, puis l’écriture de la donnée dans le cache (laquelle sera recopiée en mémoire plus tard). Lorsqu’on souhaite remplir une zone mémoire (et non pas copier des données), le gain est très significatif puisqu’on divise par deux la charge du bus mémoire.

La différence entre les opérations en 32 bits et 64 bits est marginale dans ce cas de figure (taille de la zone touchée très supérieure à la taille des caches). En pratique, le G4 recombine les données écrites dans un tampon intermédiaire (CSQ) de façon à procéder à l’écriture dans le cache en une seule opération (Store Gathering). S’il est vrai qu’il faut deux fois moins de stores pour écrire la même quantité de données, il ne faut pas perdre de vue qu’au final, le bus mémoire va induire un ralentissement certain puisque la bande passante est nettement inférieure à ce que peut soutenir la LSU. En lecture, c’est un peu différent : puisqu’il faut moins de loads, on élimine la moitié des latences introduites par l’accès aux caches ce qui conduit à un léger gain en performances.

Les G4 étant (à priori) les mêmes sur les plateformes considérées, les différences constatées ne peuvent venir que d’une configuration différente des processeurs (fonctionnalités désactivées) ou du hardware lui-même. A ce titre, ce genre de benchmark met en évidence ces différences en chiffrant la bande passante maximale. Une application quelconque ne pourra en aucun cas faire mieux, pourra souvent faire aussi bien (vu que le code n’a pas besoin d’être spécialement optimisé compte tenu du fait que le processeur est beaucoup plus rapide que la mémoire), ou parfois moins bien. Dans les deux derniers cas, il vaut mieux disposer de 260 Mo/s plutôt que de 180 Mo/s.

[edit] Pour info, un PowerMac G4 1.25 donne 750 Mo/s en écriture (à priori sans DCBZ) et 450 Mo/s en lecture pour un bloc de 16 Mo.