Führt jemand Hardware-Benchmarks zum Kompilieren von Code durch? [geschlossen]

21

Ich habe eine Reihe von Websites gesehen, die neue Hardware in Bezug auf die Spieleleistung, das Komprimieren einiger Dateien, das Kodieren eines Films oder was auch immer vergleichen. Gibt es welche, die die Auswirkung neuer Hardware (wie SSDs, neue CPUs, RAM-Geschwindigkeiten oder was auch immer) auf die Kompilierungs- und Verbindungsgeschwindigkeiten testen, entweder unter Linux oder unter Windows?

Es wäre wirklich gut, herauszufinden, was für die Kompiliergeschwindigkeit am wichtigsten ist, und sich darauf zu konzentrieren, anstatt nur von anderen Benchmarks zu extrapolieren.

benchmarking

— Colen
quelle

Ich denke das gehört auf SuperUser.

— Mahmoud Hossam

2

@ Mahmoud Hossam: Die Kompilierung ist ein gemischtes Thema. Sie ist eine reine Programmieraktivität, während Hardware-Benchmarks definitiv ein anderes Gebiet sind.

— Orbling

@Orbling Nun, er fragt nicht, ob er X oder Y kompilieren soll, er fragt, ob Leute das Kompilieren im Allgemeinen verwenden, um Benchmarks durchzuführen.

— Mahmoud Hossam

1

Ich habe einige kokizzu.blogspot.co.id/2015/02/…

— Kokizzu

1

Es gibt hier einen CPU-Benchmark basierend auf den Kompilierungszeiten des Linux-Kernels: openbenchmarking.org/showdown/pts/build-linux-kernel

— sjakobi

4

Ich habe das eine Weile gemacht - siehe hier und hier .

Zu dieser Zeit arbeitete ich an GTK + - und X11-Hacks für eine Linux-Handy-Distribution, und jedes Mal, wenn ich etwas auf einer so niedrigen Ebene berührte, löste dies eine Neuerstellung aller möglichen Dinge aus. Einer meiner Kollegen hat nie vollständige Builds erstellt, da das Unternehmen auf dem Computer, der mit den Standard-Kompilierungsoptionen geliefert wurde, fünf Stunden benötigte.

Ich hatte alle Arten von verrückter Hardware zu Hause, also habe ich Benchmarks auf einigen Rechnern durchgeführt, während ich auf anderen codiert habe, und Sie können die Ergebnisse unter den Links sehen.

Für das, was wir unter Ubuntu machten, schien der Flaschenhals die Festplatte zu sein, nachdem ich die CPU-Auslastung ausgeschöpft hatte - was mit dem Argument -j wirklich einfach zu bewerkstelligen ist.

Aber dann hatte die Firma große Entlassungen, also war ich zur Tür hinaus und habe das alles nicht zu Ende untersucht. Ich hatte eine Menge Daten und Interpretationen, die ich auch nicht in diesem Blog gepostet habe.

— Bob Murphy
quelle

Schade, es mit zwei detaillierten Beiträgen aufzubauen und sie stehen zu lassen. Haben Sie noch alle diese Daten? In jedem Fall wäre es sehr interessant, einige Blog-Posts / Antworten mit einigen Schlussfolgerungen zu dem, was Sie gefunden haben, zu sehen.

— Hugo

@Hugo: Nein, ich fürchte nicht - die Rohdaten sind schon lange weg. Aber im Grunde kam ich auf die Idee, dass für die Systeme (1-8 CPU-Kerne) und den Quellcode (den Linux-Kernel), die ich getestet habe, die schnellsten Build-Zeiten waren, als die Option -j das 1,5-fache der Anzahl der Kerne betrug. wobei -j = 2 für einen Kern am besten ist. Darunter waren die Systeme CPU-gebunden und darüber waren sie I / O-gebunden. Es ist eine interessante Frage - vielleicht sollte ich sie eines Tages wieder aufgreifen.

— Bob Murphy

0

Als erstes steht auf meiner Wunschliste ein Solid State Drive. Dies hat keinen großen Einfluss auf die Kompilierungszeit, aber das Öffnen von Anwendungen wird drastisch beschleunigt (IDE, PhotoShop, ETC). http://joelonsoftware.com/items/2009/03/27.html

Der größte Faktor für die Kompilierungszeit wird die CPU sein. Sie sind damit für den Benchmark http://www.cpubenchmark.net/ ziemlich sicher .

— Evan
quelle

1

Andererseits hängt vieles von Ihrer Build-Kette ab. Wenn Ihre Build-Kette nur einen einzigen Thread für die Kompilierung auf einer Multi-CPU, einem Multi-Core oder sogar einer Multi-Thread-CPU verwendet, verschwenden Sie die Chance auf massive Gewinne. Ein einfacher CPU-Benchmark zeigt das nicht, und ein Kompilierungs-Benchmark wäre nur für eine bestimmte Toolchain geeignet.

— Asoundmove

2

Tatsächlich habe ich experimentell festgestellt, dass, sobald Sie parallel kompilieren, Ihre Festplatte der Engpass ist. Mit einer langsameren CPU und einer schnelleren Festplatte sind Sie in der Regel besser dran als umgekehrt.

— Bob Murphy

0

Tom's Hardware war früher, aber es sieht so aus, als hätten sie 2008 damit aufgehört: http://www.tomshardware.com/charts/desktop-cpu-charts-q3-2008/benchmarks,31.html . Keines der neueren CPU-Diagramme enthält den Linux-Kernel-Kompiliertest.

— user92960
quelle