Δεν είναι θέμα φόρτου. Αν το overhead της παράλληλης επεξεργασίας είναι μεγαλύτερο από  το όφελος, το ForceParallelism θα προκαλέσει καθυστέρηση, όχι επιτάχυνση. Από την άλλη, υπάρχουν απλά περιπτώσεις που το .NET 4 θα κάνει λαθος. Αν π.χ. εκτελείς μία μακρόχρονη ασύγχρονη διαδικασία μέσα στο PLINQ query, μπορείς να σηκώσεις πολύ περισσότερα ταυτόχρονα tasks απ' ότι αν εκτελείς CPU heavy αλγόριθμους. Το PLINQ δεν το ξέρει όμως και έτσι επιλέγει συντηρητικά. 

Για να πεις στο PLINQ πόσα ταυτόχρονα tasks να σηκώσει χρησιμοποιείς την  WithDegreeOfParallelism για να δώσεις μέχρι 64 ταυτόχρονα tasks. Λογικό το νούμερο αν μιλάμε για CPU bound (ποιός έχει μηχάνημα με 64 cores?) μικρό αν μιλάμε για ασύγχρονη επεξεργασία, όπως π.χ. crawling

 Επιπλέον, υπάρχουν operations που το .NET 4 θα εκτελέσει πάντα σύγχρονα ενώ το 4.5 θα εκτελέσει παράλληλα. Το PLINQ Queries that run in parallel in .NET 4.5 του Stephen Toub έχει ένα πίνακα με τις εντολές που εκτελούνται πλέον παράλληλα.

Τέλος, το πρόβλημα με τα παραδείγματα που ψάχνεις είναι ότι ζητάς κάτι πολύ συγκεκριμένο - ΚΑΙ MapReduce ΚΑΙ TPL ΚΑΙ ένα μόνο μηχάνημα. Τα περισσότερα παραδείγματα ασχολούνται με ένα αντικείμενο τη φορά.

Ειδικά για το word count μπορείς να δεις αυτό το walkthrough για το DataFlow, όπου σπάει το πρόβλημα σε βήματα ξεκινώντας από το split του αρχικού κειμένου. Το παράδειγμα που κοίταζες στην αρχή θεωρεί ότι το αρχείο έχει ήδη γίνει split σε λέξεις, κάτι το οποίο κοστίζει αρκετά και μπορεί να γίνει επίσης ασύγχρονα.

Μπορεί να μην είναι το καλύτερο παράδειγμα για map reduce, αλλά δίνει μία καλή εικόνα μίας πιο γενικής αντιμετώπισης (pipeline από agents, όχι μόνο mappers, reducers).

Για να δούμε μήπως βρούμε κανα καλύτερο παράδειγμα (ή το χρόνο να γράψουμε κανένα)

Έστω ότι έχεις ένα social network και θέλεις να κάνεις friend recommendations. Τα recommendations θα είναι τα μέλη που δεν είναι φίλοι σου αλλά έχετε τους περισσότερους mutual.

Στο πρώτο βήμα, ο αλγόριθμος βρίσκει τους φίλους των φίλων σου που δεν είναι ήδη φίλοι. Αυτό θα βγάλει μία λίστα με candidates από κάθε φίλο. Στο δεύτερο βήμα, ο αλγόριθμος υπολογίζει για κάθε candidate τον αριθμό των mutuals. Τέλος, επιλέγει τους top X για να σου τους προτείνει

Το πρώτο βήμα αντιστοιχεί στο Map (από φίλους σε candidates) ενώ το δεύτερο το reduce (από πολλαπλές λίστες candidates σε ένα set από candidates με την αξιολόγηση τους). 

Και τα δύο βήματα είναι σχετικά απλά, οπότε η αξία του map/reduce προέρχεται από το ότι μπορεί να κατανείμει το κάθε βήμα σε όσο το δυνατόν περισσότερα cores χωρίς προβλήματα blocking: ο κάθε mapper ή reducer παίρνει το δικό του αντίγραφο των δεδομένων χωρίς προβλήματα locking αφού δεν μοιράζεται τίποτε με τους άλλους.