Pour l'algo, vu le genre de fichier de test et les perfs, ça me rappelle le "count sort", le tri le + rapide du monde sur des entiers pas trop gros...
Beaucoup d'algos de tris prennent les valeurs 1 à 1, et mettent à jour un tableau de résultat avec. Le count sort c'est : "je trie des entiers. Plutot que d'avoir un tableau de résultats triés, je vais passer les éléments 1 à 1 et compter le nombre de 0, de 1, de 2...". Ca bouffe une quantité de RAM pas possible (1 compteur par valeur possible), mais en 2 passes (compter-compiler) c'est fini !
Si ton synsort utilise ça, et que la commande sort prend un algo plus "général", ça explique les écarts. Ca vaudrait le coup de refaire ton test avec des choses plus complexes que des nombres entiers (genre de réels ou des chaines de caractères)
[^] # Re: Hum
Posté par qstone . En réponse au journal M'enfin ?? .... Évalué à 3.
Beaucoup d'algos de tris prennent les valeurs 1 à 1, et mettent à jour un tableau de résultat avec. Le count sort c'est : "je trie des entiers. Plutot que d'avoir un tableau de résultats triés, je vais passer les éléments 1 à 1 et compter le nombre de 0, de 1, de 2...". Ca bouffe une quantité de RAM pas possible (1 compteur par valeur possible), mais en 2 passes (compter-compiler) c'est fini !
Si ton synsort utilise ça, et que la commande sort prend un algo plus "général", ça explique les écarts. Ca vaudrait le coup de refaire ton test avec des choses plus complexes que des nombres entiers (genre de réels ou des chaines de caractères)