Compile From Sources - Απορίες, κόλπα, μυστικά και μύθοι...

[DaveMurray]

Παίρνω το θάρρος να ανοίξω το παρών νήμα, για να γίνει συζήτηση περί της δυνατότητας του να "χτίζουμε" BSD'S, Linux από τον δωρεάν, ελεύθερο πηγαίο κώδικα. Θα ήθελα να γίνει συζήτηση ουσιαστική και ειδική για τον compiler και τα σωστά flags που πρέπει να χρησιμοποιήσουμε, για να εκμεταλευτούμε και την τελευταία σταγόνα επίδοσης που μπορούμε να πάρουμε από το μηχάνημα μας είτε είναι παλιό, είτε νέο. Έχω επισκεφτεί πολλά φόρουμ για το συγκεκριμένο θέμα, πιο πολύ, προσωπικά για να μάθω πως θα κάνω ένα FreeBSD σύστημα να πετάει, χρησιμοποιώντας τα σωστά/καλύτερα flags στον compiler, να φτιάξω ένα σωστό /etc/make.conf και για μετέπειτα, αφού έχω διαλέξει να κάνω τα πάντα compile από τα φανταστικά για εμένα desktopbsd-tools, που διαθέτουν ένα πολύ όμορφο gui interface στα ports του FreeBSD. Δεν με κάλυψαν τα περισσότερα, γιατί ο καθένας δίνει και έναν διαφορετικό τρόπο, που πολλές φορές διαφέρει δραματικά με τον τρόπο που προτείνει κάποιος άλλος. Δηλαδή για να μην μακρυγορώ, τα ζητούμενα αυτού του νήματος είναι να μάθω/μάθουμε αν τελικά, διαμορφώντας τα πάντα από το μηδεν είτε είναι BSD, είτε Linux πρόκειται ουσιαστικά να κερδίσουμε κάτι (το κατα δύναμιν, ότι μπορούμε να πάρουμε...) η να καταλήξουμε πως τελικά ο μύθος του "build everything from sources" δεν ισχύει καθόλου, η μερικώς... Τέλος, θα ήθελα οι περισσότερο έμπειροι χρήστες, να μας δώσουν τα πολύτιμα φώτα τους και τις γνώσεις τους για τα σωστότερα και τα καλύτερα compiler flags που μπορούμε να χρησιμοποιήσουμε για διαφόρους τύπους επεξεργαστων (AMD,Intel,Via). Για αρχή, ας ζητήσω να μάθω ποια είναι τα flags που ενδέχεται να μου δώσουν κάτι παραπάνω (δεν με ενδιαφέρει αν το binary αποτέλεσμα θα έχει αυξημένο μέγεθος...) για τον AMD64 X2 Dual Core 3800+ Windsor Core (2ghz) (με τα virtualization extensions, το λέω αυτό γιατί κάποια "μοντέλα" με windsor δεν έχουν αυτό το χαρακτηριστικό)

[ludist]

[...]η να καταλήξουμε πως τελικά ο μύθος του "build everything from sources" δεν ισχύει καθόλου, η μερικώς...

Προσωπικά δεν είδα να ισχύει καθόλου έως τώρα. Το 5% σε διαφορά (αν θα την βρεις) εξανεμίζεται.

1. Με τον χρόνο που θα χάσεις
2. Με καλύτερο επεξεργαστή
3. Με καλύτερο (δεύτερο) σκληρό δίσκο (ανάλογα την περίπτωση βέβαια).
4. Λίγο overclock σε μνήμη / cpu αν το κατέχεις.

Αυτό που μάλλον ισχύει και έχει μεγαλύτερες διαφορές (αυτό μελετάω αυτόν τον καιρό) είναι ότι κάνοντας compile το πρόγραμμα - και τον kernel! - μπορείς να αφαιρέσεις δυνατότητες και να γλυτώσεις - κυρίως - μνήμη και αποκρισιμότητα. Βέβαια θα χάσεις σε λειτουργικότητα.

Τα powertop και latencytop είναι φίλοι σου

Επίσης εξαιρετικά και ΜΟΝΟ για τον τύπο του επεξεργαστή μου βοήθησε το compile του lame.

Και για να σε ξε-μπερδέψω περισσότερο. Μπορεί τα προγράμματα να γίνονται compile για 486 (ζωντανό παράδειγμα το Slackware) αλλά με ένα option είναι ήδη optimize για οποιοδήποτε επεξεργαστή. Παράδειγμα, δες το output του xvid που είναι compiled για 486.

 xvid build:xvid-1.1.3
        xvid thread:0
        xvid SIMD supported:(c7)
                MMX
                MMXEXT
                SSE

Προφανώς σ' αυτή την περίπτωση το binary είναι μεγαλύτερο με την αργή φόρτωση (έτσι ίσως έχεις εντύπωση "υστέρησης" (latency), αλλά στην πραγματικότητα η ταχύτητα είναι ίδια στα ανθρώπινα αισθητήρια όργανα

Στην πράξη, αυτό που κερδίζεις όταν κάνεις compile μία διανομή (ή το *BSD) είναι πως είναι γυμνά και δεν σε καθυστερεί τίποτα Στο χτίσιμο δεν βάζεις ότι να 'ναι (δυνατότητες που δεν θες), οπότε είναι ταχύτερα.

Αναφέρομαι σε DESKTOP εφαρμογές!

Για κουτσομπολιό, όταν δοκίμασα το lame σε Slackware και BSD (έγινε compile από εμένα και στις δύο περιπτώσεις με τα ίδια options) δεν υπήρξε καμία απολύτως διαφορά στην απόδοση. (telinit 1)

Αν θες καν' το, δεν αποκλείεται να βγάλεις λαυράκι (άλλωστε έτσι ανακάλυψα το bug στον κώδικα του lame [ή στον επεξεργαστή μου ή στον... compiler ή ... και στα τρία ] )

[mrsaccess]

Τα CFLAGS (και η λοιπή παρέα) είναι αρκετά περίπλοκη υπόθεση και μπορούν πιο εύκολα να σου πάρουν απόδοση αντί να σου δώσουν.

Ακόμη και το -Ο3 που υποτίθεται ενεργοποιεί τα περισσότερα optimizations είναι πιθανό να δώσει κώδικα πιο αργό από το -O2 ενώ σε ένα σύστημα με λίγη μνήμη θα τρέχει καλύτερα κώδικας που έγινε με -Os (optimize for size).

Τα καλύτερα CFLAGS λοιπόν είναι τα ασφαλή CFLAGS. Άλλωστε αν υπάρχει κάποιο CFLAG που επηρεάζει την ταχύτητα του εκτελέσιμου και δεν δημιουργεί προβλήματα θα έχουν φροντίσει οι δημιουργοί της εφαρμογής να το ενεργοποιούν κατά το make.

Για τον επεξεργαστή σου τα ασφαλή CFLAGS είναι:
CFLAGS="-O2 -march=athlon64 -pipe -msse3"

Από εκεί και πέρα αν έχεις όρεξη για πειραματισμούς ή ένα πρόγραμμα σε ενδιαφέρει ιδιαίτερα θα πρέπει να το κάνεις compile με *πολλούς* συνδυασμούς CFLAGS και κατόπιν να τεστάρεις κάθε εκτελέσιμο που προκύπτει ώστε να δεις αν είναι ταχύτερο από τα υπόλοιπα και δεν έχει προβλήματα.
Δυστυχώς αυτό θα πρέπει να το κάνεις για κάθε εφαρμογή, δεν είναι κάτι που μπορεί να γίνει για όλες ταυτόχρονα.

Τέλος υπάρχει το acovea που κάνει αυτό που περιγράφω αυτόματα. Μάλιστα μόλις είδα ότι έχει βγάλει κανονική έκδοση πια!
http://www.coyotegulch.com/products/acovea/

[ludist]

Τέλος υπάρχει το acovea που κάνει αυτό που περιγράφω αυτόματα.

Το ιδανικό δηλαδή θα ήταν να ξέραμε για κάθε πρόγραμμα τα "γρήγορα" switch του, ή ο δημιουργός του να τα μας έδινε έτοιμα.

Πού τέτοια τύχη

Καλό το acovea.

[WAntilles]

Όταν μετέβην από source Gentoo σε binary Arch (το ενδιάμεσο στάδιο του Debian Unstable το αγνοώ γιατί εκεί ήμουν "λευκός ποντικός πειραμάτων") και είδα τις διαφορές, κατέληξα στα εξής συμπεράσματα:

- ο μύθος του "υπέρ πάντων ταχύτερου" καταρρίφθηκε πλήρως

Ναι, το Gentoo είναι γρήγορο. Αλλά όχι πιο γρήγορο από μία σοβαρή binary διανομή, έξυπνα δομημένη ήδη από τη μάνα της. Στις πιο πολλές περιπτώσεις δε θα είναι και πιο αργό.

Τί εννοώ;

Αποδεικνύεται τελικά ότι 2-3 switches στον gcc παίζουν πολύ μικρότερο ρόλο από τα παρακάτω:

- σωστό, ελαφρύ, με μέτρο, modular, kernel configuration
- χτίσιμο των πακέτων με μέτρο, δηλαδή με τα απαραίτητα στο configure

Στο Arch αυτήν την πολιτική την εφαρμόζουν καθολικά.

Χαρακτηριστικά να αναφέρω επακριβώς τα λόγια κάποιου γνωστού - ο οποίος γνωρίζει πάρα πολλά από software & coding optimization - και ο οποίος έχει τρέξει πολλά commercial και μή "βαριά" UNIces, πολλές διανομές Linux, έτρεχε μόνιμα Gentoo, και ύστερα από δική μου προτροπή δοκίμασε Arch:

"Είναι ταχύτατο. Τί του έχουν κάνει και πάει έτσι;"

Όταν ύστερα από 1-2 μέρες, κοίταξε καμμιά 30αριά PKGBUILDs για να δει πώς χτίζουν γενικά οι άνθρωποί της τη διανομή, μου έγραψε:

"Έχουν πετάξει από όλα τα configures ο,τιδήποτε το περιττό. Να γιατί πάει έτσι."

Και στο τέλος γράφει:

"Αφήνω το Gentoo. Αλλάζω διανομή".

Εξιστόρησα αυτά τα γεγονότα για να δείξω ότι τα δικά μου συμπεράσματα συμφωνούν με τα συμπεράσματα κάποιου κατά πολύ εμπειρότερου.

Τελικό συμπέρασμα:

Όταν κάνεις compile από source, για να φτάσεις έστω (πόσο μάλλον να ξεπεράσεις) τις επιδόσεις μιας πολύ σοβαρής binary διανομής, πρέπει να έχεις πολυετή εμπειρία σε development με C/C++, gcc, make, configure κλπ.. Όπως και πολυετή εμπειρία με τα ενδότερα του Linux kernel.

[nikospara]

Μετά από κάποιον, περιορισμένο αριθμό πειραμάτων το 2004-2005 αποτέλεσμα το ίδιο. Είχα κάνει compile ολόκληρη τη διανομή (ROCK, τώρα T2) για τον επεξεργαστή μου. Επιπλέον έκανα λιγότερα πειράματα βελτιστοποίησης με το bzip2. Ανακάλυψα ότι ο χρόνος συμπίεσης αρχείων από το "έτοιμο" bzip2 σε "έτοιμο" πυρήνα δε διέφερε από αυτόν με πυρήνα, bzip2 χτισμένα για το σύστημά μου. Ίσως με γρηγορότερο δίσκο να έβλεπα τη διαφορά... Χωρίς να είναι και κανένα επιστημονικό αποτέλεσμα, ενισχύει το πλαίσιο των υπόλοιπων απαντήσεων.

Θα σταθώ και λίγο στο τεστάρισμα που, οπως λέει και ο mrsaccess, είναι ο μόνος τρόπος να βεβαιωθείς ότι ένα "στήσιμο" είναι πιο γρήγορο από το άλλο. Επιπλέον το συμπέρασμα πιθανότατα θα ισχύει για το συγκεκριμένο μηχάνημα των δοκιμών με τα συγκεκριμένα τεχνικά χαρακτηριστικά και φόρτο εργασίας κατά τον έλεγχο. Αλλά το σημαντικότερο είναι ότι, καθώς η βελτιστοποίηση έχει νόημα για τα πιο περίπλοκα προγράμματα και δε γίνεται χειροκίνητα, θα πρέπει να φτιάξεις για κάθε πρόγραμμα που βελτιστοποιείς σουίτα ελέγχου επιδόσεων. Φαντάσου πόσο δύσκολο θα είναι αυτό σε προγράμματα όπως ένας browser ή ένα office.

Πάντως ακόμα με γοητεύει η θεωρία του θέματος!

[mrsaccess]

Νομίζω σε προγράμματα καθημερινής χρήσης (file manager, word processor) δεν τίθεται θέμα βελτιστοποίησης. Δεν πρόκειται να δει διαφορά ο χρήστης. Αν μιλήσουμε ειδικά για το openoffice που τα έχει τα κιλάκια του η λύση πρέπει να έρθει προγραμματιστικά και όχι από τον compiler.

Ακόμη και αν μιλήσουμε για browsers (έχοντας πρόσφατο το παράδειγμα του Chrome) η βελτιστοποίηση πάλι θα πρέπει να είναι στο κώδικα και όχι στο compiler. Ο compiler δεν μπορεί να αντισταθμίσει τα «λάθη» του κώδικα.

Η μέθοδος του WAntilles δεν δημιουργεί πιο γρήγορα εκτελέσιμα. Δημιουργεί μικρότερα εκτελέσιμα και με λιγότερες εξαρτήσεις από βιβλιοθήκες. Αυτό σημαίνει ότι εκκινούν πολύ πιο γρήγορα αφού κάνουν έλεγχο για λιγότερες βιβλιοθήκες αλλά στο runtime είναι ακριβώς όμοια με τα υπόλοιπα.

Με εξαίρεση το Gentoo που αυτό ρυθμίζεται από τον ίδιο το χρήστη είμαι κατά της απενεργοποίησης δυνατοτήτων σε πακέτα binary διανομών γιατί ακόμη και 1000 χρήστες στο 1.000.000 αν χρειάζονται μια δυνατότητα και δεν τη βρουν είναι κρίμα.

Συνεχίζοντας με τους compilers, ένα custom made εκτελέσιμο μπορεί να είναι ελαφρά ταχύτερο επειδή έχει βελτιστοποιηθεί για τον επεξεργαστή που θα τρέχει. Δεν είναι όλοι οι επεξεργαστές ίδιοι και ο καθένας χρειάζεται λίγο διαφορετική assembly για να αποδώσει τα μέγιστα.

Επίσης αν πρόκειται για επιδόσεις μπορεί κάποιος να θέλει να δοκιμάσει και επιπλέον compilers. Για παράδειγμα ο compiler της Intel, ICC, δωρεάν για Linux και open source, non commercial λογισμικό μπορεί κατά περιπτώσεις να δώσει καλύτερο κώδικα από τον GCC.

Φυσικά όλα αυτά αξίζει να τα δοκιμάσουμε μόνο όπου υπάρχει πραγματική ανάγκη για μεγαλύτερη ταχύτητα.

[agis29]

Θεωρητικά με -0s λόγω μικρότερου κώδικα-αποτύπωμα στη μνήμη κτλ προγράμματα όπως ο firefox και ειδικά η έκδοση 2 ευνοούνται σε ταχύτητα.
Όντως μια μικροδιαφορά στον παλιότερο firefox είχα δει σε θέμα εκκίνησης.
Αν όμως εφαρμοστεί το 0s σε ολόκληρο το σύστημα θα γίνει πιο αργό.
Όπως και να έχει binary διανομές όπως το slackware με 486 optimasation είναι ταχύτατες
και κατα πολύ γρηγορότερες απο άλλες binary me i686 βελτιστοποίηση.
Ασχέτως με τα στραβά του Slackware αμφιβάλλω αν το Arch ή το Gentoo είναι σημαντικά ταχύτερο.
Αν υπάρχουν διαφορές είναι απειροελάχιστες.
Τέλος συμφωνώ με τον mraccess σχετικά με τον compiler της Intel.
Παράγει ταχύτερο κώδικα απο τον gcc.

[DaveMurray]

Από εκεί και πέρα αν έχεις όρεξη για πειραματισμούς

αυτό θέλω να κάνω, φτιάχνωντας και BSD και linux απο το μηδεν. Γενικα, δεν πρόλαβα να διαβάσω όλα τα posts, τώρα αυτό κάνω. Έχω ακουστά για τα "safe cflags" ποθ προτείνειν και το gentoo στο wiki του, αλλά δεν μου γιομίζουν το μάτι πως κάτι μπορώ να πάρω, χρησιμοποιώντας μόνο με αυτά. Βέβαια αυτό είναι μόνο εικασία μου, αφού θα ξεκινήσω τον δύσκολο δρόμο του στησιμάτος απο το μηδεν και linux και BSD. (με γλιτώνει που έχουμε στο σπίτι πολλά pc's με μόνο το ένα να είναι οικογενειακό. χεχε)

[mrsaccess]

Ricer!

[DaveMurray]

ICC

χμ, χμ, και αυτόν τον έχω ακουστά, αλλά όσο και να έχω δει, πχ για να κάνεις compile BSD η Linux kernels με τον προαναφερόμενο, είναι κάπως δύσκολο, εως ακατόρθωτο (φυσικά από ότι έχω διαβάσει μέχρι τώρα). Επίσης περίεργο θα είναι να έχεις AMD και να χρησιμοποιείς compiler της "εξω από εδώ" (χιουμόρ απλώς) κακιάς Intel. Δεν τον έχω χρησιμοποιήσει ποτέ μου, και δεν ξέρω αν μπορεί να χτιστεί με gcc ώστε να μπορέσω να δώ και τι κάνει και αυτός..

[mrsaccess]

Ο ICC έρχεται ως binary. Τον kernel δεν μπορείς να τον χτίσεις με αυτόν και δεν έχει και ιδιαίτερο νόημα.
Μόνο σε multimedia εφαρμογές, μαθηματικές βιβλιοθήκες κτλ αξίζει να τον δοκιμάσεις.

Ο κώδικας που παράγει είναι καλός, έχει πλεονέκτημα σε Intel επεξεργαστές αλλά ακόμη και σε AMD παρέχει απόδοση. Δεν είναι τυχαίο άλλωστε που η MySQL δίνει και ICC binaries.
Φυσικά μια εφαρμογή που θα χτιστεί με τον ICC μπορεί να τρέχει και πιο αργά από τον αν χτιστεί με GCC. Μόνο με δοκιμές ανά εφαρμογή μπορείς να είσαι σίγουρος για το πιο γρήγορο.

[DaveMurray]

what about -Οs για τον FreeBSD kernel? Δηλαδή: -Os -march=athlon64 -mtune=athlon64 -pipe -msse3 ;

........Auto merged post: DaveMurray πρόσθεσε 2 λεπτά και 19 δευτερόλεπτα αργότερα ........

Πάντως το Acovea από ότι πήρεε το μάτι μου τώρα που διάβασα στα κλεφτά, φαίνεται αρκετά ελπιδοφόρο...

[mrsaccess]

Δεν γνωρίζω για τον FreeBSD kernel αλλά ο Linux kernel δεν δέχεται CFLAGS. Τα απορρίπτει και χρησιμοποιεί τα δικά του. Είναι άκρως επικίνδυνο να παίζεις με τον kernel και δεν θα κερδίσεις σε ταχύτητα εφαρμογών.

[DaveMurray]

Πάντως..., να δώσω και μια εκτίμηση.... Για να βλέπεις αυξοσημειώτες ΔΙΑΦΟΡΕΣ, ανάμεσα σε πολλές binary διανομές Linux, και στα BSD's, όσον αφορά την απόδοση, ε δεν μπορεί, με το φτωχό μου το μυαλό σκέφτομαι πως κάτι τρέχει... Δεν είναι μόνο πχ η αφαίρεση αχρείαστων στοιχείων από τα PKGBUILDS, SlackBuilds, και τα λοιπά που λέει και ο Wan μας, αλλά σίγουρα είναι και η διαφορετική χρήση flags... Δεν μπορώ να το εξηγήσω αλλιώς... Εσείς τι λέτε επ'αυτού;