Αφού ο Mitsaras μπήκε στον κόπο να διαβάσει όσα έγραψε ο Johnny, αποφάσισα να το κάνω κι εγώ. Επειδή όμως είναι πολύ δύσκολο να βγάλει κανείς νόημα όταν δεν ξεχωρίζουν οι προτάσεις, είπα να ξαναγράψω το κείμενο του Johnny σε πιο κατανοητή μορφή. Johnny, αν πιστεύεις ότι κάπου παρανόησα όσα εννοείς, με διορθώνεις.
Nαι, νομιζω οτι και αυτη η εκδοση δεν θα χρησιμοποιεί όλη τη διαθέσιμη μνήμη και θα λυώνει το σκληρό.
Το καλύτερο ειναι το paraler programming. Σε όποιο LINQ έχεις ήδη γράψει απλά κολλάς το property "parrallel" (αν θυμάμαι καλά) και εκτελείται αυτόματα σε όποιο πυρήνα δει ότι κάθετε. Έτσι μπορείς εκτελέσεις πολλές περισσότερες ρουτίνες απ' ότι σε ένα επεξεργαστή, πολλές φορές στο μισό χρόνο. Κυρίως όμως θα μπορείς στο background να δουλέυεις και άλλες τέτοιες εργασίες.
Το "σπαστικο" είναι ότι αν χρησιμοποιήσεις το parallel και η εφαρμογή τρέξει σε μονοπύρηνο P4 ή παλιό Celeron τότε καμπούμ!!! Θα σκάσει το .ΝΕΤ 4.0. Αυτό μας είπαν πριν από λίγο καιρό σε ένα συνέδριο στην Αθήνα όπου έγινε η παρουσίαση του 2010.
οι χαζοι δεν το έκαναν κάπως πιο έξυπνο, να αντιλαμβάνεται αν το σύστημα είναι πολυπύρηνο ή όχι και αν υπαρχουν πολυπηρηνα και να λειτουργεί ανάλογα.
Έτσι τώρα θα πρέπει εμείς να έχουμε δύο μορφές για τα functions που μας ενδιαφέρουν, μία για παλιά μηχανήματα και μία για πολυπύρηνα. Βασικά, θα αναγκαστούμε να τις αντιγράψουμε όλες με copy-paste και να έχουμε άλλο ένα πονοκέφαλο στη συντήρηση.
Johnny, υποψιάζομαι ότι παρεξήγησες όσα είπε ο εισηγητής.
Καταρχήν, το Parallel LINQ δεν εκτελεί το query σε όποιο πυρήνα δεν κάθεται. Κάτι τέτοιο δεν θα έδινε κάποιο ουσιαστικό πλεονέκτημα σε σχέση με τη σημερινή κατάσταση. Αυτό μπορείς να το κάνεις και σήμερα απλά εκτελώντας όλα τα LINQ queries ασύγχρονα. Αυτό που συμβαίνει είναι ότι το PLINQ εκτελεί σε όλους τους επεξεργαστές τα Select, Where, OrderBy, χρησιμοποιώντας αλγόριθμους ειδικά φτιαγμένους για παράλληλη επεξεργασία (οι οποίοι δεν προκαλούν μπλοκαρίσματα μεταξύ των επεξεργαστών, δεν απαιτούν συχνή πρόσβαση στην ίδια μνήμη κλπ).
Αυτό που κερδίζεις είναι η ταχύτερη εκτέλεση της μίας εργασίας. Επίσης, το PLINQ δεν επιταχύνει queries που χρησιμοποιούν το LINQ to SQL provider ή το Entity Framework καθώς σε αυτή την περίπτωση τα Select, Where κλπ εκτελούνται στη βάση.
Επιπλέον, δεν αρκεί απλά να προσθέσεις το AsParallel στο query σου για να πάει αυτό πιο γρήγορα. Οι αλγόριθμοι για παράλληλη επεξεργασία έχουν το δικό τους κόστος και για μικρό όγκο δεδομένων μπορεί το query σου να πάει πιο αργά αντί πιο γρήγορα. Επίσης, η μορφή του query μπορεί να επηρεάσει την απόδοση του όταν εκτελείται παράλληλα. Θα πρέπει να επιλέξεις προσεκτικά ποιά query θα εκτελέσεις παράλληλα και ποιά όχι. Σε κάθε περίπτωση θα πρέπει να κάνεις δοκιμές για να δεις αν η παράλληλη επεξεργασία σε συμφέρει ή όχι.
Για παράδειγμα, το Where μπορεί εύκολα να εκτελεστεί παράλληλα, ενώ το OrderBy όχι. Ο λόγος είναι ότι κάθε επεξεργαστής μπορεί να εκτελέσει το Where σε ένα υποσύνολο των δεδομένων χωρίς να επηρεάζεται από τους άλλους επεξεργαστές. Το OrderBy όμως απαιτεί να συνδυαστούν τα αποτελέσματα όλων των επεξεργαστών για να δημιουργηθεί μία τελική λίστα με τα αποτελέσματα στη σωστή σειρά. Αυτό απαιτεί συγχρονισμό και επικοινωνία μεταξύ των επεξεργαστών και καθυστερήσεις.
Τελικά, η χρήστη του PLINQ είναι μία ενσυνείδητη επιλογή οπότε δεν έχει νόημα να συντηρείς δύο εκδόσεις του ίδιου query, για ένα και για πολλούς πυρήνες. Το AsParallel() δεν είναι ο διακόπτης "Turbo" του LINQ. Θα πρέπει εσύ να επιλέξεις ποιά query θα ωφεληθούν από το PLINQ και να τα γράψεις ανάλογα.
Όσον αφορά το σκάσιμο, δεν έχεις παρά να φτιάξεις ένα απλό query και να το τρέξεις σε ένα μονοπύρηνο μηχάνημα. Αν και υποψιάζομαι ότι κάτι άλλο θα είπε ο εισηγητής και όχι ότι το PLINQ προκαλεί exception αν εκτελεστεί σε μονοπύρηνο σύστημα. Σίγουρα δεν μπορεί να "σκάσει το .NET 4.0". Μάλλον εννοείς ότι δημιουργείται exception το οποίο δεν μπορεί να χειριστεί η εφαρμογή κι έτσι πέφτει το process. Κάτι τέτοιο όμως δεν συμβαίνει, οπότε υποψιάζομαι ότι υπήρξε παρανόηση.
Το ηθικό δίδαγμα της συζήτησης είναι ότι πρέπει να προσέχει κανείς όταν αντιμετωπίζει νέες τεχνολογίες. Μία βιαστική απόφαση, μία παρανόηση, μπορεί να κοστίσει σημαντικά στον ίδιο και την εταιρεία του. Η ιστορία έχει επαναληφθεί και στο παρελθόν. Όταν πρωτοεμφανίστηκε το .NET πολλές εταιρείες νόμισαν εσφαλμένα ότι τα Enterprise Services δεν έπρεπε να χρησιμοποιηθούν επειδή βασίζονταν σε COM και ότι οι εφαρμογές που χρησιμοποιούσαν ES δεν θα έπαιρναν πιστοποίηση από τη Microsoft. Έτσι ξόδεψαν σημαντικό χρόνο και χρήμα για να αντιγράψουν τις λειτουργίες των Enterprise Services χρησιμοποιώντας Remoting. Και όταν βγήκε το WCF, αναγκάστηκαν να πετάξουν όλη αυτή τη δουλειά και να την ξανακάνουν από το μηδέν.
Υποψιάζομαι ότι μία παρανόηση για το PLINQ μπορεί να οδηγήσει σε παρόμοια απώλεια χρόνου και χρημάτων. Γι αυτό, προσοχή
Παναγιώτης Καναβός, Freelancer
Twitter: http://www.twitter.com/pkanavos