Gembench - Gotteswerk oder Teufelszeug

[tuxie]

Edit Johannes: Spin-Off aus: https://forum.atari-home.de/index.php?topic=14986.msg237323#msg237323

Du kannst an die ST-Ram karte gehen, dort liegen alle Leitungen die du brauchst an, also alle Adressen, als auch AS XDS0 XDS1 und so.

Bei den Roms hast du einen Jumper dort kannst du dann das neue CS Signal zu dem Roms einspeisen

[tuxie]

Hier mal ein vergleich

1. Video Stock TT mit NVDI
https://youtu.be/PFWPVrQHQRo
2. Video Flasdh Tos und 20/40Mhz mit NVDI
https://youtu.be/mXBAxCoy-Ik

[Arthur]

NVDI verfälscht das Ergebnis nur und hat wenn's nach mir ging dabei nichts zu suchen. Ich würde die Test überwiegend  ohne NVDI machen...

[tuxie]

Hier geht es gar nicht um NVDI sondern um den Romzugriff und NVDI verfälscht auch nicht das Ergebnis, ganz im gegenteil damit kann man ganz gut die Leistungssteigerung des gesamten Systems Sichtbar machen. Ist der Fastram Schneller dann sieht man das an allen werten. Hast du kein NVDI geladen kannst du viele Beschleunigungen gar nicht sehen. Man muß es nur immer entweder beide Ergebnisse Ohne NVDI oder beide mit. Ich teste immer einmal mit und einmal ohne NVDI. Aber Leistungssteigerung kann man wirklich erst sehen wenn NVDI geladen ist. Außer beim Romzugriff da sieht man es auch ohne NVDI recht gut. Wenn ich es Schaffe dann mache ich nochmal eins ohne NVDI...

Wenn man Benchmarks laufen lässt dann doch bitte so wie wenn man mit dem Rechner Arbeitet. Arbeite ich mit NVDI weil es den Rechner schneller macht durch Optimierte Grafikroutinen dann doch auch bitte mit. Verfälscht wären die Werte wenn bei jedem Lauf die werte anders sind. Das sind sie aber nicht.

[1ST1]

Hier geht es gar nicht um NVDI sondern um den Romzugriff und NVDI verfälscht auch nicht das Ergebnis, ganz im gegenteil damit kann man ganz gut die Leistungssteigerung des gesamten Systems Sichtbar machen.

Da bin ich anderer Meinung. Denn NVDI ersetzt ja Teile des ROMs, nämlich das VDI. VDI ist im ROM, NVDI im RAM. Mit NVDI kann man also keine ROM-Vergleiche machen.

Wenn ROM-Zugriffe im Originalmodus mit beschleunigtem ROM verglichen wird, und es sind nur wenige Unterschiede zu sehen, dann scheint die Bastellei eher nichts zu bringen, dann doch lieber das ganze ROM ins RAM kopieren und dann mit WinX und NVDI drüberbügeln, dann hat man das Optimum, ganz ohne Bastellei (abgesehen von Bus-Übertaktung, aber davon profitiert ja ein RAM-TOS auch.

[tuxie]

Dem ist aber nicht so, dennoch greift Tos auf das Rom zu und die Geschwindigkeitsunterschiede sind Messbar! Da ihr ja alle schon TT´s bis zum letzten Beschleunigt habt, und die Unterschiede alle aufgezeichnet und in Excel Tabellen ausgewertet habt wisst ihr das Natürlich ganz genau! Diskutiert einfach mit der Wand weiter!!!!!!!!!!!!!

[ari.tao]

Gaaanz ruhig, Brauner!
Ich stimme Dir zu, daß man praxisgerecht _mit_ NVDI testen sollte - denn das setzt jeder ein. Aber daß man durch den beschleunigten Zugriff auf´s ROM, den Du GA empfohlen hast, einen Faktor zwei erwirtschaften kann (wie per GEMRAM), das leuchtet mir noch nicht ein. Könntest Du das bitte mal näher erleutern? (Bitte für Fußgänger wie mich, zum mitmeißeln).

[1ST1]

Dem ist aber nicht so, dennoch greift Tos auf das Rom

Ja, natürlich finden noch ROM-Zugriffe statt, auf das AES, BIOS, XBIOS, Desktop-App, GEMDOS*, aber nicht mehr auf das VDI. Und wenn du irgendwelche GEM-Benchmarks machst, wird halt auch sehr viel das (N)VDI beansprucht.

*Es sei denn, du hast BigDOS geladen!

So genau muss man schon sein! Wenn du also fair ROM-Speed testen willst, darf weder BigDOS noch NVDI geladen werden, noch ein alternatives AES oder Desktop. Wenn du "Original" gegen maximal getunt vergleichen willst, dass den getunten Rechner mit TOS im RAM, NVDI, BigDOS (oder MiNT), New/MyAES und evtl. ein alternativer Desktop. In dem Extremfall wird das ROM garnicht mehr angesprochen und jegliche Schaltungen zum Beseitigen von ROM-Waitstates sind überflüssig.

[tuxie]

Hallo,

also bei 16Mhz Bus ist /AS 120ns aktiv, also sollten die Roms auch reichen, du kannst das gern mal versuchen. Ich habe da ja noch Flash Roms drauf zum Programmieren im System, quasi Roms und Flash Chips Parallel geschaltet und nur über CS selektiert.

Gembench:

ich nutze immer die identische Referenzdatei, alles im Fastram geladen (sieht man auch in den Videos) damit die Bedingungen auch immer identisch sind.

Zur FPU was ich beobachtet habe ist das die Performance der FPU steigt wenn auch die CPU Performance steigt. Warum das so ist kann ich nicht genau erklären, ich gehe aber davon aus das wenn die CPU schneller ist dann kommt die FPU auch schneller zum Zug! Meine Läuft seit Anfang an mit 48mhz.

Hallo Tuxie,

Da fiel mir Heute noch etwas ein. Und das will ich gerne hier mal "spiegeln" 
Vom MMU wird das Chip-Select Signal für den Eproms erzeugt.
Wenn ich dieses Signal direct nach XDS0/1 verbinde mittels OC Gatter (Oder Schottky Diode sogar), sollte es auch functionieren. Natürlich sind schnellere Roms da immer noch nötig. 
Dies spart viel Verdrahtung und ist sehr wenig Arbeit. Sollte so einfach sein das fast jeder es schafft.

Werde dies mal testen.

@ Alle
Wegen Test, mag ich es immer um klar zu haben was passiert.
Einfaches ein / aus Schalten habe ich da am liebsten. Also Test mit oder ohne etwas, weiter unter gleiche Bedingungen.
Es ist mich nicht klar was Gembench genau macht bei jeden Test.
Aber bei jedes Programm werden viele Teile vom Computer benützt.
Gembench ist im Ram geladen. Aber TT oder ST-Ram? Und Firmware aus Eprom oder TT Ram nach copie? Alles hat einfluss.
Daher ist jedes mal vergleichen angesagt.
Züm Beispiel den FPU-Clock.
Ich hab bemerkt das bei steigen der Clock-geschwindigkeit über 40Hmz viel weniger passiert. Also 32 Mhz nach 40Mhz hat zuname X. Aber dann von 40 nach 48Mhz ist nicht wieder X. Und nach 56Mhz ist es noch weniger. Warum? Ich denke austausch von Daten zwischen CPU und FPU ist den "Bottleneck"
Bei diesen Tests hab ich immer nür den FPU-Takt geänderd.

MFG/
Guus

[tuxie]

Ich habe noch nie BigDOS verwendet, da ich es noch nie benötigt habe und da ich es auch noch nie zum laufen gebracht habe! Mir erschließt sich auch nicht so recht wozu ich es einsetzen sollte!

Es ist NUR NVDI geladen!!! Nichts weiter, auch keine USB Treiber, keine Nova Treiber..

Dem ist aber nicht so, dennoch greift Tos auf das Rom

Ja, natürlich finden noch ROM-Zugriffe statt, auf das AES, BIOS, XBIOS, Desktop-App, GEMDOS*, aber nicht mehr auf das VDI. Und wenn du irgendwelche GEM-Benchmarks machst, wird halt auch sehr viel das (N)VDI beansprucht.

*Es sei denn, du hast BigDOS geladen!

So genau muss man schon sein! Wenn du also fair ROM-Speed testen willst, darf weder BigDOS noch NVDI geladen werden, noch ein alternatives AES oder Desktop. Wenn du "Original" gegen maximal getunt vergleichen willst, dass den getunten Rechner mit TOS im RAM, NVDI, BigDOS (oder MiNT), New/MyAES und evtl. ein alternativer Desktop. In dem Extremfall wird das ROM garnicht mehr angesprochen und jegliche Schaltungen zum Beseitigen von ROM-Waitstates sind überflüssig.

[ari.tao]

Ad FPU:
Auf seinen Atari Pages schreibt auch Exxos
   https://www.exxoshost.co.uk/atari/last/FPU/index.htm
daß eine Beschleunigung der FPU über ein gewisses Maß hinaus nicht mehr viel bringt.
Unter Berücksichtigung der erzeugten Abwärme ist imho >40MHz zweifelhaft (auch wenn es immer heißt, die FPU vertrage problemlos Übertaktung bis 50MHz).

Ad GemBench:
Dieser Benchmark war immer schon sehr dubios.
Zu seiner Messung des ROM-Speed ist zu sagen, daß ganz offensichtlich nicht die Geschwindigkeit des ROMs gemessen wird, sondern die gewisser TOS-Zugriffe - anders ist nämlich imho der Faktor zwei für ROM-Speed nicht zu erklären, der sich ergibt, wenn man das TOS per GemRam in´s TT-RAM lädt.

[ari.tao]

Habe mal die jüngste Version 608B31 (vom 19.7.18) heruntergeladen. Nun scheint GB6 endgültig kaputt zu sein: Ein Abspeichern der Test-Ergebnisse war mir trotz mehrfacher Versuche nicht möglich und endete immer mit Absturz, einige weitere Effekte deuten an, daß da jetzt schwerwiegende Bugs zugange sind.
Finger weg von diesem Schrott! Schade um die damit vertane Zeit!

[tuxie]

Wie meine Beobachtungen es zeigen über die letzten 2 Jahre, kannst du den Takt bis zu einem gewissen Punkt hoch nehmen (bis 40Mhz) wo der Performance unterschied doch nicht unerheblich ist.Sobald aber das ganze System nochmal beschleunigt wird, legt auch die FPU nochmal eine ganze menge an performance zu. Sin beobachtungen die ich in den letzten 2 Jahren immer wieder gemacht habe.  Seit dem meine CPU mit 54Mhz Läuft und der BUS auf 18Mhz. Hat auch die FPU nochmals zugelegt (unterschied wie von 32 auf 40 nochmal von 40 auf 48. Ich gehe davon aus das ab einen Punkt die FPU von der CPU ausgebremst wird, warum das so ist habe ich noch nicht erforscht.

@ari.tao wir haben doch geschrieben das der ROM Zugriff Künstlich gebremst ist, wenn man diese Bremse ausbaut dann verdoppelt sich die Zugriffsgeschwindigkeit auf das ROM. Bei mir sind es halt 221% was auch beim normalen Arbeiten am Rechner auf Desktop ebene auch ohne NVDI sich bemerkbar macht. Ich habe nie gemram verwendet sondern nur das TOOL von Uwe Seimet. Aber das hat hier jeder Überlesen!!! Auch damit war der Geschwindigkeitsunterschied Spürbar, aber nicht richtig Messbar (warum auch immer).
 

Ad FPU:
Auf seinen Atari Pages schreibt auch Exxos
   https://www.exxoshost.co.uk/atari/last/FPU/index.htm
daß eine Beschleunigung der FPU über ein gewisses Maß hinaus nicht mehr viel bringt.
Unter Berücksichtigung der erzeugten Abwärme ist imho >40MHz zweifelhaft (auch wenn es immer heißt, die FPU vertrage problemlos Übertaktung bis 50MHz).

Ad GemBench:
Dieser Benchmark war immer schon sehr dubios.
Zu seiner Messung des ROM-Speed ist zu sagen, daß ganz offensichtlich nicht die Geschwindigkeit des ROMs gemessen wird, sondern die gewisser TOS-Zugriffe - anders ist nämlich imho der Faktor zwei für ROM-Speed nicht zu erklären, der sich ergibt, wenn man das TOS per GemRam in´s TT-RAM lädt.

[Arthur]

Ad FPU:
Auf seinen Atari Pages schreibt auch Exxos
   https://www.exxoshost.co.uk/atari/last/FPU/index.htm
daß eine Beschleunigung der FPU über ein gewisses Maß hinaus nicht mehr viel bringt.
Unter Berücksichtigung der erzeugten Abwärme ist imho >40MHz zweifelhaft (auch wenn es immer heißt, die FPU vertrage problemlos Übertaktung bis 50MHz).

Die Abwärme erhöht sich, aber hier wird ja keine PC-CPU, -Grafikkarte etc. übertaktet wo die Spannungen z.T. erheblich angehoben werden um einen stabilen Betrieb zu ermöglichen. Es wird also dem Takt entsprechend mehr gearbeitet aber auch mit entsprechend kürzeren Impulsen... unter Strich erhöht sich die Abwärme abhängig vom Chip. Dem kann man mit aktiver Kühlung oder Kühlkörpern bis zu einem gewissen Grad entgegen wirken. Die Übertaktbarkeit hängt natürlich von dem Fertigungsprozess ab wie man deutlich am 68060 sehen kann.

[tuxie]

Richtig, die mehr erzeugte Wärme hält sich in Grenzen, gerade bei der fpu . Selbst die 54mhz bei der cpu spielen kaum eine Rolle. Da ja auch die Spannung nicht erhöht wird wie es beim overclocking beim pc der Fall ist

[Lukas Frank]

Erstaunlich das eine 33Mhz CPU mit 54Mhz über lange Zeit einwandfrei läuft. Die PGA Versionen gibt es ja bis 50Mhz, wegen dem Fertigungsprozess meine ich ...

[tuxie]

Die CPU selbst läuft äusserst Stabil, viele Testprogramme laufen lassen wie Julia wo sie wirklich auch viel berechnen muß!

[Guus.Assmann]

Warum erhöhen vom FPU Takt ab einen Punt nichts mehr bringt, ist denk ich sehr einfach.
Den FPU arbeitet immer mit die maximale genauigkeit.
Es müssen dazu einige Parameter übergeben werden. Wie Zahlen und Befehle.
Dies wird vom CPU gemacht, der aber mit eine geringere geschwindigkeit lauft.
Sobald der CPU beschleunigd wird, werden auch diese Daten schneller übertragen.

MFG/
Guus

[ari.tao]

... wir haben doch geschrieben das der ROM Zugriff Künstlich gebremst ist, wenn man diese Bremse ausbaut dann verdoppelt sich die Zugriffsgeschwindigkeit auf das ROM. Bei mir sind es halt 221% was auch beim normalen Arbeiten am Rechner auf Desktop ebene auch ohne NVDI sich bemerkbar macht. Ich habe nie gemram verwendet sondern nur das TOOL von Uwe Seimet. Aber das hat hier jeder Überlesen!!! Auch damit war der Geschwindigkeitsunterschied Spürbar, aber nicht richtig Messbar (warum auch immer).

Es ist nicht die Frage, @tuxie, ob Du RomRam oder sonstwas anstatt GemRam benutzt oder nicht benutzt hast, sondern wie Du zu Deinen Meßergebnissen kommst. Wenn Du dafür lediglich GemBench bemüht hast, dann hast Du, wie oben dargelegt, höchstwahrscheinlich nicht die Geschwindigkeit des ROMs gemessen, sondern lediglich die gewisser TOS-Funktionen - die zudem auch noch gerade im Cache des 68030 gelandet sein könnten: Genau danach sieht mir nämlich Dein Ergebnis von 221% aus (wenn man noch berücksichtigt, daß Du den Bus um 2MHz höher getaktet hast).
Ich hatte mich mal vor längerer Zeit sehr intensiv mit Taktmessungen per Software am 680x0 befaßt. Für den 68000 waren Ergebnisse sehr zuverlässig zu bekommen - der 68030 jedoch ist mit seinem Cache und seiner internen Takt-Verdoppelung nur sehr schwer in Griff zu kriegen, da es afaik keine Möglichkeit gibt, sicher zu stellen, daß ein Stück Code im Cache abläuft oder nicht. Es kann anscheinend sogar passieren, daß es immer wieder in den Cache geladen wird und der Lade-Vorgang dann alles verfälscht. Das erratische Verhalten Deiner Meßergebnisse, das Du oben geschildert hast, deutet auf dergleichen hin. Da nutzt Dir dann weder ein Excel noch ein Enhancetron.

[ari.tao]

Ad Abwärme:
von 16 auf 56MHz ist´s mehr als eine ganze Größenordnung.
Da braucht der arme Chip aber wirklich einen ganz kühlen Körper.