Sind Atom-Prozessoren bezüglich älterer Software lahme Krücken?

[MaTel]

ich habe hier ein älteres CLIPPER Programm ( basiert auf DBase ). Das scheint unter WinXP unter Atomprozessoren massive Performanceprobleme zu haben.
Simple Berechnungen, bzw. Datenbankabfragen, die selbst auf einem P133 schnell gehen, dauern auf Systemen mit Atomprozessor 10x länger.
Das gleiche Programm läuft auf "normalen" aktuellen AMD / INTEL CPUs mit WinXP ohne Probleme.
Was ist an diesen Atomprozessoren anders?

[DosAmp]

Ist das wie dBase ein DOS-Programm? Wenn ja, könnte ich mir vorstellen, dass es daran liegt, dass beim Intel Atom, der lange nach dem Ende der 16-Bit-Ära geplant, produziert und auf heutige 32-/64-bittige integrierte Systeme optimiert wurde, der Virtual-8086-Modus (der von der virtuellen NT-DOS-Maschine NTVDM unter 32-bittigen WinNT-Versionen für DOS- und Win-3.x-Anwendungen benutzt wird) nur noch stiefmütterlich behandelt und statt „in Hardware“ nur noch über Mikrocode-Emulation implementiert wurde. Das Phänomen träte dann bei „vollwertigen“ Prozessoren, selbst wenn sie bei 32-Bit-Anwendungen etwa einem Dual-Core-Atom-System weit unterlegen wären, deswegen nicht auf.

[gandro]

Ich hab auch nur Halbwissen, aber DosAmp scheint recht zu haben: Gemäss dem Wikipedia-Artikel erzeugt der Atom viel mehr Microcode-Instruktionen als die Vorgänger, hat also viel weniger Instruktionen direkt in Hardware implementiert als andere x86er-Prozessoren. Und diejenigen, die sie in Hardware implementiert haben, wird kaum der alte Legacy-Scheiss sein.

Des weiteren hat der Atom wirklich sehr primitives Pipelining, deswegen hat er auch Hyperthreading, damit die CPU bei Multitasking-Systemen immer etwas zu tun hat. Alte DOS-Programme werden nur einen logischen Kern nutzen und die CPU wird damit häufiger im Leerlauf sein. Okay, der Pentium scheint das genau gleich zu machen, auch wenn ohne HT.

Aber für eine wirklich korrekte Aussage müsstest du mal Benchmarking machen. 10x langsamer klingt irgendwie nach Fehler.

[MaTel]

DosAmp schrieb:  Ist das wie dBase ein DOS-Programm? Wenn ja, könnte ich mir vorstellen, dass es daran liegt, dass beim Intel Atom, der lange nach dem Ende der 16-Bit-Ära geplant, produziert und auf heutige 32-/64-bittige integrierte Systeme optimiert wurde, der Virtual-8086-Modus (der von der virtuellen NT-DOS-Maschine NTVDM unter 32-bittigen WinNT-Versionen für DOS- und Win-3.x-Anwendungen benutzt wird) nur noch stiefmütterlich behandelt und statt „in Hardware“ nur noch über Mikrocode-Emulation implementiert wurde. Das Phänomen träte dann bei „vollwertigen“ Prozessoren, selbst wenn sie bei 32-Bit-Anwendungen etwa einem Dual-Core-Atom-System weit unterlegen wären, deswegen nicht auf.

korrekt. Clipper-Programme sind DOS Programme, die bis einschließlich WinXP problemlos auch in der Eingabeaufforderung laufen. Scheint wohl das Problem zu sein. Aber das eine Microcode-Emulation auf so schnellen Atom-Prozessoren gerade mal 386/486 Geschwindigkeitsniveau erreichen, hätte ich nicht gedacht.

[DosAmp]

MaTel schrieb:  Aber das eine Microcode-Emulation auf so schnellen Atom-Prozessoren gerade mal 386/486 Geschwindigkeitsniveau erreichen, hätte ich nicht gedacht.

Eventuell wäre es sinnvoll, Forenmitglieder wegen Tests deiner Software auf x86-Prozessoren mit RISCiger-Mikroarchitektur wie VIA C7 laufen zu lassen. Wenn es dort auch höllisch langsam läuft, liegt es an der Hardware-Architektur, ansonsten an Bugs in Zusammenspiel mit der DOS-Identität von WinNT.
Als zusätzlichen forensischen Schritt kann ich ja mal alte DOS-Benchmark-Ergebnisse rauskramen und mit Geekbench-Ergebnissen aus diesem Forum gegenchecken. Bringt nichts, weil es vermutlich einen Performance-Unterschied zwischen Real- und Virtual-8086-Untermodus beim Atom gibt. Und ich kann bestätigen, dass eine solche CPU unter blankem DOS schneller als ein 486er läuft.

[michi]

Ich könnte morgen meinen C7 wieder aktivieren und für einen Test zur Verfügung stellen, falls Bedarf ist...