
Je passe d'un moteur générique à:
- io_uring par défaut sous Linux
- IOCP par défaut sous Windows
Le moteur générique reste la pour les autres platformes.
J'ai besoin de beta tester, sur certains benchmark je fait du 100x.
Pour linux, merci de compiler depuis les sources: https://github.com/alphaonex86/Ultracopier
avec l'IA je suis enfin capable d'intégrer correctement les files managers, vu que aucun ne semble intéressé pour intégrer un petit plugin pour supporter Ultracopier (qui maintenant supporte aussi KIO sous Linux pour plasma, copie de linux 4.4: 1h sous plasma, 4s sous Ultracopier…).
La liste de fichier est maintenant géré comme un arbre ce qui réduits considérablement la taille en mémoire pour les copies de plus de 100 000 fichiers.
Pour windows:
- https://cdn.confiared.com/ultracopier.herman-brule.com/files/3.1.0.0/ultracopier-windows-XP-3.1.0.0-setup.exe
- https://cdn.confiared.com/ultracopier.herman-brule.com/files/3.1.0.0/ultracopier-windows-7-64-3.1.0.0-setup.exe
- https://cdn.confiared.com/ultracopier.herman-brule.com/files/3.1.0.0/ultracopier-windows-x86_64-3.1.0.0-setup.exe
# mauvais lien ? et petite question
Posté par lejocelyn (site web personnel) . Évalué à 3 (+1/-0).
Euh, mauvais lien pour le code ?
Sinon, pour avoir testé y'a quelques années, j'avais trouvé très bien, plus performant que les interfaces par défaut. Qu'est ce qui fait que les bureaux Linux ne remplacent pas leurs codes par le code d'ultracopier ?/problèmes de licence ?
Et sinon, l'illustration genIA, c'est pour bluffer les utilisateurs non avertis ?
[^] # Re: mauvais lien ? et petite question
Posté par alpha_one_x86 (site web personnel) . Évalué à 4 (+2/-0).
lien correcte, pour l'instant il faut compiler depuis les sources sur github.
mais juste pour toi:
https://cdn.confiared.com/ultracopier.herman-brule.com/files/3.1.0.0/ultracopier-src-3.1.0.0.tar.zst
Je suis juste ignoré la plus par du temps, a une époque pour KDE c'est car je ne supportais pas les KIO (pour moi ce n'est pas valable car c'est facile de filtrer si local -> ultracopier) -> résolut.
haikuOS c'est car j'utilise un interface Qt et il veulent une interface native (et je vais pas réécrire moi logiciel pour chaque OS).
Basiquement sous tout les unix, j'ai juste besoin d'un petit bout de code dans le file manager qui fait: essaye de te connecter a un unix socket et écrire les données, si cela marche ne pas faire la copie (car pris en charge en externe) si non faire la copie.
l'illustration genIA est beaucoup plus propre que ce que je ne serai jamais faire sur gimp.
Mon projet libre: https://ultracopier.herman-brule.com/, mon jeu libre: https://catchchallenger.herman-brule.com/
[^] # Re: mauvais lien ? et petite question
Posté par Cyril Brulebois (site web personnel) . Évalué à 4 (+2/-0).
Non, le lien n'est pas correct, à part si tu voulais faire de la pub pour « CatchChallenger is a MMORPG. JRPG + crafting + TvT + management game »…
Au passage, les différents sites mentionnés dans les dépôts, dans ta signature, etc. ne résolvent pas. Visiblement, c'est en « client hold » et « redemption period » (dixit https://lookup.icann.org/en/lookup).
Debian Consultant @ DEBAMAX
[^] # Re: mauvais lien ? et petite question
Posté par alpha_one_x86 (site web personnel) . Évalué à 3 (+1/-0).
Dsl, corrigé https://github.com/alphaonex86/Ultracopier
Mon projet libre: https://ultracopier.herman-brule.com/, mon jeu libre: https://catchchallenger.herman-brule.com/
[^] # Re: mauvais lien ? et petite question
Posté par Voltairine . Évalué à 3 (+1/-0).
Le bon lien est : https://github.com/alphaonex86/Ultracopier
De quoi s'agit-il ? De la copie des sources du noyau en version 4.4 ? Sur quel type de périphérique ?
J'ai du mal à croire en une telle différence de performance…
Si j'ai un moment je testerai.
[^] # Re: mauvais lien ? et petite question
Posté par alpha_one_x86 (site web personnel) . Évalué à 2 (+0/-0).
J'ai testé
- NVMe <-> NVMe
- NAS <-> NVMe
- HDD <-> HDD
Mon projet libre: https://ultracopier.herman-brule.com/, mon jeu libre: https://catchchallenger.herman-brule.com/
[^] # Re: mauvais lien ? et petite question
Posté par Voltairine . Évalué à 6 (+4/-0). Dernière modification le 05 juillet 2026 à 15:49.
Sur une Debian trixie avec KDE, j'ai testé la copie de ~ 13GiO de fichiers.
D'un NVMe vers un autre dossier sur le même disque. Pas de différence très significative :
- 19s en glisser déposer sur Dolphin ;
- 24s avec Ultracopier
Du NVMe vers un montage NFS (disque mécanique sur une machine du réseau local, lien 1Gb) :
- 6 min. 53s en glisser déposer depuis Dolphin ;
- 12 min 10s avec Ultracopier
Pour moi ce n'est pas concluant.
[^] # Re: mauvais lien ? et petite question
Posté par seraf1 (site web personnel) . Évalué à 3 (+2/-0).
Bonjour, le problème lors du copie n'est pas la taille, mais le nombre de fichiers ! Essayes avec quelques millions de fichiers, ce sera plus parlant (que ce soit avec cp ou ultracopier, je n'ai pas testé)
[^] # Re: mauvais lien ? et petite question
Posté par lejocelyn (site web personnel) . Évalué à 4 (+2/-0).
Je dirais que ce sont différents cas d'usage. @alpha_one_x86: il faudrait définir des tests (distirbutions, version du noyau, environnement, mais aussi nombre de fichiers à copier, quitte à fournir des sets de fichiers à copier, matos). Le retour de Voltairine est intéressant, peut-être que le problème dans son cas vient de la version du noyau qui n'inclut pas les mises à jour récente de io_uring.
[^] # Re: mauvais lien ? et petite question
Posté par alpha_one_x86 (site web personnel) . Évalué à 2 (+0/-0).
Même si je me suis diriger sur beaucoup de petit fichiers linux 4.4, il y devrai avoir un gain sur les gros fichiers, mais les gros fichiers sont principalement limiter par l'OS et le disque, donc la différence entre système de copie ne devrai pas être forte.
Mon projet libre: https://ultracopier.herman-brule.com/, mon jeu libre: https://catchchallenger.herman-brule.com/
[^] # Re: mauvais lien ? et petite question
Posté par fearan . Évalué à 3 (+0/-0).
Attention quelques millions de fichiers vides c'est pas la même choses que quelques millions avec mélange de pas grand chose et gros fichiers.
Et si on part d'un disque mécanique, faut aussi tester selon la répartitions des données; bref c'est pas un test simple à faire.
Mais si une personne arrive avec j'ai fait du 300% de perf en plus, et lors de ton premier test t'as plutôt une perte, j'avoue que ça donne pas envie d'aller plus loin.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: mauvais lien ? et petite question
Posté par Voltairine . Évalué à 2 (+0/-0). Dernière modification le 06 juillet 2026 à 11:02.
Non le problème, comme indiqué dans un commentaire plus bas, c'est l’absence de procédure de tests ou au moins un tableau synthétique des différents test réalisés.
Ce que je voulais monter c'est que prétendre qu'un outil est beaucoup plus rapide qu'un autre n'a pas de sens si on ne précise pas le contexte exact.
En l'occurrence Ultracopier est beaucoup plus lent que l'explorateur de fichiers Dolphin pour un transfert via NFS.
N.B. : si j'ai quelques millions de fichiers à copier, je ne vais pas utiliser une interface graphique mais plutôt cp, rsync ou dd
[^] # Re: mauvais lien ? et petite question
Posté par alpha_one_x86 (site web personnel) . Évalué à 2 (+0/-0).
Effectivement c'est pas quelque chose que j'ai standardisé, j'ai pris une grosse ISO et les sources du noyau Linux 4.4 sur divers testes. J'ai toujours pris les 2eme temps de copie pour le cache et avoir toujours des résultats uniforme. Et les 300% annoncé sont contre l'ancienne version d'ultracopier.
Mon projet libre: https://ultracopier.herman-brule.com/, mon jeu libre: https://catchchallenger.herman-brule.com/
[^] # Re: mauvais lien ? et petite question
Posté par Jérôme FIX (site web personnel) . Évalué à 1 (+0/-0).
Qui déplace plusieurs millions (même millier) de fichiers en interface graphique ?
Personne en réalité… enfin j'espère !
[^] # Re: mauvais lien ? et petite question
Posté par flavien75 . Évalué à 2 (+1/-0). Dernière modification le 06 juillet 2026 à 22:54.
Par exemple, pour des données sismiques les enregistrements peuvent se faire par fichier de 5 à 10 secondes. Ça permet ensuite à un second logiciel (qui n'est souvent pas sur le même PC) de venir analyser les données en quasi temps réel. On se retrouve donc avec un dossier de données brutes contenant 8600 à 17200 fichiers par jour qui va être stocké pendant quelques temps suivant le type de projet.
Dans ce cas pour copier les données, sous Windows, le plus rapide reste de générer une archive du dossier et copier l'archive plutôt que copier le dossier brut.
Ce type de problème est surtout sensible pour des petits fichiers de quelques kilo-octets.
Donc, ça arrive.
Les vrais naviguent en -42
[^] # Re: mauvais lien ? et petite question
Posté par Jérôme FIX (site web personnel) . Évalué à 1 (+0/-0).
Et ? Quel besoin de déplacer ces fichiers via une interface graphique ?
On est quand même dans des cas spécifiques (voir de niche), même sur Windows il doit y avoir des façon efficace de déplacer de grandes quantités de fichiers. (robocopy ?)
[^] # Re: mauvais lien ? et petite question
Posté par flavien75 . Évalué à 2 (+1/-0).
Réaction naturelle de l'utilisateur, comme il utilise la machine via une interface graphique, il n'a pas nécessairement le réflexe d'ouvrir une fenêtre de ligne de commande pour transférer des données sur une clef USB ou un partage réseau.
Dans ce cas, le plus rapide et le plus simple a été de dire à l'utilisateur qui se plaignait de la vitesse de transfert de faire un clic droit sur le dossier et faire "compresser" avant de déplacer l'archive.
Un point qui n'était pas clair dans mon message précédent était que le logiciel d'analyse surveillait automatiquement l'apparition des fichiers dans un dossier partagé sur le réseau. La copie manuelle ne servait qu'à faire des sauvegardes ou ponctuellement aller analyser les données sur une autre machine.
Maintenant oui, il y a surement des outils plus adaptés.
Les vrais naviguent en -42
[^] # Re: mauvais lien ? et petite question
Posté par BAud (site web personnel) . Évalué à 2 (+0/-0).
pourquoi sous windows spécifiquement ? C'est pareil sous Solaris, AIX, Linux… si tu choisis de transférer par le réseau les fichier un à un (un rsync serait sans doute déjà plus efficace).
[^] # Re: mauvais lien ? et petite question
Posté par flavien75 . Évalué à 1 (+0/-0).
J'ai précisé Windows parce ça m'est arrivé au boulot sur des PC Windows. Mais je ne serais pas surpris que le problème apparaissent sur d'autres systèmes.
Les vrais naviguent en -42
[^] # Re: mauvais lien ? et petite question
Posté par flavien75 . Évalué à 1 (+0/-0).
Je plussois qu'à la réflexion un rsync aurait été plus efficace
Les vrais naviguent en -42
[^] # Re: mauvais lien ? et petite question
Posté par alpha_one_x86 (site web personnel) . Évalué à 2 (+0/-0).
Je pense que le code ne devrai pas changer et que l'interaction avec l'utilisateur qu'elle soit via terminal ou GUI, ne devrai pas affecter le résultat… mais bon c'est pour cela que je suis le dev de ultracopier.
J'utilise toujours rsync quand je travail en CLI only.
Mon projet libre: https://ultracopier.herman-brule.com/, mon jeu libre: https://catchchallenger.herman-brule.com/
[^] # Re: mauvais lien ? et petite question
Posté par NeoX . Évalué à 4 (+1/-0).
en tenant compte du temps de compression, ou juste le temps de transfert ?
[^] # Re: mauvais lien ? et petite question
Posté par MicP . Évalué à 2 (+1/-0).
… et du temps de décompression une fois l'archive transférée (et ne pas oublier de garder un peu d'espace dans le système de fichiers cible pour pouvoir faire cette décompression)
… et dans ce royaume, ceux qui y voient un peu plus clair sont parfois très mal vus.
[^] # Re: mauvais lien ? et petite question
Posté par flavien75 . Évalué à 1 (+0/-0).
en tenant compte du temps de compression ET de décompression !
C'était impressionnant comment les transferts de petits fichiers était lent sous Windows (c'était la version 7).
Les vrais naviguent en -42
# Plutôt pas d'illustration que du slope franchement.
Posté par martoni (site web personnel, Mastodon) . Évalué à 8 (+8/-2).
Les illustrations en IA-Slope ça me bloque, j'ai plus envie de lire la suite :(
Je suis adepte des illustrations pourtant, mais même maladroitement faite à la main ça reste beaucoup mieux que du slope.
J'ai plus qu'une balle
[^] # Re: Plutôt pas d'illustration que du slope franchement.
Posté par alpha_one_x86 (site web personnel) . Évalué à 2 (+1/-1).
https://github.com/alphaonex86/CatchChallenger/blob/master/doc/algo/visibility/constant-time-player-visibility.png -> le maximum que je peu faire et hélas je doit être accessible et propre pour continuer à avoir des financements pour le projet.
Mon projet libre: https://ultracopier.herman-brule.com/, mon jeu libre: https://catchchallenger.herman-brule.com/
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.