apt-get source Vorteile?

[ESAD]

Denkt ihr man könnte Performancevorteile bekommen wenn man bei Debian die Paketsourcen lädt und diese dann kompiliert (Prozessorspezifisch optimierungen)? Gibts da eigentlich Benches wie groß die Vorteile wären?

[lumines]

Äh, kann man denn damit überhaupt Compilerflags setzen? :confused:

[Gast]

Es wurde mal mit einem Gentoo probiert, voll optimiertes Gentoo gegen Standard Debian. Getestet wurden alle Möglichen Applikationen, von Webbrowser über Textverarbeitung bis Mutimedia. Ergebnis: Kaum messbar bis wenige Prozent Geschwindigkeits- bzw. Größen (bei -Os) vorteil. Bringt also nicht wirklich was.

[Gast]

Hier habs gefunden:
http://www.linux-mag.com/id/7574/
War sogar ein einigermaßen aktuelles Ubuntu, dürften also i586-Binaries sein. Der Vorteil von Source-Distris ist also eindeutig der Paketmanager (zumindest wenn er so genial ist wie bei Gentoo) wegen der Geschwindigkeit zahlt sich das ganze aber schon überhaupt nicht aus...

[Gast]

Warum eigentlich?

SSE3 und SSE4 wird ja bei so ner Standard 64 Bit Version kaum verwendet.

[fezie]

Äh, kann man denn damit überhaupt Compilerflags setzen? :confused:

Wenn man debian/rules editiert und zum Beispiel dem ./configure Script dann CFLAGS="-O2 -march=native" übergibt schon.

[ESAD]

man kann auch apt-build verwendet dann geht das bequem in einer configdatei.

was für ein programm würde sich denn für einen schnellen test eigenen. ich würde ja grad an 7zip denken?

und was für flags würdet ihr denn empfehlen für einen core2duo mit wenig augenmerk auf speicherverbraucht? O3 und march=core2 ? sonst noch was?

[hasufell]

man kann auch apt-build verwendet dann geht das bequem in einer configdatei.

was für ein programm würde sich denn für einen schnellen test eigenen. ich würde ja grad an 7zip denken?

und was für flags würdet ihr denn empfehlen für einen core2duo mit wenig augenmerk auf speicherverbraucht? O3 und march=core2 ? sonst noch was?
mit der einstellung kompilierst du dir jede source-distri tot

lieber mal richtig mit den flags auseinandersetzen. und die auswirkungen auf einzelne Pakete sind auch unterschiedlich

guter start is imo das gentoo-wiki/foren

[ESAD]

ach selbst wenn würd ich keine ganze distri kombillieren sondern nur auasgewählte programme. ich habs jetzt aber mal mit 7zip getestet und es bringt nicht wirklich was. die einstellungen hab ich übrigends auf die schnelle aus ner gentoo wiki geklaubt.

[Gast]

ach selbst wenn würd ich keine ganze distri kombillieren sondern nur auasgewählte programme. ich habs jetzt aber mal mit 7zip getestet und es bringt nicht wirklich was. die einstellungen hab ich übrigends auf die schnelle aus ner gentoo wiki geklaubt.
Naja wenn du nur ein Programm mit speziellen Flags kompilierst galub ich gern dass das nix bringt, die ganze libs usw. die verwendet werden sind ja nach wie vor die Standard Binärpakete... (Wobei bei einem Packer der Einfluss von externen libs auf die Performance wahrscheinlich ziemlich gering ist.)
Trotzdem, eigentlich müsstest du auch sämtliche Abhängigkeiten von 7zip selber kompilieren.

[ESAD]

natürlich einen schönheitsfehler hat das ganze aber die abhängigkeiten von p7zip sind ja jetzt nicht so gigantisch und wie du auch gesagt hat sollte sich die auswirkung beim internen benchmark in grenzen halten.

[Gast]

Am meisten dürfte wohl bringen, wenn man zum Compilieren eine andere Version des GCC Compilers verwendet.

Aber ich weiß jetzt nicht, wie gut dann das Binary mit den Bibliotheken harmoniert, die ja noch überwiegend mit dem alten Compiler der Distribution compiliert wurden.


Meine Frage zu SSE4 wurden übrigens noch nicht beantwortet.

[Gast]

Am meisten dürfte wohl bringen, wenn man zum Compilieren eine andere Version des GCC Compilers verwendet.

Aber ich weiß jetzt nicht, wie gut dann das Binary mit den Bibliotheken harmoniert, die ja noch überwiegend mit dem alten Compiler der Distribution compiliert wurden.

Ich weiß nicht ob das so einen großen Unterschied macht. Verwendet nicht Ubuntu inzwischen eh schon den gcc-4.4? Debian weiß ich allerdings nicht, aber ich hoffe doch die nehmen inzwischen auch schon den 4er...

Meine Frage zu SSE4 wurden übrigens noch nicht beantwortet.
Sorry, ich hab die Frage nicht verstanden.

Warum eigentlich?
SSE3 und SSE4 wird ja bei so ner Standard 64 Bit Version kaum verwendet.

Warum eigentlich was?
Warum selber kompilieren (bezogen auf den Anfangspost) oder warum es nicht schneller wird (bezogen auf Post #4) oder ganz was anderes?

[ESAD]

Meine Frage zu SSE4 wurden übrigens noch nicht beantwortet.

bei den meisten apps bietet hals z.B. sse4 hald kaum vorteile. bei denen die davon profitieren wie z.b. multimedia software brings ja wie man sieht was.

[Gast]

Warum eigentlich was?
Warum selber kompilieren (bezogen auf den Anfangspost) oder warum es nicht schneller wird (bezogen auf Post #4) oder ganz was anderes?

So besser?


Warum eigentlich, SSE3 und SSE4 wird ja bei so ner Standard 64 Bit Version kaum verwendet?

[maximAL]

man kann auch apt-build verwendet dann geht das bequem in einer configdatei.
Funktioniert apt-build überhaupt noch? Ich hab das neulich auf Linux Mint ausprobiert, und die Werte der /etc/apt/apt-build.conf werden scheinbar ignoriert. Zudem kann man dort nur noch -mtune setzen, aber nicht mehr -march.

[Exxtreme]

Warum eigentlich, SSE3 und SSE4 wird ja bei so ner Standard 64 Bit Version kaum verwendet?
Wenn es Vorteile bringen würde dann würde man es verwenden. Vorteile hat man mit diesen Erweiterungen hauptsächlich bei Streaming-/Multimedia-Anwendungen. Nur wenn diese auch ohne diese Erweiterungen wirklich schnell genug laufen dann bringt das Kompilieren jetzt auch nix.

[Gast]

Wenn es Vorteile bringen würde dann würde man es verwenden.Nö. Du vergisst den unseligen Bedarf für Abwärtskompatibilität. Solange die Binarys auf jedem AMD64-System in jeder Situation laufen sollen, kann man nicht SSSE3 oder SSE4 voraussetzen. Die alten Athlon 64 hatten ja nichtmal SSE3.

Bei MeeGo ist Intel diesen Schritt aber für die x86-Variante gegangen. Da die Zielplattform sich eigentlich auf Atoms beschränkt, hat man hier SSSE3 vorausgesetzt. Bringt wohl Vorteile im mittleren einstelligen Prozentbereich, zumindest auf einem neueren Atom. Für die ARM-Builds ist man auch dazu übergegangen für armv7l zu kompilieren.

[mii]

Mich beschäftigt die Frage auch ein wenig, ob es mehr performance bringt, wenn man selbst kompiliert.

Der Vorteil den man imho beim selbst kompilieren hat, wäre jener, das man die Softwarekomponenten nur mit den Features kompiliert, die man wirklich braucht.
Somit hat die Software im eneffekt weniger RAM-Verbrauch.

Allerdings ist die Frage ob sich der Aufwand bei der heutigen hardware noch wirklich lohnt. Wirtschaftlich gesehen ist hardware sicherlich immer noch günstiger, als zeit(=geld) in die optimierung eines linux-systems für ältere hardware zu stecken.

Im privaten bereich siehts natürlich anders aus. :)

[Binary Outlaw]

Nachteil Source Pakete man bekommt sie schwieriger wieder los.

[Shink]

Der Vorteil den man imho beim selbst kompilieren hat, wäre jener, das man die Softwarekomponenten nur mit den Features kompiliert, die man wirklich braucht.
Somit hat die Software im eneffekt weniger RAM-Verbrauch.
Dieser Vorteil existiert tatsächlich: Man kann nicht benötigte Module weglassen und bekommt kleinere Binaries und - wenn statisch gebunden wird - auch weniger Speicherbedarf.

Ist nunmal etwas unsinnig deshalb Source statt Binaries runterzuladen und dann auch noch zu compilen, außer man rollt das dann auf viele, viele Systeme aus.

Also ist eine "Atom-Distro" schon sinnvoll, immerhin haben im Netbook-Zeitalter wahrscheinlich erstmals in der PC-Geschichte:freak: sehr viele Systeme eine fast identische Kombination aus CPU, Grafik und Chipsatz.

Aber auch eine AMD64-Distro bringt schon Vorteile: Die 32 Bit Distros laufen AFAIK alle auf dem Geode LX wegen OLPC, Thin Clients etc.
Und die unterstützen nicht einmal SSE 1.