Προς το περιεχόμενο

Προτεινόμενες αναρτήσεις

Δημοσ. (επεξεργασμένο)

Καλησπερα σας. Εδω και αρκετα χρονια εχω εναν FX 8320 στην κατοχη μου πανω στον οποιο πειραματιστικα και εκανα καποιες ανακαλυψεις οι οποιες δεν ειναι καταγεγραμμενες πουθενα αλλου, σε ολοκληρο το διαδυκτιο. 

Ας αρχισουμε με τα βασικα. Οι FX ειναι βασισμενοι στην αρχιτεκτονικη CMT. (Clustered MultiThreading). Ενας FX επεξεργαστης δεν εχει τους συνηθεις πυρηνες, αλλα Modules. Ας παρουμε για παραδειγμα τον 8320 που κατεχω. Εχει συνολο 4 modules, αλλα ξερουμε οτι ειναι 8πυρηνος επεξεργαστης. Και η αληθεια ειναι πως οντως ειναι. Το καθε Module περιλαμβανει 2 πυρηνες μεσα του οπου μοιραζονται resources (L3/L2 cache κυριως αλλα και fetch/decode), αποτελουνται απο 1 ALU με 1 integer core ο καθενας, εχουν τα δικα τους pipelines και registers, αλλα μοιραζονται ενα 256bit FPU το οποιο το διαχωριζουν σε ενα 128bitο ανα πυρηνα. (1η εικονα)

SCFQUtJ.png

Τωρα που καλυψα τα βασικα ας αρχισω με την πειραματικη διαδικασια η οποια μου προεκυψε τυχαια. Αρχισα λοιπον διερευνωντας αποτελεσματα απο το Cinebench οταν παρατηρησα οτι εβγαζα μεγαλυτερο σκορ βαζωντας το affinity του προγραμματος σε πυρηνες, οι οποιοι βρισκονται σε διαφορετικο module. (Δυστυχως δεν εχω σε εικονα το πρωτο Run το οποιο εβγαλα 181 ποντους και σε αυτο πρεπει να με εμπιστευτειτε)
 Î¦ÏÏογÏαÏία ÏÎ¿Ï Kostas Anes.

To single core δεν ειχε αλλαξει, ενω το Multicore αλλαξε κατα 10 ποντους, πραγμα απολυτως λογικο αν σκεφτουμε πως οταν τρεχεις τα νηματα σε ξεχωριστα module οι πυρηνες δεν μοιραζονται πορους, αρα δουλευουν πιο γρηγορα, σωστα? Το εξης θεμα εχει αναφερθει πολλακις εδω και χρονια (και υποτιθεται οτι εχει φτιαχτει), οποτε μεχρι εδω δεν εχουμε κατι το νεο η το συνταρακτικο.

Το ενδιαφερον κομματι ερχεται μετα απο τεσταρισμα σε ενα παιχνιδι (που απο την φυση του εχει απροβλεπτο κωδικα, σε αντιθεση με ενα benchmark) το οποιο χρησιμοποιει εως το πολυ 2 threads. To παιχνιδι που χρησιμοποιησα ηταν το S.T.A.L.K.E.R : Shadow Of Chernobyl σε αναλυση 800x600 στα lowest για να ειμαι 100% CPU bound (RX 480 η καρτα, φαινεται και στην υπογραφη). 
ΦÏÏογÏαÏία ÏÎ¿Ï Kostas Anes.

Η παραπανω εικονα τραβηχτηκε με τον επεξεργαστη στα 4GHz και το affinity manual σεταρισμενο στο Module 1 (Core 0, 1). Βλεπουμε πως βγαζω 250 FPS στην παραπανω σκηνη.
ΦÏÏογÏαÏία ÏÎ¿Ï Kostas Anes.

Ενω αυτη η εικονα τραβηχτηκε με το Affinity manually set στα Module 1, 2 με ενα πυρηνα απο το καθενα (Core 0, 2). Οπως παρατειρειτε, μιλαμε για διαφορα 38% στο framerate, παλι κοιταζοντας την ιδια σκηνη. Κραταμε αυτην την μεγαλη διαφορα, μιας και θα την αναλυσω πιο κατω.
ΦÏÏογÏαÏία ÏÎ¿Ï Kostas Anes.

Η τριτη εικονα παρουσιαζει διαφορετρικη συμπεριφορα. Σεταρα το affinity στα Module 1, 4 παλι απο εναν πυρηνα σε καθε module (Core 0, 7) και βλεπουμε πως εχω μειωση 12% στο framerate, πραγμα το οποιο θεωρω ακρως περιεργο, μιας και τα FPS σταθεροποιηθηκαν εκει.

Aς παμε πισω ομως στην 2η εικονα (403 FPS). Το νουμερο φαινεται... υπερβολικα μεγαλο για να δικαιολογησει το performance gain που δινει η απουσια του resource sharing. Ετσι λοιπον αποφασισα να το ψαξω παραπανω. Μετα απο μια ημερα σκεψης μου ηρθε η επιφωτιση. Μπορει καποιος να παρατηρησει οτι ενα module περιεχει εναν μονο branch predictor, ενω περιλαμβανει 2 πυρηνες. Τι και αν ο branch predictor "μπουκωνεται" απο τους 2 πυρηνες που λειτουργουν ταυτοχρονα και δεν προλαβαινει να ανταπεξερθει? Σαν θεωρια στεκει, αφου αμα το σκεφτουμε λογικα, καθε φορα που εναλλασεται το thread το οποιο εχει προτεραιοτητα, ο branch predictor πρεπει να αδειαζει τα pipelines, να κανει reset και να ξαναφορτωνει τον κωδικα εκ νεου. Δηλαδη σε καθε εναλλαγη εχουμε 3 παραπανω βηματα (τουλαχιστον) απο εναν συνηθισμενο επεξεργαστη.
Flush -> Reset -> Load


Aπο αυτα τα 3, το μονο σταδιο που μπορω να επηρεασω ειναι το "Load". Ο επεξεργαστης φορτωνει δεδομενα απο την Cache και την RAM, αρα δεν εχω παρα να τα κανω πιο γρηγορα. Αυτο το πετυχα αυξανοντας το NorthBridge Frequency απο τα 2200MHz στα 2648MHz, αυξανοντας ετσι την ταχυτητα της L3 Cache με την οποια συνδεεται και αυξανοντας την RAM απο τα 1600 MHz CL10 που ειναι το στοκ της, στα 2648MHz CL11 (ναι ξερω, χρυσο κιτ παει μεχρι τα 2800). 

Ξεκινησα κλασσικα απο το Cinebench, με το affinity σεταρισμενο σε ενα Module (Core 0, 1)
iQt1f8s.png

(Εδω φαινεται και το 181 που ανεφερα πριν, ζητω συγγνωμη αλλα δεν ηθελα να αποκαλυψω ακομα την φωτο). Βλεπουμε πως βγαζω ιδιο single core score (95 ηταν το προηγουμενο, 1 ποντος θεωρειται αμελητεα διαφορα), ενω εχω 8 ποντους διαφορα στο Multicore. Ξανατρεχω λοιπον αλλη μια το bench με το affinity σεταρισμενο σε 2 διαφορετικα modules (Core 0, 2) αυτην την φορα για να δω αν το Cache/RAM OC επηρεασε γενικα την επιδοση του επεξεργαστη.
yY5rU5z.png

Που οπως φαινεται δεν την βελτιωσε. Παλι αμελητεα διαφορα. Θυμιζω στο παλιο bench που ηταν σε στοκ συχνοτητες οι RAM/Cache ειχα βγαλει 191 στην ιδια διαταξη των cores. Aυτο επιβεβαιωνει την θεωρια μου για τον branch predictor. Μειωνοντας το performance hit του branch predictor πηρα παραπανω επιδοσεις οι οποιες εμφανιζονται μονο οταν ο branch predictor ειναι "μπουκωμενος". Και τι επιδοσεις. Αν λαβουμε υπ οψιν μας οτι εξαφανιζοντας το θεμα του sharing και του predictor πηρα 10 ποντους, ενω μειωνοντας μονο (θυμιζω επηρεαζω 1 απο τα 3 σταδια) το θεμα του predictor πηρα 8, καταλαβαινουμε οτι σε Multithreaded σεναρια τουλαχιστον το 80% του performance hit ειναι λογω του branch predictor (το οποιο προβλημα, η αργη cache των FX δεν βοηθαει, αν και επαρκει οπως φαινεται για να "ταισει" μονους πυρηνες.

Φυσικα ομως και το πειραμα δεν σταματησε εκει. Θεωρητικα σε παινχιδι που εχει πιο απροβλεπτο κωδικα, το θεμα στον branch predictor πρεπει να μεγαλωνει, αφου εχουμε περισσοτερα αποτυχυμενα predictions αλλα και περισσοτερες εναλλαγες. 
G8gAWms.png

Αυτη την φορα δεν το εκανα με φωτογραφια, αλλα με benchmark απο FRAPS, παλι στο S.T.A.L.K.E.R. Δεν θα κατσω να αναλυσω το affinity και τα αποτελεσματα, αφου βρισκονται πανω στην φωτογραφια οι σχετικες πληροφοριες. Παντως τα αποτελεσματα συμβαδιζουν με αυτα που ειδαμε πανω. Να αναφερω πως δεν εμεινα στατικος, αλλα κινηθηκα σε μια προκαθορισμενη πορεια κατα την διαρκεια του benchmark.
g6KPUMl.png

Στην δευτερη φωτογραφια βλεπουμε μια διαφορα της ταξης του 12% στο framerate (μετραω το average) οταν τρεχω με κλοκαρισμενη RAM/Cache σε 1 Module, ενω αμελητεα διαφορα (κατω του 1%) οταν τρεχω σε 2 Modules. Οποτε η θεωρια μου ξαναεπιβεβαιωνεται. Αυτη την φορα η διαφορα ειναι αρκετα μεγαλη για να φαινεται.

Το επομενο τεστ που κανω ειναι στο PUBG, το οποιο ειχα ανακαλυψει οτι αγαπαει τις γρηγορες RAM, αλλα οπως φαινεται, τελικα ειναι κυριως εξ αιτιας του branch predictor ο λογος που δημιουργειται η διαφορα. Να σημειωσω πως οταν τρεχω κανονικα με τις RAM στα 2600 και με 8 πυρηνες, το PUBG παιρνει ~25 FPS απο οτι με τις RAM σε στοκ. Αυτην την μεγαλη διαφορα την δικαιολογω μιας και το PUBG ειναι αρκετα mulithreaded (χρησιμοποιει εως και 8 νηματα) αρα αφου χρησιμοποιουνται ολα τα Modules με ολους τους πυρηνες τους, το effect στον branch predictor γινεται πιο εμφανες.
Ας παμε ομως στις φωτογραφιες. 
QDW2OHl.png

Ολα τα bench εγιναν στο Miramar στο 1ο λεπτο του παιχνιδιου οπου ειναι οι παικτες μαζεμενοι (και ειναι βαρυ στον CPU) στα very low/720p/70% screen scale για να ειμαι σιγουρα CPU bound. Εδω βεβαια δεν ετρεξα με 2, αλλα με 4 thread τα οποια βλεπετε στην εικονα σε τι διαταξη τα εβαλα και τι αποτελεσματα πηρα. Δωστε προσοχη στο γεγονος οτι οταν εβαλα 1 πυρηνα ανα module εβγαλα λιγοτερα average FPS, εστω και αν μεχρι τωρα τα στοιχεια μας δειχνουν οτι θα επρεπε να ειχα περισσοτερα.
gu1lUry.png

Στο 2ο run βλεπουμε αυξηση 22% στο framerate για την διαταξη 2 πυρηνες ανα module, σε 2 module (4 πυρηνες συνολο), ενω αυξηση 4% στο framerate για την διαταξη ενος πυρηνα ανα module, την οποια αυξηση την αποδιδω στην RAM. Και παλι βλεπουμε ομως το περιεργο. Αφου προηγουμενως οταν εξαφανιζα το resource sharing και το θεμα του branch prediction, επαιρνα εως και 40% παραπανω επιδοσεις, εδω γιατι πηρα λιγοτερες?

Η απαντηση ηρθε οταν κοιταξα το performance tab του task manager. 
p1tvTqb.png

Αυτο που απεικονιζεται ειναι το PUBG να τρεχει με affinity σε Core 1, 3, 5, 7. Κανονικα πρεπει και τα 4 thread να ειναι μαξαρισμενα (οπως τα 2 πανω), αλλα παρατηρουμε περιεργη συμπεριφορα στο thread 5 και ακομα πιο περιεργη στο thread 7. Αν αναποδογυρισουμε την γραφικη παρασταση της χρησης του Core 7 και την φερουμε πανω απο την γραφικη παρασταση του Core 5, θα δουμε πως τα κενα ταιριαζουνε σαν παζλ και σχηματιζεται μια γραφικη παρασταση παρομοια με αυτες των πανω cores. Θυμαστε και το result στο STALKER οπου εβγαλα λιγοτερο οταν εβαλα το affinity στο Core 0 και 7? Ιδια συμπεριφορα. Αυτο ειναι ενα πολυ σημαντικο θεμα, το οποιο δεν ξερω που οφειλεται.

26jeUhZ.png

H παραπανω εικονα περιγραφει μια θεωρια μου. Το γεονος οτι το latency μεταξυ των modules που βρισκονται οριζοντια και διαγωνια το ενα απο το αλλο (δηλαδη σε διαφορετικο cache block) ειναι αρκετα μεγαλο. Αυτο μας υποδυκνειει οτι υπαρχει σοβαρο θεμα με την Cache η το Interconnect που χρησιμοποιειται (HyperTransport)
Μια αλλη πιθανοτητα ειναι να εχει προβλημα η cache και για καποιον λογο να μην μπορει να διαχειριστει την ταχυτητα επεξεργασιας και να συμβαδισει (Tα πρωτα 2 Module εχοντας επεξεργαστει ηδη τα δεδομενα που χρειαζονται επεξεργασια, κανουν το 2ο block απο cache βρισκεται σε μια συνεχη διαδικασια αδειασματος/γεμισματος)
Θα μπορουσε ομως να ειναι και θεμα των Windows το οποιο κανει κακη διαχειρηση πορων. Η αληθεια ειναι πως δεν ξερω. Αλλα αφου εφτασα ως εδω, θα προσπαθησω να μαθω μεσα απο περισσοτερο πειραματισμο.

Σας ευχαριστω ολους που φτασατε ως εδω και σας παρακαλω να αφησετε την γνωμη σας και/η δικη σας εμπειρια/τεστ που εχετε κανει μιας και θα με βοηθησουν ιδιαιτερα στο να ανακαλυψω τι τρεχει και για ποιον λογο. Ελπιζω να το βρηκατε οσο ενδιαφερον οσο το βρηκα εγω!

Επεξ/σία από kostas_anes
  • Like 15
Δημοσ.

Εύγε φίλε μου για τη προσπάθεια και το κουράγιο σου να τρέξεις όλα αυτά!!  Δοκίμασε μερικά  τεστακια  με geek bench 3 και 4 που έχουν και single και multi κομμάτι καθώς παίζουν αρκετά και οι μνήμες εδώ

Επίσης επειδή έχω παίξει αρκετά με fx παίζει μεγάλο ρόλο και το μεγάλο fsb από 250 και πάνω σε συνδιασμό με μεγάλο north bridge 2600-2800

 

  • Like 1
Δημοσ.
3 λεπτά πριν, ultraex2003 είπε

Εύγε φίλε μου για τη προσπάθεια και το κουράγιο σου να τρέξεις όλα αυτά!!  Δοκίμασε μερικά  τεστακια  με geek bench 3 και 4 που έχουν και single και multi κομμάτι καθώς παίζουν αρκετά και οι μνήμες εδώ

Επίσης επειδή έχω παίξει αρκετά με fx παίζει μεγάλο ρόλο και το μεγάλο fsb από 250 και πάνω σε συνδιασμό με μεγάλο north bridge 2600-2800

Σε ευχαριστω για τα καλα σου λογια και για την προταση! Πιστεψε με , πολλα ειναι αυτα που θελω να τρεξω, αλλα δυστυχως ο χρονος ειναι περιορισμενος (μαθητης 3ης λυκειου βλεπεις :/ ). Θα προσπαθησω τωρα στις διακοπες του Πασχα να το ψαξω καλυτερα το θεμα, που θα εχω καπως λιγοτερη πιεση.

  • Like 1
Δημοσ.

Αυτό με το affinity υπάρχει σαν παρατήρηση απο τότε που είχαν βγει οι Bulldozers. Είχαν λάθος τον πρώτο καιρό, και το λειτουργικό φόρτωνε διαδοχικά τους πυρήνες απο το ίδιο module, αντί να φορτώνει αρχικά ένα απο κάθε module. Το patchαραν και έστρωσε θεωρητικά.

BTW ωραία το έψαξες, αλλά κόψε τις ####κίες τώρα εν όψη Πανελληνίων και κάτσε διάβασε. Ψάχνεις ότι θες μετά τον Ιούνιο.

  • Like 5
Δημοσ.

Το ξερω οτι ηταν γνωστο το θεμα με το affinity και το αναφερω μεσα στο κειμενο. Αυτο που δεν μπορω να βρω πουθενα και το "νεο" που βρηκα ειναι το θεμα με το branch prediction και το Interconnect/Cache.
Οσο για τις Πανελληνιες, δεν θα διαφωνισω καθολου! Ολο το testing κτλ γινεται στον (λιγοστο, αλλα ακομα υπαρκτο) ελευθερο χρονο μου. Τι να πω την βρισκω με αυτα, αλλα οχι σε βαρος των σπουδων μου! Εχω φαει 3 μερες για να τεσταρω πραγματα που συνολικα μου φαγανε συνολο 2.5 ωρες.

  • Like 2
Δημοσ.

Μπράβο σου. Σου εύχομαι να περάσεις σε τέτοια σχολή που την 'αρρώστια' σου θα μπορέσεις να την κάνεις επάγγελμα 

Δημοσ. (επεξεργασμένο)

Κώστα, αυτά είναι ψιλογνωστά.

 

Η λύση τους ήρθε με τον παρακάτω πυρήνα.

 

AMD-Steamroller-vs-Bulldozer.jpg

 

d288f2d0-3d4e-404a-b723-fd63978f19b3.jpg

 

3c61ca4d-a512-495b-b3ef-b0e7903ef268.jpg

 

f3c51798-79e6-4854-b29a-aaca693dcbde.jpg

 

AMD-FX-Processor-Steamroller.jpg

105f.jpg

 

 

Οριστε και όλα τα block της AMD , από Κ8 / Κ10 και μπροστά.

 

AMD-architectures.jpg

Επεξ/σία από adtakhs
  • Thanks 1
Δημοσ.

ωραια το εψαξες αλλα το πρωτο λαθος που κανεις ειναι να νομιζεις οτι οι πυρηνες του piledriver λειτουργουν ταυτοχρονα κατι που δεν γινεται αφου δεν ειναι smt.

branch prediction ειναι πολυ πισω η amd απο την ιντελ, τουλαχιστον μεχρι εκεινη την εποχη. αν και δε νομιζω οτι και σημερα εχει αλλαξει και πολυ αυτο. θα υπαρχει μεν βελτιωση αλλα ποσο ακριβως δεν ξερω. αν κρινουμε παντως απο το spec ειναι πισω και αποτυπωνεται στο συνολικο σκορ.

ουσιαστικα εκλεισες το multithreading  σεναριο και εκμεταλλευτηκες ολη την cache που αν θυμαμαι καλα πρεπει να ειναι exclusive. ενω το δευτερο μεγαλυτερο προβλημα ειναι οτι η l1i μοιραζεται τα δυο cores με 64kb(shared), ενω και η l2 κανει αντιστοιχα το ιδιο ενω για να αποδοσει πιο σωστα επρεπε να ειναι private και οι δυο, μια μικρη για καθε πυρηνα οπως εχει το ζεν ή η ιντελ. εχουν γραφτει καμια δεκαρια σελιδες για τον buldozer αλλα και για τον sandy απο τον καντερ.

https://www.realworldtech.com/bulldozer/

Δημοσ.
8 ώρες πριν, Sheogorath είπε

Αυτό με το affinity υπάρχει σαν παρατήρηση απο τότε που είχαν βγει οι Bulldozers. Είχαν λάθος τον πρώτο καιρό, και το λειτουργικό φόρτωνε διαδοχικά τους πυρήνες απο το ίδιο module, αντί να φορτώνει αρχικά ένα απο κάθε module. Το patchαραν και έστρωσε θεωρητικά.

BTW ωραία το έψαξες, αλλά κόψε τις ####κίες τώρα εν όψη Πανελληνίων και κάτσε διάβασε. Ψάχνεις ότι θες μετά τον Ιούνιο.

Βασικά όλα αυτά υπάρχουν στο διαδίκτυο.

Αυτό το δεν υπάρχει που διάβασα στην αρχή.....

Οκ μπράβο στο παιδί για τον κόπο του αλλά δεν ανακάλυψε τον τροχό ;)

  • Like 1
Δημοσ. (επεξεργασμένο)
4 ώρες πριν, james rod είπε

ωραια το εψαξες αλλα το πρωτο λαθος που κανεις ειναι να νομιζεις οτι οι πυρηνες του piledriver λειτουργουν ταυτοχρονα κατι που δεν γινεται αφου δεν ειναι smt.

branch prediction ειναι πολυ πισω η amd απο την ιντελ, τουλαχιστον μεχρι εκεινη την εποχη. αν και δε νομιζω οτι και σημερα εχει αλλαξει και πολυ αυτο. θα υπαρχει μεν βελτιωση αλλα ποσο ακριβως δεν ξερω. αν κρινουμε παντως απο το spec ειναι πισω και αποτυπωνεται στο συνολικο σκορ.

ουσιαστικα εκλεισες το multithreading  σεναριο και εκμεταλλευτηκες ολη την cache που αν θυμαμαι καλα πρεπει να ειναι exclusive. ενω το δευτερο μεγαλυτερο προβλημα ειναι οτι η l1i μοιραζεται τα δυο cores με 64kb(shared), ενω και η l2 κανει αντιστοιχα το ιδιο ενω για να αποδοσει πιο σωστα επρεπε να ειναι private και οι δυο, μια μικρη για καθε πυρηνα οπως εχει το ζεν ή η ιντελ. εχουν γραφτει καμια δεκαρια σελιδες για τον buldozer αλλα και για τον sandy απο τον καντερ.

https://www.realworldtech.com/bulldozer/

Mα ταυτοχρονα λειτουργει ενα Module. Το CMT ειναι το hardware implementation του SMT. 

4 ώρες πριν, adtakhs είπε

Κώστα, αυτά είναι ψιλογνωστά.

Το προβλημα ομως βλεπεις οτι δεν λυθηκε. Ο branch predictor παρεμεινε ενας για καθε module, οποτε υποθετω οτι θα αντιμετωπιζει η αρχιτεκτονικη το ιδιο θεμα, αν και σε μικροτερη κλιμακα αφου εχει βελτιωμενο fetch/decode

 

3 ώρες πριν, ~Palpatin~ είπε

Βασικά όλα αυτά υπάρχουν στο διαδίκτυο.

Αυτό το δεν υπάρχει που διάβασα στην αρχή.....

Οκ μπράβο στο παιδί για τον κόπο του αλλά δεν ανακάλυψε τον τροχό ;)


Και απαντωντας και στον Palpatin μαζι, εχω να πω πως πουθενα δεν εχω βρει το θεμα με τον branch predictor αλλα ουτε και με την περιεργη συμπεριφορα λογο (cache?) η οτιδηποτε αλλο φταιει. 
Αν εχεις καποια πηγη που εστω και να τα αναφερει σε παρακαλω δειξτην και σε εμενα. Ειδικα με για το τελευταιο θεμα, το οποιο δεν μπορω να βρω γιατι υπαρχει.

Παρεμπιπτοντως φαινεται πως το θεμα ισχυει ακομα και σε συνθετικο φορτιο. Τρεχω με affinity σε core 0, 2, 4, 6
29943053_831621683688470_2116771770_o.png?_nc_cat=0&oh=b03d0728b512d8daf2461ed8434727f2&oe=5AC174EB

Επεξ/σία από kostas_anes
Δημοσ.
22 λεπτά πριν, kostas_anes είπε

Mα ταυτοχρονα λειτουργει ενα Module. Το CMT ειναι το hardware implementation του SMT. 

Το προβλημα ομως βλεπεις οτι δεν λυθηκε. Ο branch predictor παρεμεινε ενας για καθε module, οποτε υποθετω οτι θα αντιμετωπιζει η αρχιτεκτονικη το ιδιο θεμα, αν και σε μικροτερη κλιμακα αφου εχει βελτιωμενο fetch/decode


Και απαντωντας και στον Palpatin μαζι, εχω να πω πως πουθενα δεν εχω βρει το θεμα με τον branch predictor αλλα ουτε και με την περιεργη συμπεριφορα λογο (cache?) η οτιδηποτε αλλο φταιει. 
Αν εχεις καποια πηγη που εστω και να τα αναφερει σε παρακαλω δειξτην και σε εμενα. Ειδικα με για το τελευταιο θεμα, το οποιο δεν μπορω να βρω γιατι υπαρχει.

Κώστα πολύ ευχαρίστως φίλε μου αλλά έχει περάσει και αρκετός καιρός.

Πάντως ενημερωτικά σε πολλά benchmark στο HWBot έκανα χρήση όλων αυτών των "τρικ".

Anyway όπως είπα καλά έκανες και το έψαξες. 

Ίσως τώρα κατάλαβες γιατί οι FX δεν τραβούσαν αρκετά, όχι ότι δεν είχαν σχεδιαστικά λαθοι.

Το έχω γράψει άπειρες φορές, οι FX ήταν ένα στοίχημα που όχι απλά έχασε η AMD αλλά την σημάδεψε μπορώ να πω.

ΕΑΝ το software ήταν γραμμένο πάνω στο hardware της βέβαια θα ήταν εντελώς διαφορετικά τα αποτελέσματα αλλά δεν ήταν ;)

4 ώρες πριν, james rod είπε

ωραια το εψαξες αλλα το πρωτο λαθος που κανεις ειναι να νομιζεις οτι οι πυρηνες του piledriver λειτουργουν ταυτοχρονα κατι που δεν γινεται αφου δεν ειναι smt.

branch prediction ειναι πολυ πισω η amd απο την ιντελ, τουλαχιστον μεχρι εκεινη την εποχη. αν και δε νομιζω οτι και σημερα εχει αλλαξει και πολυ αυτο. θα υπαρχει μεν βελτιωση αλλα ποσο ακριβως δεν ξερω. αν κρινουμε παντως απο το spec ειναι πισω και αποτυπωνεται στο συνολικο σκορ.

ουσιαστικα εκλεισες το multithreading  σεναριο και εκμεταλλευτηκες ολη την cache που αν θυμαμαι καλα πρεπει να ειναι exclusive. ενω το δευτερο μεγαλυτερο προβλημα ειναι οτι η l1i μοιραζεται τα δυο cores με 64kb(shared), ενω και η l2 κανει αντιστοιχα το ιδιο ενω για να αποδοσει πιο σωστα επρεπε να ειναι private και οι δυο, μια μικρη για καθε πυρηνα οπως εχει το ζεν ή η ιντελ. εχουν γραφτει καμια δεκαρια σελιδες για τον buldozer αλλα και για τον sandy απο τον καντερ.

https://www.realworldtech.com/bulldozer/

 Αυτή την στιγμή έχει καλύτερο branch η AMD και βελτίωσε ακόμη και αυτό που οι περισσότεροι έλεγαν ότι δεν μπορεί να γίνει, το 90-92% cache missed που κατάφεραν στην Intel.

Στα σκορ αποτυπώνεται ένα γενικό συνολικό σκορ.

Στα ίδια ρολόγια στα περισσότερα σενάρια είναι γρηγορότερη και δεν βάζω στην εξίσωση ότι όλα σχεδόν τα προγράμματα χρησιμοποιούν τον compiler της Intel.

Το αναφέρω γιατί το ότι δεν το έχουν καραμέλα πλέον δεν παύει να μετράει στα αρνητικά, απλά η ψαλίδα έκλεισε τόσο και πολλές φορές βγαίνει και από πάνω πλέον που δεν αναφέρεται συχνά πυκνά :)

Δημοσ.
19 ώρες πριν, kostas_anes είπε

Mα ταυτοχρονα λειτουργει ενα Module. Το CMT ειναι το hardware implementation του SMT. 

Το προβλημα ομως βλεπεις οτι δεν λυθηκε. Ο branch predictor παρεμεινε ενας για καθε module, οποτε υποθετω οτι θα αντιμετωπιζει η αρχιτεκτονικη το ιδιο θεμα, αν και σε μικροτερη κλιμακα αφου εχει βελτιωμενο fetch/decode


Και απαντωντας και στον Palpatin μαζι, εχω να πω πως πουθενα δεν εχω βρει το θεμα με τον branch predictor αλλα ουτε και με την περιεργη συμπεριφορα λογο (cache?) η οτιδηποτε αλλο φταιει. 
Αν εχεις καποια πηγη που εστω και να τα αναφερει σε παρακαλω δειξτην και σε εμενα. Ειδικα με για το τελευταιο θεμα, το οποιο δεν μπορω να βρω γιατι υπαρχει.

Παρεμπιπτοντως φαινεται πως το θεμα ισχυει ακομα και σε συνθετικο φορτιο. Τρεχω με affinity σε core 0, 2, 4, 6
29943053_831621683688470_2116771770_o.png?_nc_cat=0&oh=b03d0728b512d8daf2461ed8434727f2&oe=5AC174EB

 

19 ώρες πριν, kostas_anes είπε

Mα ταυτοχρονα λειτουργει ενα Module. Το CMT ειναι το hardware implementation του SMT. 


29943053_831621683688470_2116771770_o.png?_nc_cat=0&oh=b03d0728b512d8daf2461ed8434727f2&oe=5AC174EB

δεν υπαρχει στην αρχιτεκτονικη υπολογιστων cluster mt, εκτος αν η amd εννοει με το c coarse grained. δεν λειτουργουν παραλληλα, εναλαγη των threads γινεται, φυσικα εμεις δε το καταλαβαινουμε γιατι γινεται ταχυτατα(ms), ανα εντολες(1000 πχ) ή οταν στολαρει(λεπτοκοκο) αλλαζει το thread.

19 ώρες πριν, ~Palpatin~ είπε

Κώστα πολύ ευχαρίστως φίλε μου αλλά έχει περάσει και αρκετός καιρός.

Πάντως ενημερωτικά σε πολλά benchmark στο HWBot έκανα χρήση όλων αυτών των "τρικ".

Anyway όπως είπα καλά έκανες και το έψαξες. 

Ίσως τώρα κατάλαβες γιατί οι FX δεν τραβούσαν αρκετά, όχι ότι δεν είχαν σχεδιαστικά λαθοι.

Το έχω γράψει άπειρες φορές, οι FX ήταν ένα στοίχημα που όχι απλά έχασε η AMD αλλά την σημάδεψε μπορώ να πω.

ΕΑΝ το software ήταν γραμμένο πάνω στο hardware της βέβαια θα ήταν εντελώς διαφορετικά τα αποτελέσματα αλλά δεν ήταν ;)

 Αυτή την στιγμή έχει καλύτερο branch η AMD και βελτίωσε ακόμη και αυτό που οι περισσότεροι έλεγαν ότι δεν μπορεί να γίνει, το 90-92% cache missed που κατάφεραν στην Intel.

Στα σκορ αποτυπώνεται ένα γενικό συνολικό σκορ.

Στα ίδια ρολόγια στα περισσότερα σενάρια είναι γρηγορότερη και δεν βάζω στην εξίσωση ότι όλα σχεδόν τα προγράμματα χρησιμοποιούν τον compiler της Intel.

Το αναφέρω γιατί το ότι δεν το έχουν καραμέλα πλέον δεν παύει να μετράει στα αρνητικά, απλά η ψαλίδα έκλεισε τόσο και πολλές φορές βγαίνει και από πάνω πλέον που δεν αναφέρεται συχνά πυκνά :)

στο σκορ δεν αποτυπωνεται ενα γενικο συνολικο σκορ αλλα ενα σκορ που βγαινει μεσα απο διαφορα bench που χρησιμοποιουν branch δηλαδη ενα προγαμμα θα εχει 7% και ενα αλλο 25%.τρεχουν διαφορα τετοια - πανω απο 10 - και βγαινει ενας μεσος ορος.

 

Δημοσ.

Το παράδειγμα σου ισχύει σε ορισμένες περιπτώσεις ναι, στο CB όμως όχι.

Αν τώρα θέλεις να μου πεις για άλλα πολύ ευχαρίστως να γράψεις και να σου απαντήσω για το καθένα ;)

Θέλεις να πάμε σε 3DMark πχ να γελάσουμε; Εκεί και αν γίνεται του κλεψαντος στο DX12, γιατί πολύ απλά η Χ εταιρεία δεν μπορεί να ακολουθήσει!!

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

  • Like 1

Δημιουργήστε ένα λογαριασμό ή συνδεθείτε για να σχολιάσετε

Πρέπει να είστε μέλος για να αφήσετε σχόλιο

Δημιουργία λογαριασμού

Εγγραφείτε με νέο λογαριασμό στην κοινότητα μας. Είναι πανεύκολο!

Δημιουργία νέου λογαριασμού

Σύνδεση

Έχετε ήδη λογαριασμό; Συνδεθείτε εδώ.

Συνδεθείτε τώρα
  • Δημιουργία νέου...