Η επόμενη έκδοση του pctbench.

[DarthMoul]

Αναφορικά με την επόμενη έκδοση του pctbench έχω κάνει τις παρακάτω σκέψεις.

- Single threaded υπολογισμός του pi με σειρά taylor και standard 10 ψηφία.
- Single threaded υπολογισμός του tcp/ip checksum για buffer 8 Kbytes με 16, 32 και 64 bits για να τεστάρουμε τις επιδόσεις του Athlon64 σε 32 και 64 bit mode.
- Υπολογισμός pi και tcpip checksum 32 bits εν παραλλήλω για να δούμε κατά πόσο αποδίδει το Hyperthreading όταν τα δύο threads δεν διεκδικούν τους ίδιους πόρους.
- Ταξινόμιση μερικών εκατομμυρίων records με quick sort, little endian και big endian radix sort ώστε να πιέσουμε στο μέγιστο μνήμη, L1/L2 cache και registers την ίδια στιγμή.
- Και φυσικά linux support.

Διάλεξα ως tests το tcp/ip checksum και την ταξινόμιση γιατί είναι διαδικασίες που εκτελούνται εκατομμύρια φορές καθημερινά από τους υπολογιστές μας. Επίσης ως γνωστές διαδικασίες, λαμβάνονται υπόψη και από τους κατασκευαστές των επεξεργαστών και των μεταγλωττιστών κατά την φάση υλοποίησης και σχεδιασμού.

Αν υπάρχουν κάποιες προτάσεις προς συζήτηση, είναι ευκαιρία να την κάνουμε τώρα, πριν αρχίσω την κατασκευή. Ελπίζω το πρόγραμμα να είναι έτοιμο σε 2-3 εβδομάδες.

[circular]

Μια ακόμα πρόταση - ίσως για μελλοντική έκδοση - η συμπίεση με κάποια βιβλιοθήκη τύπου zlib - bzip2 κλπ, αφού και αυτή η διαδικασία είναι τυπική και επαναλαμβανόμενη. Ανάλογα με το μέγεθος των δεδομένων που θα δίνεται προς συμπίεση θα μπορούν να αξιολογηθούν διάφορα χαρακτηριστικά πχ L1 - L2, αλλά αν θέλουμε να το κάνουμε και multithreaded θα πρέπει να το συνδυάσουμε με κάποιο άλλο τεστ ή να κάνουμε 2 συμπιέσεις παράλληλα. Δεν ξέρω κατά πόσον οι μεταγλωττιστές σχεδιάζονται με γνώμονα κάτι τέτοιο αλλά πστεύω οτι μπορεί να δώσει χρήσιμα αποτελεσματα.

[DarthMoul]

Μια ακόμα πρόταση - ίσως για μελλοντική έκδοση - η συμπίεση με κάποια βιβλιοθήκη τύπου zlib - bzip2 κλπ, αφού και αυτή η διαδικασία είναι τυπική και επαναλαμβανόμενη. Ανάλογα με το μέγεθος των δεδομένων που θα δίνεται προς συμπίεση θα μπορούν να αξιολογηθούν διάφορα χαρακτηριστικά πχ L1 - L2, αλλά αν θέλουμε να το κάνουμε και multithreaded θα πρέπει να το συνδυάσουμε με κάποιο άλλο τεστ ή να κάνουμε 2 συμπιέσεις παράλληλα. Δεν ξέρω κατά πόσον οι μεταγλωττιστές σχεδιάζονται με γνώμονα κάτι τέτοιο αλλά πστεύω οτι μπορεί να δώσει χρήσιμα αποτελεσματα.Καλή ιδέα. Συμπίεση εν παραλλήλω! Γίνεται και multithreading εύκολα. Εννοώ για μία συμπίεση, όχι δύο μαζί. Αυτό που θέλω να αποφύγω είναι disk access, αλλά μπορούμε να το κάνουμε και χωρίς disk access. To winzip zlib χρησιμοποιεί;

[circular]

Δε νομίζω... αλλά είναι συμβατά τα archives που φτιάχνει το zlib με αυτά του winzip.

[DarthMoul]

Μάλλον το compression bench θα ενσωματωθεί στην μεθεπόμενη έκδοση. Δεν ξέρω πόσοι κοίταξαν το source και τα makefiles. Αν υπάρχει κάποια πρόταση ή παρατήρηση, καλό είναι να γίνει τώρα γιατί η επόμενη έκδοση θα είναι κάπως πιο πολύπλοκη στα sources.

[DarthMoul]

H επόμενη έκδοση είναι σχεδόν έτοιμη όπως φαίνεται και στο screenshot. Μένει να ετοιμάσω τα πακέτα για linux και windows και να γράψω τα αντίστοιχα README. Το sort benchmark χρησιμοποιεί κάπου στα 250 ΜΒ RAM. Θα υπάρξει πρόβλημα με αυτό; Όσες μηχανές έχουν μόνο 256 MΒ RAM θα ζοριστούν. Να το αφήσω έτσι;

[circular]

Άστο έτσι, οι περισσότεροι έχουν πάνω από 256ΜΒ μνήμη. Εναλλακτικά ίσως θα πρεπε να μπει αλλη μια παραμετρος ωστε να χρησιμοποιει πχ 100ΜΒ RAM.

[DarthMoul]

Άστο έτσι, οι περισσότεροι έχουν πάνω από 256ΜΒ μνήμη. Εναλλακτικά ίσως θα πρεπε να μπει αλλη μια παραμετρος ωστε να χρησιμοποιει πχ 100ΜΒ RAM. Γίνεται και αυτό, αλλά μετά δεν θα έχουμε σωστό μέτρο σύγκρισης. Μην ξεχνάς ότι πρόκειται για ταξινόμιση. Άλλοι αλγόριθμοι έχουν linear συμπεριφορά και άλλοι exponential όταν αυξάνει το dataset που ταξινομούν. Θα το αφήσω έτσι και βλέπουμε. Αν γίνουν παράπονα θα το αλλάξω.

Θα έχουμε και την ευκαιρία να δούμε αν το quicksort είναι ο γρηγορότερος αλγόριθμος ταξινόμισης όπως μας έλεγαν όταν είμασταν φοιτητές. Και πως συμπεριφέρεται ο καθένας από τους τρεις ανάλογα με την μηχανή.

[circular]

To QuickSort μπορεί στη γενική περίπτωση να είναι πολύ γρήγορος αλλά στη χειρότερη μπορεί να γίνει O(n2), εξαρτάται σε μεγάλο βαθμό από την σειρά των δεδομένων που του έρχονται σαν είσοδο. Οι εγγραφές που φτιάχνεις για τη δοκιμή παράγονται δυναμικά/τυχαία ή είναι στάνταρ η σειρά τους πριν την ταξινόμηση?

[DarthMoul]

To QuickSort μπορεί στη γενική περίπτωση να είναι πολύ γρήγορος αλλά στη χειρότερη μπορεί να γίνει O(n2), εξαρτάται σε μεγάλο βαθμό από την σειρά των δεδομένων που του έρχονται σαν είσοδο. Οι εγγραφές που φτιάχνεις για τη δοκιμή παράγονται δυναμικά/τυχαία ή είναι στάνταρ η σειρά τους πριν την ταξινόμηση? Για να είναι δίκαιες οι μετρήσεις, είναι pattern created. To quicksort την πατάει όταν το dataset είναι ήδη ταξινομιμένο, οπότε εκφυλίζεται σε buble-sort που είναι πολύ αργό. Το pattern που χρησιμοποιώ εγώ και θα το δείτε στα sources παράγει εντελώς άτακτο dataset, πράγμα που διευκολύνει το quicksort και αντίθετα δυσκολεύει το radix.