3. Kleine Datei - Vorteile / Nachteile

Kleine Datei - Vorteile / Nachteile

  • C

    mrclue schrieb:

    Oft lese ich, dass sich Entwickler verschiedenster Bibliotheken dafür rechtfertigen das die Datei am Ende doch recht groß wird.

    Dann liest du die falschen Seiten. Die Dateigröße ist heute in den meisten Fällen doch völlig irrelevant.

    0
  • ?

    Große Dateien sind schlecht, weil jeder Datenträger länger braucht große Dateien zu lesen.
    Insbesondere kann das die Bootzeit stark verlängern, wenn es sehr viele Dateien sind.

    Ein Programm das nur 1 MB groß ist und z.B. nur auf die WinAPI zugreift ist viel schneller geladen, als ein Programm das 10 MB groß ist und noch zusätzlich die ca. > 40 MB große Qt oder GTK+ Lib laden muß.
    Gleiches trifft auf das Laden der Java VM oder .Net zu.
    Die WinAPI dagegen wird gleich beim Start von Windows geladen und ist dann im Speicher verfügbar, muß also nicht nachträglich geladen werden.

    Außerdem passen sehr kleine Programme vollständig in den Cache, das muß auf große Programme die auch noch auf viele Libs zugreifen längst nicht zutrefen.
    Das kleine Programm ist damit auch schneller in der Ausführung.
    Gerade bei Compilern und deren erzeugten Binarys ist das relevant.
    Erfahrungsgemäß bringen manchmal Compilate mit großer Optimierung (bei G++ z.B. -O3) nicht so viel, weil viele davon auch größer werden, dadurch passen sie nicht mehr komplett in den 1st Level Cache und sind damit manchmal sogar langsamer, als die, die mit einer geringeren Optimierungsstufe wurden.

    0
  • C

    Kleine Programme schrieb:

    Erfahrungsgemäß bringen manchmal Compilate mit großer Optimierung (bei G++ z.B. -O3) nicht so viel, weil viele davon auch größer werden, dadurch passen sie nicht mehr komplett in den 1st Level Cache und sind damit manchmal sogar langsamer, als die, die mit einer geringeren Optimierungsstufe wurden.

    Ich hoffe, du hast beim gcc diesen Bug gemeldet, als du diese Erfahrung gemacht hast.

    0
  • P

    http://www.linuxjournal.com/article/7269 schrieb:

    Although -O3 can produce fast code, the increase in the size of the image can have adverse effects on its speed. For example, if the size of the image exceeds the size of the available instruction cache, severe performance penalties can be observed. Therefore, it may be better simply to compile at -O2 to increase the chances that the image fits in the instruction cache.

    Ich denke, das ist kein Bug.

    0
  • C

    pyhax schrieb:

    http://www.linuxjournal.com/article/7269 schrieb:

    [-O3 kann langsamer sein, weil der Code zu groß wird für den Cache]

    Ich denke, das ist kein Bug.

    Ich hab die "Erfahrung" betont, weil ich mir einen Beleg gewünscht hätte. Die Aussage hab ich auch schon ein paar Mal gefunden, aber keinen reproduzierbaren Beleg.

    edit: Um es auszuführen: -O3 sollte als höchste Optimierungsstufe den schnellsten Code erzeugen. Dann sollte -O3 doch auch Cache-Effekte berücksichtigen und kürzeren Code erzeugen, wenn dieser am Ende schneller ausgeführt wird. Deswegen halte ich es für einen Bug, wenn das nicht der Fall ist. Aber vielleicht sehen die g++-Entwickler das ja anders.

    0
  • C

    Und woher weiß der GCC wie groß der L1-Cache auf dem Rechner ist, auf dem das Programm dann läuft?

    0
  • C

    cooky451 schrieb:

    Und woher weiß der GCC wie groß der L1-Cache auf dem Rechner ist, auf dem das Programm dann läuft?

    Dafür gibt es den Schalter -march. Die gibt zwar nicht den Cache präzise an, aber zumindest eine Größenordnung. Wenn es sich so sehr lohnt, könnte der gcc ja auch mehrere Codepfade bauen für unterschiedliche Cache-Größen.

    0
  • C

    Na ja, selbst wenn man die Cache größe angibt weiß man ja nicht unbedingt wo das ausgeführt wird - und die meisten User könnten nicht mal entscheiden welche .exe sie nutzen sollen, da ist man ja froh wenn das Wort CPU geläufig ist.

    Das mit den unterschiedlichen Codepfaden klingt zwar interessant, aber geht dann etwas an "warum kann O3 langsamer sein als O2" vorbei. 😉

    0
  • ?

    Christoph schrieb:

    edit: Um es auszuführen: -O3 sollte als höchste Optimierungsstufe den schnellsten Code erzeugen. Dann sollte -O3 doch auch Cache-Effekte berücksichtigen und kürzeren Code erzeugen,

    Auf welche CPU soll sich der Compiler denn festlegen?

    Das geht also allein schon deswegen nicht, weil jede neue CPU von Intel oder AMD unterschiedlich viel Cache hat, es verändern sich nicht nur die SSE, AVX usw. Einheiten, sondern ja auch der Cache.

    Deswegen optimiert der Compiler nur auf die speziellen Recheneinheiten und auf eine schnelle Codeausführung, nicht aber auf die Cachegröße.

    0
  • C

    Kleine Programme schrieb:

    Christoph schrieb:

    edit: Um es auszuführen: -O3 sollte als höchste Optimierungsstufe den schnellsten Code erzeugen. Dann sollte -O3 doch auch Cache-Effekte berücksichtigen und kürzeren Code erzeugen,

    Auf welche CPU soll sich der Compiler denn festlegen?

    Auf die CPU, die ihm mittels -march empfohlen wird. Soweit ich das sehe, haben alle Sandy-Bridge-CPUs (pro Core) exakt gleich viel Level 1 und Level 2 Cache. Nur der Level 3 Cache unterscheidet sich je nach Modell. Aber hier geht ja um den kleinen Level 1 und Level 2 Cache. In die vielen Megabytes des Level 3 Cache passt der Maschinencode so oder so.

    Auf ein festes Ziel von 32kB Level 1 Cache und 256kB Level 2 Cache müsste man doch gut optimieren können? Ich seh zumindest keinen technischen Grund, warum -O3 die Cache-Größe nicht berücksichtigen sollte bei den Optimierungen, und gelegentlich kürzeren Code bevorzugt, auch wenn er mehr Takte bräuchte, wenn man Cache-Effekte ignoriert. Dass solche Optimierungen nicht einfach zu implementieren ist, steht auf einem anderen Blatt.

    0
Anmelden zum Antworten