Hallo hab mir mal ein Programm geschrieben, mit dem ollen Borland C++-Builder, zur Berechnung von Primzahlen. Jetzt hab ich mir mal gedacht, ich schau mal, wie lange meine Rechner für die Berechnung einer bestimmten Anzahl an Primzahlen braucht. Zwei meiner Notebooks (Fujitsu und Acer, jeweils I5, 3.Gen bzw 4.gen) brauchen 10, bzw 11 Minuten. Dann wurde das Gesicht aber lang, als ich das Programm auf meinem PC mit nem Ryzen 5 2600 laufen liess und der mehr als doppelt so lange brauchte. Im Taskmanager sieht man, dass da ein Prozessor mit 100% läuft, aber wieso trotzdem so langsam? Wieso sind die ollen Notebooks doppelt so schnell? Gruß
Ohne das Programm zu sehen, wird eine Einschätzung schwierig. Bei so billigen Berechnungen ist es oft die Konsolen-Ausgabe oder das Schreiben in Dateien, das die meiste Zeit benötigt.
Und auf was der Compiler optimiert hat, ist auch noch immer so eine Sache.
Compiler versuchen Prozessor-Optimierten Code zu erstellen. Das geht solange perfekt wie man sich in der Selben Prozzesor-Generation befindet. Die einzigen Unterschiede zwischen AMD + Intel sind das die Prozessoren gewisse Sachen unterschiedlich regeln. Wechselt man auf eine Prozessor einer anderen Generation setzt der andere Prioritäten zum Abarbeiten seiner Jobs. Einfach gesagt, er ist auf die modernere Hardware optimiert. Dies führt dazu das gewisse Aufgabe halt etwas länger dauern. Besonders wenn die Hersteller die Chips nicht auf das Arbeiten sondern auf die Brenchmark-Tests hin optimieren. Man muss den Leuten halt nur erzählen sie sind schnell ;) und braucht ein renommiertes Prg. das dann die schönen Zahlen liefert. Keine Aluhut Geschichte. Sondern von Fachmagazinen damals nachgewiesen. Weshalb die üblichen Magazine inzwischen kaum noch so Brenchmark-Tests veröffentlichen. Sondern die Office-Pakete nutzen dafür. Wenn die Hersteller auf Office Optimieren hat man mehr davon als nur geile Zahlen ;) Dazu kommen noch andere Komponenten wie Grafikausgabe etc. Besonders die Grafik ist ein Problem. Weshalb ich lieber eine Zählschleife laufen lasse und die Grafik nur alle 100 Berechnungen aktualisiere, als bei jeder Berechnung. Ist mehr Code den der Computer abarbeiten muss, macht die Sache selbst aber locker 2-3 x so schnell. Es kann sogar dazu führen, das der Prozessor gewissen Berechnungen die er vorher selbst (auf hoher Ebene) gemacht hat, nun an Sub-Routinen auslagert. Prozessoroptimierung ist eine Wissenschaft und zwar eine sehr komplexe.
Ah ja, also es ist schon eine Windows-Applikation. Aber der Borland C++-Builder ist ja ne 32-Bit Applikation, erstellt auch "nur" 32-Bit-Programme. Das könnnte auch ne Rolle spielen? Auf einem der Notebooks läuft 32-Bit Win7, auf dem anderen 64-Bit Win7. Auf dem "langsamen" PC 64-Bit Win10. Wie war das mit der X64-Architektur und 32.Bit Programmen? Kann das auch ne Rolle spielen? Während des Laufs der primärzahlberechnung läuft nur der Zähler für die Anzahl der Berechnungen. Gruß
Franko P. schrieb: > Wie war das mit der X64-Architektur und > 32.Bit Programmen? Kann das auch ne Rolle spielen? Ja unbedingt. Das Problem ist, das MS nicht die Eier hat, die Abwärts-Kompatibilität einzustellen. Also muss aller alter schei** notfalls durch einen Emulator. Witzigerweise zwingen sie 90% der Bevölkerung sich neue Hardware anzuschaffen aber haben nicht die Eier das OS darauf zu Fixieren.
Es hängt u.U. von der Laufzeit eines bestimmten die Rechnung dominierenden Befehls ab. Dazu siehe Punkt 4 in https://www.agner.org/optimize/#manuals
Schlaumaier schrieb: > Das Problem ist, das MS nicht die Eier hat, die Abwärts-Kompatibilität > einzustellen. Also muss aller alter schei** notfalls durch einen > Emulator. Da wird nichts emuliert.
Schlaumaier schrieb: > Compiler versuchen Prozessor-Optimierten Code zu erstellen. Compiler optimieren so, wie man denen das vorgibt. Und wenn man denen nichts vorgibt, nehmen die eine Default-Optimierung, die als kleinsten gemeinsamer Nenner den Befehlssatz eines (generischen) Basisprozessor-Typs nutzt. Welcher das genau ist (x86, x64, Amd64, …), steht in der Doku. Beim Borland C++ ist das (vermutlich) der 80386 - Befehlssatz, in 32 Bit. Ein Ryzen 2600 sollte jeden dieser Codes in zu i3/i5 mindestens vergleichbarer Geschwindigkeit abarbeiten. Oliver
:
Bearbeitet durch User
(prx) A. K. schrieb: > Da wird nichts emuliert. Vielleicht etwas unglücklich von mir Ausgedrückt, das gebe ich zu. https://docs.microsoft.com/de-de/troubleshoot/windows-server/performance/compatibility-limitations-32-bit-programs-64-bit-system Mit dem WOW64-Subsystem können 32-Bit-Programme ohne Änderungen auf x64-basierten Versionen von Windows ausgeführt werden. Das WOW64-Subsystem erstellt dazu eine 32-Bit-Umgebung in den x64-basierten Versionen von Windows.
Oliver S. schrieb: > in Ryzen 2600 sollte jeden dieser Codes in zu i3/i5 mindestens > vergleichbarer Geschwindigkeit abarbeiten. Je kleiner das Testprogramm ist, desto grösser ist der Einfluss bestimmter Unterschiede.
Nachtrag : Zitat des Links s.o. Einige 32-Bit-Programme werden unter diesen Betriebssystemen möglicherweise langsamer ausgeführt als bei 32-Bit-Versionen von Windows. Und GENAU DAS ist das Problem des TO.
> Je kleiner das Testprogramm [..]
..das wir noch nichtmal gesehen haben. Wäre nett wenn der FO Quellcode
nebst Compilereinstellungen veröffentlichen würde, dann könnte man
möglicherweise konkrete Tipps geben anstatt Glaskugel zu lesen.
Schlaumaier schrieb: > Mit dem WOW64-Subsystem können 32-Bit-Programme ohne Änderungen auf > x64-basierten Versionen von Windows ausgeführt werden. Das > WOW64-Subsystem erstellt dazu eine 32-Bit-Umgebung in den x64-basierten > Versionen von Windows. Das betrifft aber nur Aufrufe von Windows-APIs, wen 32-Bit Aufrufe ins 64-Bit Windows umgesetzt werden müssen. Der Prozessor selbst kann beide Modi nebeneinander. Solange sein Primzahlprogramm hauptsächlich rechnet, sind Unterschied in API-Aufrufen irrelevant.
(prx) A. K. schrieb: > Solange sein Primzahlprogramm hauptsächlich rechnet, > sind Unterschied in API-Aufrufen irrelevant. Man weiß es nicht ;) g457 schrieb: > ..das wir noch nichtmal gesehen haben. Wäre nett wenn der FO Quellcode > nebst Compilereinstellungen veröffentlichen würde, dann könnte man > möglicherweise konkrete Tipps geben anstatt Glaskugel zu lesen. STIMMT
Schlaumaier schrieb: > Das Problem ist, das MS nicht die Eier hat, die Abwärts-Kompatibilität > einzustellen. Wenn es einen wirklichen Erfolgsfaktor von MS gibt, dann den, dass 40 Jahre alte Dosenanwendungen immer liefen. Ohne Emulator. Klar, immer wieder musste man sich von Programmen verabschieden, die Wartezeit durch Nops-Schleifen erzeugten oder aus anderen gründen inkompatibel wurden. Aber der Wille war (im Gegensatz zu hippen anderen) da.
Schlaumaier schrieb: > Witzigerweise zwingen sie 90% der Bevölkerung sich neue Hardware > anzuschaffen aber haben nicht die Eier das OS darauf zu Fixieren. Weil sie damit einen großen Teil der Anwendungsprogramme verlieren wollen. Ohne Anwendungsprogramme ist das OS wertlos. A. S. schrieb: > Wenn es einen wirklichen Erfolgsfaktor von MS gibt, dann den, dass 40 > Jahre alte Dosenanwendungen immer liefen. Ohne Emulator. Ich denke auch, dass das hohe Maß an Abwärts-Kompatibilität die wichtigste Stärke von Windows ist.
Stefan ⛄ F. schrieb: > Weil sie damit einen großen Teil der Anwendungsprogramme verlieren > wollen. Ohne Anwendungsprogramme ist das OS wertlos. Stimmt. Aber Apple hatte damals die Eier. Als sie den Motorola gegen Intel getauscht haben meine ich. Also wieso nicht mal ein Schnitt im OS machen. Meinetwegen können sie das andere Zeug ja als Emulator (Macht Apple + Linux auch mit MS) laufen lassen. Ich kann dir die Antwort sagen, und auch jeder Firmenchef auch. Es ist 50 x teuren was neues zu machen(anzuschaffen) als an den Toten Kind herum zu basteln. So malen sie das Teil nur neu an, machen ein paar Routinen rein um Leute zu ärgern, und das wars. Und Leute wie wir sagen dann. "Mit ein paar Tricks geht das aber doch". Ist halt Marktwirtschaft. ;(
Stefan ⛄ F. schrieb: > Weil sie damit einen großen Teil der Anwendungsprogramme verlieren > wollen. Ohne Anwendungsprogramme ist das OS wertlos. Korrektur würden, nicht wollen.
Schlaumaier schrieb: > Also wieso nicht mal ein Schnitt im OS machen? Ich denke, wenn das passiert, wird Microsoft eine Linux Distribution heraus bringen. Die machen ja jetzt schon recht viel in dem Umfeld. Irgendwas wird dann aber trotzdem absichtlich inkompatibel sein, das ist ja deren Tradition. Vielleicht trifft es die Druckertreiber. Oder die Grafiktreiber. Wobei ich eher erwarte, dass die großen Hersteller der Grafikkarten sich bald zusammen tun und ein neues Grafiksystem etablieren, das alle Betriebssysteme nutzen werden. Der aktuelle Wildwuchs ist ja nicht mehr vernünftig zu erklären.
Schlaumaier schrieb: > Aber Apple hatte damals die Eier. Als sie den Motorola gegen Intel > getauscht haben meine ich. Macht Microsoft auch. Es gibt Windows-Laptops mit ARM Prozessor. ARM Programme laufen nativ, x86 Programme werden emuliert - ja, diesmal passt der Begriff.
:
Bearbeitet durch User
(prx) A. K. schrieb: > Macht Microsoft auch. Es gibt Windows-Laptops mit ARM Prozessor. ARM > Programme laufen nativ, x86 Programme werden emuliert - ja, diesmal > passt der Begriff. Danke für die Info. Muss ich mich mal schlau machen.
Schlaumaier schrieb: > Aber Apple hatte damals die Eier. Als sie den Motorola gegen Intel > getauscht haben meine ich. Auch schon vorher. Apple verdient sein Geld aber auch überwiegend mit HW. Und durch Steve Jobs, ohne seine Rückkehr und seine Visionen (und MS-Hilfe) wären sie l#ngst Geschichte. Sie leben vielleicht nicht wegen, sondern trotz der Eier. Auch bei Autos wird die Oberklasse (Maybach, S-Klasse, Phaeton, Ferrari, ...) vom Massenmarkt am Leben erhalten.
A. S. schrieb: > Apple verdient sein Geld aber auch überwiegend mit > HW. Ähem… Apple verdient sein Geld auch mit Hardware, aber nicht im Sinne von einzelner Hardware. Die ist da nur Teil des geschlossenen Universums aus Software, Services, Shops, und Hardware, welches als Ganzes das Geld verdient. Macs und Ähnliches sind da allerdings eh nur Nebengeräusche. Die Musik spielt bei denen woanders. Oliver
Tja also, sieht tatsächlich so aus, als würde die Anzeige der Durchläufe das Programm so massiv bremsen. Statt jeden hochgezählten Wert anzuzeigen mache ich das nur noch nach jeweils 10000, und schon ist das Notebook nach 1:23 fertig und der Ryzen-PC auch. Die Grafik macht hier wohl Probleme. Danke für die Kommentare. Evtl beshäftige ich mich mal nochmal mit dem Problem (das ja eigentlich keins ist). Gruß :-)
Franko P. schrieb: > Statt jeden hochgezählten Wert anzuzeigen Schlaumaier schrieb: >> Solange sein Primzahlprogramm hauptsächlich rechnet, >> sind Unterschied in API-Aufrufen irrelevant. > > Man weiß es nicht ;) Touché.
Franko P. schrieb: > Die Grafik macht hier > wohl Probleme. Nicht wirklich. Es wird NICHT nur Anzeige wird aktualisiert, sondern die ganze Form (Fenster) neu gemalt. Das dauert mehr Zeit als das Rechnen selbst. Ist ja auch ne Menge Arbeit so viele Pixel immer wieder neu zu malen. Wenn das nicht so schnell gehen würde würde es blinken. Und da fängt dann Problem 2 an. Wenn deine "mach Anzeige"-Schleife zu hoch eingestellt ist, wird dein Prg. schneller. ABER wenn du nun das Fenster anklickst, steht oben "Keine Rückmeldung" weil das Prg. so beschäftigt ist, sein Job zu machen, das es keine Zeit hat, den GDI (Grundlage der Grafik) zu sagen wie es das Fenster zu malen hat. Weshalb ich wie oben erwähnt irgendwas zwischen 100 + 1000 (Je nach Dauer EINES Durchlauf der Berechnungsschleife) angebe. In Basic geht das so. lauf = true x = 0 i = 0 Do while Lauf = true X = x +1 i = i + 1 if x = 100 then '<- Wert der Aktualisierung x = 0 ' anzeige wert von i my.application.doevent ' Zwingt das Prg die Form(Fenster) neu zu zeichnen und das den GDI zu sagen. Macht man noch ein schönen Balken oder so, dann siehst das richtig cool aus. ;) end if ' mach was loop Das beschleunigt das Prg. gigantisch.
Schlaumaier schrieb: > Franko P. schrieb: >> Die Grafik macht hier >> wohl Probleme. > > Nicht wirklich. > > Es wird NICHT nur Anzeige wird aktualisiert, sondern die ganze Form > (Fenster) neu gemalt. Nun ja, ich habe ja immer noch die Hoffnung, daß der TO einigermaßen Ahnung von dem hat, was er da tut, und die Ausgabe auf die Konsole geht. Schlaumaier schrieb: > In Basic interessiert das niemanden. Oliver
Oliver S. schrieb: > interessiert das niemanden. Eigentlich doch. Da der Code als eine Art Ablauf-Diagramm zu sehen ist. Was bedeutet das der Leser das auf JEDE Sprache locker umsetzen kann. Und für die großen Trottel schreibe ich dabei das es Basic-Code ist, seit ich mal erlebt habe das sich einer Beschwert hat, das der Code in C++ nicht läuft. Er hätte ihn rein kopiert und der Compiler würde nur Error anzeigen. ;) Und die allgemeine Lage ja so ist, der der Gesetzgeber die Leute verpflichte, jede Menge Warnhinweise zu machen. Weil die Menschheit zu viel RTL nutzt, und nicht mehr selbst denken kann. ÖR schlagen inzwischen auch diesen Kurs ein. Aber das ist ein anderes Thema.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.