Dr. MaRV schrieb:
@mae
macOS ist vollständig POSIX und UNIX 03 konform. Etwas das Windows mit Kompatibilitätserweiterung nicht ansatzweise ist.
Ich weiss nicht, was Du mit "Windows mit Kompatibilitaetserweiterung" meinst, aber das POSIX.1 Subsystem fuer Windows NT war eben ein "zertifiziertes Unix" nach den Kriterien, die damals fuer Ausschreibungen des US-Verteidigungsministeriums galten; und es war natuerlich nicht UNIX 03 konform, weil UNIX 03 lange nach Windows NT herauskam. Jedenfalls hatte das POSIX-Subsystem fuer Windows NT trotz Zertifizierung den Ruf, praktisch unbrauchbar zu sein. Und genauso sagt eine Konformitaet mit Unix 03 wenig ueber die praktische Kompatibilitaet aus. Wenn ich mir da
mmap() von POSIX.1-2017 anschaue (Nachfolger von UNIX 03), dann steht da, dass Implementationen PROT_EXEC nicht unterstuetzen muessen (mprotect() auch nicht). Also hurra, mmap() in MacOS is POSIX.1-2017-konform, aber leider ist damit kein JIT-Compiler, den ich kenne, POSIX.1-2017-konform. M.a.W., POSIX.1-2017 (und davor UNIX 03) ist eine notwendige, aber keine hinreichende Bedingung, damit ein Betriebssystem ein praktikables Unix ist.
Du hängst dich an einem Programm auf, wolltest du schlau daherreden? Dann nimm es in Version 0.73, das läuft in macOS BigSur, Monterey, Ventura, auf Intel und Apple Silicon.
Ja, mal ausprobiert auf Darwin 21.06 (keine Ahnung, welchem Codenamen das entspricht), laeuft tatsaechlich, weil die Version 0.7.3 noch keine Ahnung von Aarch64 hat, sich fuer ARM (also A32/T32) konfiguriert, aber gluecklicherweise offenbar nichts davon verwendet. Insbesondere verwendet es auch keine JIT-Compilation, und damit spielt die reduzierte mmap()-Funktionalitaet von MacOS auf Apple Silicon keine Rolle fuer die Lauffaehigkeit.
Was das "Sich-Aufhaengen" betrifft: Ich habe versucht, ein Programm zu portieren, und meine Eindruecke davon berichtet. Vielleicht ist es ein Einzelfall, aber ich bezweifle es.
Dann schauen wir uns einmal die Performance an (Zahlen sind Laufzeiten in s):
Code:
sieve bubble matrix fib
0.254 0.240 0.167 0.272 gforth-0.7.3, MacOS, Mac Mini M1, clang-14.0.0
0.091 0.088 0.053 0.080 gforth-0.7.9-20220707, Linux, Mac Mini M1 Firestorm 3000MHz; gcc-11.3.0
0.136 0.155 0.081 0.147 gforth-0.7.9-20220707, Linux, Mac Mini M1 Icestorm 2064MHz; gcc-11.3.0
0.056 0.055 0.033 0.044 gforth-0.7.9-20210218, Linux, AMD Ryzen 5800X 4800MHz; gcc-8.3
Ich weiss nicht, ob das unter MacOS auf einem Firestorm-Kern lief oder einem Icestorm-Kern, aber auch der Icestorm ist unter Linux schneller als was ich unter MacOS gemessen habe. Dazu kann auch gcc beigetragen haben (auf MacOS kriege ich komischerweise clang, wenn ich gcc aufrufe), aber eben auch, dass 0.7.9 unter Linux eine JIT-Compiler verwendet. Zum Vergleich habe ich noch einen Ryzen 5800X dazugegeben.
@Fakechaser: Ja, Gforth versucht, Bereiche RWX zu mmap()en. In 0.7.3 faellt es automatisch auf den interpretativen Modus zurueck, da reicht auch Allokation mit malloc() (die unter MacOS auf M1 verwendet wird, weil die mmap()-Aufrufe failen).