Τι κάνει το Clear Linux να είναι τόσο γρήγορο.

To Clear Linux είναι γρήγορο, πολύ γρήγορο

Και όταν λέμε γρήγορο το εννοούμε ή εικόνα είναι από εδώ:

Σε σχέση με τα Windows 11 [πηγή]

Δεν έχει σε όλα τα τεστ τόσο εξωφρενική διαφορά, αλλά έχει σε πολλά.

Το ερώτημα είναι τι το κάνει τόσο γρήγορο;

Γιατί είναι τόσο γρήγορο

Σύμφωνα με το ίδιο γιατί ακολουθεί μια ολιστική προσέγγισή στην απόδοση σε επίπεδο υλικού και λογισμικού. Ανταλλάζει (πολύ) μεγαλύτερους χρόνους στο compiling αλλά και στο μέγεθος του εκτελέσιμου για την απόδοση σε χρόνο εκτέλεσης. Η βελτιστοποίηση γίνετε για χρήση σε περιβάλλοντα server και cloud.

Μερικές τεχνικές που εφαρμόζει είναι οι εξής:

1. Βελτιώσεις στο compiling

Θα τρέξει μόνο σε επεξεργαστές της Intel μετά το έτος 2010 (αλλά έτρεξε μια χαρά και στον AMD που έχω). Θα θέσει march=westmere και mtune=haswell ένω θα κάνει compile με Ο3.

Το LTO Link-time optimization θα εφαρμοστεί στο τέλος της μεταγλώττισης. Αυτό κάνει μια επίμονα αργή ανάλυση του τελικού κώδικα για να τον κάνει καλύτερο. Το PGO Profile guided optimization θα βελτιστοποιήσει τον κώδικά χρησιμοποιόντας πληροφορία που συγκεντρώνει ο κώδικας κατα την εκτέλεση. Αυτό θα βελτιστοποιήσει τις συνηθέστερες διαδρομές εκτέλεσης.

2. Βελτιστοποιήσεις στον πυρήνα

Διαφορετικούς πυρήνες ανάλογα με το αν τρέχει bare metal η σε συγκεκριμένους τύπους VM. Ένα ειδικό εργαλείο θα βελτιστοποιήσει τις παραμέτρους του πυρήνα κατά την εκτέλεση. Χρήση peroformance governor που αξιοποιεί καλύτερα τα P-States του επεξεργαστή

3. Βιβλιοθήκες

Κάθε βιβλιοθήκη έχει χρηστεί πολλές φορές για διαφορετικές αρχιτεκτονικές. Η βιβλιοθήκη που θα χρησιμοποιηθεί θα επιλεχθεί δυναμικά για να ταιριάζει στο μοντέλο του επεξεργαστή. Υπάρχουν τρόποι να το κάνεις αυτό με τη βοήθεια του gcc, τόσο σε επίπεδο μεμονωμένης συνάρτησης, όπου γράφεις τον κώδικά πολλές φορές βελτιστοποιημένο σε επίπεδο αρχιτεκτονικής. Επίσης, μπορεί να γίνει σε επίπεδο Linker για ολόκληρη τη βιβλιοθήκη. Αν ενδιαφέρει μπορεί να το δούμε αυτό αναλυτικά κάποια στιγμή σε ένα άρθρο. Για μένα αυτό αλλάζει το παιγνίδι απέναντι σε source based διανομές.

Όπως βλέπετε είναι πολύ δουλειά, αλλά το αποτέλεσμα αξίζει.

Γιατί αυτές οι βελτιστοποιήσεις δεν εφαρμόζονται σε άλλες διανομές ;

Σε ένα πείραμα στο Phoronix προσπάθησαν να εφαρμόσουν κάποια τα παραπάνω σε ένα Ubuntu

Τα αποτελέσματα ήταν ανάμεικτα αλλά πάντα οι βελτιστοποιήσεις βελτίωναν σημαντικά την απόδοση ενώ σε κάποιες περιπτώσεις το ξεπερνούσαν

Σε μια σημερινή ανάρτηση στο twitter γιατί το PopOS δε χρησιμοποιεί τις τεχνικές που χρησιμοποιεί το ClearLinux η απάντηση ήταν μονολεκτική: συμβατότητα.

Είναι όμως έτσι; Πράγματι, το ClearLinux απαιτεί αρκετά από τον επεξεργαστή, αλλά δεν έχω και τον τελευταίο, δεν έχω καν Intel και παίζει σε μένα μια Χαρά. Αλλά υπάρχει ένας επίσημος τρόπος να ελέγξουμε τον επεξεργαστή μας [πηγή]

curl -O https://cdn.download.clearlinux.org/current/clear-linux-check-config.sh
chmod +x clear-linux-check-config.sh
./clear-linux-check-config.sh host
./clear-linux-check-config.sh container

Στον υπολογιστή μου

Είμαι περίεργος να μάθω αν τρέχει σε εσάς και αν όχι τι μοντέλο επεξεργαστή έχετε.

Σαν επίλογος

Η καινοτομία είναι εκεί έξω. Δε θα τη βρούμε σε διανομές που δε γουστάρουν systemd, wayland, ακόμα και το pam !!! κλπ. Θα τη βρούμε σε διανομές που προσπαθούν να επαναορίσουν τι σημαίνει μια μοντέρνα διανομή. Επίσης δεν βλέπω σήμερα κανένα νόημα σε source based διανομές δεν έχουν να προσφέρουν τίποτα, έκτος από αυξημένο λογαριασμό στη ΔΕΗ. Εσάς ποια είναι η γνώμη σας;

Δείτε ακόμα

3 «Μου αρέσει»

Εγω το βλεπω αλλιως. Μια διανομη οταν αναπτυχθει απο την εταιρεια του επεξεργαστη, τοτε πολυ πιθανο να ειναι οτι καλυτερο υπαρχει σε ταχυτητα. Γιατι τρεχει σε amd? Νομιζω θα ετρεχε σε καθε x86 επεξεργαστη. Αν και οι x86 εχουν αλλαξει απο τις πρωτες γενιες. Γιατι απο το 2010? Γιατι αν θυμαμαι καλα καπου το 2008 παρατησε η intel κατι ψοφαλογα που εβγαζε. Να μη βαλει και 2 χρονια να ειναι κατι απουλητο ,οπως πχ ενα επωνυμο pc με ψοφαλογο?

Ολα μαρκετινγκ ειναι… ενταξει τρεχει πιο αποδοτικα σε intel με intel καρτα δικτυου με intel ssd και και και…

Εγω πιστευω και στον ρωσικο επεξεργαστη elbrus να το εγκαταστησεις θα τρεξει μια χαρα εφοσον και αυτος ο επεξεργαστης υποστηριζει χ86 εντολες

Όχι, δεν είναι καθόλου προφανές αυτό. Ας δούμε το παράδειγμα της βιβλιοθήκης IPP, μιας βιβλιοθήκης με χιλιάδες βελτιστοποιημένες ρουτίνες για Image, Video, DSP, rendering, speech recogninion, computer vision, cryptography

Επίσης, η βιβλιοθήκη MKL για μαθηματικά, γραμμική άλγεβρα, στατιστική νευρωνικά δίκτυα. Οι βιβλιοθήκες αυτές δεν τρέχουν καλά σε επεξεργαστές AMD. O λόγος είναι στον αλγόριθμο που ελέγχει τις δυνατότητες του επεξεργαστή. Χρησιμοποιεί το αναγνωριστικό του επεξεργαστή και όχι τις δυνατότητες που ο ίδιος λέει ότι έχει. Για όσους έχουν γράψει WEB είναι σαν να τσεκάρεις μόνο το UA.

Οι βιβλιοθήκες αυτές είναι κλειστό λογισμικό, αλλά είναι διαθέσιμες από την Intel χωρίς αντίτιμο. Υπάρχουν κάποια αμφίβολης νομιμότητας patch εκεί έξω που αλλάζουν λίγες εντολές και μαγικά η ταχύτητα σε AMD απογειώνετε.

Μια άλλη παρανόηση είναι πως το Clear Linux χρησιμοποιεί τον (πανάκριβο) icc τον compiler της Intel που έχει τη φήμη πως βγάζει τα γρηγορότερα εκτελέσιμα. Η απάντηση είναι πως όχι. Χρησιμοποιεί τον gcc.

Οπότε ναι είναι κάτι άξιο αναφοράς. Η Intel θα μπορούσε να χρησιμοποιήσει τον δικό της compiler και τος δικές της βιβλιοθήκες (πολλά ελεύθερα λογισμικά μπορούν να κάνουν χρήση των ICC/MKL) και με λίγα πολύ γνωστά κόλπα να εμποδίζει να τρέξει σε άλλους κατασκευαστές ή να έχει απόδοση για τα τάρταρα. Γιατί το θέμα δεν είναι αν τρέχει το θέμα είναι αν όταν τρέχει κάνει χρήση των SSE2, SSE3, SSE4.2, AVX, AVX2, AVX-512 κλπ

ΥΓ: Κάθε φορά που κοιτάζω θα βρω τα παραπάνω σε άλλο πακέτο με άλλο όνομα. Σήμερα που κοίταξα και μου επιτρέπει να τα κατεβάσω χωρίς κατ να δώσω email, αλλά βρήκα και τεκμηρίωση για τον dispatcher και μοιάζει να υπάρχει και ο πηγαίος κώδικας διαθέσιμος. Θα πρέπει να το ψάξω λίγο περισσότερο αλλά η κατάσταση έχει αλλάξει πρως το θετικό

Έχουν νόημα σε όποιον θέλει να φτιάξει ένα ειδικευμένο σύστημα. Για παράδειγμα η Google χρησιμοποιεί Gentoo για να φτιάξει το chromeOS, το οποίο ενδιαφέρον πως δεν χρησιμοποιεί ούτε systemd (upstart), ούτε wayland (δικό του graphics stack που χρησιμοποιεί KMS/DRM), και pam μόνο όταν ενεργοποιηθεί το dev mode (που βασικά το μετατρέπει σε κανονικό σύστημα αντί να είναι ένας baremetal web browser).

1 «Μου αρέσει»

Το οποίο όμως το κατεβάζεις έτοιμο και χτισμένο στον υπολογιστή σου. To που θα γίνει η μεταγλώττιση καθορίζει αν είναι μια διανομή source based η όχι. Αλλιώς δε βγάζει νόημα. Ποια η διαφορά τότε από πχ το Ubuntu;

Το τι χρησιμοποιεί σαν βάση είναι αδιάφορο. Και είναι σκάλες οικονομικότερο και αποδοτικότερο να χτίσεις μια φορά τα πακέτα eproducible και να κάνεις όλα τα παραπάνω κόλπα, LTO, PGO, multi arch και ας κάνει το compile τριπλάσιο χρόνο παρά να το κάνεις σε κάθε υπολογιστή χωριστά και να κλαις όταν σου έρθει ο λογαριασμός. Το τι δυνατότητες σου δίνει μια διανομή για να τη φέρεις στα μέτρα σου είναι ένα ανεξάρτητο ορθογωνικό ζήτημα.

Υπήρχε μια εποχή που είχε νόημα το Gentoo. Να προσαρμόσεις το εκτελέσιμο στον υπολογιστή σου είχε νόημα. Αλλά σήμερα οι compilers είναι διαβολικά έξυπνοι. Loop Upnrolling; θα το κάνουν μόνοι τους. Και αν έχεις ένα καλο CPU distatcher που σήμερα έχουμε θα διαλέξει την καλύτερη διαδρομή, εφόσον βέβαια το εκτελέσιμο έχει πολλές διαδρομές. Όταν είχε βγεί το Gentoo τα εργαλεία μας δεν μπορούσαν να υποστηρίξουν αυτά τα σενάρια. Σήμερα δυστυχώς δεν τους κάνουμε όση χρήση θα μπορούσαμε :slight_smile:

Μερικά παραδείγματα για να καταλάβουμε την εξέλιξη των μεταγλωττιστών. Όταν βγήκε ο compiler explorer και έγινε βασικό εργαλείο για πολλούς θυμάμαι είχαν πέσει κάτω πολλά σαγόνια…

Δείτε επίσης ένα ποιο εντυπωσιακό παράδειγμα.

Η γλώσσα C είχε μια φορά τη λέξη κλειδί register. Με αυτή έλεγες στον compiler ότι μια μεταβλητή είναι σημαντική. Σήμερα αυτό είναι από τα απλούστερα πράγματα που μπορεί να κάνει. Η δε πληροφορία για το αν μια μεταβλητή είναι register απλά αφαιρείτε κατά το ṕarsing.

H C++ έχει αντίστοιχα την ínline κάτι καλύτερο απο τα #define της C, αλλά σύντομα άχρηστη. Προσπαθεί να κάνει τον κώδικα γρήγορο αντιγράφοντας εντολές αντί για κλήση μικρών συναρτήσεων. Μα αυτό ακριβώς κάνει το LTO.

Επιτέλους στην τελευταία έκδοση της C++ μπορούμε να πούμε likely/unlikely για να επηρεάσουμε μια εντολή if..then...else. Αν το κάνεις σωστά θα έχεις μια αύξηση της απόδοσης κατά ~30\% αλλά αν το κάνεις λάθος η απόδοση θα μειωθεί στο μισό. Άουτς. Για να το κάνεις σωστά θέλεις πληροφορίες και arcs από ένα profiler που θα τρέξει το πρόγραμμα και θα βρει τις «καυτές» διαδρομές. Ελάχιστα προγράμματα έχω δει που να έχουν έστω τα πρότυπα εκτέλεσης (Το TDD δεν κάνει γιατί σκοπός του είναι να διερευνήσει τα ελάχιστα πατημένα μονοπάτια, δηλαδή το αντίθετο). Εξεπλάγην που το PGO αναφέρθηκε απο την Intel. Είναι φρικτά δύσκολο και εξαιρετικά χρονοβόρο για μαζικά daily builds ακούγετε σαν ανέκδοτο.

Τώρα που το ξανακοιτάζω πολύ μπλα μπλά βρε αδελφέ.

image

Και υπάρχει ακόμα. Το compile ενός προγράμματός δεν είναι απαραίτητα για να κάνεις optimize. Αντίθετα κάνεις compile όταν θες να αλλάξεις ρυθμίσεις που είναι προσβάσιμες μόνο κατά το compile. Δεν γνωρίζω για άλλες source-based διανομές και κατά πόσο ισχύει αυτό σε όλες (πιθανώς δεν ισχύει), αλλά το Gentoo (το οποίο βασικά χρησιμοποιεί hybrid σύστημα αφού μπορεί πλήρως να χρησιμοποιηθεί και ως bin-based διανομή αν παρεχθεί κάποιο binhost) υπάρχει για τη δημιουργία ενός συστήματος προσαρμοσμένου σε κάθε χρήση.

Ένα βίντεο για LTO

1 «Μου αρέσει»

Είναι θετικό που ενήργησε κατ αυτον τον τρόπο η Intel, θετικό για το Linux και για μας τους χρηστες του! Αναμφισβήτητα, αυτο το λειτουργικο θα υπερεχει σε αποδοση και οχι μονον (κατα τη γνώμη μου) πανω σε επεξεργαστες intel. Μπορεί να του λείπουν βέβαια κάποια άλλα χαρακτηριστικά αλλά , ουδείς τέλειος. Ισως να βρεθεί καποιος να κανει κατι παρομοιο για επεξεργαστες ΑΜD… και στο φιναλε ολη αυτή ή, μέρος αυτής της βελτιστοποίησης ισως να μπορεσει να αξιοποιηθεί γενικοτερα από πολλές διαφορετικες διανομες GNU Linux.
@asfodelus : Αστους να λενε για τη “register”… :slightly_smiling_face: Κι εγω ετσι διαβασα αλλά, μετρησα τον χρονο εκτελεσης ενος βρογχου και πηγε πολυ πιο γρηγορα οταν η μεταβλητη ελεγχου του βρογχου ηταν δηλωμενη ως register… οχι παντα ομως… .λογικα εξαρταται απο τους διαθεσιμους πορους εκεινη τη στιγμη. Στην περιπτωση ομως της απλης μεταβλητης ελεγχου του βρογχου ο χρονος εκτελεσης ηταν παντα μεγαλυτερος συγκριτικα. Θα υπαρχουν διαφορες βεβαια αναλογα με τον compiler. Και να μην το παρακανει καποιος με τις δηλωσεις register μεταβλητων…γιατι μιλαμε για δεσμευση καταχωρητων δεδομενων του συστηματος και οχι απλα για λιγες θεσεις μνημης… .

1 «Μου αρέσει»

Θα σου πω ένα μυστικό. Αν δεις τον κώδικά του gcc η χρήση της register κάνει ένα και μόνο ένα πράγμα. Κατά τη συντακτική ανάλυση βγάζει μήνυμα λάθους αν προσπαθήσεις να πάρεις τη διεύθυνση μνήμης μιας μεταβλητής δηλωμένης με αυτό σαν storage class. Μόνο αυτό και τίποτα άλλο.

Όταν φτιαχτεί το Abstact Syntax Tree (AST) αυτή η πληροφορία δεν υπάρχει καν. Κάπου στα χαμηλά στρώματα της μεταγλώττισης θα καταλήξεις με ένα AST μιας stack machine που δεν έχει καταχωρητές. Τότε θα περάσουμε στο τελικό στρώμα που γνωρίζει επιτέλους για ποιον επεξεργαστή προορίζετε το πρόγραμμα και τότε θα γίνει η αντιστοίχηση μεταβλητών σε καταχωρητές. Και σήμερα για ένα compiler είναι παιγνιδάκι. (Δες το κεφάλαιο 13 του βιβλίου των Cooper/Torczon τα ελληνικά απο τις ΠΕΚ ή στο Dragon book έχω την ελληνική έκδοση κάτι που δεν επηρεάζει στο ελάχιστο την ευκολία ανάγνωσης του λολ).

Στη C++ σήμερα η λέξη register έχει μια μοναδική ιδιότητα. Επίσημα δεν κάνει τίποτα, αλλά παραμένει δεσμευμένη λέξη για μελλοντική χρήση (υπάρχουν σχέδια να δηλώνει multi threading atomic, κάτι που θα κάνει ένα safe singleton εύκολ ο στην υλοποίηση). Το άλλο storage class της γλώσσας C, το auto έχει εντελώς άλλη έννοια και έχει μεταλλάξει εντελώς την γλώσσα.

Τα loop ειναι πραγματικά ένα πεδίο που οι επεξεργαστές δίνουν ρέστα, και ανάλογα με το σύνολο εντολών του επεξεργαστή (MMX, AVL κλπ) το τελικό σχήμα του κώδικα αλλάζει δραστικά. Πάιξε με ένα loop στον compile explorer άλλαξε μοντέλο επεξεργαστή ή επίπεδο βελτιστοποίησης και θα σου πέσει το σαγόνι.

Αλλά αυτά που μπορεί να κάνει ο μεταγλωτηστής σήμερα δεν μπορούσε να τα κάνει ένας πριν 30-40 χρόνια που δεν είχε μνήμη και έπρεπε να ελαχιστοποιήσει τα περάσματα του κώδικά. Και για αυτό έχουμε πχ τον περιορισμό του κανόνα του μοναδικού ορισμού ενός πράγματος πριν χρησιμοποιηθεί και τα header files ου μας ταλαιπωρούν ακόμα.

1 «Μου αρέσει»

Πολύ ωραία Γιάννη !! Πολύ καλό όλο το θέμα δηλαδή !! Δεν την γνωρίζω τη C++ καθόλου ! Δοκίμασα σε C πρόπερσι, έτσι από περιέργεια δηλαδή και διαπίστωσα αυτήν τη διαφορά ταχύτητας και χάρηκα πολύ διότι , ήταν παλιά συνήθεια δική μου να ορίζω μια - δυο μεταβλητές ανά συνάρτηση ως register, ειδικά για έλεγχο loops και μόνον εφόσον υπήρχαν loops. Πολύ πιθανόν στις μέρες μας να μπορούσα να ορίσω και παραπάνω… Δουλεύoυν γρηγορότερα και τα arrays. Το “auto” επίσης το χρησιμοποιώ , λίγο πρακτικά βέβαια με έναν προσωπικό τρόπο δηλαδή, (διότι θεωρητικά οι τοπικές είναι auto εκτός από τις χρησιμότατες static), με περίσκεψη όμως γιατί παλιότερα οι καταχρήσεις προκαλούσαν ενίοτε κατακερματισμό της μνήμης . Όσο να είναι προκύπτει αραιά και που η ανάγκη να χρησιμοποιηθούν και κάποιες ας τις πούμε “πολύ τοπικές” μεταβλητές, για πολύ λίγο δηλαδή κι ύστερα να πηγαίνουν στο καλό .