Einloggen
[c] [meta] [fefe]

/fefe/ – Fefes Kommentarfunktion


Antwort erstellen

(≤ 4)



[Zurück]

  • [l] Ich arbeite gerade für libowfat an einem ninja-Buildpfad. ... Effe ## Mod Wed, 22 Jan 2025 17:32:54 GMT Nr. 145965
    JPG 1000×656 121.6k
    Ich arbeite gerade für libowfat an einem ninja-Buildpfad. Im Moment ist das noch GNU make und damit bin ich eigentlich auch soweit zufrieden.

    Aber man hört ja, dass ninja furchtbar viel schneller sein soll, also habe ich das mal als Feierabendprojekt angefangen. GNU make ist programmierbar und damit ninja deutlich voraus in der Expressivität der Buildanweisungen. Ich musste hier also einiges von Hand konvertieren, aber bin jetzt so weit, dass ich mit ninja alle Dateien kompilieren kann.

    Gucken wir doch mal!

    % time make -s -j16 libowfat.a
    make -s -j16 libowfat.a  14.03s user 6.11s system 1222% cpu 1.647 total
    % time ninja
    ninja  15.98s user 7.85s system 1530% cpu 1.557 total
    


    Tsja. Ein Wort mit X. Das war wohl nix.

    Der ninja-Build sagt einem ja am Ende, wie viele Edges er hatte. Das sind 570. Wir reden hier also nicht von einem Trivialprojekt.

    Klar, das Buildsystem tut auch nicht so viel. Der ruft halt den Compiler ganz oft auf, und der braucht dann Zeit. Insofern weiß ich auch nicht, woher da die großen Einsparen kommen sollen am Ende.

    Ich vermute jetzt aber, dass wenn ninja in anderer Leute Projekten mehr rausholt, dass das dann weniger an ninja oder make und mehr an schlechten Makefiles liegt.

    Und ja, was automake und cmake da generieren, am besten noch mit rekursiven make-Aufrufen, das kostet dann natürlich mehr beim Bauen. Nicht dass mein Makefile jetzt besonders tiefergelegt und auf Sparsamkeit getrimmt wäre. Aber es versucht natürlich, wenig überflüssige Dinge zu tun. Klar.

    https://blog.fefe.de/?ts=996febed
  • [l] Felix Wed, 22 Jan 2025 20:44:53 GMT Nr. 145995
    Warum gibt Fefe in seiner Make-Datei explizit Include-Dateien als Abhängigkeiten an?

    Z.B. ist als Abhängigkeit von array_allocate.o die Include-Datei likely.h angegeben. Die Datei likely.h wird aber nirgendwo generiert, das ist eine ganz normale Include-Datei.

    https://github.com/gebi/libowfat/blob/master/Makefile#L55

    >time
    Komisches Format dort (normalerweise kennt Felix da "real", "user", "sys"), aber oke.
    >1222% cpu
    >1530% cpu
    Sieht das Felix richtig? Von Fefes 16 Kernen waren bei make nur ~12 Kerne ausgelastet, bei ninja ~15 Kerne? Warum ist make dann schneller?
  • [l] Felix Wed, 22 Jan 2025 21:07:11 GMT Nr. 145999
    >>145995
    Abhängigkeiten sind ja nicht nur für generierte Dateien. Wenn du inkrementell baust, dann willst du natürlich, dass alle Dateien neu kompiliert werden, die einen Header einbinden, wenn dieser editiert wurde. Durch die Änderung könnte sich ja z.B. die Größe eines Structs geändert haben oder so und damit wäre dann das ABI kaputt. Da muss neu gebaut werden. Ansonsten hat dein Makefile einen Bug. Das ist ein Hauptgrund, warum die meisten Leute CMake, Meson und Co. verwenden, weil jene die Abhängigkeiten automatisch erkennen, was das Bauen wesentlich weniger fehleranfällig macht als handgepfrengte Makefiles.
  • [l] Felix Wed, 22 Jan 2025 21:20:10 GMT Nr. 146001
    >>145999
    Ja, genau. Bei Make-Dateien für C/C++ macht man deswegen normalerweise das hier:
    https://www.gnu.org/software/make/manual/html_node/Automatic-Prerequisites.html

    >You can see that for a large program you would have to write dozens of such rules in your makefile. And, you must always be very careful to update the makefile every time you add or remove an #include.
    Außer man ist Herr Leitner, dem kann so etwas natürlich nie passieren.

    Felix fragt sich gerade, ob die längere Laufzeit von ninja damit zusammenhängen könnte, dass ninja alle Abhängigkeiten beim Kompilieren ausgegeben bekommt und die Zeitstempel aller dieser Dateien prüfen muss. Und zwar nicht nur die Zeitstempel lokaler Include-Dateien (das müsste man auch bei der Make-Datei), sondern auch von System-Include-Dateien (was die Make-Datei nicht macht).
  • [l] Felix Wed, 22 Jan 2025 21:29:29 GMT Nr. 146003
    >>146001
    %.d: %.c
            @set -e; rm -f $@; \
             $(CC) -M $(CPPFLAGS) $< > $@.$$$$; \
             sed 's,\($*\)\.o[ :]*,\1.o $@ : ,g' < $@.$$$$ > $@; \
             rm -f $@.$$$$
    

    So richtige kryptische Nackenbartscheiße. Genau wegen sowas war der .xz-Exploit möglich. Nee, da würde Felix auch lieber seine Makefiles von Hand pfrengen.
  • [l] Felix Wed, 22 Jan 2025 21:47:16 GMT Nr. 146004
    >>146003
    Iss gut, Fefe
    Erzähl den Lesern lieber mal, warum ninja so langsam war.

    Wenn einem die reine Make-Lösung nicht gefällt, gibt es auch noch makedepend oder irgendwas mit depcomp.


[Zurück]
[c] [meta] [fefe]