Nicolas Boulay a écrit 15824 commentaires

#pragma omp for
 for(int n=0; n<10; ++n)
 {
   printf(" %d", n);
 }
 printf(".\n");

Cela va te lancer n thread en découpant la clause for en morceau. Le système se débrouille même si tu peux aussi le guider. Sur du code numérique, c'est assez facile du moment que tu comprends que tu ne peux pas partager d'information entre threads.

Si tu as des ressources intéressantes à ce sujet je suis preneur, si tu estimes que ça permets vraiment d'estimer les coûts d'un projet en fonction des langages utilisés.

https://en.wikipedia.org/wiki/COCOMO ?

Je retient surtout : ab*(KLOC)^bb. Cela veut dire que la difficulté n'est pas linéaire au nombre de ligne, mais augmente plus vite.

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

openMP n'est pas une api C. Ce sont des directives de compilation pour générer du code multithread.

"la taille d'un code comme un indice par rapport au fait qu'il soit lisible"

Non, mais sur sa concision. Il y a eu des études portant sur la productivité (cocomo) quelque soit le langage, la productivité en ligne de code par unité de temps est la même.

"De quel domaine parles-tu? Dans la discussion, on parlait de façon assez générale il me semble…"

Je pensais à l'IHM.

"Ici, ça semble être le calcul scientifique?"

Non, il y a aussi manipulation de symbole.

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

Le C génére bien de l'assembleur.

Ces langages étant turing complet et bas niveau, on peut tous faire avec ou presque. Après, il y a une question de verbosité. Le code généré est plus gros, que ce tu ferais à la main, cela décale ton langage vers la gauche dans le graphe.

Donc, un langage générant du C peut être plus rapide et concis qu'un code C fait main.

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

"Battait, ça veut dire que C a rattrapé Lisaac ensuite?"

Oui, car lisaac générant du C, c'est facile de comprendre pourquoi il est plus rapide. Au pire, tu copie/colle sa sortie et tu dis que c'est du C manuel.

"Et sinon, le C++ n'a pas ces problèmes il me semble, et pourtant les bench disent souvent la même chose: il est souvent plus lent que le C."

Dans le shootout, il est régulièrement premier grâce à openMP et les templates.

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

"je suis intrigué qu'il n'ait pas réussi s'il est meilleur"

Le code du compilo n'était pas simple du tout (détermination du type réel de chaque objet). Et le dev principal a coupé les ponts du jour au lendemain.

Les codes c++ et C utilisent massivement openMP qui n'existe pas dans le monde ocaml.

"Ce benchmark est à 2 dimensions: taille du code (et pas expressivité) à l'horizontale et vitesse d'exécution sur la hauteur, si je ne me trompe pas?"

Non, c'est juste l'affichage de ce graph, il est intéressant car la case la plus intéressante est en bas à droite : compact et rapide.

"ils mesurent la taille du code en octets, en ayant enlevé commentaires et espaces, et en compressant le texte ainsi obtenu. Franchement… je trouve difficile de trouver une façon moins pertinente de mesurer la taille des codes."

Au contraire, cela évite de parler de la définition de la "ligne de code". La compression limite l'augmentation de taille des langage verbeux par rapport à ceux abusant des symboles.

"il n'y a que des algo de calcul, donc pas d'accès aux ressources, de gestion d'IHM, et caetera. Donc, comme d'hab avec les bench, résultats à n'utiliser que pour des optimisations des "zones de calcul"."

C'est vrai. Mais les problèmes de logiciels dans ce domaine, sont liés aux algos utilisés. Il faut aussi que la taille du benchmark reste accessible aux codeurs. Il y a aussi des benchs manipulant des symboles (de mémoire, le truc qui manipule de l'ADN).

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

J'ai écrit et optimier une IA en java. La vitesse est digne d'un gcc -O0, pas d'inline des getter/setter, etc… Cela ne peut pas être rapide, même les "clause if" n'étaient pas sorti des boucles.

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

Il n'y a pas un seul benchmark, mais une dizaine. L'algo est fixe.

Haskell vu sa gestion de la mémoire à forcément des cas pathologiques.

Pas la peine de vendre du rêve!

Lisaac battait le code C dans la plus part de tests donc bon. Le problème n'est pas de faire un compilo intelligent. Le problème est de faire un langage avec suffisamment de sémantique pour qu'un compilateur puisse faire un boulot intelligent. Par exemple, le C fixe le layout mémoire de ces structures de données, et 2 pointeurs de même type sont censé pouvoir pointé sur la même zone mémoire. Ces 2 caractéristiques peuvent être des killers de performances. En gros, c'est le boulot du codeur, et le compilo ne peut rien faire.

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

Le dev de Lisaac est arreté. Le site est mort. Il y a eu un gros article sur les concepts manipulés publiés dans linux mag en début d'année dernière de mémoire.

http://www.ed-diamond.com/produit.php?ref=lmag148&id_rubrique=1

Comme benchmark :
http://benchmarksgame.alioth.debian.org/u32/code-used-time-used-shapes.php

Lisaac a été premier de ce benchmark quelque temps avant que les téchniques soient copié pour les code C et C++.

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

Sauf qu'on aura toujours besoin de langage comme C/C++ pour implémenter des trucs qui doivent aller vite, comme les interpréteurs de langage haut niveau ou des compilateurs. Chacun son domaine.

Ou que non alors ! Lisaac a déjà prouvé que l'on peut être du niveau de smaltalk en terme d'expressivité et battre le C++ en terme de vitesse.

OCaml est de trés haut niveau, mais les optimisations dans la génération de code sont minimes (pas de déroulage de boucle ou de spécialisation de fonction). Il est pourtant dans le top10 en terme de vitesse.

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

Scala est un langage fonctionnel, pas java…

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

Sans doute, mais quand tu as 2 niveaux de fold, mon cerveau fait un overflow.

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

Scala n'est pas du tout dérivé de java, il produit du code pour jvm, c'est tout. Et je suis d'accord que la syntaxe est encore pire que celle de Ocaml.

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

objet ou pas objet, le but est de pouvoir parcourir un arbre en séparant la définition de l'arbre et les parcours.

Et pour ça, les types sommes et le "pattern matching" sont totalement imbattables. C'est tellement puissant que je ne comprends pas pourquoi cela n'a pas été ajouter au C++.

C'est une très bonne alternative pour tous les cas ou il y a une pléthore de petit objet à gérer ensemble.

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

Quand on voit la complexité du truc…

type base_t
type derived_t
type t = 
     | BASE of base_t * t list 
     | DERIVED of derived_t * t list

let rec visitor accumulator t =
   match t with
       | [] -> List.rev accumulator
       | BASE (base_info, suite) :: tail 
                    -> let a  = visitor ((foo_base base_info) :: accumulator) tail in
                       visitor ((foo_base base_info) :: a) suite
       | DERIVED (derived_info, suite) :: tail 
                    -> let a  = visitor ((foo_base base_info) :: accumulator) tail in
                       visitor ((foo_derived derived_info) :: a) suite
(*execution : *)
let resultat_list = visitor [] my_data_tree in
 ...

Et encore, dans le match on peut mettre des bouts d'arbres comme :
| BASE (base_info, BASE (base_info2, []))

Le petit point difficile est l'usage d'une liste dans le type, mais on peut utilisé un type Option pour faire la terminaison de récursion.
Pour info :
(item :: list) permet d'ajouter un item au début d'une list ou de décomposer une liste dans les matchs.
(foo plop) permet d'appliquer la fonction foo au paramètre plop

En conclusion, vive les types sommes et le "pattern matching" d'arbre.

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

Je n'aime pas trop le commentaire interne. Cela empêche souvent d'avoir la fonction entière sur un seul écran. Décrire l'intention au dessus de la fonction est pas mal. J'aime bien aussi les microfonctions qui porte le nom de ce qu'elles font même si il s'agit d'une ligne.

Si un compilateur vérifie le code, très peu vérifie les commentaires (si cela existe : nom de fonction avec erreur, ( ou [ non appairé, etc… ).

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

Du moment, qu'il y a des gens pour y croire :)

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

C'est aussi la différence entre la lettre et l'esprit. L'esprit importe à ceux qui ont créé le concept, la lettre pour les juristes.

Sinon, c'est bien connu que la GPL ne fait pas confiance dans la nature humaine, au contraire de la BSD.

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

Dans une guerre des standards, en général, il en reste un à la fin. Ce qui n'a pas été le cas.

Par défaut, un truc sous DRM est mille fois plus chiant que le truc piraté (copy/transfert/sauvegarde compliqué).

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

Cela me déprime d'avoir encore raison, 10 ans plus tart. Je parle beaucoup de mp3, qui ont laissé tomber les DRM, mais cela reste toujours valable pour les ebook et les vidéos.

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

Non, chaque fichier a sa propre licence, compatible entre elle. Et certains sont sous v3. Amusant, non ? lxr n'est pas pratique pour trouver un exemple. Mais je l'avais fait à une époque.

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

Tient cela me rappelle ce texte, que j'ai écrit, y'a presque 10 ans : (tin, je suis vieux :/)
http://www.unixgarden.com/index.php/gnu-linux-magazine/aliennation-2

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

Si tu ne peux pas changer un binaire pour cause de DRM, par recompilation, cela reste du libre légalement. Mais on est loin de l'esprit. C'est même la raison de la création de la GPLv3. La GPL n'est pas le libre, on est d'accord. Mais le libre a été créé pour que les utilisateurs gardent le contrôle de leur code pour avoir un vrai contrôle sur leur donné. La tivoisation est un moyen détourner de casser les principes du libre.

Tu parles de la GPLv3 mais la lgplv2 l'interdit aussi (indirectement, car il doit être possible de remplacer une lib lgpl fournis par une version compilé par ces soins).

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

la LGPL dispose d'une clause assez spécial pour empécher qu'une library libre devienne dépendante de donné non libre ;

Vous pouvez modifier votre ou vos copie(s) de la Bibliothèque […] pourvu que vous satisfassiez également à chacune de ces conditions :
[…]
d) Si une facilité dans la bibliothèque modifiée se réfère à une fonction ou une table de données devant être fournie par une application utilisant la facilité, autre qu’un argument passé quand la facilité est invoquée, alors vous devez faire un effort en toute bonne foi pour vous assurer que, dans l’éventualité où une application ne fournirait pas une telle fonction ou table, la facilité restera opérationnelle et effectuera une partie quelconque de sa finalité de façon sensée. https://www.gnu.org/licenses/lgpl.html

Et je pense qu'une clef secrète peut tout à fait rentrer dans ce cadre.

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

"Secure Boot", ne va vérifier que grub, rien de plus.

"Secure Boot et d'autres idées sur les signatures, on peut signer la chaîne complète, et donc n'accepter que ce qui est "acceptable" par toute la chaîne."

Mais cela impose plein de complexité sur les mise à jour de faille. Le fameux TCPA voulait pousser ce genre d'approche, il y a des années. Dans ce cas, il faut savoir qui contrôle la clef master qui gère le tout. Dans toutes les implantations, c'est l'utilisateur de départ qui le gère. Si les clefs appartiennent à un tier, il y a tout de même un risque énorme de fuite.

Le seul moyen vraiment fiable serait d'avoir un secret unique par machine. Ainsi, une fuite n'aurait pas d'intérêt. Mais la mise en place serait d'une lourdeur énorme.

"Genre TiVo, qui utilise du libre (et même de la GPL bien en copyleft), rien de nouveau."

Ils sont au courant que des bouts de Linux sont sous GPLv3 ?

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

Sauf que l'outil qui fournit la clef doit être sacrément intrusif pour être efficace. Tellement intrusif, que je ne vois pas comment il peut exister sous un os libre, à moins de le mettre dans un superviseur contrôler par le BIOS.

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