Faire une architecture correct et simple, ou recoder une fonction qui existe déjà pour aller plus vite, ce n'est pas la même démarche. Pas du tout.
Si tu recodes String.split, alors que tu n'utilises cette fonction uniquement pour lire une configuration à l'init, cela ne sert à rien. Par exemple.
_"Quand ton produit est à taille humaine, on est tout à fait capable d'estimer "au pif" si telle ou telle solution est viable et de le POCé/testé en quelques minutes si on a besoin de chiffre." _
Sauf pour le gros grain, mais une fois ton archi faite, en général les estimations aux doigts mouillés des "bottlenecks" de performance, sont en général fausses.
"Si tu n'as plus junior devant ton nom tu sais aussi commencer à estimer ce qui va coûter cher ou non et le mesurer corriger ASAP pour ne pas cumuler des choses non-rattrapables."
En général, ceux qui disent ça, n'ont plus "junior" devant leur titre, mais par encore "senior" ou "expert".
Je confirme, il y a 2 moyens de gagner du temps :
- avoir une bonne archi (ne pas faire 2 fois le même boulot couteux, éviter un parcours exponentiel.)
- hacker (refaire les trucs à la main, …)
Le 1er se fait en amont, avec des gains monstrueux à la clef (x1000). Le 2ième te fait gagner x10 maxi.
En général, les optimisations prématurées ne font rien gagné du tout, et rajoutent des bugs. C'est plus difficile de faire marcher un truc le plus simplement du monde (== moins de code, moins de bug, plus petit,…), que de le faire aller plus vite ensuite.
Franchement, dans le cycle de dev, l'optimisation en temps arrive à la toute fin, et en général, on a pas le temps, sauf si cela devient une "feature".
L'optimisation a aussi un coup de maintenance (code peu lisible, plus gros, etc…). Et souvent, cela ne vaut pas le cout d'optimiser. Le seul moyen de savoir si cela vaut le cout, c'est de faire des mesures (donc à la fin d'un dev).
« ABC: Always Be Coding » est à rapprocher d'un autre article sur le même sujet, mais qui donne des conseils à ceux qui pose des questions.
L'auteur de cette article propose de savoir écrire les yeux fermé des algo comme A*, des parcours de graph et autre algo de trie. La facilité de faire cela serait un bon moyen d'être embauché.
Mais quel informaticien écrit en moyenne par mois, de tel algo ? Personne ou presque. Un codeur passe son temps à architecturer du code, prévoir plus ou moins l'avenir, revoir les besoins du "clients", debuguer. Mais certain aucun temps à faire ce genre d'exercice.
Concernant les structures de données, il ne sert à rien d'avoir des collections complexe pour des tailles inférieurs à 100. Le O(1) cache souvent un cout fixe énorme, il ne faut pas jeter trop vite les bon vieux tableaux ou liste chainé.
L'article parle de "team work" et que MS serait aller bien plus loin que les autres. En sachant tout cela, je ne comprends plus comment il serait possible pour une boite française un peu sensible, d'utiliser un seul logiciel ou service US.
Un bug subtile à la openbsd (de mémoire) a peu de chance d'être détecté. De plus, comment être sûr que le binaire qui tourne est le même que celui compilé ? Il est possible de faire des diff telquel ? Une backdoor ajouté par un compilateur, cela a été aussi déjà fait il y a longtemps. Et avec les méthodes de mise à jour en ligne, comment être sûr qu'une backdoor n'est pas ajouté en même temps ?
Les caches de µops étaient utilisé dans le Pentium 4, mais plus maintenant, cela prendre trop de place (sauf gestion de boucle).
Si ARM ne fait pas quelques intructions spécialisées pour tout ce qui est couteux (controlleur DRAM dans le cpu, instruction pour les hash, la compression, la crypto), ils se feront manger par intel.
La consomation statique est gérée depuis longtemps : on coupe tout (horloge et alimentation). Les téchniques sont connues. Le vrai défi c'est la consommation max à 100%, quand on navigue sur internet ou joue a Angry Bird.
En effet, Texas instrument avait ses propres usines orienté basse consommation, mais aujourd'hui utilise une fab coréenne comme tout le monde presque, sauf intel. Ils ont ainsi perdu leur avance sur la consommation.
L'avantage est tellement énorme de rester compatible PC, que jamais intel ne fera l'erreur d'inventer encore un nouveau truc. ARM n'a pas vraiment de définition d'architecture d'ordinateur, il suffit de voir les drviers linux de plateforme arm, pour le comprendre.
Le x86 peut contenir des sortes de vliw internes, c'est un peu loin des RISC.
"C'est aussi quelque chose de primordial à saisir pour appréhender les obstacles qu'a le x86 à franchir pour la basse consommation,"
Le seul problème de intel est son inertie interne, c'est tout. Le x86 a par exemple une densité de code très élèvé, supérieur à l'arm. C'est un avantage énorme pour l'efficacité du cache de code.
Intel a sorti, il y a 5 ans, un cpu qui consommait en sommeil autant qu'un ARM à 100%. Aujourd'hui, le dernier soc intel (medfield) consomme moins, soit moins de mips par watt qu'un arm.
Et en plus, l'itanuim était un des seul processeurs VLIW supporté par gcc, difficile de faire fonctionner les optimisations dédiers au coeur superscalaire. Le seul autre VLIW un peu connu est le DSP c6000 de chez Ti.
"en pratique, chaque instruction est ensuite décomposée en micro-instructions qui suivent les principes de RISC."
Le ISC de RISC et CISC, veut dire "instruction set computer". On parle du jeu d'instruction et pas du tout de la micro-architecture interne. Le but premier des mips et sparc, les 1ers RISC, était de réduire la taille du pipeline en ayant l'unité de load/store bien séparé de l'ALU. Le nombre réduit de mode d'adressage (le moyen de choper les data, ici par registre quasi exclusivement) était aussi un avantage de simplicité.
"Decode → Execute → Memory" n'est clairement pas un "risc".
Aujourd'hui, le x86 est toujours plus complexe, et il me semble que la grammaire de l'assembleur x86 est ambiguë. Le décodeur est donc un monstre, ce qui permet à intel de mettre une sacré barrière à l'entré sur son marché. De l'autre coté le PowerPC dispose de plein de mode d'adressage, qui' l'éloigne aussi du risc. La taille des instructions des nouveaux ARM est mixte 16/32 bits.
On peut lire que les principes RISC ont "gagné", mais je pense surtout que les RISC sont devenus des CISC.
"simplement « sauter » l'étage mémoire du pipeline"
C'est simplement impossible car la mémoire peut aussi générer des données. Ce genre de bypass implique que l'étage suivant à des entrées multiples, et c'est tout, sauf simple.
"VLIW : Cependant, le bilan énergétique peut être désastreux (après tout, toutes les instructions sont exécutées, qu'elles soient utiles ou pas !)."
C'est même pire que ça, puisque le cpu peut passer sont temps à exécuter des instructions inutiles. Le fait de ne pas pouvoir faire correctement d’ordonnancement statique par le compilateur, en sans doute la raisons principale de l'échec de l'itanium qui devait prendre le relève du x86 pour le 64 bits. Mais il fallait des caches internes monstrueux à l'itanium pour aller vraiment plus vite que les Xeon (sauf en flottant).
" Les processeurs de type SPARC utilisent ces registres pour accélérer les changements de contexte entre threads/processus."
Perdu, les banc de registres à fenêtre , c'est pour les appels de fonctions. Sur SPARC, il y a 32 registres, 8 globaux et 3 paquets de 8 glissant sur une fenêtre de 128 registres ou plus. A chaque call, tout se décale de 8 registres, cela permet d'offrir 8 registres tout frais, sans faire de sauvegarde dans la pile (moins besoin de registre "callee save"). Par contre, une fois qu'il n'y plus de place, il y a une interruption pour tout sauver en mémoire. sur de gros programme avec beaucoup d'appel, cela peut tuer l'avantage de la simplification des fonctions.
[^] # Re: Sécurité du DES
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Microsoft : pbpg a-t-il eu une attaque ? "Votre vie privée est notre priorité". Évalué à 3.
Ou dans le générateur aléatoire dans le cas de crypto à clef publique…
"La première sécurité est la liberté"
[^] # Re: non-libre
Posté par Nicolas Boulay (site web personnel) . En réponse au journal une mise en demeure de la part de TF1, pour l'auteur de Captvty. Évalué à 4.
Je pense que les restrictions géographique peuvent être vu comme un DRM, et donc un proxy contourne ce genre de DRM.
Faut-il encore que ce DRM soit "efficace".
"La première sécurité est la liberté"
[^] # Re: quelques points
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche De tout, de rien, des bookmarks, du bla bla #29. Évalué à 4.
Faire une architecture correct et simple, ou recoder une fonction qui existe déjà pour aller plus vite, ce n'est pas la même démarche. Pas du tout.
Si tu recodes String.split, alors que tu n'utilises cette fonction uniquement pour lire une configuration à l'init, cela ne sert à rien. Par exemple.
_"Quand ton produit est à taille humaine, on est tout à fait capable d'estimer "au pif" si telle ou telle solution est viable et de le POCé/testé en quelques minutes si on a besoin de chiffre." _
Sauf pour le gros grain, mais une fois ton archi faite, en général les estimations aux doigts mouillés des "bottlenecks" de performance, sont en général fausses.
"La première sécurité est la liberté"
[^] # Re: quelques points
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche De tout, de rien, des bookmarks, du bla bla #29. Évalué à 2.
"Si tu n'as plus junior devant ton nom tu sais aussi commencer à estimer ce qui va coûter cher ou non et le mesurer corriger ASAP pour ne pas cumuler des choses non-rattrapables."
En général, ceux qui disent ça, n'ont plus "junior" devant leur titre, mais par encore "senior" ou "expert".
"La première sécurité est la liberté"
[^] # Re: quelques points
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche De tout, de rien, des bookmarks, du bla bla #29. Évalué à 5.
Je confirme, il y a 2 moyens de gagner du temps :
- avoir une bonne archi (ne pas faire 2 fois le même boulot couteux, éviter un parcours exponentiel.)
- hacker (refaire les trucs à la main, …)
Le 1er se fait en amont, avec des gains monstrueux à la clef (x1000). Le 2ième te fait gagner x10 maxi.
En général, les optimisations prématurées ne font rien gagné du tout, et rajoutent des bugs. C'est plus difficile de faire marcher un truc le plus simplement du monde (== moins de code, moins de bug, plus petit,…), que de le faire aller plus vite ensuite.
"La première sécurité est la liberté"
[^] # Re: Intérêt de la chose
Posté par Nicolas Boulay (site web personnel) . En réponse au journal A quand la prochaine secousse sismique dans le monde High-Tech ?. Évalué à 2.
y'a pas de "finger gesture" pour remplacer le bouton "home" ?
"La première sécurité est la liberté"
[^] # Re: Intérêt de la chose
Posté par Nicolas Boulay (site web personnel) . En réponse au journal A quand la prochaine secousse sismique dans le monde High-Tech ?. Évalué à 2.
Envois ton cahier des charges au fabricant du Qooq, cela pourrait les intéresser :)
Par contre, ne néglige pas les possibilités de livre un peu plus dynamique qu'un simple texte : animation, mini application, etc…
"La première sécurité est la liberté"
[^] # Re: quelques points
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche De tout, de rien, des bookmarks, du bla bla #29. Évalué à 7.
Franchement, dans le cycle de dev, l'optimisation en temps arrive à la toute fin, et en général, on a pas le temps, sauf si cela devient une "feature".
L'optimisation a aussi un coup de maintenance (code peu lisible, plus gros, etc…). Et souvent, cela ne vaut pas le cout d'optimiser. Le seul moyen de savoir si cela vaut le cout, c'est de faire des mesures (donc à la fin d'un dev).
"La première sécurité est la liberté"
[^] # Re: Et tu aurais voulu qu'ils fassent quoi d'autre ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Microsoft : pbpg a-t-il eu une attaque ? "Votre vie privée est notre priorité". Évalué à -3.
eglibc n'est pas glibc, il est question de code static, ce qui est rare.
"La première sécurité est la liberté"
# quelques points
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche De tout, de rien, des bookmarks, du bla bla #29. Évalué à 10. Dernière modification le 17 juillet 2013 à 10:21.
« ABC: Always Be Coding » est à rapprocher d'un autre article sur le même sujet, mais qui donne des conseils à ceux qui pose des questions.
L'auteur de cette article propose de savoir écrire les yeux fermé des algo comme A*, des parcours de graph et autre algo de trie. La facilité de faire cela serait un bon moyen d'être embauché.
Mais quel informaticien écrit en moyenne par mois, de tel algo ? Personne ou presque. Un codeur passe son temps à architecturer du code, prévoir plus ou moins l'avenir, revoir les besoins du "clients", debuguer. Mais certain aucun temps à faire ce genre d'exercice.
Concernant les structures de données, il ne sert à rien d'avoir des collections complexe pour des tailles inférieurs à 100. Le O(1) cache souvent un cout fixe énorme, il ne faut pas jeter trop vite les bon vieux tableaux ou liste chainé.
"La première sécurité est la liberté"
[^] # Re: Et tu aurais voulu qu'ils fassent quoi d'autre ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Microsoft : pbpg a-t-il eu une attaque ? "Votre vie privée est notre priorité". Évalué à 3.
Un logiciel se vérifier ? Comment ? Le moindre logiciel MS semble prendre des Go sur disque, comment vérifier ?
"La première sécurité est la liberté"
[^] # Re: Et tu aurais voulu qu'ils fassent quoi d'autre ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Microsoft : pbpg a-t-il eu une attaque ? "Votre vie privée est notre priorité". Évalué à 2.
L'article parle de "team work" et que MS serait aller bien plus loin que les autres. En sachant tout cela, je ne comprends plus comment il serait possible pour une boite française un peu sensible, d'utiliser un seul logiciel ou service US.
"La première sécurité est la liberté"
# D'ou vient le nombre minimal ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Comment fonctionne Bitcoin. Évalué à 2.
Dans l'opération :
HASH ( bloc + nonce ) < XXX
D’où vient le XXX ? qui décide de sa valeur basse ?
"La première sécurité est la liberté"
[^] # Re: Bof
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Espionnage sous Linux ou délire paranoïaque ?. Évalué à 4.
Un bug subtile à la openbsd (de mémoire) a peu de chance d'être détecté. De plus, comment être sûr que le binaire qui tourne est le même que celui compilé ? Il est possible de faire des diff telquel ? Une backdoor ajouté par un compilateur, cela a été aussi déjà fait il y a longtemps. Et avec les méthodes de mise à jour en ligne, comment être sûr qu'une backdoor n'est pas ajouté en même temps ?
"La première sécurité est la liberté"
[^] # Re: p2p-wars ?
Posté par Nicolas Boulay (site web personnel) . En réponse au message Je retrouve pas... un texte sur linux, le LL et tout ça, en parodie de StarWars. Évalué à 4.
Surtout surtout, ne commencez pas à lire ! Vous allez perdre 3 jours de votre vie.
"La première sécurité est la liberté"
[^] # Re: Je maintiens qu'il y a une partie qui n'est pas terrible
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Où vont les supercalculateurs ? D’où on vient, quels sont les problèmes, où l’on va (1re partie). Évalué à 7.
Les caches de µops étaient utilisé dans le Pentium 4, mais plus maintenant, cela prendre trop de place (sauf gestion de boucle).
Si ARM ne fait pas quelques intructions spécialisées pour tout ce qui est couteux (controlleur DRAM dans le cpu, instruction pour les hash, la compression, la crypto), ils se feront manger par intel.
La consomation statique est gérée depuis longtemps : on coupe tout (horloge et alimentation). Les téchniques sont connues. Le vrai défi c'est la consommation max à 100%, quand on navigue sur internet ou joue a Angry Bird.
"La première sécurité est la liberté"
[^] # Re: Je maintiens qu'il y a une partie qui n'est pas terrible
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Où vont les supercalculateurs ? D’où on vient, quels sont les problèmes, où l’on va (1re partie). Évalué à 6.
En effet, Texas instrument avait ses propres usines orienté basse consommation, mais aujourd'hui utilise une fab coréenne comme tout le monde presque, sauf intel. Ils ont ainsi perdu leur avance sur la consommation.
L'avantage est tellement énorme de rester compatible PC, que jamais intel ne fera l'erreur d'inventer encore un nouveau truc. ARM n'a pas vraiment de définition d'architecture d'ordinateur, il suffit de voir les drviers linux de plateforme arm, pour le comprendre.
"La première sécurité est la liberté"
[^] # Re: Je maintiens qu'il y a une partie qui n'est pas terrible
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Où vont les supercalculateurs ? D’où on vient, quels sont les problèmes, où l’on va (1re partie). Évalué à 4.
Le x86 peut contenir des sortes de vliw internes, c'est un peu loin des RISC.
"C'est aussi quelque chose de primordial à saisir pour appréhender les obstacles qu'a le x86 à franchir pour la basse consommation,"
Le seul problème de intel est son inertie interne, c'est tout. Le x86 a par exemple une densité de code très élèvé, supérieur à l'arm. C'est un avantage énorme pour l'efficacité du cache de code.
Intel a sorti, il y a 5 ans, un cpu qui consommait en sommeil autant qu'un ARM à 100%. Aujourd'hui, le dernier soc intel (medfield) consomme moins, soit moins de mips par watt qu'un arm.
"La première sécurité est la liberté"
[^] # Re: De la nécessité de faire des incantations vaudou sur le code
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Où vont les supercalculateurs ? D’où on vient, quels sont les problèmes, où l’on va (1re partie). Évalué à 5.
Et en plus, l'itanuim était un des seul processeurs VLIW supporté par gcc, difficile de faire fonctionner les optimisations dédiers au coeur superscalaire. Le seul autre VLIW un peu connu est le DSP c6000 de chez Ti.
"La première sécurité est la liberté"
[^] # Re: quelques trucs !
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Où vont les supercalculateurs ? D’où on vient, quels sont les problèmes, où l’on va (1re partie). Évalué à 2.
Je pensais à thumb2 pour arm.
La dizaine d'octet se trouve surtout avec les instructions qui peuvent avoir 2 adresses mémoire immédiat en dure. C'est long mais pas trop complexe.
"La première sécurité est la liberté"
[^] # Re: quelques trucs !
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Où vont les supercalculateurs ? D’où on vient, quels sont les problèmes, où l’on va (1re partie). Évalué à 2.
Je pense aussi que je me trompe, et que l'étage Ex dans le cas d'un load sert à faire des calculs d'adresse.
Dans un cpu moderne, c'est complètement séparé.
"La première sécurité est la liberté"
[^] # Re: De la nécessité de faire des incantations vaudou sur le code
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Où vont les supercalculateurs ? D’où on vient, quels sont les problèmes, où l’on va (1re partie). Évalué à 5.
tu viens de réinventer "Lisaac" ! (Mais il est mort)
"La première sécurité est la liberté"
# quelques trucs !
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Où vont les supercalculateurs ? D’où on vient, quels sont les problèmes, où l’on va (1re partie). Évalué à 7. Dernière modification le 05 juillet 2013 à 16:01.
"en pratique, chaque instruction est ensuite décomposée en micro-instructions qui suivent les principes de RISC."
Le ISC de RISC et CISC, veut dire "instruction set computer". On parle du jeu d'instruction et pas du tout de la micro-architecture interne. Le but premier des mips et sparc, les 1ers RISC, était de réduire la taille du pipeline en ayant l'unité de load/store bien séparé de l'ALU. Le nombre réduit de mode d'adressage (le moyen de choper les data, ici par registre quasi exclusivement) était aussi un avantage de simplicité.
"Decode → Execute → Memory" n'est clairement pas un "risc".
Aujourd'hui, le x86 est toujours plus complexe, et il me semble que la grammaire de l'assembleur x86 est ambiguë. Le décodeur est donc un monstre, ce qui permet à intel de mettre une sacré barrière à l'entré sur son marché. De l'autre coté le PowerPC dispose de plein de mode d'adressage, qui' l'éloigne aussi du risc. La taille des instructions des nouveaux ARM est mixte 16/32 bits.
On peut lire que les principes RISC ont "gagné", mais je pense surtout que les RISC sont devenus des CISC.
"simplement « sauter » l'étage mémoire du pipeline"
C'est simplement impossible car la mémoire peut aussi générer des données. Ce genre de bypass implique que l'étage suivant à des entrées multiples, et c'est tout, sauf simple.
"VLIW : Cependant, le bilan énergétique peut être désastreux (après tout, toutes les instructions sont exécutées, qu'elles soient utiles ou pas !)."
C'est même pire que ça, puisque le cpu peut passer sont temps à exécuter des instructions inutiles. Le fait de ne pas pouvoir faire correctement d’ordonnancement statique par le compilateur, en sans doute la raisons principale de l'échec de l'itanium qui devait prendre le relève du x86 pour le 64 bits. Mais il fallait des caches internes monstrueux à l'itanium pour aller vraiment plus vite que les Xeon (sauf en flottant).
" Les processeurs de type SPARC utilisent ces registres pour accélérer les changements de contexte entre threads/processus."
Perdu, les banc de registres à fenêtre , c'est pour les appels de fonctions. Sur SPARC, il y a 32 registres, 8 globaux et 3 paquets de 8 glissant sur une fenêtre de 128 registres ou plus. A chaque call, tout se décale de 8 registres, cela permet d'offrir 8 registres tout frais, sans faire de sauvegarde dans la pile (moins besoin de registre "callee save"). Par contre, une fois qu'il n'y plus de place, il y a une interruption pour tout sauver en mémoire. sur de gros programme avec beaucoup d'appel, cela peut tuer l'avantage de la simplification des fonctions.
"La première sécurité est la liberté"
[^] # Re: Que du bon
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Le noyau Linux 3.10 est sorti. Évalué à 3.
Et pouvoir ou pas basculer sur les drivers propriétaires juste pour lancer un jeu, et garder nouveau le reste du temps, c'est prévu ?
"La première sécurité est la liberté"
# mouais...
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Le thème surprise de linuxfr.org ce soir.. Évalué à 6.
C'est pas mal. Sauf que sur un écran 16/9, il doit y a avoir 40% de bande marron inutile.
"La première sécurité est la liberté"