RAGEmem (Os4 memtest, OS4emu)

15 sujets de 16 à 30 (sur un total de 56)

  • Kokin0u

      #28511

      Sur mon A.One G4 XE à 800MHz:

      Lecture: 276.53 MB/sec

      Ecriture: 782.87 MB/sec

      Brumiga

        #28512

        Bonjour Crisot,

        As-tu sorti une nouvelle version de rage.mos ? Celle que j’ai trouvé sur ton site voici 5/6 mois a la version 0.30 du 23/03/04.

        Brumiga

        jah

          #28513

          tiki peg2 g4 1GHz

          R SPEED: 229.95 MB/sec

          W SPEED: 178.70 MB/sec

          toi sur un 750FX un g3 donc , à 800MHz

          R 195

          W 728

          je suis desolé mais ca sent le bug, si l’a1 etait 4x plus rapide en

          ecriture ca se saurait et surtout ca se sentirait

          et encore, avec ces chiffre la, le fossé a1/peg est inimaginable

          puisque c le g3 qui est 4x plus rapide que le g4

          brumiga oui c un nouveau rage et il y a le lien dans le premier

          message du thread

          Brumiga

            #28514

            Jah, j’ai vérifié et c’est une version os4 qui ne fonctionnera pas sous morphos à moins que Crisot ou une autre personne me prouve le contraire.

            Brumiga

            jah

              #28515

              il a jamais ete dit que c’etait une version morphos, c’est une version

              a faire tourner avec os4emu

              la preuve en est que tu peux retrouver en debut de thread,le test de

              tiki et le mien sur pegs

              (en tout cas hier ca fonctionnait)

              SoundSquare

                #28516

                encore un concours de bites ?

                :-?

                cdfr

                  #28517

                  Si je devais comparer les performance memoire des A1 et Pegasos j’ecrirai une petite boucle en C utilisant les fonctions systemes que tous les developeurs utilisent.

                  Je compilerais ca avec le SDK distribué avec chaque OS et voila.

                  Ca donnerait une idée de la perf memoire des machines.

                  Le truc ASM de Crisot c’est certainement pas representatif des performances de la machine en utilisation réelle.

                  De toute facon le meilleur benchmark c’est de prendre vos applis les plus utilisées et de les tester.

                  anonyme

                    #28518

                    Bon je récupitules pour ceux qui n’auraient pas suivis.

                    Avec un Algorythme normal (ce que vous aurez en C), un AOne G4 sous Os 4 écrit à 711 Mo/SEC tandis qu’un Pegasos 2 G4 sous MOS écrit à 460 Mo/SEC.

                    Avec ma trick du DCBZ, l’AOne monte à 780 Mo/SEC tandis que le Pegasos 2 G4 tombe à 170 Mo/SEC, seul le Pegasos 1 ou 2 en G3 profite de la trick.

                    Pourquoi le Pegasos 2 G4 tombe, et uniquement le G4? A cause, je pense, de la cache coherency qui n’est pas dans le mode recommandé par IBM/Motorola pour des raisons dont seul la MOS team à sans doute su se convaincre.

                    A savoir que le meme Pegasos 2, dans le bon mode de cache coherency, sur G4, monte à 650 mo/sec environ.

                    Voila. Avant de me re poser des questions sur les différences de performances, lisez attentivement ce post, les réponses sont dedant.

                    henes

                      #28519

                      @Crisot

                      Tu es d’une arrogance…

                      Si encore, tu avais raison, ce serait moins fatiguant.

                      >Avec un Algorythme normal (ce que vous aurez en C), un AOne G4 sous Os 4 écrit à 711 Mo/SEC tandis qu’un Pegasos 2 G4 sous MOS écrit à 460 Mo/SEC.

                      Tu oublies de préciser que tu parles de store FPU 64bits. Cela ne concerne pas les autres types d’opération.

                      Tu oublies aussi de préciser qu’il ne s’agit pas d’écriture en mémoire vidéo, ce qui est sans doute l’un des seuls cas d’utilisation de ce genre de chose.

                      Enfin, un Pegasos2 G4 dépasse les 600 ou 700 Mo/sec (j’avoue ne plus me souvenir du chiffre exact, c’était il y a tellement longtemps) si la configuration du CPU est modifiée (j’espère que tu vois à quoi je fais référence, sinon tu as le droit de relire les PDFs de Motorola).

                      Mais vu les immenses problèmes engendrés à côtés, cela n’a que peu d’intérêt pratique. Sauf dans les benchmark comme le tiens (tu comprends que ce n’est pas péjoratif), mais tu sera d’accord pour dire qu’on s’en fiche un peu:-).

                      >Avec ma trick du DCBZ, l’AOne monte à 780 Mo/SEC tandis que le Pegasos 2 G4 tombe à 170 Mo/SEC, seul le Pegasos 1 ou 2 en G3 profite de la trick.

                      >Pourquoi le Pegasos 2 G4 tombe, et uniquement le G4? A cause, je pense, de la cache coherency qui n’est pas dans le mode recommandé par IBM/Motorola pour des raisons dont seul la MOS team à sans doute su se convaincre.

                      Tu te trompes. Rage donne les même résultats quelque soit le mode de cohérence. Et ne viens pas me dire le contraire, j’ai fait l’essai. Merci :)

                      J’avoue ne pas encore avoir d’avis définitif sur la question. Il faudrait quelqu’un qui sache un peu plus de quoi il parle (ni toi, ni moi, quoi). Peut-être que kakace aurait une idée plus précise.

                      Cependant, je remarque que tu ne hint pas le PPC avant d’effectuer ton dcbz. Un oubli? C’est peut-être l’origine du problème.

                      >Voila. Avant de me re poser des questions sur les différences de performances, lisez attentivement ce post, les réponses sont dedant.

                      N’oublie pas de te calmer avant d’écrire une éventuelle réponse. Et pas la peine de te contenter d’écrire une série d’attaques terminée par une insulte ;)

                      cdfr

                        #28520

                        Quelqu’un sait il pourquoi est ce que la lecture en RAM est moins performante que l’ecriture ?

                        Kokin0u

                          #28521

                          Pas la peine d’être aigris les Pegasistes… L’A-One, il pête la gueule à votre Peg I ou II.

                          Kokinou, qui a peut-être 3 grammes après ce jour de l’an ;-)

                          Kokin0u

                            #28522

                            Et puis mon A-One G4 XE, vus les résultats actuels, il fait partie des meilleurs.

                            Bon, OK, je ->

                            logo

                              #28523

                              Comment te prendre au sérieux Crisot après de tels commentaires ?

                              Pourtant, le fait que ton programme sorte des résultats en écriture bien supérieurs à ceux en lecture devrait t’inciter à la modestie et à la prudence, mais non…

                              PowerMac - G5 2.0 GHz - 1.7 Go RAM - Radeon 9600P 128 Mo - MorphOs 3.13 et Peg2 - G4 RIP
                              Mac mini - G4 1.42 GHz - 1 Go RAM - Radeon 9200 32 Mo - MorphOs 3.9
                              WinUAE sur HP Core2 Quad 8200
                              Epave de Mist FPGA remplacé par un Sidi
                              A1200 malade 😉 et A500 512+512Ko RAM Kickstart 1.3

                              kakace

                                #28524

                                Il est tout à fait normal que l’écriture soit notablement plus rapide que la lecture. Lorsque le processeur écrit quelque chose en mémoire, il se contente de placer les données dans le cache (mode Write Back) ou dans une pile (écriture directe en mémoire). Lorsque c’est fait, donc très rapidement, l’instruction est retirée du pipeline.

                                Pour la lecture, c’est totalement différent : la LSU doit ATTENDRE que la donnée soit copiée dans un registre, ce qui prend énormément de temps comparé à un bête « store ».

                                Même lorsque le bus mémoire est saturé, la lecture « à travers » les caches induit des latences supplémentaires qui rendent la lecture plus lente que l’écriture, quelle que soit la quantité de données transférées.

                                Au passage, le benchmark de Crisot permet de mettre en évidence une faiblesse du hardware (bande passante mémoire, sous-exploitation des possibilités du processeur, configuration sub-optimale du CPU, etc). Ainsi, un chipset foireux ou un design simplifié peuvent conduire à inhiber certaines fonctions du CPU, conduisant de fait à des lenteurs inexplicables autrement.

                                kakace

                                  #28526

                                  Vous me permettrez d’avoir un avis différent :-D

                                  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.

                                15 sujets de 16 à 30 (sur un total de 56)

                                • Vous devez être connecté pour répondre à ce sujet.

                                Forums AmigaOS, MorphOS et AROS Guéguerres RAGEmem (Os4 memtest, OS4emu)

                                Amiga Impact