PCTBENCH 200412 - Οι μετρήσεις εδώ!

[DarthMoul]

Όπως διαβάσατε και στην ανακοίνωση του circular, με αυτήν την έκδοση του pctbench έχουμε αρκετές προσθήκες:

Κατ’ αρχήν οι παράμετροι –p και –t ισχύουν όπως ακριβώς τις ξέρετε. Με αυτό το bench μετράγαμε την δύναμη της FPU και την απόδοση του multithreading στους P4 όταν τα threads διεκδικούσαν τον ίδιο πόρο (δηλαδή την FPU).

Η παράμετρος –c υπολογίζει το TCP/IP checksum όπως αυτό περιγράφεται από το RFC, δηλαδή με 16 bits βήμα. Επιπλέον όμως κάνει υπολογισμούς με 32 bits βήμα αλλά και με 64 bits όπου αυτό υποστηρίζεται. Έτσι θα μπορέσουμε να μετρήσουμε την συμπεριφορά του Athlon 64 με native 64 bits κώδικα στο userspace αλλά και κατά πόσον οι compilers παράγουν αποδοτικό 64μπιτο κώδικα.

Η παράμετρος –x εκτελεί εν παραλλήλω με χρήση POSIX threads έναν υπολογισμό του π με taylor για 9 ψηφία ακρίβεια και ένα υπολογισμό του TCP/IP checksum με 32 bits. Εδώ θα δούμε κατά πόσον το Hyperthreading αποδίδει όταν τα threads διεκδικούν διαφορετικούς πόρους.

Η παράμετρος -s ταξινομεί 5,000,000 κλειδιά των 16 bytes με τρεις τρόπους. Αρχικά με την συνάρτηση quicksort της C. Αμέσως μετά με two-array big-endian radix sort. Αυτός είναι ένας αλγόριθμος που παρουσίασε η IBM το 1923 μαζί με τον card sorter, μια συσκευή που ταξινομούσε καρτέλες. Τέλος με αναδρομικό little-endian radix sort.

Τέλος με την παράμετρο –a τρέχουμε όλα τα tests και αγνοούμε όλα τα παραπάνω. Αυτήν θα χρησιμοποιήσουμε περισσότερο όπως βλέπετε στο screenshot.

Η μέτρηση είναι από έναν Dual P3 στα 800 MHz με Windows 2000 Pro

[ThorLite]

Aπο τον Α64 τα αποτελεσματα στα 2.55GHz το κατεβασα γιατι αρχικα ολες οι εκδοσεις gcc κρασαρανε οταν πηγαινε στα 64Bit αλλα τελικα κρασαρουνε και τον P4 στο ιδιο σημειο......

[ThorLite]

Απο τον P4 στα 3.7GHz.......

[circular]

Ναι, η αλήθεια είναι οτι με το -α στα παραθύρια και μένα κρασάρουν τα gcc binaries πριν το τεστ με την ταξινόμηση, αλλά δεν κατάφερα να βρω καποιο bug στον κώδικα...

[KTM]

Κι απο μενα, με τον P4 3.550GHz

[bourlas]

το ιδιο και εδω πριν κανει το τελευταιο τεστ με -α κρασαρει
p42800@3600

[KTM]

Εγω πως γινεται και ειμαι πιο γρηγορος απο του ThorLite τον 3.7 ?
Που οφειλεται?

[ThorLite]

To δικο μου δεν ηταν idle καθως ειναι και ο server και κατεβαζει και ισως το ποιο σημαντικο οι μνημες,μια και το χαμηλωσα γιατι κολλαγε το prg αν και δεν εφταιγαν τα PC τελικα,που τις εχω ασυγχρονα χαμηλωσανε πολυ.....

[KTM]

οκ man. ;)

[DarthMoul]

Το είδα και εγώ το crash με gcc στα windows. Αφού το πρόγραμμα δουλεύει με τον msvc και τον icc και τον gcc σε linux, σίγουρα δεν έχει πρόβλημα ο κώδικας. Το Βinary που παράγει ο gcc για windows είναι προβληματικό. Θα πάω να καταχωρήσω το bug και θα το έχουμε στα υπόψην για το μέλλον.
Συγγνώμη παιδιά αλλά το έχει η μοίρα μου ότι bug κυκλοφορεί στον πλανήτη να κρασσάρει τον δικό μου κώδικα. Ανάλογο πρόβλημα με αυτήν την έκδοση του pctbench βρήκα στον compiler του sco unix 5.0.5 και στις βιβλιοθήκες του Tru64 5.1B. Γενικότερα ότι bug υπάρχει στο σύστημα εμφανίζεται πάντα στις overoptimized εφαρμογές.

ΥΓ. Ο κώδικας που παράγει ο icc τρέχει καλύτερα στον Athlon XP και Athlon64
απ' ότι ο κώδικας που παράγει o gcc. Η AMD τον χρησιμοποιεί και στα spec submition. Οπότε δεν υπάρχει πρόβλημα.

[DarthMoul]

Αυτό είναι από έναν dual opteron στα 2.2 GHz με 100% load και linux. Προσέξτε την διαφορά μεταξύ 32 και 64 bits στον υπολογισμό του TCP/IP checksum

[DarthMoul]

Εδώ είναι ένας P4 στα 3.0 GHz με HT και Win XP Pro, 0% load. Εδώ φαίνεται να έχουμε διαφορετική συμπεριφορά. Στα 32 bits ο P4 αργεί περισσότερο από ότι στα 16 bits :022:

Το Hyperthreading φαίνεται να συμφέρει μόνο όταν τα δύο threads ΔΕΝ διεκδικούν τον ιδιο πόρο. Κερδίζουμε κάπου στο 30%. Όταν όμως διεκδικούν τον ίδιο πόρο (πχ την FPU) το κέρδος είναι μηδενικό ή έχουμε και επιβάρυνση όπως φαίνεται και στο δεύτερο screen shot.

[KTM]

Το Hyperthreading φαίνεται να συμφέρει μόνο όταν τα δύο threads ΔΕΝ διεκδικούν τον ιδιο πόρο. Κερδίζουμε κάπου στο 30%
Αυτο το κερδος το εχω διαπιστωσει δουλευοντας seti η folding.(με 2 κονσολες)
Τι θα γινοταν στην περιπτωση που δουλευα 1 κoνσολα με απενεργοποιημενο το HT?
Ποσο % απο το κερδος που εχω με το HT ενεργο θα εχανα?

[DarthMoul]

Αυτο το κερδος το εχω διαπιστωσει δουλευοντας seti η folding.(με 2 κονσολες)
Τι θα γινοταν στην περιπτωση που δουλευα 1 κoνσολα με απενεργοποιημενο το HT?
Ποσο % απο το κερδος που εχω με το HT ενεργο θα εχανα? To pctbench γι αυτό υπάρχει.
Κάνε ένα test με HT enabled και disabled και ποστάρισε και τα δύο να τα δούμε όλοι.

[KTM]

οκ, νομιζα οτι ηδη το ξερεις.

[DarthMoul]

Μια και το ζήτησε ο φίλος μου ο ΚΤΜ, εδώ είναι οι μετρήσεις από εναν P4 στα 3 GHz. Η πρώτη είναι με Hyperthreading και η δεύτερη χωρίς. Το κέρδος με Hyperthreading είναι σαφές στο combined benchmark που τρέχει με δύο threads.
Κρίμα που ο P4 έχει τόσο καχεκτική FPU. Ίσως θα ήταν καλή ιδέα κάποια στιγμή η Intel να προσθέσει και δεύτερη ώστε στις multithreaded εφαρμογές να φτάσει τις επιδόσεις της FPU του Athlon64 και να πάρει σαφές προβάδισμα στις overall επιδόσεις. Αλλά μάλλον τεχνικά είναι πολύ δύσκολο να γίνει.

[KTM]

Ευχαριστω πολυ DarthMoul. ;)

[DarthMoul]

Υπάρχει κανείς με Athlon64 και linux να τρέξει το bench; Εγώ έχω πρόσβαση σε δύο dual opteron 248 αλλά δεν τους βρίσκω εύκολα idle για να τους μετρήσω σωστά. Αν έχει κάποιος την καλοσύνη ας κάνει μια μέτρηση και ας ποστάρει εδώ το αποτέλεσμα.

[DarthMoul]

Ας υποθέσουμε ότι έχουμε δύο συστήματα με την ίδια CPU αλλά διαφορετικής συχνότητας. Το ένα με συχνότητα 1 GHZ και το άλλο με συχνότητα 2 GHz.

Υποθέτοντας ότι ένα συγκεκριμένο task στον μικρό (στο 1 GHz) διαρκεί 10 sec, για να έχουμε κλιμάκωση 1:1 θα πρέπει στο μεγάλο να διαρκέσει 10/2 sec δηλαδή 5 sec.

Αν μετρώντας βρούμε πως τελικά το μεγάλο χρειάζεται 7 sec για να ολοκληρώσει το task τότε για να βρούμε την κλιμάκωση θα πρέπει να υπολογίσουμε την παράσταση:

(10/2) / 7. To οποίο μας δίνει 0,71. Συνεπώς ο τύπος της κλιμάκωσης είναι

S = (T0 / F1) / T1

όπου Τ0 ο χρόνος που έκανε το μικρό, F1 η συχνότητα του μεγάλου σε GHz και Τ1 ο χρόνος που έκανε το μεγάλο.

Αντίστοιχα όταν κάνετε overclocking μπορείτε να υπολογίσετε την κλιμάκωση πριν και μετά την αύξηση της συχνότητας. Το ζουμί είναι στο S. Όταν αυτό είναι μεγαλύτερο από το 1, τότε χαράς ευαγγέλια αφού από την αύξηση της συχνότητας κερδίζουμε μεγαλύτερο ποσοστό σε επιδόσεις. Αντίστροφα όταν το S είναι μικρότερο από το 0, τότε η αύξηση της συχνότητας δεν αποδίδει και τόσο πολύ. Πάμε να δούμε παράδειγμα

[DarthMoul]

Εδώ είναι οι μετρήσεις από το pctbench για δύο συστήματα. Το πρώτο στο 1 GHz και το δεύτερο στο 1.4 GHz.

[DarthMoul]

Παμε τώρα να βγάλουμε το scaling για τα δύο παραπάνω και να εξηγήσουμε τι σημαίνει το καθένα σε σχέση με την συχνότητα πάντα:

Taylor pi: 0,99. Εδώ βλέπουμε την συμπεριφορά της FPU.

16 bit checksum: 0,99. Η απόδοση της ALU στα 16 bits και του L1 cache.

32 bit checksum: 0,99. Το ίδιο με το παραπάνω αλλά στα 32 bits.

Combined bench: 1,15. Η απόδοση όταν κάνουμε Multithreading. Αν έχουμε SMP σύστημα τότε δείχνει την συμπεριφορά του NUMA.

Quicksort: 0,93. Η ποιότητα της βιβλιοθήκης του compiler και η απόδοση της μνήμης και του cache.

Bigendian Radix Sort: 0.70. Η αποτελεσματικότητα της μνήμης και του cache ΜΟΝΟ.

Little Endian Radix Sort: 1.20. Η αποτελεσματικότητα των προγραμμάτων που γράφει ο Darth Moul :p Όπως είχαμε πει και παλιά, τα καλογραμμένα overengineered, overoptimized προγράμματα έχουν πολύ καλύτερο frequency scaling από τα άλλα, με αποτέλεσμα να κάνουν πιο αποδοτική και την αναβάθμιση και το overclocking.

[SLN]

Darth,
Εμενα μετα το σημειο που βλεπεις μου κρασαρει το προγραμμα και με πεταει εξω.
Κλασσικο παραθυρακι "...has performed an illegal operation and will be shut down". Το εκανε και σε περιβαλλον 2000 και σε ΧΡ. Τρεχω το προγραμμα για Αθλον ΧΡ...
Ειναι φυσιολογικο γιατρε??

[DarthMoul]

Darth,
Εμενα μετα το σημειο που βλεπεις μου κρασαρει το προγραμμα και με πεταει εξω.
Κλασσικο παραθυρακι "...has performed an illegal operation and will be shut down". Το εκανε και σε περιβαλλον 2000 και σε ΧΡ. Τρεχω το προγραμμα για Αθλον ΧΡ...
Ειναι φυσιολογικο γιατρε?? Είναι bug του gcc για windows. Δοκίμασε με τα binaries που είναι από msvc ή από icc. Αν θέλεις υποχρεωτικά gcc θα πρέπει να πας από linux. Sorry παιδιά αλλά δεν είναι δικό μου το bug και δεν μπορώ να το φτιάξω :017:

[SLN]

Χμμ μαλλον εχει ξαναναφερθει το προβλημα... Σορρυ για την επαναληψη.

Ετρεξα το blended msvc...
Αγριο sex!! Πρεπει να σας κερδισα ολους...
Το συστημα παραμενει το ιδιο με την προηγουμενη φωτο.
Ειχα κι ενα mozilla απο πισω αλλα δεν μασησε φανταζομαι το bench!!

[DarthMoul]

Χμμ μαλλον εχει ξαναναφερθει το προβλημα... Σορρυ για την επαναληψη.

Ετρεξα το blended msvc...
Αγριο sex!! Πρεπει να σας κερδισα ολους...
Το συστημα παραμενει το ιδιο με την προηγουμενη φωτο.
Ειχα κι ενα mozilla απο πισω αλλα δεν μασησε φανταζομαι το bench!! Αν και εδώ δεν είναι κόντρα, έχεις πολύ καλούς χρόνους!
Τρέξε και το msvc-ppro23. Θα σου δώσει μάλλον καλύτερους χρόνους.

[MrSeanKon]

Αργησα αλλα ηρθα κι εγω.......
Βασικα εκανε συμπιεση βιντεο εκεινη τη στιγμη αλλα το εθεσα σε Low Priority βεβαια το Bench του Darth τρεχει σε Normal τεσπα....
Δεν εκανα καμμια μεταγλωττιση απλα ετρεξα το gcc-athlon4 σωστα μεχρις εδω?? :105:
Ειναι αναγκαιο αυτο να γινει γιατι μπερδευτηκα οταν διαβασα ολα εκεινα που λες δεν εχω και μυαλο να συγκεντρωθω εχω τρεξιμο...
32bit Παραθυρα εχω δεν παιζει να βαλω τα 64βιτ παλι εχω ενα δισκο κι ειναι ολο ροζ δε παιζει να μπει αλλο παρτισιον παλι.
Ισως το κανω στο μελλον αλλα θα δουμε.......

Θα σου προτεινα να βαλεις ενα παουζ στην αρχη να εκτυπωνει ενα μυνημα να βαζουμε High Priority μεσω Τασκ Μανατζερ.
Επισης επιεδη βαριομουνα να το τρεχω μεσω κω*οΜΣΔΟΣ παραθυρο εφτιαξα εγω κατι εξτρα και το ετρεξα με ενα απλο κλικ......... :p
Απλα χαμηλωσα κατα 1MHz FSB την ταχυτητα φοβηθηκα μη γινει κανενα χοντρο κολλημα και μετα τζαμπα χρονος βιντεοσυμπιεσης.......

Darth το greeklish μυνημα απευθυνεται στο δημιουργο του εξτρα MSDOS προγραμματος δηλαδη στον υποφαινομενο. :082: :003: :080:

[DarthMoul]

Αργησα αλλα ηρθα κι εγω.......
Βασικα εκανε συμπιεση βιντεο εκεινη τη στιγμη αλλα το εθεσα σε Low Priority βεβαια το Bench του Darth τρεχει σε Normal τεσπα....
Δεν εκανα καμμια μεταγλωττιση απλα ετρεξα το gcc-athlon4 σωστα μεχρις εδω?? :105:
Ειναι αναγκαιο αυτο να γινει γιατι μπερδευτηκα οταν διαβασα ολα εκεινα που λες δεν εχω και μυαλο να συγκεντρωθω εχω τρεξιμο...
32bit Παραθυρα εχω δεν παιζει να βαλω τα 64βιτ παλι εχω ενα δισκο κι ειναι ολο ροζ δε παιζει να μπει αλλο παρτισιον παλι.
Ισως το κανω στο μελλον αλλα θα δουμε.......

Θα σου προτεινα να βαλεις ενα παουζ στην αρχη να εκτυπωνει ενα μυνημα να βαζουμε High Priority μεσω Τασκ Μανατζερ.
Επισης επιεδη βαριομουνα να το τρεχω μεσω κω*οΜΣΔΟΣ παραθυρο εφτιαξα εγω κατι εξτρα και το ετρεξα με ενα απλο κλικ......... :p
Απλα χαμηλωσα κατα 1MHz FSB την ταχυτητα φοβηθηκα μη γινει κανενα χοντρο κολλημα και μετα τζαμπα χρονος βιντεοσυμπιεσης.......

Darth το greeklish μυνημα απευθυνεται στο δημιουργο του εξτρα MSDOS προγραμματος δηλαδη στον υποφαινομενο. :082: :003: :080: Για να τα βάλουμε στην σειρά ένα ένα.

Στην επόμενη έκδοση θα προσθέσω μία παράμετρο (πχ -w) που θα κάνει pause στην αρχή για όποιον την χρειάζεται.

Οι gcc εκδόσεις δεν θα τρέξουν σε windows τα sort benchmarks λόγω bug που έχει ο gcc 3.3.3. Γι αυτό δεν μπορώ να κάνω τίποτα. Έκανα καταχώρηση του bug στην gnu και ίσως το φτιάξουν μέχρι την επόμενη έκδοση.

Καλύτερα παίξε με κάποια έκδοση που να είναι icc ή msvc. Πχ win32-icc-piv.exe ή win32-msvc-ppro23. Δοκίμασε και τις δύο να δεις ποια σου δίνει καλύτερα αποτελέσματα. Οι εκδόσεις που γράφουν blended είναι ουσιαστικά για pentium και δεν έχουν κανένα optimization (εκτός από τα λίγα που έχω βάλει εγώ στον κώδικα μου).

Win64 έκδοση δεν υπάρχει ακόμα αφού δεν έχω ούτε win64, ούτε compiler και δεν χαραμίζω έναν dual opteron στον οποίο έχω πρόσβαση για να τρέχει βλακείες. Αν θέλεις να τρέξει το 64 μπιτο bench, χρειάζεσαι linux x86-64 port όπως αυτό που φαίνεται εδώ: http://www.pctechnology.gr/vbull/vb/attachment.php?attachmentid=2341

Κάθε bench από τα τέσσερα στρεσσάρει και μετράει κάτι διαφορετικό. Κοίτα παραπάνω στο post για το frequency scaling που εξηγώ στο τέλος τι ακριβώς μετράει το καθένα. Κάποια σε ενδιαφέρουν για το oc που κάνεις και κάποια άλλα λιγότερο.

Για όποια διευκρίνηση, απορία ή πρόταση εδώ είμαστε :001:

[circular]

Να και μερικα αποτελεσματα απο SuSE 9.0 / gcc 3.3.1

[DarthMoul]

Όταν λέμε η απόδοση των 64 bits σε σχέση με τα 32 bits εννοούμε πόσο κέρδος (ή ζημιά) θα έχουμε από την χρήση τους εξαιτίας του hardware αλλά και εξαιτίας της ποιότητας του κώδικα που παράγει ο compiler.

Για να βγάλουμε τα πλεόν ασφαλή συμπεράσματα με το pctbench θα πρέπει να μετρήσουμε πάντα κάτω από το ίδιο φορτίο, με τον ίδιο compiler, μία φορά με την blended έκδοση που δεν έχει κανένα optimization, και μια φορά με την έκδοση που είναι optimized για την CPU μας. Το benchmark που θα χρησιμοποιήσουμε είναι αυτό που υπολογίζει το TCP/IP checksum με 16, 32 και 64 bits βήμα (παράμετρος -c).

Εδώ θα συγκρίνουμε τρεις 64 bit πλατφόρμες. Έναν Opteron στα 2.2 GHz, έναν Itanium 2 στα 1.4 GHz και έναν Alpha ev68 στο 1 GHz.

Τα screenshots που ακολουθούν είναι με την blended έκδοση του pctbench από τον gcc και με την σειρά που τα αναφέρω πιο πάνω δηλαδή Opteron, Itanium και Alpha.

[DarthMoul]

Εδώ με την ίδια σειρά βλέπουμε τις μετρήσεις από τις optimized εκδόσεις του pctbench, πάντα από τον gcc. Όλες οι μετρήσεις σε όλες τις περιπτώσεις έγιναν κάτω από φορτίο 100%.

Οι μετρήσεις για τον Opteron και τον Itanium έγιναν σε linux ενώ για τον Alpha σε tru64 unix.

ΥΓ. Όπως έλεγε κάποτε και η διαφήμηση:
"Nothing runs faster than Tru64 on Alpha" :029:

[DarthMoul]

Και αυτό είναι από έναν dual opteron 242 στο 1.6 GHz w2k pro.

[MrSeanKon]

DarthMoul θα σου δειξω δυο post με το Celeron 2.4GHz (18 X 133 μαμισια) ο οποιος ηταν πουσαρισμενος στα 18 Χ 200 = 3.6GHz.
Οπως ξερεις τραβαω εντονα ζορια οποτε να εισαι υπομονετικος θα σου στειλω μετρησεις και με τον Prescott για να δουμε ποσο επηρεαζει η cache το αποτελεσμα 256ΚΒ vs 1MB

[DarthMoul]

DarthMoul θα σου δειξω δυο post με το Celeron 2.4GHz (18 X 133 μαμισια) ο οποιος ηταν πουσαρισμενος στα 18 Χ 200 = 3.6GHz.
Οπως ξερεις τραβαω εντονα ζορια οποτε να εισαι υπομονετικος θα σου στειλω μετρησεις και με τον Prescott για να δουμε ποσο επηρεαζει η cache το αποτελεσμα 256ΚΒ vs 1MB
Με δεδομένη την διαφορά τιμής, μόλις έσκισες έναν dual opteron 242.
Σε πέρασα μόνο στο multithreading λόγω 2 CPU και στο bigendian radix sort λόγω hypertransport. Στα υπόλοιπα με πάτσισες ή με έσκισες. Μήπως έπρεπε να πάρω Celeron;

[MrSeanKon]

Στρατηγε τι να σου πω τωρα.... :003:
O Celeron τα αξιζει με το παραπανω τα λεφτα του.
Φαντασου οτι δεν εχω στησει επανω την υδροψυξη οποτε θα ανεβαινε κοντα στα 4 γιγα....
Παντως στον DrDivX ο P4 ειναι καπου +20% γρηγοροτερος απο το Σελερον για να δουμε ποσο τελικα θα ειναι στο δικο σου benchmark. :017:

[DarthMoul]

Στρατηγε τι να σου πω τωρα.... :003:
O Celeron τα αξιζει με το παραπανω τα λεφτα του.
Φαντασου οτι δεν εχω στησει επανω την υδροψυξη οποτε θα ανεβαινε κοντα στα 4 γιγα....
Παντως στον DrDivX ο P4 ειναι καπου +20% γρηγοροτερος απο το Σελερον για να δουμε ποσο τελικα θα ειναι στο δικο σου benchmark. :017:
Εδώ http://www.pctechnology.gr/vbull/vb/showthread.php?t=4654&page=2&pp=20
από το post #25 και κάτω κοντράρω ένα Dual Xeon στα 3.2 GHz. Κοίταξε το και πες μου. Μήπως θα πρέπει η Intel να κάνει discontinue τον Xeon και να βάλει στην θέση του Celeron; Τελικά βλέπεις την αξία των devtools; Ο icc κάνει τον celeron να πατάει κάτω ένα chip τετραπλάσιας αξίας. Δηλαδή αν έτρεχες linux με είχες φάει ζωντανό.

[MrSeanKon]

LOL DarthΜοul αυτα να τα πεις σε οσους θαβουν το Celeron.....
Η μονη ***** που εχει κανει η Intel ειναι οτι δεν ενσωματωσε το ΗΤ επανω του....
Αλλιως θα ηταν ακρως πολυ συμφερουσα αγορα.
Kαι φυσικα δε θα αγοραζα Prescott Ρ4 τοτε... :106:
Το γεγονος οτι ανεβαινει πολυ ψηλα οφειλεται στο χαμηλο FSB και το μεγαλο Multi που εχει αλλα αυτα θα τα πω αλλη φορα σε αλλο thread η ιστορια επαναλαμβανεται (βλεπε Celeron 300A, 333A). :030:

Χμ μπορεις να δειξεις τα αποτελεσματα αυτα στην Ιntel και να τους ανοιξεις τα ματια! :023:

[DarthMoul]

LOL DarthΜοul αυτα να τα πεις σε οσους θαβουν το Celeron.....
Η μονη ***** που εχει κανει η Intel ειναι οτι δεν ενσωματωσε το ΗΤ επανω του....
Αλλιως θα ηταν ακρως πολυ συμφερουσα αγορα.
Kαι φυσικα δε θα αγοραζα Prescott Ρ4 τοτε... :106:
Το γεγονος οτι ανεβαινει πολυ ψηλα οφειλεται στο χαμηλο FSB και το μεγαλο Multi που εχει αλλα αυτα θα τα πω αλλη φορα σε αλλο thread η ιστορια επαναλαμβανεται (βλεπε Celeron 300A, 333A). :030:

Χμ μπορεις να δειξεις τα αποτελεσματα αυτα στην Ιntel και να τους ανοιξεις τα ματια! :023:
Αυτά μην τα λες σε εμένα. Όταν όλοι σου έλεγαν πάρε Intel ή πάρε AMD εγώ σου είπα πρώτος πάρε Celeron! 478 είναι αυτοί; 1U rackmounts φτηνά όμως που θα βρω; 478 1U mb υπάρχουν σίγουρα γιατί έχω δεί στο top500 ότι έφτιαχναν clusters με P4/478.
Με 1500 ευρώ φτιάχνω 10 diskless celeron nodes. Άλλα τόσα για master node, rack και switches. Και κάπου 600-700 για UPS. Αν τα παραγγείλω όλα μαζί θα μου κάνουν και έκπτωση ίσως. Θα το προτείνω στην δουλειά να δούμε τι θα πουν.
:115:

Αν είναι μέχρι 4000 ευρώ μπορεί να το εγκρίνουν!

[MrSeanKon]

Darth εκανα αλλες δυο μετρησεις με το προγραμμα σου στον Ρ4 στα 3950MHz.
Ενα αντιγραφο ετρεξα την καθε φορα.
Αμα βρω κανεναν ξεκλειδωτο Barton τοτε θα σου στειλω κι αλλο υλικο.

[KTM]

Και απο μενα μια ακομα μετρηση για το αρχειο, με prescot στα 4.080Mhz

[DarthMoul]

Βλέπω τις μετρήσεις από τους P4 και σκέφτομαι ότι αν είχαν λίγο καλύτερη FPU, δεν θα υπήρχε ποτέ περίπτωση να αγοράσω Opteron. Ταξινομεί πάνω από 15Μ κλειδιά ανά δευτερόλεπτο. Εκπληκτική επίδοση. Θα την ζήλευαν πολύ ακριβότερα chips.

[axel]

Οριστε και οι μετρησεις απο ενα συστημα με CPU AMD64 3400+.
Η πρωτη εγινε σε περιβαλλον win xp 32 bit, ενω η δευτερη σε Linux και πιο συγκεκριμενα σε Fedora Core 3 64bit. Τα σχολια δικα σας.

[DarthMoul]

Μπράβο axel. Από τις πιο χρήσιμες μετρήσεις. Παραβάλει δύο λειτουργικά και δύο compilers στο ίδιο σύστημα :023: Βλέπω έκανες και το compile μόνος σου στο linux :)

Λοιπόν έχουμε και λέμε. Windows 32 bits με microsoft C vs Linux Fedora Core 3 64 bits με gcc.

Στο πρώτο τέστ που μετράμε καθαρά την FPU έχουμε:
Windows 8.22 seconds, Linux 10.44 seconds

Στο δεύτερο τεστ που μετράμε την ALU έχουμε:
16 bits: Windows 0 seconds, Linux 15.14 seconds.
32 bits: Windows 7.56 seconds, Linux 11.41 seconds.
64 bits: Windows τίποτα, Linux 26.55 seconds.

Στο τρίτο τεστ που μετράμε το multitasking:
Windows: expected 15.78 seconds, achieved 19.38 seconds.
Linux: expected 21.85 seconds, achieved 16.17 seconds.

Στο τέταρτο τεστ που μετράμε:
α) Την ποιότητα της βιβλιοθήκης του συστήματος με το quicksort:
Windows: 1.52 seconds, Linux: 5.77 seconds.
β) Το memory efficiency με το big-endian 2-array radix sort (hand optimized απο εμένα):
Windows: 2.84 seconds, Linux: 2.80 seconds.
γ) Το ψώνιο μου να γράφω overoptimized κωδικα :p με το little-endian recursive radix sort:
Windows: 0.86 seconds, Linux: 0.88 seconds.

Σε όσα τεστς έπαιζε ρόλο η ποιότητα του compiler και μόνο ο gcc ηττήθηκε κατά κράτος. Η ταχύτητα του κώδικα που παράγει ο gcc 3.4.x που χρησιμοποίησες είναι η μόνιμη αιτία γκρίνιας στο usenet εδώ και κάτι μήνες. Εγώ ακόμα χρησιμοποιώ τον 3.3.x που παράγει πολύ πιο γρήγορο κώδικα αλλά θα τον αλλάξω υποχρεωτικά γιατί έχει bugs που στον 3.4.x εχουν διορθωθεί.

Στο multitasking τα windows την πάτησαν άσχημα (αναμενόμενο) ενώ όπου είχα βάλει εγώ το χεράκι μου οι διαφορές ήταν αμελητέες. Πάντως αν έχεις την δυνατότητα να χρησιμοποιήσεις τον gcc 3.3.2 ή τον 3.3.4 θα δεις άλλα αποτελεσματα. Αλλιώς περίμενε για τον 3.5.0 που θα έχει ενσωματωμένο vectorizer όπως ο icc και λένε πως θα πηγαίνει πολύ καλύτερα.

[axel]

Πολυ ενδιαφερουσες οι παρατηρησεις σου DarthMoul! :038: Βγηκαν χρησιμα συμπερασματα απο τις μετρησεις και τα σχολια σου! Μολις κυκλοφορησει ο gcc 3.5 θα επανελθω με νεες μετρησεις για να δουμε τη διαφορα. Λογω των bugs του 3.3 δεν θελω να γυρισω προς τα πισω. Εις αναμονη του 3.5 λοιπον.

[DarthMoul]

Όχι ότι παίζει κανέναν ιδιαίτερο ρόλο, αλλά μια και έπεσε αυτό το τερατάκι στα χέρια μου είπα να μετρήσω το multithreading που μπορεί να κάνει. Λοιπόν έχουμε και λέμε: Για τον υπολογισμό του π με 9 ψηφία από τον taylor θέλει ακριβώς 0.2 sec :eek:

Εδώ είναι ο δικός dual opteron 242 στο 1.6 GHz για να έχουμε μέτρο σύγκρισης
http://www.pctechnology.gr/vbull/vb/attachment.php?attachmentid=2806

To μηχάνημα μου χρειάζεται μόνο 28 φορές περισσότερο χρόνο για να κάνει την ίδια δουλειά :p :p

[skouket]

processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 6
model name : Celeron (Mendocino)
stepping : 5
cpu MHz : 434.313
cache size : 128 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr
bogomips : 851.96


slackware 10.1 με πυρηνα 2.6.11.12
using the gcc compiler, version 3.3.4.
using the icc compiler, version 810.
icc-autodetected optimizations : -static -O3 -ipo -axKWNBP
gcc-slack : -O2 -march=i486 -mcpu=i686

Εχω κανει τα αποτελεσματα sort με αυξουσα σειρα :)

--> pi 8 digits

8.81 gcc-p4 + gcc-slack
8.82 icc-blended + gcc-blended
8.88 icc-auto + gcc-p3
9.06 gcc-p2


--> pi 9 digits

87.77 gcc-slack
87.93 ggc-p4
87.99 icc-blended
88.06 gcc-blended
88.49 gcc-p2
88.51 gcc-p3
88.55 icc-auto

--> pi 10 digits

877.17 gcc-slack
878.77 gcc-p4
880.06 icc-blended
880.33 gcc-blended
884.25 gcc-p2 + gcc-p3
885.04 icc-auto
--------------------------------------------------------------

(Sorting 5000000 keys, 16 bytes size each)

Standard C Library QuickSort

29.83 icc-auto
29.90 icc-blended
42.06 gcc-p2 + gcc-slack
42.07 gcc-p3
42.84 gcc-p4
46.34 gcc-blended

Big-endian two array Radix sort

21.54 icc-blended
21.68 icc-auto
23.90 gcc-p4
24.18 gcc-slack
24.82 gcc-p2
24.89 gcc-p3
36.93 gcc-blended

Little-endian recursive Radix sort

4.32 icc-auto
4.57 gcc-slack
9.34 icc-blended
10.64 gcc-p2 + gcc-p3
10.65 gcc-p4
14.63 gcc-blended
--------------------------------------------------------------

(Calculating the TCP/IP checksum for 8K buffer, 4000000 times)

16 bits. Checksum: 56010.

0 icc-auto
54.08 icc-blended
76.93 gcc-p2
76.94 gcc-p3
76.95 gcc-p4
96.33 gcc-slack
807.29 gcc-blended (!)


32 bits. Checksum: 56010.

47.94 icc-blended
48.15 icc-auto
78.81 gcc-p4
80.11 gcc-slack
83.08 gcc-p2 + gcc-p3
231.29 gcc-blended



Σχολια:
Αν και με autovectorization που εκανε ο icc για floating point πραξεις στον υπολογισμο του π δεν νικησε τον gcc κατα κρατος.
Στις sorting διαδικασιες και στα TCP/IP ο icc πηρε κεφαλι γενικα..

Αυτο που παρατηρω και χαιρομαι γι'αυτο ειναι οτι οι ρυθμισεις του slackware στον gcc αφηνουν πολυ καλα αποτελεσματα σε γενικο επιπεδο.Νομιζα οτι με "-march=i486 -mcpu=i686" θα εχανα σε επιδοσεις αλλα δεν συμβαινει κατι τετοιο.O Pat φαινεται οτι το εχει ψαξει παραπανω απο οτι φαινεται.Ετσι φαινεται ποσο καλη διανομη ειναι το slackware για παλια μηχανηματα γενικα..εκτος απο το οτι ειναι μια πορτα για γνωση στο λινουξ :)

Darthmoul γενικα οταν κανω compilation για να εχω μικροτερους χρονους compilation χρειαζομαι μια δυνατη ALU, FPU ή Vector Unit ?? καποιο συνδυασμο ή και τα τρια μαζι ???

[skouket]

Oσον αφορα το 1 bug που ειναι typo error για την εκδοση του λινουξ εχουμε για το αρχειο pctbench-mt.c :

line 93:Aν προσθεσουμε ενα '\n' μετα το "exiting" θα εχουμε καλυτερο αισθητικο αποτελεσμα

[DarthMoul]

Darthmoul γενικα οταν κανω compilation για να εχω μικροτερους χρονους compilation χρειαζομαι μια δυνατη ALU, FPU ή Vector Unit ?? καποιο συνδυασμο ή και τα τρια μαζι ???
Χρειάζεται να αφαιρέσεις όλα τα optimizations του compiler (-O0) και να τα κάνεις εσύ με το χέρι εκεί που πρέπει. Και γρήγορες μνήμες.

[skouket]

Απο ενα λαπτοπ μιας φιλης μου με Dothan στα 1.6Ghz.
Το λαπτοπ αυτο ειχε μονο windows-XP SP2 && all hotfixes μετα το SP2.
Χρησιμοποιησα τις τελευταιες pthread lirbraries για win32 που βρηκα στην redhat και οχι αυτες που ερχονται default μαζι με το pctbench.Δεν ξερω κατα ποσο επηρεαζει το αποτελεσμα αυτο εφοσον δεν χρησιμοποιησα πανω απο μια thread.



\bin>win32-msvc-pentium.exe -p 10 -c -s
PCTBENCH. Jul 2 2005.
Compiled for the x86 architecture with pentium optimizations
using the msvc compiler, version 1300.
Command line options: /O2 /Ox /G5
-Calculating pi:
Thread model: Single. No POSIX calls.
Thread # 0 starts from: 1 ends to: 20000000000
10 digits precision Pi:3.1415926535 Elapsed time: 196.72 seconds
-Calculating the TCP/IP checksum for 8K buffer, 4000000 times
16 bits. Checksum: 56010. Elapsed time: 0.00 seconds
32 bits. Checksum: 56010. Elapsed time: 18.14 seconds
64 bits not supported on this platform.
-Sorting 5000000 keys, 16 bytes size each:
Standard C Libary QuickSort. Elapsed time: 2.52 seconds
Big-endian two array Radix sort. Elapsed time: 3.22 seconds
Little-endian recursive Radix sort. Elapsed time: 0.89 seconds


\bin>win32-msvc-blended.exe -p 10 -c -s
PCTBENCH. Jul 2 2005.
Compiled for the x86 architecture with blended optimizations
using the msvc compiler, version 1300.
Command line options: None
-Calculating pi:
Thread model: Single. No POSIX calls.
Thread # 0 starts from: 1 ends to: 20000000000
10 digits precision Pi:3.1415926535 Elapsed time: 232.72 seconds
-Calculating the TCP/IP checksum for 8K buffer, 4000000 times
16 bits. Checksum: 56010. Elapsed time: 82.69 seconds
32 bits. Checksum: 56010. Elapsed time: 46.88 seconds
64 bits not supported on this platform.
-Sorting 5000000 keys, 16 bytes size each:
Standard C Libary QuickSort. Elapsed time: 2.97 seconds
Big-endian two array Radix sort. Elapsed time: 4.89 seconds
Little-endian recursive Radix sort. Elapsed time: 1.55 seconds


\bin>win32-msvc-ppro23.exe -p 10 -c -s
PCTBENCH. Jul 2 2005.
Compiled for the x86 architecture with ppro 2 and 3 optimizations
using the msvc compiler, version 1300.
Command line options: /O2 /Ox /G6
-Calculating pi:
Thread model: Single. No POSIX calls.
Thread # 0 starts from: 1 ends to: 20000000000
10 digits precision Pi:3.1415926535 Elapsed time: 196.70 seconds
-Calculating the TCP/IP checksum for 8K buffer, 4000000 times
16 bits. Checksum: 56010. Elapsed time: 0.00 seconds
32 bits. Checksum: 56010. Elapsed time: 18.55 seconds
64 bits not supported on this platform.
-Sorting 5000000 keys, 16 bytes size each:
Standard C Libary QuickSort. Elapsed time: 2.52 seconds
Big-endian two array Radix sort. Elapsed time: 3.14 seconds
Little-endian recursive Radix sort. Elapsed time: 0.83 seconds



Παραθετω και 2 screenshots απο το CPU-Z με πληροφοριες για τον επεξεργαστη και την μνημη.Η μητρικη εχει το 915 chipset.

YΓ: απο οτι βλεπω οι περισσοτεροι τρεχετε το -a οποτε θα δοκιμασω το βραδακυ -p 9 για να δωσω και αλλα αποτελεσματα , ωστε να μπορουμε να εχουμε καλυτερο μετρο συγκρισης..κατ'εμε οσο περισσοτερα ψηφια ακριβειας δινουμε τοσο καλυτερο συγκριτικο αποτελεσμα εχουμε.

[DarthMoul]

Καθόλου άσχημα για laptop CPU. Αν κοιτάξεις τις τρεις τελευταίες μετρήσεις με το sort και τις συγκρίνεις με τις άλλες πιο πάνω, μάλλον θα διαπιστώσεις ότι δύσκολα βρίσκεις καλό software γι αυτόν. Ο icc 8.1 έχει και Dothan specific optimizations. Θα φροντίσω να τα περιλάβω στην επόμενη έκδοση.

[skouket]

για το ιδιο μηχανημα στο παραπανω ποστ εχουμε:


\bin>win32-msvc-blended.exe -p 9

PCTBENCH. Jul 2 2005.
Compiled for the x86 architecture with blended optimizations
using the msvc compiler, version 1300.
Command line options: None
-Calculating pi:
Thread model: Single. No POSIX calls.
Thread # 0 starts from: 1 ends to: 2000000000
9 digits precision Pi:3.141592653 Elapsed time: 23.27 seconds

\bin>win32-msvc-pentium.exe -p 9

PCTBENCH. Jul 2 2005.
Compiled for the x86 architecture with pentium optimizations
using the msvc compiler, version 1300.
Command line options: /O2 /Ox /G5
-Calculating pi:
Thread model: Single. No POSIX calls.
Thread # 0 starts from: 1 ends to: 2000000000
9 digits precision Pi:3.141592653 Elapsed time: 19.67 seconds

\bin>win32-msvc-ppro23.exe -p 9
PCTBENCH. Jul 2 2005.
Compiled for the x86 architecture with ppro 2 and 3 optimizations
using the msvc compiler, version 1300.
Command line options: /O2 /Ox /G6
-Calculating pi:
Thread model: Single. No POSIX calls.
Thread # 0 starts from: 1 ends to: 2000000000
9 digits precision Pi:3.141592653 Elapsed time: 19.69 seconds


πολυ κακη η FPU του Pentium-M...απορω αυτοι σε κατι SPi και Pi βγαζουν καλυτερο χρονο με τον Pentium-M απο κατι AMD :042: :042:
Θελει σχεδον τον διπλασιο χρονο και απο τον Athlon XP του SLN στη προηγουμενη σελιδα. :039:

Λογικα με 2 threads οι διπυρηνοι της Intel θα φτανουν πανω κατω τους .. μονοπυρηνους της ΑΜD στην FPU

θα δοκιμαζα και με icc αφου αλλα προσπαθω 2-3 μερες τωρα να κατεβασω το evaluation copy της 9ης εκδοσης αλλα κατεβαινει με την τρομερη ταχυτητα των 17KB/s απο την σχολη..αυτο δεν συνεβαινε οταν κατεβαζα προηγουμενες εκδοσεις..μαλλον πεσαν ολοι με τα μουτρα στην τελευταια εκδοση για windows..

YΓ:εχω καμια μερα που ρωτησα το Intel® Math Kernel Library forum της Intel αν οι Math Kernel Libraries ειναι optimized για το Vector Unit οταν προκειται για Floating point operations ή χρησιμοποιουν την FPU αλλα μεχρι και σημερα δεν πηρα απαντηση.