Ton article date de 2004, même si il a raison dans le fond, on continue de faire à l'ancienne car le multithread est très couteux à faire, en 2015.
Il ne faut pas oublier non plus que Intel n'a plus de concurrent depuis des années. Il y a eu une course entre Athlon et Pentium4. Mais depuis l'architecture "core", AMD n'a jamais rien fait de sérieux depuis. Intel s'est endormis sur ses lauriers. AMD aurait pu ouvrir ses shaders et exposer plus facilement leur puissance, mais ils n'ont rien fait. C'est pourtant le seul domaine, ou il écrase encore Intel.
Dire qu'il aurait suffit d'un bon compilo openCL open source, ou d'une bonne api ouverte…
Je ne comprends pas vraiment le sens de ta question, mais je n'ai pas l'impression d'avoir dit ça.
Ce que je veux dire, c'est que changer ta machine est bien moins couteux pour la collectivité que de demander d'optimiser tous les logiciels que tu utilises.
Je ne sais pas combien tu as de RAM. Mais les machines sont bloqué à 4 Go depuis des années (10ans). Hors, l'augmentation des besoins mémoires à toujours été de l'ordre de +50%/an.
On disait à une époque qu'un ordinateur équilibré avait un cpu de 1 Mhz pour 1 Mbs de bande passante réseau pour 1 Mo de RAM. La fréquence et le nombre de cpu à grimper en flèche mais pas le reste.
En gros, passe à 8 ou 16 Go de ram si possible, et rajoute un SSD. Cela change tout.
Je crois que tu as mal interprété le propos d'Antoine qui se voulait ironique :)
Je sais mais il voulait sans doute dire que malgré que PHP est un outil de merde, facebook a réussi. Sauf qu'à l'époque, il n'avait trop de choix et qu'ils ont changer PHP pour correspondre à leur besoin (typage progressif, jit,…).
oui bien sûr. Dans le modèle derrière peuvent s'appliquer les mêmes méthodes de référence et de neutralité que pour wikipedia. On peut aussi ajouter un outil de traçabilité entre le code et des documents.
Disons que int est mappé sur la taille la plus pratique. Le C propose 3 type d'archi 16 32 et 64 bits. Le 16 bit est le minimum même sur µC avec registre 8 bits (qui sont souvent mixte 8/16 bits en fait). 32 bit est la norme pour ceux à registre 32 bits. Ce qui ont des registres 64 bits, utilise int en 32 bits, ce qui est incompatible avec les pointeurs 64 bits.
C'est pour ça qu'il y a 3 "sortes" de C. D'ailleurs, il n'est pas possible de faire un code sans ifdef qui reste compatible avec les 3 tailles de registres.
c'est lui qui sait comment les données sont organiser et qui va répondre au mieux aux demandes.
Non justement. Linux ne cherche pas à optimiser la bande passante global, ou le temps de fin global. Il essaye d'être juste ("fair") entre chaque flux IO. Il va donc faire un peu de tout, pour satisfaire tout le monde. Il va garantir une latence minimum pour tous. Or, on se fout qu'un des job soient très en retard. Sur un HD, on peut augmenter la bande passante réelle avec des "bandes" jusqu'à ~15 Mo. Plus l'accès est linéaire, plus la copie/lecture est rapide.
(par exemple elle se déclenchera quand tu aura vraiment mis de la pression sur ton allocation mémoire).
C'est justement de ce cas pathologique dont on parle : plein d'allocation suffisamment grosse pour aller dans la "zone vieille" mais à collecter ensuite. Je n'ai pas testé d'augmenter franchement la zone jeune, c'est peut être une autre solution (256Ko de mémoire).
Sincèrement la lecture de 10 000 fichiers c'est plus les accès disques qui vont te poser problème que l'allocation mémoire.
Pour mon cas, non. En bidouillant le GC d'OCaml, j'avais des perf en plus (10 % de mémoire), en multipliant la conso mémoire par 10 (en gros, le gc se déclenche beaucoup moins ouvent).
Lancer les lectures de manière asynchrone va probablement te permettre de passer un gap très important.
Dans le cas de lecture sur le même disque, je ne vois pas pourquoi. Je n'ai pas fait le test, mais je persuadé que tu va juste augmenter le nombre de "seek" et ralentir le tout. Cela se voit bien entre plein de copie en parallèle ou une liste de copie.
Les gc générationnels font déjà se boulot avec une granularité plus fine et de manière plus systématique que ce que tu ferra.
Surtout si ta mémoire est read only comme en Ocaml (le parsing se fait uniquement sur les string, sinon, il faudrait tout recoder avec "buffer"). Mais si tu as une génération jamais parcouru par le GC, c'est plus rapide non ?
Les sécurités et autre artifices qui entrent en jeux lors de la création d'un objet peut poser un vrai problème (et ne sont pas forcément facile à prendre en compte (mal grès l'utilisation de pool d'objet).
Dans Ocaml, c'est un déplacement d'un pointeur de pile. Dans le cas de mémoire à faible durée de vie, c'est ultra rapide. C'est ensuite, que cela se complique.
Au pire dans le temps réel dure, on ne fait pas d'allocation de mémoire du tout (Misra C). Ou on le fait uniquement après le démarrage de l'application, puis on y touche plus (type serveur graphique Arinc 661).
Dans le cas auquel je pense, c'est vraiment pour de l'optimisation, je suis bien d'accord. Le fait de faire plusieurs programme aurait ralentit le tout. Je parle de lire 10 000 fichiers en quelques secondes.
Sans piloter le GC, il pourrait être utile d'avoir un moyen de créer des données totalement hors du contrôle du GC. Cela permet d'éviter des scans inutiles. Voir de se passer complètement du GC dans certain cas, par exemple pour les données qui vont rester en vie, durant toute la vie du programme.
C'est logique que les toits des bâtiments ont sauté ? (je voie des murs uniquement)
Il serait bien de faire une écriture plus propre pour le nom des rues. Le truc est flou et moche. J'imagine qu'il faudrait un moyen d'écrire après coup au bon endroit, au lieu d'avoir une grosse image déformée.
On pourrait imaginer le GC pilotable. rust permet un peu ça, et permet aussi d'avoir des zones mémoires hors GC.
ocaml pourrait permettre de réutiliser des variables en tant que bloc mémoire inutile. J'ai souvenir d'écriture d'un parseur, qui lisait des milliers de petit fichiers, qui devait à chaque fois réallouer une nouvelle string pour les lire.
L'espace n'utilise pas la DO178b, mais pas du tout. C'est même à des années-lumière de la DO (j'ai bossé 5 ans dans le secteur spatiale et 8, dans l'aéronautique).
"Notamment la DO178B. La méthode la plus sûre reste l'emploi de méthodes formelles. "
C'est toi qui parlais de DO, je ne parlais pas en général, car tu ne le faisais pas non plus.
C'est gentil de se relire avant de répondre…
Ton deuxième lien ne donne pas d'exemple dans l'aéronautique. L'aéronautique exige, que pour utiliser un outil qui génère des "trucs" qui sont embarqués, il faut que l'outil soient développé selon les mêmes méthodes que la DO préconise (sauf pour les compilateurs C, qui sont une exception "pratique"). Même si la DO178c rend plus facile le développement d'outils, cela reste très difficile. Par exemple, écrire tous les HLR/LLR d'un outil comme un prouveur doit être du délire.
"Tu vois, c'est exactement ce genre d'arrogance que je dénonce ne pensant que les devs se croient plus important que le reste du monde. "
Moi je vois l'effet inverse. On était une petite boite avec 2 IT au service de tout le monde; enquête de satisfaction : 90%. On vient de se faire racheter par un monstre, avec l'IT qui fait un peu ce qui veut, ayant des budgets énormes. Des bugs chiant qui touchent, tout le monde jamais corriger. Ils ne font même pas d’enquête de satisfaction, tellement ils savent qu'ils vont se faire allumer.
"Comptablement, les devs e la R&D aussi coute de l'argent sont donc aussi un centre de cout."
Quand tu vend du logiciel, c'est pas vraiment le cas. En tout cas, au US, les dev ne sont pas vu comme cela du tout, par exemple.
il faut quelqu'un pour s'occuper de chaque chose.
Je suis d'accord. Les dev sont là pour le produit. Les IT sont là pour support des autres services, le problème arrive quand ils pensent se suffire à eux-même. Ils n'existent pourtant uniquement comme support du reste.
[^] # Re: Drôle de phrase
Posté par Nicolas Boulay (site web personnel) . En réponse au journal "Gummiboot UEFI Boot Loader" sera ajouté à Systemd. Évalué à 5.
Ton article date de 2004, même si il a raison dans le fond, on continue de faire à l'ancienne car le multithread est très couteux à faire, en 2015.
Il ne faut pas oublier non plus que Intel n'a plus de concurrent depuis des années. Il y a eu une course entre Athlon et Pentium4. Mais depuis l'architecture "core", AMD n'a jamais rien fait de sérieux depuis. Intel s'est endormis sur ses lauriers. AMD aurait pu ouvrir ses shaders et exposer plus facilement leur puissance, mais ils n'ont rien fait. C'est pourtant le seul domaine, ou il écrase encore Intel.
Dire qu'il aurait suffit d'un bon compilo openCL open source, ou d'une bonne api ouverte…
"La première sécurité est la liberté"
[^] # Re: Drôle de phrase
Posté par Nicolas Boulay (site web personnel) . En réponse au journal "Gummiboot UEFI Boot Loader" sera ajouté à Systemd. Évalué à -1.
Ce que je veux dire, c'est que changer ta machine est bien moins couteux pour la collectivité que de demander d'optimiser tous les logiciels que tu utilises.
"La première sécurité est la liberté"
[^] # Re: Drôle de phrase
Posté par Nicolas Boulay (site web personnel) . En réponse au journal "Gummiboot UEFI Boot Loader" sera ajouté à Systemd. Évalué à 1.
Parce que tu crois que c'est gratuit ?!
Ma machine du boulot à 8Go de RAM et une compile sous Eclipse prend tout.
"La première sécurité est la liberté"
[^] # Re: Drôle de phrase
Posté par Nicolas Boulay (site web personnel) . En réponse au journal "Gummiboot UEFI Boot Loader" sera ajouté à Systemd. Évalué à -2.
Les SSD commencent à 80€, qui peuvent servirent de disque système.
Avec moins de 500€, tu as tout en mieux :
http://www.materiel.net/ordinateur/materiel-net-nucleus-plus-100114.html
440€ pour avoir un meilleur cpu, ou 240€ pour avoir plus de RAM et un SSD ?
"La première sécurité est la liberté"
[^] # Re: Drôle de phrase
Posté par Nicolas Boulay (site web personnel) . En réponse au journal "Gummiboot UEFI Boot Loader" sera ajouté à Systemd. Évalué à -3.
Je ne sais pas combien tu as de RAM. Mais les machines sont bloqué à 4 Go depuis des années (10ans). Hors, l'augmentation des besoins mémoires à toujours été de l'ordre de +50%/an.
On disait à une époque qu'un ordinateur équilibré avait un cpu de 1 Mhz pour 1 Mbs de bande passante réseau pour 1 Mo de RAM. La fréquence et le nombre de cpu à grimper en flèche mais pas le reste.
En gros, passe à 8 ou 16 Go de ram si possible, et rajoute un SSD. Cela change tout.
"La première sécurité est la liberté"
[^] # Re: Un langage complexe ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Le langage Rust en version 1.0 alpha, on arrête de tout casser !. Évalué à 2.
Je sais mais il voulait sans doute dire que malgré que PHP est un outil de merde, facebook a réussi. Sauf qu'à l'époque, il n'avait trop de choix et qu'ils ont changer PHP pour correspondre à leur besoin (typage progressif, jit,…).
"La première sécurité est la liberté"
[^] # Re: un tableur en ligne
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Climat et logiciel. Évalué à 2.
oui bien sûr. Dans le modèle derrière peuvent s'appliquer les mêmes méthodes de référence et de neutralité que pour wikipedia. On peut aussi ajouter un outil de traçabilité entre le code et des documents.
"La première sécurité est la liberté"
# un tableur en ligne
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Climat et logiciel. Évalué à 2.
Je rêves d'avoir ce genre d'outil mais avec l'édition du code source en mode wiki. Cela permettrait aussi de valider le modèle qu'il y a derrière.
"La première sécurité est la liberté"
[^] # Re: Un langage complexe ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Le langage Rust en version 1.0 alpha, on arrête de tout casser !. Évalué à 7.
Oui enfin les zozo de facebook ont aussi écrit un nouveau langage 100% compatible php pour corriger les bugs. (the hack langage https://linuxfr.org/news/the-hack-language-php-avec-un-peu-de-typage-statique http://hacklang.org/ )
Cette vidéo sur le pourquoi, ils l'ont fait est super intéressante :
http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/Hack
"La première sécurité est la liberté"
[^] # Re: Une chose que j'ai oublié d'ajouter
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Le langage Rust en version 1.0 alpha, on arrête de tout casser !. Évalué à 3.
Disons que int est mappé sur la taille la plus pratique. Le C propose 3 type d'archi 16 32 et 64 bits. Le 16 bit est le minimum même sur µC avec registre 8 bits (qui sont souvent mixte 8/16 bits en fait). 32 bit est la norme pour ceux à registre 32 bits. Ce qui ont des registres 64 bits, utilise int en 32 bits, ce qui est incompatible avec les pointeurs 64 bits.
C'est pour ça qu'il y a 3 "sortes" de C. D'ailleurs, il n'est pas possible de faire un code sans ifdef qui reste compatible avec les 3 tailles de registres.
"La première sécurité est la liberté"
[^] # Re: Un langage complexe ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Le langage Rust en version 1.0 alpha, on arrête de tout casser !. Évalué à 2.
J'imagine que la démonstration de "ça passe" doit être compliqué.
"La première sécurité est la liberté"
[^] # Re: Un langage complexe ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Le langage Rust en version 1.0 alpha, on arrête de tout casser !. Évalué à 2.
Non justement. Linux ne cherche pas à optimiser la bande passante global, ou le temps de fin global. Il essaye d'être juste ("fair") entre chaque flux IO. Il va donc faire un peu de tout, pour satisfaire tout le monde. Il va garantir une latence minimum pour tous. Or, on se fout qu'un des job soient très en retard. Sur un HD, on peut augmenter la bande passante réelle avec des "bandes" jusqu'à ~15 Mo. Plus l'accès est linéaire, plus la copie/lecture est rapide.
C'est justement de ce cas pathologique dont on parle : plein d'allocation suffisamment grosse pour aller dans la "zone vieille" mais à collecter ensuite. Je n'ai pas testé d'augmenter franchement la zone jeune, c'est peut être une autre solution (256Ko de mémoire).
"La première sécurité est la liberté"
[^] # Re: Un langage complexe ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Le langage Rust en version 1.0 alpha, on arrête de tout casser !. Évalué à 2.
Pour mon cas, non. En bidouillant le GC d'OCaml, j'avais des perf en plus (10 % de mémoire), en multipliant la conso mémoire par 10 (en gros, le gc se déclenche beaucoup moins ouvent).
Dans le cas de lecture sur le même disque, je ne vois pas pourquoi. Je n'ai pas fait le test, mais je persuadé que tu va juste augmenter le nombre de "seek" et ralentir le tout. Cela se voit bien entre plein de copie en parallèle ou une liste de copie.
Surtout si ta mémoire est read only comme en Ocaml (le parsing se fait uniquement sur les string, sinon, il faudrait tout recoder avec "buffer"). Mais si tu as une génération jamais parcouru par le GC, c'est plus rapide non ?
Dans Ocaml, c'est un déplacement d'un pointeur de pile. Dans le cas de mémoire à faible durée de vie, c'est ultra rapide. C'est ensuite, que cela se complique.
"La première sécurité est la liberté"
[^] # Re: Un langage complexe ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Le langage Rust en version 1.0 alpha, on arrête de tout casser !. Évalué à 3.
Beaucoup de jeu utilise un énorme truc en C++ mais un langage de script pour le reste. Unity https://fr.wikipedia.org/wiki/Unity_%28moteur_de_jeu%29 utilise mono. D'autres utilisent Lua.
"La première sécurité est la liberté"
[^] # Re: Un langage complexe ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Le langage Rust en version 1.0 alpha, on arrête de tout casser !. Évalué à 4.
Au pire dans le temps réel dure, on ne fait pas d'allocation de mémoire du tout (Misra C). Ou on le fait uniquement après le démarrage de l'application, puis on y touche plus (type serveur graphique Arinc 661).
"La première sécurité est la liberté"
[^] # Re: Un langage complexe ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Le langage Rust en version 1.0 alpha, on arrête de tout casser !. Évalué à 2.
Dans le cas auquel je pense, c'est vraiment pour de l'optimisation, je suis bien d'accord. Le fait de faire plusieurs programme aurait ralentit le tout. Je parle de lire 10 000 fichiers en quelques secondes.
Sans piloter le GC, il pourrait être utile d'avoir un moyen de créer des données totalement hors du contrôle du GC. Cela permet d'éviter des scans inutiles. Voir de se passer complètement du GC dans certain cas, par exemple pour les données qui vont rester en vie, durant toute la vie du programme.
"La première sécurité est la liberté"
# retour ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal X3D et osm. Évalué à 2.
C'est logique que les toits des bâtiments ont sauté ? (je voie des murs uniquement)
Il serait bien de faire une écriture plus propre pour le nom des rues. Le truc est flou et moche. J'imagine qu'il faudrait un moyen d'écrire après coup au bon endroit, au lieu d'avoir une grosse image déformée.
"La première sécurité est la liberté"
[^] # Re: Un langage complexe ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Le langage Rust en version 1.0 alpha, on arrête de tout casser !. Évalué à 1.
On pourrait imaginer le GC pilotable. rust permet un peu ça, et permet aussi d'avoir des zones mémoires hors GC.
ocaml pourrait permettre de réutiliser des variables en tant que bloc mémoire inutile. J'ai souvenir d'écriture d'un parseur, qui lisait des milliers de petit fichiers, qui devait à chaque fois réallouer une nouvelle string pour les lire.
"La première sécurité est la liberté"
[^] # Re: Pas sûr que trouver des erreurs/la fiabilité soit si important pour la communauté libre..
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche [code] Trouver les erreurs. Évalué à 3.
oula.
L'espace n'utilise pas la DO178b, mais pas du tout. C'est même à des années-lumière de la DO (j'ai bossé 5 ans dans le secteur spatiale et 8, dans l'aéronautique).
"La première sécurité est la liberté"
[^] # Re: Pas sûr que trouver des erreurs/la fiabilité soit si important pour la communauté libre..
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche [code] Trouver les erreurs. Évalué à 3.
Dans la liste d'exemple, il ne parle pas d'aéronautique. Il parle d'espace, mais cela n'est pas les mêmes règles.
"La première sécurité est la liberté"
[^] # Re: Un langage complexe ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Le langage Rust en version 1.0 alpha, on arrête de tout casser !. Évalué à 4.
Tu as des exemples de complexités ?
"La première sécurité est la liberté"
[^] # Re: Pas sûr que trouver des erreurs/la fiabilité soit si important pour la communauté libre..
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche [code] Trouver les erreurs. Évalué à 2.
Tu as écris ça :
C'est toi qui parlais de DO, je ne parlais pas en général, car tu ne le faisais pas non plus.
C'est gentil de se relire avant de répondre…
Ton deuxième lien ne donne pas d'exemple dans l'aéronautique. L'aéronautique exige, que pour utiliser un outil qui génère des "trucs" qui sont embarqués, il faut que l'outil soient développé selon les mêmes méthodes que la DO préconise (sauf pour les compilateurs C, qui sont une exception "pratique"). Même si la DO178c rend plus facile le développement d'outils, cela reste très difficile. Par exemple, écrire tous les HLR/LLR d'un outil comme un prouveur doit être du délire.
"La première sécurité est la liberté"
[^] # Re: Pas sûr que trouver des erreurs/la fiabilité soit si important pour la communauté libre..
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche [code] Trouver les erreurs. Évalué à 1.
J'aimerais bien savoir pourquoi j'ai été "moinsé". Quelqu'un connait un seul exemple d'usage de la méthode B sous DO178 ?
"La première sécurité est la liberté"
[^] # Re: Sérieux?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Besoin d'arguments pour obtenir une station de travail sous GNU/Linux ?. Évalué à 3.
Moi je vois l'effet inverse. On était une petite boite avec 2 IT au service de tout le monde; enquête de satisfaction : 90%. On vient de se faire racheter par un monstre, avec l'IT qui fait un peu ce qui veut, ayant des budgets énormes. Des bugs chiant qui touchent, tout le monde jamais corriger. Ils ne font même pas d’enquête de satisfaction, tellement ils savent qu'ils vont se faire allumer.
Quand tu vend du logiciel, c'est pas vraiment le cas. En tout cas, au US, les dev ne sont pas vu comme cela du tout, par exemple.
Je suis d'accord. Les dev sont là pour le produit. Les IT sont là pour support des autres services, le problème arrive quand ils pensent se suffire à eux-même. Ils n'existent pourtant uniquement comme support du reste.
"La première sécurité est la liberté"
[^] # Re: Sérieux?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Besoin d'arguments pour obtenir une station de travail sous GNU/Linux ?. Évalué à 1.
Le rapport avec le poste ?
"La première sécurité est la liberté"