Compilieren von Software auf Windows - Performance benefit?

Wenn Du sie nicht nur einfach mit den Voreinstellungen compilierst, sonder selbst den Code liest verstehst und optimierst, hat das eindeutig den Vorteil, daß Du die Bugs wegmachen kannst, den NSA-Kram entfernen kannst und dann noch mit den optimierten libraries linkst, hast Du hinterher deutlich bessere Andwendungen.

Wenn Du hingegen, einfach nur "make config; make; make install" tippst, kanst Du Dir das auch sparen, sofern Du das überhaupt gebaut bekommst.

lks

Die Persormanceunterschiede zwischen Linux und Windows sind nicht so groß, als die Performanceunterschiede zwischen den Compilern. Ich würde eher recherchieren welcher Kompiler das am Besten packt und davon abhängig das Betriebssystem wählen.

Das hängt aber auch davon ab welche Flags man beim Compiler überhaupt setzt. Denn klar - normal werden die Dinger mit nem Standard-Set gebaut -- so das die eben auf AMD, Intel und whatever laufen. Wäre ja blöd wenn ein Hersteller z.B. ein Spiel rausbringt, welches aber nur auf nen Intel xyz läuft, die Grafikkarte genau die xyz sein muss usw... Damit fallen dann aber natürlich auch spezifische optimierungen oder ganze Befehlssatz-Bereiche raus. Wenn man das jetzt selbst übersetzt kann man die mit im Compiler aufnehmen lassen UND die werden dann genutzt. Das kann schon einiges bewirken. Das Problem an der Kiste wird nur werden: Bis man da alles zusammen hat um das Programm zu bauen braucht man ja auch Zeit. Denn es ist ja bei grösseren Programmen eher nicht der Fall das man einfach nur eine Datei lädt und gut ist - da sind abhängige Librarys drin, ggf. werden sogar noch spezielle Versionen von denen benötigt,... Auch das muss man sich ja dann erst mal zusammensuchen. Dann muss man natürlich auch noch die Zeit einrechnen die der Compiler verwendet - bei grossen Programmen kann das ja auch durchaus einige Stunden dauern (und das mehrfach weils eben ab und an auch dann einfach nur ne Fehlermeldung am Ende gibt). Wenn man den Zeitaufwand mal dagegen rechnet stellt sich die Frage ob sich das noch lohnt...

Wenn man dann noch glaubt wirklich da "NSA-Kram" oder sonstwas suchen zu wollen - viel Spass... Selbstverständlich würde jede Behörde da nen Block einfügen
/*

• Here begins the NSA/CIA/BND-Area, pls. do not remove

*/
Auch da würde ich somit mal vermuten das es in den Frameworks drinne hängen würde und da hat man dann eben keinen Zugriff auf die sources (ganz davon abgesehen das man es ja auch erst mal erkennen müsste). Schon ist der Teil also egal -> bis man das wirklich komplett debugged hat hätte man die Engine auch einfach komplett selbst geschrieben. Bugs entfernen ist genauso Unsinnig in dem Kontext - weil man sich ja da ne eigene Version baut. Wenn man nicht zufällig was findet und das auch an den Hersteller zurück liefert hätte man jetzt also nen eigenen Source-Tree erzeugt. Man selbst hat dann also 1 Bug gefixt - super... der Hersteller, bei dem die SW-Entwickler ihren Code ja kennen, hat in der Zeit aber 10 andere gefixt die bei einem selbst dann noch offen sind. Daher sind das eher keine Bereiche die optimierungen betreffen - das sind eher die "interessierten" Personen die sowas lesen und die eben dann aber auch die Hersteller (bestenfalls) informieren oder (schlimmstenfalls) die Lücken ausnutzen um andere Rechner anzugehen...

Maximal 5% unterschied in der Performance. Was du meinst sind Module, die Linux einfach weg lässt.

Hat er ja auch nicht ganz Unrecht, da die nicht geladen werden, ist das System natürlich schneller. IMHO sind das heutzutage aber nur Messwerte. Auf einem 286 oder 386 hat das noch was gebracht. Auf meinem 486 DX 33 mit 64 MB RAM habe ich das schon nicht mehr bemerkt.

🖖