Nicolas Boulay a écrit 16008 commentaires

Rien que pour la France, les chiffres annoncés sont entre 50 et 100G€/an. Le budget de l'état français tourne autour de 300G€/an.

"La première sécurité est la liberté"

On parle d'une addition et d'une multiplication, tu as vu la tronche de ton code ? Qui peut comprendre en 10s ce qu'il fait exactement ?

"La première sécurité est la liberté"

Tu compares int_of_float avec ça ?

    let x : u8 = 3u.to_u8().expect("Integer Overflow");

    let x : u8 = 3u as u8;

"La première sécurité est la liberté"

On pourrait aussi regretter que Rust wrap en cas d’overflow (et va donc silencieusement produire de mauvais résultats) au lieu de trap ou un truc du genre.

Ce qui est idiot en plus, c'est que ce si tu fais du code qui utilise cette propriété (genre filtre numérique), l'optimisateur se croit avec des entiers qui ne wrapent pas, et te détruit ton code.

"La première sécurité est la liberté"

Il y a quand même des cas ou cela marche, on dirait :

We find most cases of tail _recursion_ convert reasonably well to loops, and most cases of non-recursive tail calls encode state machines that convert reasonably well to loops wrapped around enums. Neither of these are _quite_ as pretty as the tail-call-using variants, but they do work and are "as fast"*, as well as idiomatic for C and C++ programmers (who are our primary audience).


"La première sécurité est la liberté"

J'avoue qu'avoir enfin un remplacement pour le C, est vraiment bienvenue. Rajouter l'équivalent des type somme, les fonctions de 1er ordres sont vraiment bien. Il est aussi nécessaire de mieux gérer la mémoire.

Mais j'ai été déçu d'apprendre qu'ils ne pourront jamais de faire de transformation automatique appel récursif vers une boucle, ce qui est la base quand on veut avoir une base de code fonctionnel. Si le langage devient aussi complexe et subtil que C++, pourquoi ne pas rester à C++ ?

Bref, je suis un peu déçu.

"La première sécurité est la liberté"

mais par exemple compiler un gros projet ça risque de stresser plus ton hdd/ssd que ton processeur au final,

Ce n'est pas une compilation Java non plus (spécial dédicace à Eclipse), si le PC a assez de RAM, j'imagine que la totalité des sources finira dans en cache très rapidement.

Je trouve que c'est quand même important d'en être conscient quand on écrit du soft pour la performance.

Oui, si tu peux te permettre d'écrire du code spécifique pour une machine, et que tu ne réutilises pas de code, ou que tu ne veux pas écrire du code "portable".

"La première sécurité est la liberté"

J'imagine bien que la syntaxe permet des subtilités. Mais je croyais que le C++ avait calmé les concepteurs concernant les subtilités des langages. Cela peut devenir une énorme source d'erreur.

"La première sécurité est la liberté"

Ça tombe bien c'est l'un des gros intérêt de rust de gérer la mémoire de manière fine et haut niveau.

Je parlais des binding C. j'ai vu le problème en ocaml et en Perl, par exemple.

"La première sécurité est la liberté"

Quitte à refaire un langage, pourquoi créer une séparation artificielle des concepts quand il n'y en a pas besoin ? Les closure en ocaml sont détecté quand ils sont à l'intérieur d'une autre fonction, pourquoi faire 2 syntaxes différentes ?

Ensuite pour le comparer à Ocaml, je doute que tu fasse une bibliothèque qui s'interface avec du C aussi facilement en Ocaml qu'avec rust (non, on ne compare pas 2 langages sur une exemple de 5 lignes…).

J'ai regarder rapidement, et cela semble être la même chose qu'en ocaml avec une déclaration "externe". La complexité est généralement dans l'accès aux données structurés et dans la gestion de la mémoire, pas vraiment dans les appelles de fonction avec des paramètres scalaires.

"La première sécurité est la liberté"

Pourquoi faire aussi complexe ?
```
fn twice(x: int, f: |int| -> int) -> int {
f(x) + f(x)
}

fn main() {
let square = |x: int| { x * x };

twice(5i, square); // evaluates to 50

}
```En ocaml, on peut l'écrire :

let twice x f = (f x) + (f x)

let _ =
let square x = x *x in
twice 5 square

Pourquoi créer un nouveau langage pour faire aussi verbeux et compliquer qu'avant ?

"La première sécurité est la liberté"

Je peux juste dire que les micro benchs ont rarement un intérêt, car ils sont encore plus difficile à interpréter que les benchs applicatifs.

J'imagine qu'un "make -j" d'un noyau Linux particuliers, donnera une bonne idée de la vitesse des CPU, et du système d'IO sur des données petites.

Des tests utilisant des compresseurs video (ffmpeg, mencoder) ou audio (lame) peuvent servir pour les calculs lourd (entiers ou flottant selon les options).

7zip/gzip peuvent servir pour le bench de calcul d'entier.

Je crois qu'il existe des clients pour exciter des serveurs web et mesurer les temps de réponse, il doit donc être possible d'installer des applications web commune, et comparer ses temps, avec un PC classique.

Utiliser des vrais applications permet aussi de mesurer le degré d'adaptation/d’adaptabilité des softs avec le nouveau cpu. Si le cpu a plein de particularités pour aller vite, mais qu'aucun soft ne les gère, un micro bench dira que le cpu est le plus rapide, mais il n'aura aucun intérêt pratique. A l'époque de l'arrivé 64 bit, les soft de compression vidéo n'utilisant pas de code assembleur était forcément plus lent que leur version 32 bit optimisé à la main.

"La première sécurité est la liberté"

Je serais curieux de voir les vrai cas d'usage. J'avoue que depuis que j'ai "dc -l" sous la main (ou même les calculs fait par google), j'ai du mal à voir l’intérêt d'une calculatrice.

"La première sécurité est la liberté"

Une liseuse avec un bon système tactile devrait faire une calculatrice efficace.

"La première sécurité est la liberté"

Cela évite d'utiliser des pointeurs :)

"La première sécurité est la liberté"

Une liseuse, cela peut être un ARM9 à 200Mhz. Il n'y a pas de fpu, mais c'est toujours plus rapide que les cpu dédiés à 20Mhz.

"La première sécurité est la liberté"

Ou alors tu le code toi-même : un vector pour le stockage et un hashmap pour l'association composant <-> entity.

"La première sécurité est la liberté"

Pour chaque entité tu alloues tous les composants ? Pourquoi pas seulement, les composants utiles ?

"La première sécurité est la liberté"

Les indirections sont bien plus local que dans un système classique.

"La première sécurité est la liberté"

Une personne en 4/5ième (80%), à 5 semaines de congé de 4 jours.

"La première sécurité est la liberté"

Pour moi, le layout mémoire idéal d'un système à entité consiste à regrouper par composant.

L'entité est simplement un nombre, nombre qui sert de clef dans un conteneur à composants, pour retrouver les composants.

L'idée est que chaque système manipule un nombre réduit de composants sur un grand nombre d'entités, ainsi on bénéficie d'une meilleure localité d'accès pour les caches.

Le conteneur peut être une hashmap ou un arbre.

"La première sécurité est la liberté"

Dans ce cas, il pourrait trouver une tablette chinoise, sans wifi ni bluethout de 5 à 7", cela fera bien mieux l'affaire.

"La première sécurité est la liberté"

J'aurais fais les mêmes choix de soft, mais pourquoi ne pas en faire une application libre pour smartphone ?

J'imagine que le hard est fun à faire, mais cela limite pas mal la diffusion du projet.

"La première sécurité est la liberté"

C'est pas Obiwan Kenobi, le dernier espoir ?

"La première sécurité est la liberté"

Après ma position ce n'est pas que les GPU sont inutiles, loin de là. C'est juste que parler d'un rapport 100, c'est n'importe quoi. Ni en théorie, ni en pratique, on atteint le rapport 100. Même en comparant un CPU d'il y a trois ans à GPU de cette année.

Ok. J'étais rester sur des GPU avec >1 TFlops de puissance, et des cpu qui tournait à 60 Gflops. (2 instructions fpu/cycles/cpu).

"La première sécurité est la liberté"