Il se peut très bien que GNU sort ait été écrit simplement pour faire ce qu'il a besoin de faire et que personne n'ait jamais eu le besoin de mettre la pression aux développeurs pour en faire une voiture de course. Cela ne me dérange pas plus que cela ...
Mais surtout, synsort c'est un logiciel propriétaire ? Code source fermé, etc ? Si c'est le cas, il y a eu une équipe de développement spécialement affectée à ce projet en particulier, ce qui favorise les efforts d'optimisation. Le logiciel a été conçu pour çà. Ensuite, si ton logiciel est livré déjà compilé, sans les sources, etc. et n'est pas spécialement un projet GNU, ou de philosophie Unix, il y a fort à parier qu'ils fassent un usage poussé de fonctions assembleur propre à la machine sur laquelle tu tournes (99% du temps un PC, même si Windows ou Linux) et tirent avantage des jeux d'instructions étendu style MMX etc. Et en ce sens, ils ont parfaitement raison. Une opération de tri est pratiquement un cas d'école dans ce domaine.
A cela, on peut ajouter la façon dont les différents outils acquièrent leurs données, et gèrent les fichiers. Je suppose que sort est capable d'utiliser mmap depuis longtemps, mais il doit rester un programme tout-terrain, gérant les ressources avec des appels les plus conventionnels possibles.
Avec tout cela, j'ai presque envie de dire que 3x la vitesse de sort, c'est honorable mais sans plus. Je suis persuadé qu'un algo de tueur optimisé par un démomaker (ou pire, un programmeur de 8 bits :-) devrait pouvoir monter jusqu'à 10 fois la vitesse de base (à vue de nez bien sûr).
# Plusieurs raisons possibles.
Posté par Obsidian . En réponse au journal M'enfin ?? .... Évalué à 8.
Il se peut très bien que GNU sort ait été écrit simplement pour faire ce qu'il a besoin de faire et que personne n'ait jamais eu le besoin de mettre la pression aux développeurs pour en faire une voiture de course. Cela ne me dérange pas plus que cela ...
Mais surtout, synsort c'est un logiciel propriétaire ? Code source fermé, etc ? Si c'est le cas, il y a eu une équipe de développement spécialement affectée à ce projet en particulier, ce qui favorise les efforts d'optimisation. Le logiciel a été conçu pour çà. Ensuite, si ton logiciel est livré déjà compilé, sans les sources, etc. et n'est pas spécialement un projet GNU, ou de philosophie Unix, il y a fort à parier qu'ils fassent un usage poussé de fonctions assembleur propre à la machine sur laquelle tu tournes (99% du temps un PC, même si Windows ou Linux) et tirent avantage des jeux d'instructions étendu style MMX etc. Et en ce sens, ils ont parfaitement raison. Une opération de tri est pratiquement un cas d'école dans ce domaine.
A cela, on peut ajouter la façon dont les différents outils acquièrent leurs données, et gèrent les fichiers. Je suppose que sort est capable d'utiliser mmap depuis longtemps, mais il doit rester un programme tout-terrain, gérant les ressources avec des appels les plus conventionnels possibles.
Avec tout cela, j'ai presque envie de dire que 3x la vitesse de sort, c'est honorable mais sans plus. Je suis persuadé qu'un algo de tueur optimisé par un démomaker (ou pire, un programmeur de 8 bits :-) devrait pouvoir monter jusqu'à 10 fois la vitesse de base (à vue de nez bien sûr).