Software > Coding
gcc, GEMDOS Super und Stackzerstörung
czietz:
Um zu zeigen, dass nicht alles schlecht ist mit dem gcc, habe ich mal den CoreMark [1] compiliert und laufen lassen. Das ist recht moderner CPU-Benchmark, der über die Kommandozeile parametriert wird, damit der Compiler eben nichts vorberechnen kann.
Hier die Resultate -- jeweils auf einem Atari ST mit 8 MHz, oder vielmehr dessen zyklusgenauer Emulation in Steem. Größere Zahl ist hier besser:
CoreMark 1.0 : 0.814332 / PureC 1.1 / STACK
CoreMark 1.0 : 0.363438 / GCC4.6.4 (MiNT 20130415) -O0 -mcpu=68000 -fomit-frame-pointer -DPERFORMANCE_RUN=1 / STACK
CoreMark 1.0 : 1.167202 / GCC4.6.4 (MiNT 20130415) -O1 -mcpu=68000 -fomit-frame-pointer -DPERFORMANCE_RUN=1 / STACK
CoreMark 1.0 : 1.716738 / GCC4.6.4 (MiNT 20130415) -O2 -mcpu=68000 -fomit-frame-pointer -DPERFORMANCE_RUN=1 / STACK
CoreMark 1.0 : 1.722653 / GCC4.6.4 (MiNT 20130415) -O3 -mcpu=68000 -fomit-frame-pointer -DPERFORMANCE_RUN=1 / STACK
CoreMark 1.0 : 1.465738 / GCC4.6.4 (MiNT 20130415) -Os -mcpu=68000 -fomit-frame-pointer -DPERFORMANCE_RUN=1 / STACK
Wie man sieht, muss sich hier PureC dem gcc-Optimierer (teilweise deutlich) geschlagen geben. Und gcc verhält sich plausibel, was die Optimierungsstufen angeht: -O3 ist schneller als -O2 ist schneller als -O1.
Mit meinem yrt_tim.c hingegen stelle ich den gcc-Optimierer wohl auf eine (zu harte) Probe...
[1] http://www.eembc.org/coremark/index.php
mfro:
Ahja. Jetzt stimmt mein Weltbild wieder. Danke!
1ST1:
Sehr beeindruckendes Ergebnis. Da sieht man dann schon, was 20 Jahre Optimierungen im Compiler so bringen können. Würde man jegliche ST-Software damit kompilieren, wäre der ST ja gleich doppelt so schnell, ganz ohne eine Turbokarte einzubauen. Wow!
ari.tao:
--- Zitat von: mfro am Mo 15.08.2016, 08:14:17 ---
--- Zitat von: ari.tao am Mo 15.08.2016, 06:49:11 ---... Ich benutze den Explorer...
--- Ende Zitat ---
Da geht so was auch:
http://praxistipps.chip.de/internet-explorer-gif-bilder-deaktivieren_15640
--- Ende Zitat ---
Danke an @mfro . Erstmal hilft die ESC-Taste (aus og. praxistipps).
Kann der Firefox parallel installiert werden, oder muß ich zuerst den Explorer entfernen?
.......
--- Zitat von: czietz am So 14.08.2016, 10:32:59 ---
--- Zitat von: ari.tao am So 14.08.2016, 08:41:57 ---Man kann SuperExec (XBIOS_38) grundsätzlich auch für Prozeduren mit Parametern verwenden. Falls es noch interessiert, kann ich ein Bsp. für M2(TDI) zeigen, mit C kenne ich mich nicht aus. Alles nur eine Frage des Bindings.
--- Ende Zitat ---
Auch wenn das Problem mittlerweile gelöst ist, würde mich das Beispiel (auch wenn's in Modula 2 ist) interessieren.
--- Ende Zitat ---
Hatha das versprochene Bsp. (hat ebbs gedauert, weil ich aus den vorhandenen ein zur Demo geeignetes heraussuchent & didaktisch aufbereiten mußte):
--- Code: ---(* IMPLEMENTATION *) MODULE SUP_DEMO;
(* ½ 2016 Ari.Tao * 15.08.16 TDI-M2 .
Two examples how to use XBIOS_38 (SuperExec) with parameters:
SupExec (long out par. only)
PeekL (long in & long out par.)
*)(*$T-,$S-,$A+ mini *)
IMPORT GT;
FROM SYSTEM
IMPORT ADR,ADDRESS, WORD, SETREG,CODE;
CONST RTS = 4E75H;
UNLK = 4E5EH;
TRAP = 4E40H;
XTRAP = TRAP+14; (* XBIOS *)
PUSHW = 3F3CH; (* MOVE.W #*,-(A7) ; Word-Konstante.*)
PUSHV = 2F2EH; (* MOVE.L s(A6),-(A7); Long- v VAR-Parameter.*)
RETL = 2D40H; (* MOVE.L D0,d(A6) ; Long-Ergebnis. *)
CONST SUPER = 38; D0 = 0; PM = 8;
TYPE SuperPar = RECORD Op: CARDINAL; Code: PROC END;
TYPE HANDLE = POINTER TO ADDRESS;
(* Beispiel_1: *)
PROCEDURE SuperExec (Code: PROC);
BEGIN CODE (PUSHV,PM, PUSHW,SUPER, XTRAP) END SuperExec;
PROCEDURE SupExec (Code: PROC): (*D0 via Code:*) LONGINT;
BEGIN CODE (PUSHV,PM, PUSHW,SUPER, XTRAP, RETL,PM+4, UNLK,RTS) END SupExec;
(* Beispiel_2: *)
PROCEDURE peekL; VAR h: HANDLE; p: POINTER TO RECORD q,z: HANDLE END;(*$S-*)
BEGIN CODE (RETL+14,-4); p := h^+PM; p^.z := p^.q^ END peekL; (*$S=*)
PROCEDURE PeekL(a: ADDRESS): (*Val:*) ADDRESS; VAR P: SuperPar;
BEGIN P.Op := SUPER; P.Code := peekL; CODE (XTRAP, UNLK,RTS) END PeekL;
(* Test: *)
PROCEDURE TestCode; (*$S-*) BEGIN SETREG (D0, 13H) END TestCode; (*$S=*)
CONST MEMTOP = 436H;
BEGIN (* .TOS *)
GT.wHexL (SupExec (TestCode), 10);
GT.wHexL (PeekL (MEMTOP), 10);
END SUP_DEMO .
--- Ende Code ---
Hinweise:
1) Das Phragma $S- unterdrückt den StackTest des TDI-Compilers.
2) Selbstverständlich sind die Bindings Compiler-abhängig, also nur bedingt portabel.
3) Die Idee stammt aus einem Zeitschriften-Artikel. Leider ging mir die Quelle verloren.
4) Das fertig kompilierte Prg. -> Anhang (ziemlich uninteressant, nur zur Vollständigkeit)
.......
Ad Benchmarking:
--- Zitat --- Deshalb bevorzuge ich echte Applikationen als Benchmark.
--- Ende Zitat ---
Klaro, dacour.
Es liegt mir fern, den CoreMark in Zweifel zu ziehen. Aber der dient doch in erster Linie dazu, Prozessoren zu vergleichen? Beim RAM-Test spielt der Bus eine wesentliche Rolle.
Ist der CoreMark (nomen est omen?) dafür denn auch zuständig? Wenn nicht, dann ist
--- Zitat --- Fakt ist: Selbst mit -O3 (oder -Os) läuft mein RAM-Test YAART schneller, wenn ich ihn mit Pure C compiliere.
--- Ende Zitat ---
überhaupt kein Wunder. Der gcc wurde vermutlich dem CoreMark angepaßt, aber PureC dem Dhrystone oä.
Übrigens wird im BegleitText zum Dhrystone die von Dir @czietz angesprochene Optimierungs-Problematik durchaus berücksichtigt. Deshalb halte ich imho diesen mittelalterlichen Test für unsere OldTimer immer noch für gut geeignet. An ein paar wenigen Dhrystones Unterschied würde ich keine Bewertung festmachen, aber bei einem Faktor von ca. 2 gibt es am Dhrystone wohl nix herumzukritteln. Man kann jedenfalls gut sehen, daß der TT mehr Leistung hat als ein F30 mit 32MHz oder auch die groben Unterschiede in verschiedenen Compiler-Designs oder auch den Einfluß des BusTakts oder auch, wieviel Performance eine höhere Grafik-Auflösung im Falcon kostet; und das ist alles sehr plausibel.
.......
@czietz , wo bitte genau finde ich im Hatari-Universum das Stückchen Code, das für die ´Zyklen´ zuständig ist?
Eine jede Wissenschaft hat ein sog. Hauptproblem. Dasjenige der Informatik ist nicht etwa, Information zu erzeugen, sondern, sie (wieder-)zufinden!
1ST1:
Offtopic, ari.tao schrieb:
--- Zitat ---Kann der Firefox parallel installiert werden, oder muß ich zuerst den Explorer entfernen?
--- Ende Zitat ---
Du musst den Exploder nicht entfernen, kannst du unter Windows nichtmal. Du darfst gerne neben dem Firefox auch noch Chrome, Opera, ... parallel installieren und gleichzeitig starten und mit allen gleichzeitig surfen! Und dann legst du dir einen der neuen Browser als Standard fest und hast in Zukunft Ruhe vor dem IE, wenn du möchtest. Mindestens der Firefox kann auch all deine Lesezeichen usw. vom IE importieren.
Navigation
[0] Themen-Index
[#] Nächste Seite
[*] Vorherige Sete
Zur normalen Ansicht wechseln