Ich hatte mit ihm schon einmal darüber diskuttiert am Telefon und da meinte er der 68030 hätte ...
Ich möchte hier einmal klarstellen, daß es nur einziges Tel.-Gespräch mit tuxie gab - das war Anfang Dez ´16 - und in dem ging es nmE. um soziale Belange des Forums und nicht um technische Fragen, schon gar nicht um Interna des 68030. Als Beleg habe ich noch seine vorweggehende PM an mich.
-------
Ich rede & schreibe Hochdeutsch,
@tuxie - das ist keine Attitüde, sondern meine Muttersprache - und lege wert auf korrekte Präpositionen, ibs. wenn ich zitiert werde. Ich hatte geschrieben
... der 68030 jedoch ist mit seinem Cache und seiner internen Takt-Verdoppelung nur sehr schwer in Griff zu kriegen ...
(und spreche von ´intern´, weil der Cache im Prozessor integriert ist) und nicht, was Du da als mich angeblich zitierend zusammenfabulierst.
Ich möchte Dich auch bitten, daß Du höflich und sachlich bleibst anstatt beleidigend:
Sag mal kannst du Lesen`?
und auch nicht schon wieder herumschreist mit 1000 Ausrufezeichen. Es geht hier nicht darum, einen Hahnenkampf auszufechten, sondern darum, einen technischen Irrtum zu beseitigen. Ich kann nichts dafür, daß Du offensichtlich niemals eine alternative Meßmethode anstatt GemBench verwendet hast. Nochmal in aller Deutlichkeit: Auch wenn GemBench behauptet, es messe ´ROM Access´, so ist diese Behauptung zumindest für den 68030 offenbar falsch (auch wenn für den 68000 die verwendete Methode noch funktioniert haben mag).
Zumindest aber muß, wie
@1ST1 sehr richtig bemerkt hat:
Man misst aber fast nur die Taktverdoppelung des Prozessors. Denn aufs ROM wird nur einmal zugeriffen, wenn die TOS-Routine das erste Mal aufgerufen wird. Wird sie dann noch hundert mal durchlaufen, ist sie 99 mal schon im Cache.
Will man wirklich das ROM benchmarken, dann ... und mit ausgeschaltetem Cache.
der Cache ausgeschaltet sein. Das ist aber in allen Deinen Bildern, sowohl hier (s. zB. #57 & #60) als auch auf YT, _nicht_ der Fall. Aber selbst bei ausgeschaltetem Cache halte ich die Methode von GemBench für nicht seriös genug, um wirklich von einer Messung der ROM-Geschwindigkeit zu reden.
Spätestens, als Du ebenfalls einen Faktor zwei für das ST-RAM im TT bemerkt hast, hättest Du aufmerken müssen. Und noch mehr, wie oben schon erklärt, bei erratischen Meßergebnissen. Ich habe jedenfalls auch auf meinem TT diesen Faktor zwei (bei eingeschaltetem Cache - und ohne modif. AdressDecoder).
Du hattest mich in einer PM Ende ´16 gebeten, Dir einen einschlägigen Benchmark zu schreiben - und ich habe dies abgelehnt, weil ich auf Grund meiner Erfahrungen schon wußte, welche Fallen beim 68030 da lauern. Das wäre eine wirklich mühsame & aufwändige Arbeit! Das Problem ist, die Messung des ROM-Zugriffs von allen anderen Einflüssen zu isolieren: Je nachdem, mit welchem Befehl der Proz. gerade beschäftigt war, kann der Zugriff unterschiedlich lange dauern. Und der Cache greift nochmal anders zu.
Wenn Du durch einen ´modifizierten Adressdecoder´* wirklich einen Faktor zwei erzielt hast, tuxie, dann bist Du entweder genialer als Shiraz Shivji & Co. - oder aber es könnte sein, Du hast womöglich die Validierung des Proz.-Caches ausgehebelt und damit einen HW-Bug in Deinen TT eingebaut, dessen Auswirkung Du bloß noch nicht bemerkt hast.
Weiß jmd., wie anderswo (Apple etc.) damit umgegangen wurde?
* Ich hatte übrigens in #32 darum gebeten, daß Du das mal genauer erläuterst - und damit war nicht ein weiteres Propaganda-Video auf YT gemeint.
PS: Zurecht wurde exxos für seine default-Referenz in GemBench_6 kritisiert.
Leider ist tuxies Ersatz unbrauchbar, da offenbar trotz Auflösung TT-med seine GK nicht abgeschaltet war. Das trat hervor, als ich die Situation auf meinem TT nachstellen wollte, siehe angehängter ScreenShot.
Edit.: Nach der Moderation #30 & #33 anstatt #57 & #60.
