Mingw64 erzeugt sehr langsamen Code
Hallo !
Die Frage steht eigentlich schon da.
Mit dem mingw Compiler erzeuge ich jeweils einen 64-bit und einen 32-bit Code.
Unter der "Leitung" von CodeBlocks.
Der 64-bit Code ist geschätzte 5 Mal langsamer als der 32-bit Code. Das macht leider
den Vorteil, viel RAM zu haben, komplett nutzlos.
Habe schon endlos mit den Optimierungen probiert, die CB anbietet - bleibt sich alles gleich...
Mein Rechner ist ein HP ProBook mit AMD Llano und 4GB RAM .
Ist mir da zu helfen ?
Für jede Antwort dankbar - Ekkehard
Die Frage steht eigentlich schon da.
Mit dem mingw Compiler erzeuge ich jeweils einen 64-bit und einen 32-bit Code.
Unter der "Leitung" von CodeBlocks.
Der 64-bit Code ist geschätzte 5 Mal langsamer als der 32-bit Code. Das macht leider
den Vorteil, viel RAM zu haben, komplett nutzlos.
Habe schon endlos mit den Optimierungen probiert, die CB anbietet - bleibt sich alles gleich...
Mein Rechner ist ein HP ProBook mit AMD Llano und 4GB RAM .
Ist mir da zu helfen ?
Für jede Antwort dankbar - Ekkehard
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 309944
Url: https://administrator.de/contentid/309944
Ausgedruckt am: 14.11.2024 um 03:11 Uhr
5 Kommentare
Neuester Kommentar
Hallo Ekkehard.
MinGW ist die Windows-Portierung des GCC. Der wiederum wurde ursprünglich für *nixoide Betriebssysteme entwickelt. Es wäre nicht weiter verwunderlich, wenn der kompilierte Code etwas Overhead beinhaltet. Insbesondere bei C++ Anwendungen wird das der Fall sein. Dort landet der Code für die Objekte der STL direkt statisch gelinkt im Binary, während bspw. der VC gegen compilerspezifische DLLs linkt.
Wie auch immer, das kann eigentlich nicht die Ursache dafür sein, dass ein 64 Bit Programm langsamer läuft als ein 32 Bit Build desselben Quellcodes. Da ist sicher was anderes im Spiel. Was passiert denn, wenn du deinen Virenscanner mal deaktivierst? Hast du sonst noch irgendwas installiert, das Prozesse überwacht?
Grüße
rubberman
MinGW ist die Windows-Portierung des GCC. Der wiederum wurde ursprünglich für *nixoide Betriebssysteme entwickelt. Es wäre nicht weiter verwunderlich, wenn der kompilierte Code etwas Overhead beinhaltet. Insbesondere bei C++ Anwendungen wird das der Fall sein. Dort landet der Code für die Objekte der STL direkt statisch gelinkt im Binary, während bspw. der VC gegen compilerspezifische DLLs linkt.
Wie auch immer, das kann eigentlich nicht die Ursache dafür sein, dass ein 64 Bit Programm langsamer läuft als ein 32 Bit Build desselben Quellcodes. Da ist sicher was anderes im Spiel. Was passiert denn, wenn du deinen Virenscanner mal deaktivierst? Hast du sonst noch irgendwas installiert, das Prozesse überwacht?
Grüße
rubberman
Hallo Ekkehard,
es lohnt sich bestimmt
Spaß beiseite. Einerseits, wenn es dich nicht stört dass das schnellere das 32 Bit Programm ist, dann nutze doch das. Andererseits, wenn Linux etwas ist, von dem du dir mehr versprichst, als nur ein Programm schneller laufen zu lassen, dann teste es aus.
Persönlich hab ich den ganzen Tag mit Windows zu tun. Ich sehe keinen Grund privat ein anderes OS zu nutzen. Wenn ich mir ein Tool schreibe, das ich auch beruflich nutzen will, muss es sowieso auf Windows laufen ...
Grüße
rubberman
es lohnt sich bestimmt
Spaß beiseite. Einerseits, wenn es dich nicht stört dass das schnellere das 32 Bit Programm ist, dann nutze doch das. Andererseits, wenn Linux etwas ist, von dem du dir mehr versprichst, als nur ein Programm schneller laufen zu lassen, dann teste es aus.
Persönlich hab ich den ganzen Tag mit Windows zu tun. Ich sehe keinen Grund privat ein anderes OS zu nutzen. Wenn ich mir ein Tool schreibe, das ich auch beruflich nutzen will, muss es sowieso auf Windows laufen ...
Gruß von (s. Anhang)
Hmm sieht nach Insel aus. Mehr kann ich da nicht reininterpretieren Grüße
rubberman
von Kreta
Ah Jetzt wo ich's weiß, sehe ich die Ähnlichkeit auch.nachdem ich nicht mehr für Autoindustrie und Wissenschaftsbetrieb knechten muss
Da muss ich noch ein paar Jahre. Aber dann kauf ich mir 'ne Insel Das Bild und viele andere macht mein Progrämmchen aus "Tabellen" mit Höhenwerten. Die kann sich jeder runterladen, von den meisten Orten der Welt. Alle 30 m in x und y ein Messwert. Von einem Projekt "ASTER".
Sehr cool.Und liegt der Hase begraben
Nee nee. Der Hase liegt nur im Pfeffer und erfreut sich bester Gesundheit. Aber ich sehe dein Dilemma, "die Lage ist hoffnungslos aber nicht ernst." Linux kannst du ja parallel ... Man könnte noch etwas spielen. Ich weiß nicht warum und es ist auch nicht so ganz logisch, aber sowohl Virenscanner als auch Windows mögen "Müll" am Ende des Binary. Füge mal eine Versioninfo Resource deinem Projekt hinzu.Datei "dummy.rc"
/*
https://msdn.microsoft.com/en-us/library/windows/desktop/aa381058(v=vs.85).aspx
*/
#define WIN32_LEAN_AND_MEAN
#include <windows.h>
#define APP_VS 1,0,0,0
#define APP_VERSION "1.0.0.0\0"
#define APP_BUILD "July 2016\0"
#define APP_DEVELOPER "John Doe\0"
#define APP_COPYRIGHT "© 2016 John Doe\0"
#define APP_NAME "DUMMY\0"
#define APP_FILENAME "dummy.exe\0"
#define APP_COMMENT "dummytext\0"
LANGUAGE LANG_ENGLISH, SUBLANG_ENGLISH_US
VS_VERSION_INFO VERSIONINFO
FILEVERSION APP_VS
PRODUCTVERSION APP_VS
FILEFLAGSMASK VS_FFI_FILEFLAGSMASK
#ifdef _DEBUG
FILEFLAGS VS_FF_DEBUG|VS_FF_PRIVATEBUILD|VS_FF_PRERELEASE
#else
FILEFLAGS 0x0L // final version
#endif
FILEOS VOS_NT_WINDOWS32
FILETYPE VFT_APP
FILESUBTYPE VFT2_UNKNOWN // not used
{
BLOCK "StringFileInfo"
{
BLOCK "040904E4" // Lang=US English, CharSet=Windows Multilingual
{
VALUE "Build", APP_BUILD
VALUE "Comments", APP_COMMENT
VALUE "Developer", APP_DEVELOPER
VALUE "FileDescription", APP_COMMENT
VALUE "FileVersion", APP_VERSION
VALUE "InternalName", APP_NAME
VALUE "LegalCopyright", APP_COPYRIGHT
VALUE "OriginalFilename", APP_FILENAME
VALUE "ProductName", APP_NAME
VALUE "ProductVersion", APP_VERSION
} // BLOCK "040904E4"
} // BLOCK "StringFileInfo"
BLOCK "VarFileInfo"
{
VALUE "Translation", 0x0409, 0x04E4 // 0x04E4 = 1252
} // BLOCK "VarFileInfo"
}
Grüße
rubberman