Nicolas Boulay a écrit 16281 commentaires

fsync() à une sorte de sémantique d'urgence, qui fait ralentir tout le système.

Souvent on voudrait juste un fdone(), quitte à le mettre dans un thread. Mais j'ai aucune idée de comment il est possible de garantir l'atomicité d'une modification sans fsync(). En gros, on veut écrire 64K, mais en cas de problème on veux soit la version précédente sois la nouvelle version mais pas un mixte. Je pense qu'un simple write (sys_write()) doit avoir cette sémantique avec les nouveaux systèmes de fichier mais que l'on a aucune idée de la taille max qu'il peut gérer comme cela (une page de 4K ? un buffer autour de 1Mo ? une grosse page de 4Mo ?).

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

et ce qui est important c'est que c'est toi qui veut nous vendre quelque chose, donc c'est à toi de nous convaincre.

Je crois surtout que je vais arrêter de me stresser dans des querelles stériles, cela n'apporte rien du tout, et cela ne sert à rien. A te lire, cela desserre aussi le projet. Donc, je vais oublier linuxfr pour la suite de Lisaac, inutile de perdre le temps de tout le monde.

Je suis toujours intéresser pour comprendre les vrai besoins des utilisateurs de langage, cela m'a toujours passionner. J'imagine que tu peux comprendre la différence entre "je ne peux pas avoir un temps de compilation de 10 minutes, vu que je passe mon temps à faire des build pour avoir des résultats intermédiaires à coup de printf() à l'ancienne", et "ton produit à compile global forcément lente est bon à jeter, je ne peux pas débugguer dessus". (je fais aussi du debug à coup de printf(), mais avoue qu'un outil plus costaux serait mieux, d'ailleurs souvent gdb rend la recompile inutile). Je devrais utiliser la réponse classique en open source : "send me the patch !". :)

Tu critique Timaniac qui critique Lisaac, mais tu est le premier à en balancer des conneries sur tout ce qui n'est pas Lisaac...

Tu parles encore de Javascript ? Ou de lisp ? (pour info, lisp, c'était de l'humour)

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

"+" à la place d'un "-", je veux bien comprendre que cela soit difficile à attraper statiquement, mais cela dépend aussi de comment tu écris ton contrat. Il y a des contrats ou tu utilises des propriétés à conserver, genre "f(a,b)=f(b,a)", cela permetrait d'attraper certaine erreur dans les équations. On pense aussi mettre une lib qui vérifie la dimension physique des opérations (cela n'aura pas le + à la place du -, certe).


De manière générale, les bug qui me prennent le plus de temps sont des bugs impossible à trouver par un compilateur.

Et sur la masse total d'erreur ?


Autant pour une version finale, pas de problèmes pour un build d'une demie heure, autant pour une compilation de debugage, c'est poubelle direct.

C'est quelques minutes pour le compilateur au total. C'est supportable. Mais je suis d'accord que la série test/erreur n'est pas jouable avec des trucs trop long.

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

il y avait une polémique identique avec les robots ms qui allaient voir les url pointé à travers de MSN.

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

Pas de mmu sur une machine qui est monoprocess, cela n'est pas choquant, non ?

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

j'ai fait un super bench avec 8500 iops qui est vachement plus réaliste qu'une copie de fichier".

Si tu fais une copie de fichier de 1 Mo par exemple ou moins, un SSD serait plus rapide qu'une grosse baie raid 5.

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

Je dirais que en théorie tu as raison. Mais dans ce cas, comment expliques tu que tout les utilisateurs de SSD considèrent que leur PC a perdu toutes ses petites latences qui rend l'ordinateur "mou" et surtout comment voit-il une différence entre SSD comme avec le X25-e ?

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

\o/ leur base de donné a l'air à jour.

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

J'ai lu il y a un moment un blog d'un codeur du noyau linux. Il était content des nouveaux OCZ vertex, qui sont les 1er SSD a être compétitif face à ceux d'intel.

Au bout d'un moment, git lui remontait des erreurs dans ses fichiers (git utilise des hash sha-256). Il s'est rendu compte que les OCZ faisait moins attention à ses données que les disques intel. Il est donc retourné dépité sous intel.

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

On peut même dire que la différence entre SSD pro type X25-e et X25-M, c'est la bande passante des paquets de 4Ko en écriture aléatoire. En gros autour de 1Mo pour les disques dures et à plus de 10 Mo pour les SSD pro.

C'est une donnée très importante pour toutes applications qui passent leur temps à faire des fsync() comme firefox avec SQLlite.

http://www.pcworld.fr/image/zoom/1045351/ControllerWR (intel SLC, c'est le X25-e)

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

Est-ce qu'il y a des filtres pour "gommer" les déformations géométriques des objectifs ? Il existe un logiciel libre dont j'ai oublier le nom qui utilise une formule connu avec 3 paramètres. Ceux ci sont dans une base de donné pas mis à jour (fulla de mémoire, mais j'ai pas vérifier depuis un moment).

Il serait super utile tout de même d'avoir un plugin qui permet de faire un truc "au jugé" à la main. (http://wiki.panotools.org/Lens_correction_model ). Si il est possible de faire ça par plan de couleur, cela permet aussi de récupérer des abérations chromatique (les franges violettes).

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

Si mais de façon bizarre, en gros, tu as interdiction de modifier, tu lis des trucs commun, et tu écris ailleurs. Beaucoup d'algos peuvent se faire comme ça. En gros, cela ressemble à un filtre shell :)

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

http://www.lisaac.org/documentation/simplicity ?

Je ne vois pas de licence là-bas. Cela serait à ajouter qq part, d'ailleurs.

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

Pour information, Lisaac a été créé par un thésard du créateur de smarteffel. La lib de Lisaac a été reprise de smarteffel.

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

Les assertion attrapent les erreurs dynamiquement. Les contrats sont des conditions sur l'état des objets. C'est vérifier à l'exécution en mode debug. Le sain graal serait de pouvoir les vérifier automatiquement.

Le compilo attrape les "call sur nul" statiquement, sans utiliser de contrat.

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

- Tu va voir ta source et tu lui demande de bon arguments histoire de défendre son point de vue ;
- Tu va faire un tour sur le net (et pas que wikipedia) et tu vois que en effet plein de gens tout à fait respectables pensent le contraire, et tu admet ton erreur ;
- Tu refuse d'admettre que tu ais pus avoir tord mais tu as la flemme de demander au gourou des arguments, et dans ce cas la, vu qu'on est pas vendredi, tu fait le mort.


J'ai répondu un peu coté, j'attendais les vrais arguments mais la personne en question répond peu au mail. Et c'est argument était faible (en gros, c'est que javascript n'est pas été conçu pour être compilé). Ensuite concernant faire un tour sur le web, tu tombes sur la page wikipedia. Et souvent sur des très trucs pointus, c'est pas la joie.

Et j'ai fait un peu le mort dégouté par ce qui intéresse les gens : polémiquer. Peut être que tu as rater d'autres news/journal mais c'est assez systématique, typiquement de la part de Timaniac qui essaye de démontrer par A+B que Lisaac ne sert à rien. Il essaye de le démontrer par tout les moyens, ils insistent sur la syntaxe ou des choix téchnique qui ne sont que des choix. Ils ne sont pas moins bon, ils sont autres : à quoi sert de faire comme tout le monde ?

Alors oui, on essaye de faire de la pub. Un nouveau langage, c'est dur à lancer, à avoir une taille critique. Alors quand on a un beau truc, qui se fait critiquer systématiquement sur la tronche du "if", c'est gavant. D'où mes réactions.

Le "gourou" communique peu. C'est pas son truc. Alors on le fait à sa place mais on est pas chercheur en labo. On a des boulots. Moi, je suis dans l'informatique bas niveau avec un back ground en microelec. Je suis loin des langages (même si ma boite en produit un).


Ici encore : la page wikipedia sur le sujet, elle même un peu contredite par la page qui décrit les langage à prototype de quelle contradiction parle tu ? J'ai pas lu en détails, mais je ne vois pas vraiment de contradictions entre les deux.

Cela a pourtant été pointer par d'autre, je pensais au message de mathieu ici :
http://linuxfr.org/comments/1087357.html#1087357

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

Cette découpe n'existait que pour des raisons des capacités d 'un compilo sur des machines des années 80. Depuis, on a un peu plus de patates sous le pieds.

Le compilo Lisaac se compile en quelques seconde sur un atom (50kloc ?). C'est gcc qui rame ensuite quelques minutes.

- les gars, vous compiler toujours tout.

Oui, et c'est pas si lent.

- si vous devez compiler pour tester, vous compilerez tout.


Oui mais les bugs sont attrapé par le compilo en majorité. Une grosse parti de la compile pour être mis en cache.

L'avenir c'est le test statique par le compilo, pas le test. Cela ne passe pas à l'échelle.


- si vous devez compiler pour débugguer, vous compilerez tout.


Oui, c'est sans doute le plus chiant. Le débug, en ligne, est aussi le degré zéro de la validation, même si on n'a pas encore le choix.


- si vous devez proposer des modules interchangeable d'un point de vue déploiement, vous n'allez jamais le faire.


Si en plugin. Ensuite, j'imagine que niveau performance, cela sera beaucoup plus intéressant de distribuer des binaires complets différents. Et plus l'appli est grosse et plus cela sera intéressant par la magie de la compilation global.


- si vous voulez distribuer des bibliothèques sous forme binaires, vous n'allez jamais le faire.


Oui, sauf sous forme de plugin. J'imagine que l'on pourrait faire une sorte de paquet prédigéré pour accélérer la compilation et la distribution, faire cela juste pour l'obfuscation, c'est un peu naze surtout si il y a beaucoup d'introspection dans le langage.

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

Cool. Dans les omap, il n'y a pas de cohérence, donc pour causer entre le dsp et le cpu, c'est "un peu lent"...

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

Tu es peut-être en ext4 ?

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

L'intérêt est aussi dans le parallélisme. Tous les GPU fonctionnent comme ça.

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

Est-ce que tu es sûr que les Tile ont une cohérence mémoire ? Dans un soc habituel il n'y en a pas, et c'est assez horrible à gérer. C'est un défi en soi.

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

Quand on voit comment est fait les GPU, cela ressemble un peu à ça : une cohereance mémoire minimum controler par logiciel.

Quand on voit Fermi de Nvidia, c'est en gros un cpu qui gère 32 threads en même temps avec 32 unité de calcul !

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

Que passer de 100 cores à 100 000 000, cela pose les mêmes problèmes qui existe peu à 4 coeurs. En gros, linux maintient un maximum de structure local à chaque coeur pour éviter tout transfert de mémoire entre coeur.

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

On peut aussi préciser qu'il tourne avec quelques milliers de processeurs.

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

Donc l'idée du nouveau noyau linux qui partage les pages de données identiques, est une bonne idée ?

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