Reprise du message précédent :

Ben comme t'as l'abo à Opus, fais les traductions.

Elle était bien la soupe ?  

traductions des autres langages ?  
 
jcroyais que tu voulais faire un truc de merde bancal sur godbolt où tu maitrises rien pour comparer  

Le monde appartient à ceux qui se lèvent tôt, le problème c'est que le soir t'es fatigué  

Tu ne profites pas d’un sommeil récupérateur dans le train ?

je suis en remote demain, merci de penser à moi

Ben si tu le prends comme ça, tu attendras demain pour des résultats.

Ah enfin !  
 

 
On va se faire une bonne terrasse demain pour étrenner tout ça    

En vrai, godbolt a du mal à compiler, ça marche une fois sur 5, je ne sais pas pourquoi.
Les serveurs doivent être fortement sollicités.
Je referai des mesures demain matin.

 
1/ idem, même si pour l'instant j'ai rien sur des serveurs persos
2/ idem, sans mode Yolo c'est ingérable, la gestion des droits Gemini pue par rapport à Claude (c'est pas que la granularité n'y est pas, c'est que le harnais extrapole mal. J'en ai plein le cul de devoir approver f1 read-only <script ultra specifique #1>, puis 5sec plus tard f1 read-only <script ultra specifique #2> : me propose de mettre ça en dure dans ma conf est complètement con, par contre j'apprécierais un "Approve f1 read-only for this project / approve f1 readonly forever"
 
je vais même plus loin: je donne accès aux systèmes RH, et je laisse l'agent interagir avec via un browser contrôlé

Bon, après traduction du code Go en C++, en Rust et en Zig, sur un run avec N = 2 000 000, j'ai:

Go x84-gc 1.26.0:

N = 1 000 000
slices.Sort (stdlib)         89 ms
iCantBelieveItCanSort    ignoré (O(n²) avec n > 50000)
Selection Sort           ignoré (O(n²) avec n > 50000)
Insertion Sort           ignoré (O(n²) avec n > 50000)
Shell Sort                  151 ms  OK
Merge Sort                  101 ms  OK
Heap Sort                   653 ms  OK
QuickSort                    97 ms  OK

N = 2 000 000
slices.Sort (stdlib)        242 ms
iCantBelieveItCanSort    ignoré (O(n²) avec n > 50000)
Selection Sort           ignoré (O(n²) avec n > 50000)
Insertion Sort           ignoré (O(n²) avec n > 50000)
Shell Sort                  905 ms  OK
Merge Sort                  280 ms  OK
Heap Sort                   954 ms  OK
QuickSort                   710 ms  OK

C++ x64-gcc 16.2:  -std=c++17 -O3

N = 1 000 000
std::sort (stdlib)           89 ms
iCantBelieveItCanSort    ignoré (O(n²) avec n > 50000)
Selection Sort           ignoré (O(n²) avec n > 50000)
Insertion Sort           ignoré (O(n²) avec n > 50000)
Shell Sort                  169 ms  OK
Merge Sort                  115 ms  OK
Heap Sort                   408 ms  OK
QuickSort                   117 ms  OK

N = 2 000 000
std::sort (stdlib)          233 ms
iCantBelieveItCanSort    ignoré (O(n²) avec n > 50000)
Selection Sort           ignoré (O(n²) avec n > 50000)
Insertion Sort           ignoré (O(n²) avec n > 50000)
Shell Sort                  438 ms  OK
Merge Sort                  789 ms  OK
Heap Sort                   961 ms  OK
QuickSort                   293 ms  OK

Zig 0.15.2:  -O ReleaseFast

N = 1 000 000
Reference (std.sort)               73 ms  OK
I Can't Believe It Can Sort  SKIPPED (quadratic)
Selection Sort               SKIPPED (quadratic)
Insertion Sort               SKIPPED (quadratic)
Shell Sort                        124 ms  OK
Merge Sort                         57 ms  OK
Heap Sort                         120 ms  OK
QuickSort                          79 ms  OK

N = 2 000 000
Reference (std.sort)              198 ms  OK
I Can't Believe It Can Sort  SKIPPED (quadratic)
Selection Sort               SKIPPED (quadratic)
Insertion Sort               SKIPPED (quadratic)
Shell Sort                        839 ms  OK
Merge Sort                        156 ms  OK
Heap Sort                         837 ms  OK
QuickSort                         212 ms  OK

Rust rustc 1.98.0 : -O

N = 1 000 000
Reference (std::sort)              21 ms  OK
I Can't Believe It Can Sort  SKIPPED (quadratic)
Selection Sort               SKIPPED (quadratic)
Insertion Sort               SKIPPED (quadratic)
Shell Sort                        184 ms  OK
Merge Sort                        112 ms  OK
Heap Sort                         432 ms  OK
QuickSort                         108 ms  OK

N = 2 000 000
Reference (std::sort)              33 ms  OK
I Can't Believe It Can Sort  SKIPPED (quadratic)
Selection Sort               SKIPPED (quadratic)
Insertion Sort               SKIPPED (quadratic)
Shell Sort                        316 ms  OK
Merge Sort                        192 ms  OK
Heap Sort                         828 ms  OK
QuickSort                         181 ms  OK

Code ici: https://github.com/NJdevPro/sorting_algs  (j'ai pas encore changé les gists)

L'algo de tri de référence de la lib standard Rust est exceptionnellement rapide.

Bon c'est un algo ultra sophistiqué, bien plus que les algos de tri des autres libs standard.

GPT-5.6 Sol s'ennuyait, résultats sur mon Mac Mini M4 Pro.

Versions:

• Go: go1.26.1 darwin/arm64
• C/C++: Apple clang version 21.0.0 / Target: arm64-apple-darwin25.6.0
• Java: javac 26.0.2
• Zig: 0.16.0
• Rust: 1.98.1

Build & run:

• Go: CGO_ENABLED=0 go build -o app . && ./app -n 1000000 -runs 10 -o go-1m.csv
• C: clang -O3 -DNDEBUG -std=c17 -Wall -Wextra -Wpedantic  -o app main.c && ./app -n 1000000 -runs 10 -o c-1m.csv
• C++: clang++ -O3 -DNDEBUG -std=c++17 -Wall -Wextra -Wpedantic -o app main.cpp && ./app -n 1000000 -runs 10 -o cpp-1m.csv
• Java: javac SortBench.java && java -Xms1g -Xmx1g SortBench -n 1000000 -runs 10 -warmup 5 -o java-1m.csv
• Zig: zig build-exe main.zig -O ReleaseFast -femit-bin=app && ./app -n 1000000 -runs 10 -o zig-1m.csv
• Rust: rustc --edition=2024 -O -o app main.rs && ./app -n 1000000 -runs 10 -o rust-1m.csv

Méthodologie:

L'objectif de ce benchmark n'est pas seulement de comparer les fonctions de tri fournies par les bibliothèques standard, mais également de comparer les performances obtenues lorsque les différents langages exécutent des implémentations aussi proches que possible des mêmes algorithmes.

Pour chaque langage, cinq tris sont mesurés : le tri de la bibliothèque standard, QuickSort, Merge Sort, Heap Sort et Shell Sort. Les quatre algorithmes maison utilisent les mêmes principes et optimisations dans chaque langage.
Les benchmarks sont réalisés avec deux tailles de tableaux : 1 000 000 et 2 000 000 d'éléments.

Neuf types d'entrées sont utilisés afin de ne pas mesurer uniquement le cas favorable d'un tableau aléatoire : données aléatoires, permutation sans doublons, tableau déjà trié, tableau inversé, seulement 100 valeurs distinctes, valeurs toutes identiques, tableau presque trié, distribution « organ-pipe » et motif en dents de scie.

Le même générateur pseudo-aléatoire SplitMix64, avec la même graine, est réimplémenté dans chaque langage. Les différents programmes travaillent donc sur les mêmes jeux de données.
Chaque combinaison est exécutée 10 fois. L'ordre des algorithmes est mélangé à chaque passage afin de limiter les biais liés aux caches, à la fréquence du processeur ou à l'ordre d'exécution.

La génération des données, la copie du tableau de travail et la vérification du résultat sont effectuées en dehors de la zone chronométrée. Seul le tri lui-même est mesuré.
Les résultats affichés correspondent à la médiane des 10 mesures, plus robuste qu'une mesure unique face aux variations ponctuelles du système. Les temps bruts de chaque run sont également conservés dans des fichiers CSV.

Pour Java, plusieurs passages de chauffe non mesurés sont effectués avant le benchmark afin que le JIT HotSpot puisse compiler les méthodes avant les mesures.
Tous les programmes ont été compilés en mode optimisé/release avec les options habituelles de leur toolchain, sans optimisation spécifique au processeur.

Résultats:

Compare directement les bibliothèques standard des 6 langages sur le cas le plus classique, avec 1M et 2M côte à côte.

Distingue les performances des langages/compilateurs de la qualité de leur bibliothèque standard. Ici, les implémentations de Shell/Merge/Heap/Quick sont volontairement quasiment identiques.

Montre l’intelligence des implémentations modernes : détection des données déjà triées, algorithmes adaptatifs, etc. Les écarts avec un QuickSort classique peuvent être énormes.

Cas de 1 million d’éléments mais seulement 100 valeurs distinctes. Cela montre quels tris savent exploiter efficacement les doublons.

Cas volontairement moins favorable aux QuickSort simples. Il montre pourquoi les bibliothèques standard modernes utilisent PDQSort, introsort, dual-pivot, ipnsort, etc., plutôt qu’un QuickSort scolaire.

Montre comment chaque stdlib se comporte lorsque N double. La ligne pointillée indique le ratio attendu pour nlog n, environ 2,10x entre 1M et 2M.

Conclusion:

Les résultats montrent surtout qu'il n'existe pas un unique « langage le plus rapide » pour trier des données : une grande partie des écarts vient de la qualité et de la stratégie choisie par la bibliothèque standard.

Sur les données aléatoires, Rust se détache très nettement avec slice::sort_unstable, devant le std::sort de C++. Go, Zig et Java sont sensiblement derrière, tandis que le qsort du C termine dernier.

Le QuickSort maison est particulièrement révélateur. Sur un million de valeurs aléatoires, C, C++, Go et Rust obtiennent tous un temps voisin de 43 ms. Lorsque l'algorithme est quasiment identique, les différences entre plusieurs langages compilés deviennent donc relativement faibles.

Les bibliothèques standard montrent en revanche des comportements très différents sur les données particulières. Certaines reconnaissent très efficacement les tableaux déjà triés, les nombreuses valeurs identiques ou certaines distributions structurées. Java est notamment extrêmement rapide dans plusieurs de ces cas, alors que Rust domine nettement les données aléatoires.

Le passage de un à deux millions d'éléments donne également des résultats cohérents : sur les cas classiques, les temps augmentent généralement d'un facteur proche des ~2,1 attendus pour un algorithme en O(n log n).

Au final, le résultat le plus intéressant n'est probablement pas qu'un langage gagne partout, mais que les algorithmes maison donnent souvent des performances proches entre langages, alors que les implémentations des bibliothèques standard peuvent présenter des écarts considérables. Le choix de l'algorithme et la qualité de son implémentation comptent donc au moins autant que le langage utilisé.

J'ai été voir sur internet, c'est complètement fou : tu peux tout payer avec une carte qui tient dans la poche    On peut dire ce qu'on veut de Elon Musk, il n'en reste pas moins qu'il révolutionne toutes les technologies qu'il approche !!!

Rien à dire, c'est propre.
J'avais bien noté que le sort de la std lib de zig était moisi.
Je me demande pourquoi le heapsort de zig n'est pas terrible alors que les autres algos sont quasiment au niveau de C/C++. Tu as le code quelque part ? (tu peux demander à sol ?)

Et comme ça t'es pas obligé de trimballer ton téléphone partout pour payer, juste une petite carte et hop !

Pense à acheter un porte-feuille anti RFID, y'a des gens peu scrupuleux dans le métro.  
J'ai une amie à qui ils ont volés 5000€ en 2 secondes.

Ça y est on a Opus dispo sur antigravity, on va pouvoir faire des vraies battle avec Gemini.

Opus on l'aime bien au village il est bien brave

Je trouve que GPT 5.6 fait du meilleur boulot, typiquement c'était mieux pour les benchmark de much.
 
Pareil si je le lache sur du Go, il m'a l'air meilleur, vibe au doigt mouillé évidemment.

C'est clair que GPT est devenu vachement bon. Même sur la partie gratuite, qui a visiblement un contexte très limité, le code est généré hyper rapidement et souvent correct. Mais il ne fait pas l'effort que Claude fait de l'exécuter pour voir s'il y a un soucis.
J'imagine que sol fait le boulot, au vu du rapport qu'a produit Flaie.

En offre payant si, pour le Zig par ex il a installé le tooling de son côté car y'a un truc qu'il était pas sur pour la 0.16.0 et pour pas me filer du code qui passe pas il a fait ça en préventif.

Petite question: vous payez, vous, ou c'est la boîte qui paie ?

Je paye avec mes propres deniers, GPT tous les mois. Claude ça arrive que je le coupe, si j'ai des idées dans la tête je reprends Claude comme ça j'alterne avec GPT quand j'ai plus de tokens.
 
À la COGIP on a Copilot avec un nombre de crédits par mois (largement suffisant pour ce que j'en utilise pour l'instant).

Je me demande pourquoi le heapsort de zig n'est pas terrible alors que les autres algos sont quasiment au niveau de C/C++. Tu as le code quelque part ? (tu peux demander à sol ?)

 
Boite.

 
Et Java avec GraalVM ça donne quoi ?

https://topaz.github.io/paste/#XQ...

 
L'entreprise paie pour Claude, un compte à 125$ donne tellement de Fable 5.1 c'est l'opulence en vrai.

native-image 25.0.4.1 2026-08-18
GraalVM Runtime Environment Oracle GraalVM 25.3.4.1+1.1 (build 25.0.4.1+1-LTS-jvmci-25.3-b22)
Substrate VM Oracle GraalVM 25.3.4.1+1.1 (build 25.0.4.1+1-LTS, serial gc, compressed references)

Moins bon que la JVM chaude.

#tiktok On a trop banalisé les perfs d'une JVM bien chaude #/tiktok

 
C'est une contrepèterie ?

JVM bien chaudes près de chez vous ?

Toi tu vas encore acheter des heures de ménage  

La France en 27e place au classement PISA.
 
Loin derrière les USA (13e)  
 

 
Je suis pas surpris.
 
Par exemple l'Angleterre top 10 : L'Angleterre recueille ses gros efforts depuis des années dans le primaire. Apprentissage de la lecture dès 4 ans, maths journaliers tout au long du primaire.  
A noter que si globalement, le UK dépense moins que la France pour l'éducation, ça comprend aussi les universités.
 
Parce que pour le primaire, surprise :
 

 
Dépenses annuelles par élève du Primaire:
 
FR: Environ 7 400 € (Inférieur à la moyenne de l'OCDE)
UK : Environ 8 200 € (£7 000) (Supérieur à la France)
 
Au UK, point de Bac général ultra couteux. 3 à 4 matières seulement choisies par les élèves (si leurs résultats au GCSE le leur permet).
 
C'est pour l'université que personnellement, je considère le UK comme un scandale à cause du coût prohibitif des études et de l'endettement subi par les jeunes qui veulent étudier.

HLM, ton multi

Moi j'ai jamais trouvé comment configurer les sites d'actualités pour me donner "la une" d'il y a cinq jours. Alors un peu de respect.

Je le savais !

Après le classement n'a pas dû changer des masses depuis 5 jours.

 
C’était sa façon de te dire qu’on en a déjà discuté ici il y a quelques jours maintenant.