Reprise du message précédent :

Bah ça va.
L'IA t'as refait ton budget ?

Ce qui m'emmerde c'est que c'est assez difficile à suivre. C'est passionnant, certes, mais c'est chiant.
Les sujets sur les harness, le tooling, les modèles, l'effort, l'intégration, l'hébergement/ZDR, le local, les autorisations clients, ..
 
Là j'ai sous la main Fable, Astra, Opus et Sol mais à qui je donne quoi à faire

Les alternatives sont souvent bien pires

 
c'est un truc qui n'est pas propre aux LLM, c'est juste une tendance actuelle avec les réseaux sociaux.
 
Par ex je joue à Factorio. Si tu vas sur Reddit ou YouTube, tu vois les gens faire des speedruns, débattre des meilleurs blueprint, toujours dans le but de maxxer tout. Ça m'a fait arreter le jeu.
J'ai repris une partie, je maxx rien du tout, je joue juste comme ça me vient, et je m'amuse beaucoup avec
 
Des fois faut juste y aller et faire (pour ta question sur les LLMs, à ce stade que tu prennes le stack Anthropic ou OpenAI, t'as un bon truc, je suis pas certain que ça fera une grosse difference sur ton resultat final (fais avec celui dont tu préfères le style / personalité, parce que tu vas beaucoup lire sa prose)

J'évite globalement la logique en dehors de l'outillage propre au projet mais just semble nettement moins attardé quand même.

Hagrid

Je capte pas trop ton truc de réseau sociaux
 
J'ai Anthropic et OpenAI, donc accès aux 4 modèles cités. Avant Astra et Fable 5.1 j'utilise Opus 4.8 en orchestrateur dans Claude Code, avec Opus 5 en subagent pour un peu de code et autres (build, etc), Sol 5.6 via codex exec pour le code et Fable 5 en gate/review.
Maintenant j'ai encore plus puissant mais je sais pas comment les utiliser (je suis quand même passé sur Fable 5.1xghigh en orchestrateur, c'est un autre level ces trucs là)

Après, pour un petit projet perso, make fait le taf, mais dès qu'on arrive à des niveaux industriels, ça devient horrible, et j'utiliserais autre chose.

 
Avant on faisait n'importe quoi mais on ne le savait pas car personne n'échangeait.
Maintenant on a facilement accès à ceux qui font "mieux" donc on essaie de faire la même chose et de minmaxer plein de trucs

this

J'ai lurke pas mal de temps avant de créer mon compte, les posteurs de ce topic me faisaient peur  

Le C++ est toujours une découverte https://godbolt.org/z/4edjr58a9

 
Merci Ikea, je vois que vous maitrisez bien votre affaire, vous avez bien fait de prendre les agents IA les moins chers du marché pour votre service client  

Fake, c'est une capture d'écran de ta commande Dell

Et revenez pas la ramener sur l'AGI, ce débat appartient au passé et Anthropic est passé à la superintelligence maintenant :  

Les gens qui agentisques, vous êtes à quel niveau de parano entre gatsu qui fait tourner openclaw en admin sur sa machine perso et dans un conteneur dans une vm sur le cloud?

Ça me choque pas des masses, les tailles sont toutes en octets pas en bits, la taille minimum de C/C++ est 1 (même une structure vide prend 1 octet), et en bonus c'est IB et quasiment toujours `int` quand non spécifié. Si tu regardes le sizeof de ton Classic, c'est 4.

(techniquement avec  __attribute__((__packed__)) tu descends à 1, dans clang et GCC).

 
Niveau très élevé, (même sur mes projets persos).  
 
Concernant le pro, on vérifie tout et les agents n'ont jamais accès à des choses critiques en écriture. On a essentiellement du monitoring (donc du read-only par définition) (fabuleux au passage et VRAI progrès par rapport à l'ère pre-AI).
Même concernant nos outils d'analyse SQL (toujours essentiellement pour le monitoring), les agents n'ont accès qu'à une copie de la base de donnée et en lecture seule.  
Pour ce qui est de la production de code, on vérifie tout pour le moment. Et une grosse partie du code est toujours produite à la mains sur notre principal produit (on est en transition). Par contre, on va plus loin s'agissant par exemple de modules ou de choses nouvelles. Là, on est déjà à 100% du code produit par IA, mais bien sûr on vérifie tout pour le moment.

 
Tiens, je me suis amusé à tester le même programme en Java, D, C++, Rust, Zig, histoire d'avoir une idée des perfs actuelles.
 
Quelques algos de tri classiques, traduits automatiquement par Claude code. J'ai commenté les plus lents en n^2
 
https://gist.github.com/NJdevPro
 
Je les ai lancés avec l'optimisation standard pour la perf sur godbolt. Et voici ce que je vois, du plus rapide au plus lent:
 
Zig,  
Rust et C++ à égalité,  
Java,  
D
 
Ca vaut ce que ça vaut.

relecture bien sur
pour les trucs qui se font sans acces particulier il tourne dans une VM avec pas mal de données mais sans droits root
pour les trucs un peu tricky, j'ai un hyperviseur sur lequel il a la main pour déployer des VMs au besoin + une VM ou il est root (notamment pour des question d'accès aux logs )

Merci d'ajouter Go.

 
Ce genre d'exercice le problème c'est que le niveau d'expertise dans le langage peut vite changer la donne (et le niveau du compilateur aussi bien sûr) c'est vraiment pas évident d'en tirer quelque chose, ni d'en généraliser un comportement dans un gros soft (on frôle le micro-benchmark ici)

Disons que j'en étais resté à C "the choice of type is implementation-defined, but shall be capable of representing the values of all the members." et C++ "on a aussi les enum class avec underlying type int", je n'avais pas fait gaffe que l'enum C en C++ avait une range 'logique' aussi subtile (je mets logique car en effet derrière c'est souvent un int)

Du coup c'est marrant de monter la valeur de B à 4 (3 bits) ou de passer A à -1 (signed) pour voir la range logique bouger à [-4, 3]  

Done.
C'est quel compilateur et quelles options de compile ?

Avec gc 1.26 pour x86-64, sans option, c'est très rapide, je dirais comparable à Java. L'assembleur est très lisible.

Oui je sais bien, mais quand je fais ce genre de truc, je cherche pas à exploiter des trucs comme le SIMD (encore que pour le tri, c'est difficilement exploitable), mais à coder comme je le ferais normalement dans le langage. Je laisse les experts optimiser la librairie standard. En général je privilégie la clarté du code, et le compilateur s'en sort mieux dans les optimisations. Là, les algos sont suffisamment simples pour que le compilo fasse son taf. Ca donne une idée de l'ordre de grandeur à attendre dans des conditions normales.

where repo ? quel archi tu as ?

Je balance tout ça sur Godbolt. Pas envie d'installer tous les compilateurs sur ma machine (windows).

si archi amd64
GOAMD64=v3 (ou v4) CGO_ENABLED=0  
 
si arm64 ca dépends du cpu pour la valeur de GOARM64
 
tu peux aussi faire un pprof et le nommer default.pgo et tu relances un go build  
 
mais peut être pas sur godbolt

Je ne connais pas l'archi de Godbolt. On ne sait même pas si leur réseau de serveurs est homogène ou hétérogène, on part dans l'hypothèse qu'ils sont homogènes. Du coup les résultats d'une seule exécution ne sont pas représentatifs, il faut en balancer plusieurs pour avoir une idée. Donc je laisse le compilo sélectionner l'archi du binaire.
Je me contente de O2 pour gcc , -O pour rustc, -O ReleaseFast pour Zig.

Mais si tu veux essayer sur ta machine, tu peux récupérer le code.
PS: c'est zig 0.15.2, la 0.16 a complètement changé la lib std, le changement est lourdingue et godbolt fait un SIGKILL à l'exécution.

Ok donc c'est bancal

Mon Claude perso a accès à mon dépôt GitHub perso, il écrit directement sans supervision et déploie sur mon cloudflare.

Mon agent pro est en mode yolo, il a le droit de faire de façon autonome tout ce que je peux faire : lignes de commande (donc accès indirect à la prod, la stack prod demande en général un second humain pour approuver), approuver ou soumettre des PR, et accès complet à internet et à ma machine virtuelle.

ça vaut ce que ça vaut, comme j'ai dit

Pour info Opus dit que ton impl est pas bonne, prob dans merge et shell sort, et tu peux éviter des allocations.

Qu'est-ce qu'il dit précisément ?

Sur mon Mac Mini M4 Pro.
 
ton gist

 
celui d'Opus

 
Ce qui est invalide dans l'implémentation originale

• Merge sort faux : dans merge(), la dernière boucle (reste de la moitié droite) oublie k++. Les éléments restants sont tous écrits au même indice et le tableau final n'est pas trié. Vérifié sur 1M d'éléments : slices.IsSorted renvoie false. Le temps affiché mesure donc un tri incorrect.
• Shell sort partiellement faux : la suite d'écarts int((gap-1)/2.25) peut passer de 2 ou 3 directement à 0, sans jamais faire la passe finale avec un écart de 1. Le tableau reste alors mal trié pour n = 4 à 7, 12 à 19, 30 à 47, etc. Ça fonctionne pour n = 1 000 000 par chance.
• Aucune vérification des résultats pour Shell, Merge, Heap et Quick : inOrder() n'est appelé que dans les deux tris commentés, ce qui explique que le bug du merge sort soit passé inaperçu.
• Mesure faussée : iCantBelieveItCanSort et selectionSort appellent fmt.Println(inOrder(arr)) à l'intérieur de la fonction. La vérification et l'affichage sont donc inclus dans le temps chronométré.
• Détails : heapSort fait une dernière itération inutile avec i = 0 (swap(0, 0)). rand.Seed est obsolète depuis Go 1.20.

Ce qui a été optimisé

• Merge sort, allocations : un seul buffer de n/2 alloué une fois, au lieu de deux slices créées à chaque appel récursif, et seule la moitié gauche est copiée avant la fusion. Sur 1M d'éléments : de ~2 millions d'allocations et 164 Mo alloués à 1 allocation et 4 Mo, de 213 ms à 139 ms.
• Merge sort, hybride : tri par insertion sous 12 éléments et test « moitiés déjà dans l'ordre » (139 ms à 120 ms). Ces deux ajouts changent l'algorithme : à retirer pour une comparaison fidèle entre langages.
• Heap sort : heapify écrit en boucle au lieu d'être récursif. C'est le même algorithme, mais Go n'élimine pas les appels terminaux, contrairement à GCC/Clang en -O2. Gain non mesuré.
• main() : suppression du tableau ord, alloué pour rien, et un seul buffer de travail réutilisé (copy) au lieu d'une copie allouée par tri. On passe de 6 tableaux

Il raconte de la merde.

Voir au dessus j'ai edith

On veut donc le resultat godbolt desormais

Et vite je vais bientot me coucher

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