Tout d'abord, être clair, je suis conscient qu'un grand nombre d'implémentations de MD5 existent en C ++. Le problème ici est que je me demande si une comparaison de la mise en œuvre est plus rapide que les autres. Étant donné que j'utilise cette fonction de hachage MD5 sur les fichiers de taille supérieure à 10 Go, la vitesse est en effet une préoccupation majeure ici.
4 Réponses :
Je suis sûr qu'il y a beaucoup d'adaptations CUDA / OPENCL de l'algorithme qui devrait vous donner une vitesse définitive. Vous pouvez également prendre l'algorithme de base et penser un peu -> Obtenez une implémentation CUDA / OPENCL.
Les chiffres à blocs sont des candidats parfaits pour ce type de mise en œuvre.
Vous pouvez également obtenir une implémentation C et saisir une copie du compilateur Intel C et voir à quel point c'est bon. Les extensions de vectorisation dans Intel CPU sont incroyables pour des boostes de vitesse.
table disponible ici:
http://www.golubev.com/gpuest.htm
On dirait probablement votre goulot d'étranglement sera votre HardDrive Io
Je pense que le point Avakar tente de faire est: avec une puissance de traitement moderne, la vitesse IO de votre disque dur est le goulot d'étranglement n'est pas le calcul du hachage. Obtenir un algorithme plus efficace ne vous aidera pas comme ça n'est pas (probablement) le point le plus lent.
Si vous faites quelque chose de spécial (1000 ronds par exemple), il peut être différent, mais si vous calculez simplement un hachage d'un fichier. Vous devez accélérer votre IO, pas vos maths.
Ce n'est pas une réponse. Il n'a rien mentionné sur l'architecture. Pour tout ce que vous savez, ces fichiers pourraient exister dans un ramdisk.
... ou simplement dans le cache de disque. J'ai regardé ce fil parce que je trouvé que la mise en œuvre du MD5 utilisé dans l'application que je cherche ralentit le démarrage en raison du hachage de nombreux petits fichiers.
Je ne pense pas que cela compte beaucoup (sur le même matériel; mais en effet GPGPU-S sont différents, et peut-être plus rapide, matériel pour ce type de problème). La partie principale de MD5 est une boucle assez complexe d'opérations arithmétiques complexes. Qu'est-ce que la matière est la qualité des optimisations du compilateur?
Et qu'est-ce qui compte aussi comment vous lisez le fichier. Sur Linux, MMAP et MADVise et ReadAhead pourrait être pertinent. La vitesse du disque est probablement le goulot d'étranglement (utilisez un SSD si vous le pouvez).
Et êtes-vous sûr de vouloir MD5 spécifiquement? Il existe des algorithmes de codage de hachage plus simples et plus rapides (MD4, etc.). Toujours que votre problème est plus d'E / S lié que la CPU Lié.
Vous avez ces disques super modernes, plus rapides que SSD, n'est-ce pas?
Ce Question pourrait aider . J'allais suggérer quelque chose que vous pouvez paralléliser, mais je suppose que cela dépend de la manière dont vos données sont stockées.
@avakar: Si les données sont répliquées, elles doivent être au moins plausibles pour accélérer le calcul en l'exécutant en parallèle des différentes répliques, si le système lui a permis.
@avakar: très bon point! J'aurais dû vérifier mon goulot d'étranglement d'E / S :)
J'aurais un coup d'œil aux programmes de craquage MD5 ...
@avakar: Tout ce qui est arrivé au bon vieux raid?
@Kerreksb, oui, un raid de disques SSD pourrait fonctionner.