Je me demande juste est parallèle fichier.read code> à l'aide de plinq / parallèle peut être plus rapide? Mon code est comme suit (.NET 4.0): public static void ReadFileParallel(List<string> fileName)
{
Parallel.Foreach(fileName, file=>File.Read(file));
}
public static void ReadFilePLINQ(List<string> fileName)
{
fileName.AsParallel().foreach(file=>File.Read(file));
}
7 Réponses :
Il existe un excellent PDF de MSFT qui passe en détail sur les possibilités parallèles et de threading.
Cela pourrait aider.
Cela dépend.
Si vos fichiers étaient dans différents emplacements, sur différentes actions réseau ou sur différents disques durs physiques, oui, le chargement parallèle aidera probablement. S'ils sont sur un seul disque dur en filage, la lecture des fichiers en parallèle vous fera probablement mal de votre performance de manière significative en raison du temps de recherche supplémentaire que vous risquez probablement de ces lectures parallèles.
Si vos fichiers sont sur un SSD, vous obtiendrez probablement un peu moins de performances, mais cela dépendra du nombre de fichiers que vous lisez en parallèle et quelles sont leurs tailles. J'imagine qu'à un certain seuil de taille de fichier et à un certain nombre de lectures parallèles, les performances diminueront de manière significative. Difficile à dire sur celui-là sans une certaine expérimentation.
Ce sont des critères raisonnables. En pratique, je dirais que cela plutôt que de deviner, cependant.
Vous le penseriez, mais ce n'est pas quelles mesures montrent. Lorsque les fichiers d'E / S ont une latence importante, en particulier sur les réseaux, le faire en parallèle peut garder le tuyau rempli.
à une première approximation, il vous aidera si les fichiers sont sur différents disques et le rendent plus lent autrement (en raison de la recherche de temps passée).
Il peut être légèrement plus rapide si tous les fichiers sont mis en cache (puisque vous pouvez utiliser plusieurs cœurs).
Votre meilleur pari est bien sûr de courir des points de repère.
Vous ne faites pas exactement un fichier parallèle.Lead, vous faites plusieurs fichiers.Leilles en parallèle. Si les fichiers sont dans différentes broches, vous vivrez un débit amélioré simplement en utilisant plusieurs broches à la fois.
Vous pouvez également expérimenter des performances améliorées, même si vous utilisez une seule broche, si chaque lecture est suivie par le traitement lié à la CPU, bien que dans ce cas, ce soit beaucoup mieux pour et planifier des objets de tâches. Dans ce cas, vous pouvez avoir des tâches de chargement de données à partir de fichiers, tandis que d'autres utilisent des données déjà chargées pour exécuter un traitement lourd.
Ouais, mais si ses fichiers sont sur le même disque dur, il frappera le temps de recherche de la tête et le débit diminuera bien, alors 2 fois. Rappelez-vous que la moyenne de la recherche de 3,5 "7200 tours tr / min est de 13 à 15 millisecondes. Et contrairement à la capacité et au taux de lecture / écriture linéaire, ce chiffre est cohérent au cours des dernières années.
C'est pourquoi j'ai dit "chaque lecture suivie du traitement lié à la CPU". Pendant que l'un des threads lisait le fichier, un autre effectue le traitement, les conservant donc tous les deux.
Je pense que vous avez à peu près frappé le clou sur la tête ici.
Les opérations parallèles en général sont toujours étrangères par le point à partir de laquelle vous êtes à court de ressources pour exécuter les opérations en parallèle, mais même vous avez toujours des retours diminuant sur une quantité croissante de fils parallèles.
Jeff Atwood a tweeté un graphique intéressant que j'ajouterai ensuite à cela, montrant plus tard les retours décroissants des processeurs Mutli-Core avec un environnement multi-threading. Accordé ce n'est pas exactement la même chose. Mais regardons cela de la pensée que même si vous aviez 100 fichiers sur 100 disques durs, quelque part que l'IO est en train de reculer un seul canal qui entraînera une diminution de l'augmentation de la lecture.
Ce que j'essaie essentiellement de dire, c'est simplement courir quelque chose en parallèle ne signifie pas que cela se fera de manière spectaculaire, il est important de déterminer comment les processus parallèles sont réellement exécutés.
C'est une affaire difficile. Si vous le faites de mal, la tête de disque se déplace en arrière pour essayer de lire deux fichiers en même temps. Ceci est particulièrement un problème sur des fichiers plus grands.
Cependant, si vous lisez beaucoup de petits fichiers en parallèle, vous pouvez gagner un peu parce que le sous-système de disque peut choisir de lire les fichiers dans une commande différente de celle que vous avez posée. Je n'ai cependant pas vu cet effet dans la vie réelle.
Le traitement également que vous faites sur le contenu peut être effectué en parallèle avec la lecture des fichiers. Donc, vous devez profiler et repasser avant de vous expédier.