@Golem: Compilertests?

[Mr Miyagi]

Ich finde es schade das das Anwendungsfeld Softwareentwicklung im Artikel wieder so schlecht abgedeckt wird, insbesondere da hier dearart hohe Kernzahlen tatsächlich Sinn machen.

[NeoXolver]

Ich wollte gerade die selbe Frage stellen. Wäre schon interessant wie sich einige gängige Compiler auf der Kiste machen.
Ob man hier alles aus den Kernen raus holen kann oder die schmale Speicheranbindung auch hier bremst.

[Mr Miyagi]

Ich vermute das wird stark projektabhängig sein. Z.b. Firefox zu kompilieren scheint extrem speicherintensiv zu sein. Dabei wird Speicher bzw CCX stark bremsen vermute ich.

[pioneer3001]

Der Standardtest ist das Kompilieren eines aktuellen Linux-Kernels. Vor einigen Tagen habe ich ein Script gebaut, dass auf meinem Ryzen 5 1600X mit 6C12T nacheinander 12 Tests (make -j12 bis make -j1) laufen lässt und die Ergebnisse in eine Textdatei schreibt. Mit 12 Jobs braucht das 129 Sekungen und mit einem 830 Sekunden. Skaliert nicht linear und HT bringt etwas, aber vernachlässigbar. Für die programmierfaulen kommt hier das Script (verzichte auf Urheberrecht). Eventuell muss man noch vorher gcc, make etc. insten:

sudo apt-get update
sudo apt-get install build-essential
chmod u+x kernel-test.sh
./kernel-test.sh

#!/bin/bash

# some hard coded params
url="https://cdn.kernel.org/pub/linux/kernel/v4.x/linux-4.17.13.tar.xz"
file="linux-4.17.13.tar.xz"
directory="linux-4.17.13"
results="results.txt"

# some queried params
cores=$(nproc)

# some preliminary tests
[ ! -e $file ] && wget $url
[ -e $directory ] && rm -rf $directory
[ -e $results ] && rm $results

uname -a | tee -a $results
echo "" | tee -a $results

counter=$cores
while [ $counter -ge 1 ]
do
ccache -C &>/dev/null

echo "Test: make -j$counter" | tee -a $results
tar xf $file
cd $directory

# some work
make defconfig >/dev/null # je nach distro macht das evtl. eine etwas andere config
{ time make -j$counter >/dev/null; } 2>&1 | grep real | tee -a ../$results

echo "---" | tee -a ../$results
cd ..
rm -rf $directory

((counter--))
done

rm $file

echo "All done"



2 mal bearbeitet, zuletzt am 13.08.18 20:54 durch pioneer3001.

[NeoXolver]

Naja bei so „kleinen“ Compilieraufgaben, wie dem Linux Kernel, ist dass aber auch schwer zu optimieren.
Ich kenne einige Projekte, Bei denen man in Minuten auf ähnliche Werte kommt.

Zudem wären auch einpaar Crosscompiler interessant. Und was ist wenn man mehrere object files parallel baut. Diese sind ja vor dem linken erstmal vollständig unabhängig.

Das wiederum SMT ggf nicht viel bringt beim Compilieren, ist sogar nachvollziehbar.

[ms (Golem.de)]

Wir haben Qt 5.11 drin

Marc Sauter, Sr Editor
Golem.de

[1e3ste4]

Bei der großen Kernzahlen frag ich mich immer: Wie lange dauert es ein Gentoo mit KDE und allem möglichen Gedöns zu kompilieren - natürlich mit "emerge -e"! :D

[pioneer3001]

NeoXolver schrieb:
--------------------------------------------------------------------------------
> Naja bei so „kleinen“ Compilieraufgaben, wie dem Linux Kernel,
> ist dass aber auch schwer zu optimieren.
> Ich kenne einige Projekte, Bei denen man in Minuten auf ähnliche Werte
> kommt.
>
> Zudem wären auch einpaar Crosscompiler interessant. Und was ist wenn man
> mehrere object files parallel baut. Diese sind ja vor dem linken erstmal
> vollständig unabhängig.
>
> Das wiederum SMT ggf nicht viel bringt beim Compilieren, ist sogar
> nachvollziehbar.

Da werden doch mehrere Objekt-Dateien mit make -j12 parallel gebaut. Und das Cross-kompilieren mit z.b. crosstools-ng (habe viel Erfahrung mit cross-bauen von Libs) braucht man nicht testen, weil da ja auch nur ein Linux-Kernel für eine andre Architektur wie Raspi 3 (armv8) statt i686 kompiliert wird. Vorher werden ggf. einige Patches angewendet. Und es kommen noch andere Tools dazu die gebaut werden. Das Bauen eines Linux-Kernels unter Linux ist also vollkommen ausreichend zum Einschätzen wie sich die Kernanzahl auf das eigene Projekt in C/C++ auswirken würde.

Beispielsweise braucht mein C++-Projekt mit 160k Zeilen Code (in Headern und CPPs) ca 13 Minuten mit 12 Threads auf einem Ryzen 6 1600X mit 6C12T, wenn es unter Linux x64 für Linux x64 kompiliert. Wenn es cross-kompiliert mit mingw32 für Windows 32 Bit (i686) braucht es 14 Minuten. Das nimmt sich also nicht viel. Man kann auch einen gcc selbst optimiert kompilieren, damit er noch schneller kompiliert, aber viel ist da wohl nicht rauszuholen nach meinen Internet-Recherchen. Das kann man vergessen in der Praxis.

Eher bringt es mehrere PCs zu nutzen und die Kompilierung zu verteilen mit distcc. Das hilft wenn man z.b. ein schwaches Netbook mit Atom-Prozessor hat. Dann lässt man einen Teil auf seiner Kiste unterm Schreibtisch kompilieren und einen Teil auf dem Netbook. Das Linken passiert dann aber auf dem Netbook, was das stark ausbremst und nicht parallel geht. Dennoch kann man so rund 1/3 bis 1/2 Zeit sparen auf einem Netbook. Das ist schon ein Unterschied ob man auf einem Netbook 8 Minuten oder nur 4 warten muss, weil das ja das Programmieren ausbremst.



3 mal bearbeitet, zuletzt am 13.08.18 21:35 durch pioneer3001.

[pioneer3001]

1e3ste4 schrieb:
--------------------------------------------------------------------------------
> Bei der großen Kernzahlen frag ich mich immer: Wie lange dauert es ein
> Gentoo mit KDE und allem möglichen Gedöns zu kompilieren - natürlich mit
> "emerge -e"! :D

Es gibt ein Projekt mit dem man sein eigenes Linux schritt für schritt bauen kann. Habe ich mal gemacht. Hat mich Tage gekostet. Das reine Bauen dauert Stunden.

http://www.linuxfromscratch.org

Ich cross-kompiliere gelegentlich per Make-Script ca. 35 Linux-Libraries, die ich für die Cross-Entwicklung auf drei x86-Linux-Rechnern brauche. Das Bauen dauert auf einem Ryzen 1600X 6C12T mit gcc cross-kompilieren zusammen ca. 30 bis 50 Minuten, je nach Ziel-Plattform. Der größte Brocken ist die Boost Library. Die hat selbst dutzende von Libs drin.



7 mal bearbeitet, zuletzt am 13.08.18 21:57 durch pioneer3001.

[pioneer3001]

Habe mir gerade noch Gedanken zum Speicherverbrauch gemacht mit einem 32-Kerner.

Also mein C++Projekt braucht 750 MB/Kern. Deswegen ist die Kompilierung auf meinem Atom-Netbook (die haben nie mehr als 2 GB) mit vier Threads lahm, weil mein Projekt dann 4x0,75GB=3GB bräuchte, aber physisch nur 2GB hat. Daher starte ich da wenn ich das mal selten nutze, nur 2 Jobs (make -j2).

Momentan hat mein 6-Kern-Ryzen 16GB RAM, weil er 12*0,75GB=9GB braucht.

Ein 32-Kerner mit 64 Threads bräuchte aber schon 48GB RAM (oder halb so viel, wenn man HT nicht nutzen will). So eine parallele Kompilierung mit gcc ist eben auch sehr speicherhungrig.

[NeoXolver]

Habe ich scheinbar überlesen. Wobei das Ergebnis doch recht überrascht. Das sieht ja eher Singlecore Interger Leistung aus....