Γιώργος
Τιμώμενο Μέλος
Ο Γιώργος αυτή τη στιγμή δεν είναι συνδεδεμένος. Μας γράφει απο Ελβετία (Ευρώπη). Έχει γράψει 30,791 μηνύματα.
05-12-10
20:29
Προειδοποιώ ότι το παρακάτω post εμβαθύνει πολύ στις περιοχές του computer architecture.
Έπειτα, εξαρτάται καθαρά από την υλοποίηση το αν χρειάζεται μία πληροφορία να μείνει ή όχι στην RAM. Γιατί πολύ απλά ένα πρόγραμμα μπορεί να έχει δεδομένα και στην cache του επεξεργαστή και αν έχεις μία πολιτική write-back τότε σε περίπτωση που ανανεώσεις τα δεδομένα σου στην cache, δεν τα ανανεώνεις και στην RAM. Επομένως, εάν πας στην RAM και κοιτάξεις την κατάσταση του προγράμματος, μπορεί να μην είναι η πραγματική του εικόνα, καθώς μέσα στον επεξεργαστή έχεις ανανεωμένες τιμές.
Για το λόγο αυτό, μπορεί να επιλέξει ο manufacturer αυτά τα δεδομένα να τα πετάξει στο swap φερ' ειπείν και να φέρει σε εκείνες τις θέσεις κάποιες άλλες χρήσιμες πληροφορίες.
Τις caches τις αναφέρω γιατί είναι το αμέσως χαμηλότερο επίπεδο που θα πάει κάποια πληροφορία άμα φύγει απ' τους registers. Εάν όλα σου τα δεδομένα είναι στις caches, η πρόσβαση RAM δεν θα σου χρειαστεί. Αντίστοιχα, εάν έχεις περισσότερους registers (κάτι που ισχύει στην x64 αρχιτεκτονική -> πηγή) ενδέχεται να χρειαστείς λιγότερες προσβάσεις στην cache -> άρα και στην RAM.
Δεν έχω πρόχειρο τώρα ένα παράδειγμα, αλλά μπορώ να σου δώσω κώδικα που σε 2-way or 4-way set-associative caches θα δουλεύει εξαιρετικά, αλλά σε directed mapped θα έχεις conflicts, δηλαδή δύο memory blocks θα γίνονται mapped στην ίδια cache line.
Αυτό που θέλω να σου πω δηλαδή είναι ότι οι βελτιστοποιήσεις στον κώδικα έχουν νόημα εάν ξέρεις τι παίζει από κάτω. Σαφώς και μπορείς να προβλέψεις όλες τις πιθανές περιπτώσεις, αλλά κατά πάσα πιθανότητα θα πρέπει να γίνει compile ο κώδικας στο τοπικό μηχάνημα, για να αξιοποιηθεί πλήρως το εκάστοτε optimization.
Αυτό όμως δεν σημαίνει αναγκαστικά ότι και ο συνολικός χρόνος αυξάνεται. Επειδή χειρίζεσαι μεγαλύτερα data-sets ανά εντολή, θα χρειαστείς λιγότερες εντολές για την επεξεργασία ενός μεγάλου set δεδομένων.
----
@ exposed_bone / Johnny Cash : με βάση αυτό που είπα τώρα, ναι μπορεί να αποβεί ένα 64-bit σύστημα πιο "γρήγορο", γιατί μεγαλύτερο data-set -> μικρότερος αριθμός εντολών (loop iterations). Αλλά παίζουν και άλλοι παράγοντες, όπως:
Δεν είναι δηλαδή ένα yes/no ερώτημα, υπάρχουν tradeoffs που εξαρτώνται από διάφορους παράγοντες.
Κατ' αρχάς μία βαριά εφαρμογή όπως το Matlab δεν μπορεί να φορτωθεί εξ' ολοκλήρου στη μνήμη, αφενός γιατί η μνήμη σου πάει 2-4-6-8GB και αφετέρου γιατί υπάρχουν κι άλλα processes που τρέχουν και χρειάζονται και αυτά RAM.Κάθε πρόγραμμα φορτώνεται ολόκληρο στην κύρια μνήμη, όχι στους καταχωρητές του επεξεργαστή. Οι καταχωρητές χρησιμοποιούνται ώστε να γίνονται εκεί οι διάφορες αριθμητικές και λογικές πράξεις. Αυτό που λες για πληροφορία που υπάρχει στους registers και δε χρειάζεται να μείνει στη μνήμη δε το πολυκαταλαβαίνω.
Έπειτα, εξαρτάται καθαρά από την υλοποίηση το αν χρειάζεται μία πληροφορία να μείνει ή όχι στην RAM. Γιατί πολύ απλά ένα πρόγραμμα μπορεί να έχει δεδομένα και στην cache του επεξεργαστή και αν έχεις μία πολιτική write-back τότε σε περίπτωση που ανανεώσεις τα δεδομένα σου στην cache, δεν τα ανανεώνεις και στην RAM. Επομένως, εάν πας στην RAM και κοιτάξεις την κατάσταση του προγράμματος, μπορεί να μην είναι η πραγματική του εικόνα, καθώς μέσα στον επεξεργαστή έχεις ανανεωμένες τιμές.
Για το λόγο αυτό, μπορεί να επιλέξει ο manufacturer αυτά τα δεδομένα να τα πετάξει στο swap φερ' ειπείν και να φέρει σε εκείνες τις θέσεις κάποιες άλλες χρήσιμες πληροφορίες.
Τις caches τις αναφέρω γιατί είναι το αμέσως χαμηλότερο επίπεδο που θα πάει κάποια πληροφορία άμα φύγει απ' τους registers. Εάν όλα σου τα δεδομένα είναι στις caches, η πρόσβαση RAM δεν θα σου χρειαστεί. Αντίστοιχα, εάν έχεις περισσότερους registers (κάτι που ισχύει στην x64 αρχιτεκτονική -> πηγή) ενδέχεται να χρειαστείς λιγότερες προσβάσεις στην cache -> άρα και στην RAM.
Το ανέφερα παραπάνω, είναι το padding.Ένας απλός λόγος που σε αρχιτεκτονική περισσότερων bit το ίδιο λογισμικό μπορεί να απαιτεί περισσότερη μνήμη είναι το γεγονός ότι οι μεταβλητές τύπου pointer καταλαμβάνουν περισσότερα bytes στη μνήμη.
Ισχύει, σε επίπεδο κώδικα μπορείς να κάνεις βελτιστοποιήσεις με διάφορες τεχνικές, για παράδειγμα αν θα εφαρμόσεις loop distribution ή loop fusion. Το θέμα όμως είναι ότι δεν ξέρεις τι αρχιτεκτονική θα παίζει από κάτω, για να κάνεις αυτές τις βελτιστοποιήσεις.ούτε εγώ. Αυτό που υποθέτω είναι ότι θέλουν να ξαναγράψουν κομμάτια κώδικα ώστε να γίνεται καλύτερη διαχείριση μνήμης. Ακόμα και σε γλώσσες υψηλού επιπέδου όπου δε χρησιμοποιουνται εντολές που διαχειρίζονται απευθείας τη μνήμη, ο τρόπος που γράφεται ένας κώδικας μπορεί να καθορίσει πόσο αποδοτική χρήση μνήμης μπορεί να γίνει. Δεν είναι μόνο θέμα του compiler.
Δεν έχω πρόχειρο τώρα ένα παράδειγμα, αλλά μπορώ να σου δώσω κώδικα που σε 2-way or 4-way set-associative caches θα δουλεύει εξαιρετικά, αλλά σε directed mapped θα έχεις conflicts, δηλαδή δύο memory blocks θα γίνονται mapped στην ίδια cache line.
Αυτό που θέλω να σου πω δηλαδή είναι ότι οι βελτιστοποιήσεις στον κώδικα έχουν νόημα εάν ξέρεις τι παίζει από κάτω. Σαφώς και μπορείς να προβλέψεις όλες τις πιθανές περιπτώσεις, αλλά κατά πάσα πιθανότητα θα πρέπει να γίνει compile ο κώδικας στο τοπικό μηχάνημα, για να αξιοποιηθεί πλήρως το εκάστοτε optimization.
Δεν είπα ότι ντε και καλά το κάθε στάδιο για την ολοκλήρωση μίας εντολής διαρκεί ντε και καλά έναν κύκλο. Σε out-of-order επεξεργαστές ειδικά, δηλαδή επεξεργαστές που ολοκληρώνουν τις εντολές εκτός σειράς, μπορεί να δεις εντολές κινητής υποδιαστολής να θέλουν και 5-20 κύκλους παραπάνω να ολοκληρωθούν, σε σχέση με τις αντίστοιχες πράξεις ακεραίων. Αρκετά τέτοια παραδείγματα μπορείς να βρεις σε αυτό το βιβλίο.Για τον κύκλο μηχανής έχω βρει διαφορετικούς ορισμούς. Μερικοί ταυτίζουν τον όρο "κύκλο μηχανής" με τον όρο "κύκλο εντολής" ενώ μερικοί άλλοι ως κύκλο μηχανής ορίζουν το καθένα από τα επιμέρους στάδια που λες ότι περιλαμβάνονται σε ένα κύκλο εντολής. Αν δεχτούμε ως σωστό το 2ο ορισμό, και πάλι δεν είναι απόλυτο ότι καθένα από τα στάδια αυτά απαιτεί μόνο ένα κύκλο ρολογιού.
Θες να κάνεις πολλαπλασιασμό δύο 32-bit αριθμών και δύο 64-bit αριθμών. Εάν θες να διατηρήσεις την κατανάλωση ενέργειας (power dissipation) στα ίδια επίπεδα, αναγκαστικά η δεύτερη πράξη θα διαρκέσει περισσότερο -> Βαθαίνεις περισσότερο το pipeline σου [ή ρίχνεις το ρολόι σου] -> Μία εντολή χρειάζεται περισσότερο χρόνο ολοκλήρωσης. Πηγή δεν έχει εδώ.Πηγή και γι αυτό υπάρχει;;
Αυτό όμως δεν σημαίνει αναγκαστικά ότι και ο συνολικός χρόνος αυξάνεται. Επειδή χειρίζεσαι μεγαλύτερα data-sets ανά εντολή, θα χρειαστείς λιγότερες εντολές για την επεξεργασία ενός μεγάλου set δεδομένων.
----
@ exposed_bone / Johnny Cash : με βάση αυτό που είπα τώρα, ναι μπορεί να αποβεί ένα 64-bit σύστημα πιο "γρήγορο", γιατί μεγαλύτερο data-set -> μικρότερος αριθμός εντολών (loop iterations). Αλλά παίζουν και άλλοι παράγοντες, όπως:
- Σε επίπεδο επεξεργαστή, ενδέχεται να μεγαλώσει λίγο η διάρκεια ολοκλήρωσης μιας εντολής, όπως προανέφερα, αλλά αίσθησή μου είναι ότι δεν θα επηρεάσει τόσο πολύ, λόγω τεχνικών διάδοσης κρατουμένων, σύμφωνα με τις οποίες κατά την εκτέλεση μίας πρόσθεσης κάνεις πρόβλεψη των κρατουμένων που θα χρειαστείς, επομένως "παραλληλοποιείς" κάποια τμήματά της και δεν την εκτελείς bit-προς-bit, όπως θα έκανες με το χέρι.
- Το σοβαρότερο issue είναι το εξής: Μήπως το μεγαλύτερο data-set θα είναι πολύ μεγάλο για τις caches σου; Σε αυτήν την περίπτωση μπορεί να εκτοπίζεις συνέχεια δεδομένα και εν τέλει η εκτέλεση να γίνει πιο αργή.
Δεν είναι δηλαδή ένα yes/no ερώτημα, υπάρχουν tradeoffs που εξαρτώνται από διάφορους παράγοντες.
Σημείωση: Το μήνυμα αυτό γράφτηκε 13 χρόνια πριν. Ο συντάκτης του πιθανόν να έχει αλλάξει απόψεις έκτοτε.
Γιώργος
Τιμώμενο Μέλος
Ο Γιώργος αυτή τη στιγμή δεν είναι συνδεδεμένος. Μας γράφει απο Ελβετία (Ευρώπη). Έχει γράψει 30,791 μηνύματα.
04-12-10
23:31
Για να απαντήσω, όρισέ μου το "αργός", το "κύκλος" και ειδικά το "καλύτερο".Αφού εσύ αγαπάς το hardware, σου έχω ακόμη μια ερώτηση.
Ένας αργός επεξεργαστής δεν θα ήταν καλύτερο να είναι 64bit και όχι 32bit, αφού στην πρώτη περίπτωση θα μπορούσε να διαχειρίζεται περισσότερα δεδομένα σε έναν κύκλο; (Στο μυαλό μου έχω τους Intel Atom)
- Αργός ως προς τι; Ως προς τον χρόνο που χρειάζεται να εκτελεστεί μία εντολή; (Κύκλος Εντολής)
- Τι κύκλο; Κύκλος εντολής ή μηχανής;
- Καλύτερο: με βάση ποιο κριτήριο; Ειδικά αυτό όρισέ μου.
- Κύκλος μηχανής είναι ο χρόνος που μεσολαβεί μεταξύ δύο "χτυπημάτων" του ρολογιού της CPU. Πχ όταν λέμε CPU @ 2.00 GHz, τότε η συχνότητα του ρολογιού είναι 2 GHz, δηλαδή ο κύκλος μηχανής είναι 0.5 nsec.
- Κύκλος εντολής είναι ο χρόνος που μεσολαβεί για την εκτέλεση μίας εντολής. Συνήθως στους μοντέρνους επεξεργαστές είναι κάποιο ακέραιο πολλαπλάσιο του κύκλου μηχανής, καθώς η ... διαδικασία ολοκλήρωσης μίας εντολής έχει "τεμαχιστεί" σε πολλά υπο-στάδια, τα οποία και διαρκούν έναν κύκλο μηχανής. Π.χ. ένα κύκλο για ανάγνωση εντολής, ένα για εκτέλεση πράξης, ένα για write-back του αποτελέσματος στους registers.
Πάντως κοίτα, εφόσον οι 64-bit επεξεργαστές μπορούν να χειριστούν πολύ μεγαλύτερο data-set, ενδέχεται κάποιες εντολές να χρειαστούν πολύ περισσότερο χρόνο για να εκτελεστούν, λ.χ. εντολές που αφορούν πράξεις κινητής υποδιαστολής. Οπότε θα πρέπει να μου πεις τι εννοείς με το "καλύτερο".
Σημείωση: Το μήνυμα αυτό γράφτηκε 13 χρόνια πριν. Ο συντάκτης του πιθανόν να έχει αλλάξει απόψεις έκτοτε.
Γιώργος
Τιμώμενο Μέλος
Ο Γιώργος αυτή τη στιγμή δεν είναι συνδεδεμένος. Μας γράφει απο Ελβετία (Ευρώπη). Έχει γράψει 30,791 μηνύματα.
04-12-10
19:28
Για να ξεκαθαρίσουμε λίγο το θέμα με το ότι τα 64bit συστήματα καταναλώνουν περισσότερη μνήμη.
Πολύ χοντρικά, αρκετά κλειστά προγράμματα (από εταιρίες, που πρέπει να πληρώσεις) έχουν φτιαχτεί πάνω σε 32bit συστήματα και δεν μπορούν να αξιοποιήσουν πλήρως τα 64bit συστήματα.
Αρκετά όμως freeware και open-source προγράμματα έχουν λάβει υπόψιν τέτοιες περιπτώσεις, οπότε αντί να χρησιμοποιήσουν 2 x 32bit blocks, χρησιμοποιούν 1 x 64bit. Έτσι λοιπόν όχι μόνο δεν αυξάνεται η μνήμη που χρησιμοποιείται, αλλά πολλές φορές μπορεί να μειωθεί κιόλας, γιατί ένα πρόγραμμα μπορεί να εκμεταλλευτεί το γεγονός ότι ένας 64bit επεξεραστής έχει αυξημένο αριθμό καταχωρητών (registers - είναι κάποιου είδους μνήμης που είναι ακριβώς δίπλα στον επεξεργαστή και είναι η γρηγορότερη μνήμη στον Η/Υ σας), με αποτέλεσμα μία πληροφορία να μην χρειαστεί καν να μείνει στην μνήμη, εφόσον υπάρχει στους registers του επεξεργαστή.
Μην ρίχνουμε λοιπόν το φταίξιμο στα 64bit συστήματα, ενώ στην πραγματικότητα φταίει το λειτουργικό ή το πρόγραμμα που είναι ηλίθιο και δεν κάνει καλή διαχείριση πόρων.
Εάν καταναλώνουν "πολύ περισσότερη μνήμη" δεν είναι ότι φταίει το hardware, αλλά είτε το λειτουργικό που το διαχειρίζεται (Windows) είτε το πρόγραμμα που τρέχει.Ισχύει αυτό που λέει ο Morelo και ο Koum αλλά είναι παραπλανητικό γιατί τα windows 7 64 bit καταναλώνουν πολύ περισσότερη μνήμη από ότι τα 32 για τα ίδια πράγματα. Άρα δώρο άδωρο.
Πολύ χοντρικά, αρκετά κλειστά προγράμματα (από εταιρίες, που πρέπει να πληρώσεις) έχουν φτιαχτεί πάνω σε 32bit συστήματα και δεν μπορούν να αξιοποιήσουν πλήρως τα 64bit συστήματα.
- Για να δώσω ένα απλό παράδειγμα, μία πληροφορία μπορεί να είναι πολύ μεγάλη, οπότε σε ένα 32bit σύστημα να πρέπει να "σπάσει" σε δύο blocks των 32bit. Εάν δεν υπάρχει πρόνοια για 64bit συστήματα, πάλι στα 64bits θα χρησιμοποιηθούν 2 blocks των 32bit αντί για 1 των 64bit.
- Λόγω όμως του ότι σε ένα 64bit σύστημα δεν υπάρχουν 32bit blocks αλλά 64 bit blocks, τότε χρησιμοποιούνται 2 x 64bit blocks, τα οποία έχουν μέχρι τη μέση χρήσιμη πληροφορία και έπειτα μηδενικά (λέγεται padding). Έτσι λοιπόν χρησιμοποιείται διπλάσια μνήμη.
Αρκετά όμως freeware και open-source προγράμματα έχουν λάβει υπόψιν τέτοιες περιπτώσεις, οπότε αντί να χρησιμοποιήσουν 2 x 32bit blocks, χρησιμοποιούν 1 x 64bit. Έτσι λοιπόν όχι μόνο δεν αυξάνεται η μνήμη που χρησιμοποιείται, αλλά πολλές φορές μπορεί να μειωθεί κιόλας, γιατί ένα πρόγραμμα μπορεί να εκμεταλλευτεί το γεγονός ότι ένας 64bit επεξεραστής έχει αυξημένο αριθμό καταχωρητών (registers - είναι κάποιου είδους μνήμης που είναι ακριβώς δίπλα στον επεξεργαστή και είναι η γρηγορότερη μνήμη στον Η/Υ σας), με αποτέλεσμα μία πληροφορία να μην χρειαστεί καν να μείνει στην μνήμη, εφόσον υπάρχει στους registers του επεξεργαστή.
Μην ρίχνουμε λοιπόν το φταίξιμο στα 64bit συστήματα, ενώ στην πραγματικότητα φταίει το λειτουργικό ή το πρόγραμμα που είναι ηλίθιο και δεν κάνει καλή διαχείριση πόρων.
Σημείωση: Το μήνυμα αυτό γράφτηκε 13 χρόνια πριν. Ο συντάκτης του πιθανόν να έχει αλλάξει απόψεις έκτοτε.