Bien sûr baud123 d'après ce que tu dis tu n'as pas à te sentir visé par cette caricature et bien sûr ton commentaire est non agressif et tu me demandais juste ce que je pensais...Bien sûr en disant dis ça je n'ai toujours pas donné mon opinion, et à la limite, on s'en tape. C'est marrant, en fait tu sembles être intrigué par mes tournures prudentes et te demander dans quel camp je suis.
Mon intervention avait pour thème l'image des linuxiens hors de leur communauté, point.
Tu n'es pas anti-MS dis-tu, mais ça ne te pose pas de problème qu'un article comme ça passe? Vous rendez-vous compte de ce que dit le premier paragraphe, bordayl, l'avez-vous lu?
Il dit clairement:
Que Gates a fait semblant de se retirer de la direction de MS mais en tire toujours les ficelles;
Qu'il avait pour but d'assurer une mainmise sur la technologie mondiale et la connaissance mondiale;
Qu'il veut maintenant étendre sa domination à d'autres domaines;
Qu'il a un service de propagande et que les médias lui sont soumis; que les pauvres gens gobent tout;
Qu'il a pour objectif d'asservir l'humanité en la rendant dépendante de lui pour les choses vitales.
Donc oui, c'est assez grave. Si votre cerveau est tellement ramolli que vous lisez des accusations pareilles sans vous rendre compte de ce qu'elles sont, c'est votre problème.
Moi lorsque je dis "les linuxiens", je ne fais qu'une généralité vague.
En revanche lorsque le petit diffamateur auteur de cet article dit "Bill Gates", il fait une attaque personnelle avec des propos graves, et vous autres, en ne trouvant rien à redire, cautionnez. C'est son droit. Et c'est votre droit. Simplement, ne venez pas vous plaindre de votre image après. C'était mon propos. Il n'a pas grand chose à voir avec mon opinion sur linux.
J'espère que comme ça c'est plus clair...sinon je ne peux plus grand chose.
Pfouu, làlà, je ne pensais pas que c'était possible de ne pas comprendre ce que je voulais dire.
Que veux-tu? Que je te dise que je pense que les linuxiens sont un ramassis de nerds nolife aigris méchants et jaloux du génie de Bill Gates, au point de publier des articles de bashing sur un site d'audience nationale après qu'il ne soit plus à la tête de Microsoft, et qui sont anticapitalistes et anti-américains, et qui font de leur hobby une religion et qui croient agir pour le Bien de l'humanité, et qui croient en plus sincèrement que leur système chéri est le meilleur techniquement, et qui ne l'oublions pas ont tué la maman de Bambi?
Non? Eh bien, ce que je voulais dire c'est que vous ne devriez pas vous étonner si certains pensent un peu comme ça, à force de ne pas désavouer cette caricature.
Seulement généraliser, c'est normal et c'est ce que tout le monde fait. Toi, moi, tout le monde.
Ce sont les minoritaires les plus virulents d'un groupe qui se remarquent le plus et donnent leur image à l'ensemble, qui "payent pour les autres".
Elle est belle ma phrase elle pourrait s'appliquer à tant d'autres domaines de la société...mais je digresse.
Bref un groupe soucieux de son image doit donc désavouer sans faiblesse, lorsque c'est légitime bien sûr, ceux qui lui portent préjudice.
Et nous sommes sur un site à audience non négligeable, appelé "linuxFR".
D'accord sur un site on a souvent l'impression d'être entre soi, d'accord je monte en épingle un truc qui ne le mérite peut-être pas, mais vous voyez en gros ma pensée.
J'ai mon opinion, il ne faut surtout pas s'en faire pour moi.
Peut-être que je n'ai pas été clair alors? Je ne sais pas.
Ce que je veux dire c'est que, peut être, c'est ce genre de trucs qui vous donne votre réputation, (genre, ah oui les linuxiens sont aigris et en sont toujours à focaliser leur méchanceté sur l'homme qui a été à la tête de ce qu'ils rejettent).
J'me dis, peut-être vous devriez vous dire, oui mais bon finalement ça nous porte préjudice plus qu'autre chose.
L'avis d'un mec qui passe ici une fois de temps en temps vous intéressera peut-être.
Il est ma foi extrêmement simple : voir ce genre de trucs ne m'encourage pas à changer d'opinion sur linux et sur sa communauté, indépendamment des qualités (mmmh...ou pas...) des logiciels libres.
Après, est-ce que je suis un pékin isolé ou un mec représentatif d'un grand nombre de silencieux...qui sait.
Moi je dis ça, je dis rien, hein. Faites-en ce que vous voulez.
Mon commentaire aura une note de -1!!! :)
je suis déçu j'espérais que mon post irait jusqu'à-10 !
Allez un petit effort!
Spéciale dédicace à Etienne Magoud pour son commentaire non insultant, bien senti et détaché malgré mon ton! J'aime beaucoup (sans ironie).
En revanche, vladislav askiparek a le ton typique des aigris dont je parlais (mais que fallait-il attendre d'un conspirationniste, me direz-vous!)
Watchwolf, je m'incline devant ton honnête introspection :)
Je ne trolle pas dans la mesure ou je pense ce que j'ai dit, mais je trolle un peu avec le ton employé, ok, 6*20 tabs c'est peut etre un peu forcer le trait mais je suis sûr que ça doit se faire! Si j'ai une mosaique de preview d'images sur un site je clique frénétiquement sur toutes pour ouvrir des nouveaux onglets et comme ça tout se charge et je consulte tout instantanément par exemple.
Bon, j'ai un gouffre de puissance (ok un truc potable) donc firefox pourrait peut etre faire l'affaire pour etre honnete, mais sur d'autres machines c'es déjà beaaucoup moins gagné...Pour utiliser chrome depuis le day one je peux dire que ça déchire. (Bon pour être honnête, ça fuit de la ram chez moi et ça c'est grave, certains truc en flash se chargent une fois sur trois, des incompatibilités mineures...mais bon.)
Je vais vous dire ce qu'il y a dans l'inconscient des aigris, et dont les intéressés eux-mêmes ne se rendent probablement pas compte, c'est très simple :
Ca vous fait mal de réaliser que votre champion-opensource-qui-prouve-la-grandeur-et -l'efficacité-du-libre est une grosse bouse et qu'une boite avec des gens qui savent coder peut faire un truc qui est tellement loin devant.
Ca aura mis le temps à ouvrir les yeux...Sérieux, ça fait deja au moins 3 ans que firefox est bien plus lent que même IE, je me souviens encore du commentaire innocent d'un mec sans aucun a priori : 'oui j'ai déjà utilisé mais j'aime pas, c'est lent.'
Y a pas si longtemps sur un blog un mec essayait de debugger la lourdeur de firefox, si ma mémoire est bonne il parlait de 40000 mallocs de moins de 100 bytes avant d'ouvrir un tab...
Seriously, guys.
Seriously.
What the fuck.
La réponse au sondage est donc : 'J'utilise la version windows depuis longtemps.'
Depuis le day one en fait, j'ai vu l'info, j'ai lu la BD, j'ai installé, j'ai lancé, et dans la seconde, j'ai dit, 'oui, je le veux' :) ... Je dois revenir sous IE une fois l'an si un site passe mal.
Il doit bien m'arriver d'avoir cinq ou six fenêtres avec chacune dix ou vingt tabs, qui datent de quelques jours et de quelques entrées et sorties de mise en veille.
If you don't respect our decision to keep the thing closed for now, then don't use the emulator. By keeping it we are able to personally have a full understanding of the entire code base and that's practically necessary for a project like this (you need to have written a highend emulator to really understand this). This wouldn't be the possible if many more people were adding their own little tweaks all the time. Besides, there aren't really many people who are able to make useful contributions to a project like this anyway.
Right now OpenGL is less suited than Direct3D for emulating the gamecube graphics (OpenGL has less per-primitive overhead so I would have chosen it instead if the shader language situation wasn't so abysmal). D3D has HLSL which is practically necessary while the standard OpenGL shader language GLSL still doesn't work on nvidia cards and is very early and glitchy, and isn't as well suited. It's not a simple matter of just porting the current plugin to OpenGL.
Besides, if we were to make a linux port, all the usual problems with linux development that makes me stay away from it crops up: What UI toolkit should be used? What audio server? etc... whatever choice we would make, haters from the other side would crop up. That's totally unlike the situation on Windows where the only choices for these things are Win32 and DirectSound, and everyone is happy with those since they are good and work on everyone's computers without configuration.
I'm not interested in hobby Linux development until these things are standardized properly, it's just not fun to deal with crap like this. The coherent environment of Windows is a much better framework for "for fun" hobby development.
------
Voilà qui remet sèchement à leur place beaucoup de linux zealots!
Forcément ça fait mal quand ça vient de la part de quelqu'un qui fait forcément partie de l'élite des coders.
ma méthode serait connue mais elle est plus lente puisqu'elle calcule a chaque fois le plus onéreux des deux cas.
donc c'est pour ça qu'elle n'est pas utilisée, et le papier sert a montrer qu'il faut faire ce genre de trucs...
pour moi c'est clair que c'est pas 4 fois plus lent, mais au pire deux et en moyenne 1.5, et encore parce que comme l'a fait remarquer Terje sur slashdot, ça enleve les penalités de flush du pipe.
en tout cas de ne pas dire que ça existe dans leur papier, de metttre une phrase comme celle que j'ai quotée, et de declencher la rumeur médiatique sur la fin du monde :) ... c'est un peu fort mais bon.
S = M
for i from 1 to n-1 do
{
S = S * S(mod N)
if di == 1 then
{ S = S * M(mod N) }
}
replaced by:
S = M
for i from 1 to n-1 do
{
A = S * S(mod N)
B = A * M(mod N)
maskA = !di
maskB = di
S = (A & maskA) | (B & maskB)
}
Basically, it calculates the 2 possible values in to store in S, then selects automatically the right one to put in S, based on the value of di.
The choice is performed by adding properly masked results. Of course when I write "maskB = di" I mean extending the the bit to all the bits of the integer (or whatever it is). This IS possible, even in C, for example "maskB = 0 - di" if di is 0 or 1.
In assembly language you even dont need masks (that was my first idea).
On processors supporting MOVcc, you just have to move the two results conditionally to the returned register.
j'ai lu l'article, ce qu'a peu pres personne ici n'a fait.
remarques:
le process espion ne doit tourner qu'en mode utilisateur. la technique ne chronomètre pas le temps total donc rajouter un temps aleatoire a la fin ne sert a rien. mettre du code qui ne fait rien dans la branche non prise ne sert a rien. mettre presque le meme code qui prend le meme temps dans la branche non vide ne sert a rien. une seule passe sur le chiffrement est nécessaire.
les gens sont evidemment tres calés sinon ils ne feraient pas de la recherche la dedans.
j'ai pas tout compris a l'article, certains trucs sont vagues.
cependant evidemment tout ceci est futile et infondé car la solution est tres simple.
La personne ici qui a parlé des CMOV a cent fois raison..
(sauf qu'il devait penser à un JMP indirect avec l'adresse remplie par un CMOV, ce qui ne marche sans doute pas car la prédiction de branchement peut maintenant prevoir ça je crois... mais les CMOV peuvent etre utilisés pour remplacer les jumps conditionnels par des séries d'instructions conditionnelles et ça ça marche. )
celle qui a écrit ceci aussi:
"
Ne devrait-on pas dans ce cas repartir de l'algorithme initial non équilibré :
S = M
for i from 1 to n-1 do
S = S * S(mod N)
if di == 1 then
S = S * M(mod N)
et tenter de s'en sortir sans une boucle conditionnelle ?
S = M
for i from 1 to n-1 do
S = S * S(mod N)
S = S * M(mod N) * di + S * not di
Ai-je au moins compris le problème ?
"
oui.
une solution algorithmique comme celle ci marche tres bien et je suis aterré de voir que des tas d'articles hyper sérieux sont publiés depuis des années sur des trucs qui ne marchent absolument pas sans branchements. et on voit "intel fait la sourde oreille etc". je ne peux pas le croire.
en fait le probleme vient du fait que les gens ne connaissent pas l'assembleur.
sinon la solution avec les CMOV aurait été immédiate.
sans connaitre la crypto, quand j'ai vu le DEBUT de l'article sous google avec les termes "prédiction de branchements", j'ai eu l'intuition du probleme et j'ai pensé dans la meme seconde aux CMOV pour le résoudre. je dois avouer que la solution algorithmique est peut etre plus elegante, meme si ça revient globalement au meme. sans CMOV on peut y arriver aussi bien sur, en faisant des contorsions et des masquages sur les bits des registres, bits dont on s'arrange pour que certains proviennent du résultat de la comparaison concernée. ici c'est encore plus simple vu que ces bits sont deja ceux d'un nombre.
en gros quels que soient les deux cal de calculs ça marche. on a qu'a faire le calcul deux fois et stocker les deux puis faire la comparaison et bouger le bon dans le registre de destination.
et en gros n'importe quelle code conditionnel doit pouvoir se ramener a ça d'ailleurs.
c'est assez evident quand on fait de l'assembleur.(enfin moi j'avais deja reflechi par hasard au moyen de virer les Jcc donc ça doit avoir aidé)
je vais chercher vite fait sur le net parce que comme des gens ont deja donné la solution ici, et que c'est assez idiot, c'est obligé que ça se sache... quoique... d'aut papiers depuis plusieurs années font des trucs super compliqués la dessus... comme le truc sur les caches...
alors encore une fois, je suis aterré (et fier) qu'un n00b comme moi voie ça direkt parce qu'aparemment c officiel que y a pas de solution (intel dit qu'on desactivera le BTB si besoin!!!!)
quand on lit ça dans le papier:
"it especially endangers those cryptographic/algorithmic primitives, whose nature is an intrinsic and input-dependant branch process"
en fait apres avoir posté j'ai approfondi et compris l'article mais j'avais paas envie de reposter.
[quote]
Alignement sur la plus longue possible qui ne pose pas de problèmes même sur du 32 bits, ça doit même pouvoir être mieux.
[/quote]
mmmh gné? pas tout compris.. sur x86 les opcodes ont une taille variable, en nb d'octets entier...
[quote]
C'est pourtant simple (en théorie) : si l'instruction résultante est plus rapide que celle de départ, qui elle est plus générique.
[/quote]
.. et moins rapide qu'elle meme, sans NOPS.
oui oui. ça revient à justifier l'activation de cette technique, si elle est présente ^^. la question est pourquoi utiliser ceci plutot que deux codes compilés différents. sans doute que c'est parce que (comme je l'ignore) le noyau n'est pas fait avec des DLL. auquel cas on peut switcher entre deux noyaux entiers. (mais pas pendant que ça tourne à cause de l'état des variables etc)
pendant que j'y pense: un autre enorme argument en faveur de la compil specifique est que les regles d'optim des compilos varient d'une famille de pross à l'autre ( c'est pas juste une histoire d'utiliser, ou non, les nouvelles instructions). et ça, c'est pas patchable. et je pense que la recherche de performance du code présent dans le kernel n'est pas à négliger...
bien sur probablement que windows aussi par exemple utilise le plus petit denominateur commun admis pour le systeme (quoique c'est pas si sur...) ; ce truc est bien sur intéressant techniquement, mais je pense que c'est faire (tres) à moitié ce qu'on voulait faire.
[quote]
CPU hotplug, gestion des pertes de CPU, distributions avec kernel générique.
[/quote]
ça n'est valable que si le CPU que tu plugge est différent du précédent au point d'avoir une ISA différente. à supposer que ce soit le cas (sachant que le CPU est mis sur le meme socket, mais c'est possible surement, SSE tout ça)
1.on rajoute un CPU qui n'etait pas là ou on en change un qui a claqué: je suppose que c'est de la RAM partagée et que le code est exécuté par un autre CPU, différent...oh my god! :D
[ceci dit, je ne sais pas exactement comment tout ça se passe et je suis preneur de toute explication/lien...]
2. on change le seul CPU (qui marchait): la, ça a l'air de se tenir, mais il faut avoir reussi a arreter tout le bazar de maniere cohérente.
distributions avec kernel générique: argument valable.
Cependant, on est sur d'avoir presque tout le temps un truc sub-optimal.
juste une note: bien que ça n'enleve rien a leur intéret (ou pas?) , tous les commentaires plus haut sous "optim du temps de boot" n'ont strictement rien a voir avec ce sujet
mes pensees la dessus s'arretent la ce soir, les enfants. daysolay si j'ai pu paraitre hautain.
d'abord c'est pas tres clair la phrase qui en parle.
au début j'ai pensé qu'il switchait at runtime entre differents bouts de code (procedures) precompilés(un par archi).
Ce qui n'est en soi pas neuf, mais qui prend de la place en ram si tout doit rester resident. apres si on a un chargement dynamique de modules on peut ne garder que les bons bouts.)
des jeux font ça pour le SIMD.
Dans ce style y a des trucs bien plus poussés du genre la compil on the fly, j'avais vu un mec dont le moteur 3d generait les routines de tracé optimisées a la volée comme ça...me souviens plus du nom du truc, impressionnant, ça balançait du rendu de Q3, en soft, sur un P4.
en fait il s'avere que ce que ce qui est fait ici est le patch tres localisé (à chaque occurence de l'instruction concernée) pour la remplacer par celle adéquate sur cette famille de pross. "et si elle est plus longue" ai-je tout de suite pensé? si elle est plus courte on rajoute des NOPs. donc ça doit s'aligner sur la plus longue possible. super. on va me dire c'est quoi deux NOPs? c'est ça de perdu dans le pipeline et je vois pas trop de justification... ce serait plus simple d'avoir deja compilé un kernel par archi et de tout switcher au boot...c'est si gros que ça un kernel?(j'y connais pas grand ch.. heu que dalle). ou alors c'est pas assez modulaire pour ça?
bien sur dans ces cas là on peut pas switcher pendant que ça tourne mais je me demande pourquoi on peut avoir besoin de switcher pendant que ça tourne...
de plus d'aut gens emettent l'hypothese que ça pourrait creer des deadlocks (rapport au SMP là).
d'ailleurs c'est appelé SMP alternatives mais ça n'a rien de specifique au multiprocessing, ça a rapport à l'ajout d'instructions dans l'ISA.
quant aux hypotheses sur skynet, faut pas pousser. c'est du patch, pas bien plus mechant que de la resolution d'adresses lors du load d'un exe (moins risqué, meme, je dirais).
mais l'assembleur n'est pas forcément le fort des adeptes de l'open source...mais d'ailleurs qui suis-je pour critiquer? à croire que mon compte ne sert qu'à ça...
[^] # Re: Un seul son de cloche...
Posté par helloworld256 . En réponse à la dépêche Bill Gates et la diversification externe. Évalué à 1.
Mon intervention avait pour thème l'image des linuxiens hors de leur communauté, point.
Tu n'es pas anti-MS dis-tu, mais ça ne te pose pas de problème qu'un article comme ça passe? Vous rendez-vous compte de ce que dit le premier paragraphe, bordayl, l'avez-vous lu?
Il dit clairement:
Que Gates a fait semblant de se retirer de la direction de MS mais en tire toujours les ficelles;
Qu'il avait pour but d'assurer une mainmise sur la technologie mondiale et la connaissance mondiale;
Qu'il veut maintenant étendre sa domination à d'autres domaines;
Qu'il a un service de propagande et que les médias lui sont soumis; que les pauvres gens gobent tout;
Qu'il a pour objectif d'asservir l'humanité en la rendant dépendante de lui pour les choses vitales.
Donc oui, c'est assez grave. Si votre cerveau est tellement ramolli que vous lisez des accusations pareilles sans vous rendre compte de ce qu'elles sont, c'est votre problème.
Moi lorsque je dis "les linuxiens", je ne fais qu'une généralité vague.
En revanche lorsque le petit diffamateur auteur de cet article dit "Bill Gates", il fait une attaque personnelle avec des propos graves, et vous autres, en ne trouvant rien à redire, cautionnez. C'est son droit. Et c'est votre droit. Simplement, ne venez pas vous plaindre de votre image après. C'était mon propos. Il n'a pas grand chose à voir avec mon opinion sur linux.
J'espère que comme ça c'est plus clair...sinon je ne peux plus grand chose.
Sur ce...
[^] # Re: Un seul son de cloche...
Posté par helloworld256 . En réponse à la dépêche Bill Gates et la diversification externe. Évalué à 1.
Que veux-tu? Que je te dise que je pense que les linuxiens sont un ramassis de nerds nolife aigris méchants et jaloux du génie de Bill Gates, au point de publier des articles de bashing sur un site d'audience nationale après qu'il ne soit plus à la tête de Microsoft, et qui sont anticapitalistes et anti-américains, et qui font de leur hobby une religion et qui croient agir pour le Bien de l'humanité, et qui croient en plus sincèrement que leur système chéri est le meilleur techniquement, et qui ne l'oublions pas ont tué la maman de Bambi?
Non? Eh bien, ce que je voulais dire c'est que vous ne devriez pas vous étonner si certains pensent un peu comme ça, à force de ne pas désavouer cette caricature.
Je ne disais pas autre chose.
Et ce sera tout.
[^] # Re: Un seul son de cloche...
Posté par helloworld256 . En réponse à la dépêche Bill Gates et la diversification externe. Évalué à 1.
Seulement généraliser, c'est normal et c'est ce que tout le monde fait. Toi, moi, tout le monde.
Ce sont les minoritaires les plus virulents d'un groupe qui se remarquent le plus et donnent leur image à l'ensemble, qui "payent pour les autres".
Elle est belle ma phrase elle pourrait s'appliquer à tant d'autres domaines de la société...mais je digresse.
Bref un groupe soucieux de son image doit donc désavouer sans faiblesse, lorsque c'est légitime bien sûr, ceux qui lui portent préjudice.
Et nous sommes sur un site à audience non négligeable, appelé "linuxFR".
D'accord sur un site on a souvent l'impression d'être entre soi, d'accord je monte en épingle un truc qui ne le mérite peut-être pas, mais vous voyez en gros ma pensée.
Voilà voilà.
[^] # Re: Un seul son de cloche...
Posté par helloworld256 . En réponse à la dépêche Bill Gates et la diversification externe. Évalué à 1.
Peut-être que je n'ai pas été clair alors? Je ne sais pas.
Ce que je veux dire c'est que, peut être, c'est ce genre de trucs qui vous donne votre réputation, (genre, ah oui les linuxiens sont aigris et en sont toujours à focaliser leur méchanceté sur l'homme qui a été à la tête de ce qu'ils rejettent).
J'me dis, peut-être vous devriez vous dire, oui mais bon finalement ça nous porte préjudice plus qu'autre chose.
point.
[^] # Re: Un seul son de cloche...
Posté par helloworld256 . En réponse à la dépêche Bill Gates et la diversification externe. Évalué à 1.
L'avis d'un mec qui passe ici une fois de temps en temps vous intéressera peut-être.
Il est ma foi extrêmement simple : voir ce genre de trucs ne m'encourage pas à changer d'opinion sur linux et sur sa communauté, indépendamment des qualités (mmmh...ou pas...) des logiciels libres.
Après, est-ce que je suis un pékin isolé ou un mec représentatif d'un grand nombre de silencieux...qui sait.
Moi je dis ça, je dis rien, hein. Faites-en ce que vous voulez.
[^] # Re: Mouais...
Posté par helloworld256 . En réponse au sondage Chromium / Google Chrome sous Linux. Évalué à -3.
je suis déçu j'espérais que mon post irait jusqu'à-10 !
Allez un petit effort!
Spéciale dédicace à Etienne Magoud pour son commentaire non insultant, bien senti et détaché malgré mon ton! J'aime beaucoup (sans ironie).
En revanche, vladislav askiparek a le ton typique des aigris dont je parlais (mais que fallait-il attendre d'un conspirationniste, me direz-vous!)
Watchwolf, je m'incline devant ton honnête introspection :)
Je ne trolle pas dans la mesure ou je pense ce que j'ai dit, mais je trolle un peu avec le ton employé, ok, 6*20 tabs c'est peut etre un peu forcer le trait mais je suis sûr que ça doit se faire! Si j'ai une mosaique de preview d'images sur un site je clique frénétiquement sur toutes pour ouvrir des nouveaux onglets et comme ça tout se charge et je consulte tout instantanément par exemple.
Bon, j'ai un gouffre de puissance (ok un truc potable) donc firefox pourrait peut etre faire l'affaire pour etre honnete, mais sur d'autres machines c'es déjà beaaucoup moins gagné...Pour utiliser chrome depuis le day one je peux dire que ça déchire. (Bon pour être honnête, ça fuit de la ram chez moi et ça c'est grave, certains truc en flash se chargent une fois sur trois, des incompatibilités mineures...mais bon.)
# Mouais...
Posté par helloworld256 . En réponse au sondage Chromium / Google Chrome sous Linux. Évalué à -3.
Ca vous fait mal de réaliser que votre champion-opensource-qui-prouve-la-grandeur-et -l'efficacité-du-libre est une grosse bouse et qu'une boite avec des gens qui savent coder peut faire un truc qui est tellement loin devant.
Ca aura mis le temps à ouvrir les yeux...Sérieux, ça fait deja au moins 3 ans que firefox est bien plus lent que même IE, je me souviens encore du commentaire innocent d'un mec sans aucun a priori : 'oui j'ai déjà utilisé mais j'aime pas, c'est lent.'
Y a pas si longtemps sur un blog un mec essayait de debugger la lourdeur de firefox, si ma mémoire est bonne il parlait de 40000 mallocs de moins de 100 bytes avant d'ouvrir un tab...
Seriously, guys.
Seriously.
What the fuck.
La réponse au sondage est donc : 'J'utilise la version windows depuis longtemps.'
Depuis le day one en fait, j'ai vu l'info, j'ai lu la BD, j'ai installé, j'ai lancé, et dans la seconde, j'ai dit, 'oui, je le veux' :) ... Je dois revenir sous IE une fois l'an si un site passe mal.
Il doit bien m'arriver d'avoir cinq ou six fenêtres avec chacune dix ou vingt tabs, qui datent de quelques jours et de quelques entrées et sorties de mise en veille.
C'est beau la technologie moderne :)
# Commentaire de dévs lors des requetes pour un portage opensource....
Posté par helloworld256 . En réponse à la dépêche Dolphin : l'émulateur GameCube et WII rejoint le Libre !. Évalué à 1.
------
If you don't respect our decision to keep the thing closed for now, then don't use the emulator. By keeping it we are able to personally have a full understanding of the entire code base and that's practically necessary for a project like this (you need to have written a highend emulator to really understand this). This wouldn't be the possible if many more people were adding their own little tweaks all the time. Besides, there aren't really many people who are able to make useful contributions to a project like this anyway.
Right now OpenGL is less suited than Direct3D for emulating the gamecube graphics (OpenGL has less per-primitive overhead so I would have chosen it instead if the shader language situation wasn't so abysmal). D3D has HLSL which is practically necessary while the standard OpenGL shader language GLSL still doesn't work on nvidia cards and is very early and glitchy, and isn't as well suited. It's not a simple matter of just porting the current plugin to OpenGL.
Besides, if we were to make a linux port, all the usual problems with linux development that makes me stay away from it crops up: What UI toolkit should be used? What audio server? etc... whatever choice we would make, haters from the other side would crop up. That's totally unlike the situation on Windows where the only choices for these things are Win32 and DirectSound, and everyone is happy with those since they are good and work on everyone's computers without configuration.
I'm not interested in hobby Linux development until these things are standardized properly, it's just not fun to deal with crap like this. The coherent environment of Windows is a much better framework for "for fun" hobby development.
------
Voilà qui remet sèchement à leur place beaucoup de linux zealots!
Forcément ça fait mal quand ça vient de la part de quelqu'un qui fait forcément partie de l'élite des coders.
[^] # Re: assez de blabla. voila ce que j'en dis.
Posté par helloworld256 . En réponse à la dépêche Une faille majeure de la cryptographie courante. Évalué à 1.
ma méthode serait connue mais elle est plus lente puisqu'elle calcule a chaque fois le plus onéreux des deux cas.
donc c'est pour ça qu'elle n'est pas utilisée, et le papier sert a montrer qu'il faut faire ce genre de trucs...
pour moi c'est clair que c'est pas 4 fois plus lent, mais au pire deux et en moyenne 1.5, et encore parce que comme l'a fait remarquer Terje sur slashdot, ça enleve les penalités de flush du pipe.
en tout cas de ne pas dire que ça existe dans leur papier, de metttre une phrase comme celle que j'ai quotée, et de declencher la rumeur médiatique sur la fin du monde :) ... c'est un peu fort mais bon.
[^] # Re: assez de blabla. voila ce que j'en dis.
Posté par helloworld256 . En réponse à la dépêche Une faille majeure de la cryptographie courante. Évalué à 2.
how to remove conditional jumps:
my method:
S = M
for i from 1 to n-1 do
{
S = S * S(mod N)
if di == 1 then
{ S = S * M(mod N) }
}
replaced by:
S = M
for i from 1 to n-1 do
{
A = S * S(mod N)
B = A * M(mod N)
maskA = !di
maskB = di
S = (A & maskA) | (B & maskB)
}
Basically, it calculates the 2 possible values in to store in S, then selects automatically the right one to put in S, based on the value of di.
The choice is performed by adding properly masked results. Of course when I write "maskB = di" I mean extending the the bit to all the bits of the integer (or whatever it is). This IS possible, even in C, for example "maskB = 0 - di" if di is 0 or 1.
In assembly language you even dont need masks (that was my first idea).
On processors supporting MOVcc, you just have to move the two results conditionally to the returned register.
[^] # Re: assez de blabla. voila ce que j'en dis.
Posté par helloworld256 . En réponse à la dépêche Une faille majeure de la cryptographie courante. Évalué à 1.
ici:
http://it.slashdot.org/comments.pl?sid=207304&cid=169054(...)
ici:
http://it.slashdot.org/comments.pl?sid=207304&cid=169002(...)
le deuxieme son nom ne m'est pas inconnu mais je retrouve pas pourquoi...
# assez de blabla. voila ce que j'en dis.
Posté par helloworld256 . En réponse à la dépêche Une faille majeure de la cryptographie courante. Évalué à 4.
j'ai lu l'article, ce qu'a peu pres personne ici n'a fait.
remarques:
le process espion ne doit tourner qu'en mode utilisateur. la technique ne chronomètre pas le temps total donc rajouter un temps aleatoire a la fin ne sert a rien. mettre du code qui ne fait rien dans la branche non prise ne sert a rien. mettre presque le meme code qui prend le meme temps dans la branche non vide ne sert a rien. une seule passe sur le chiffrement est nécessaire.
les gens sont evidemment tres calés sinon ils ne feraient pas de la recherche la dedans.
j'ai pas tout compris a l'article, certains trucs sont vagues.
cependant evidemment tout ceci est futile et infondé car la solution est tres simple.
La personne ici qui a parlé des CMOV a cent fois raison..
(sauf qu'il devait penser à un JMP indirect avec l'adresse remplie par un CMOV, ce qui ne marche sans doute pas car la prédiction de branchement peut maintenant prevoir ça je crois... mais les CMOV peuvent etre utilisés pour remplacer les jumps conditionnels par des séries d'instructions conditionnelles et ça ça marche. )
celle qui a écrit ceci aussi:
"
Ne devrait-on pas dans ce cas repartir de l'algorithme initial non équilibré :
S = M
for i from 1 to n-1 do
S = S * S(mod N)
if di == 1 then
S = S * M(mod N)
et tenter de s'en sortir sans une boucle conditionnelle ?
S = M
for i from 1 to n-1 do
S = S * S(mod N)
S = S * M(mod N) * di + S * not di
Ai-je au moins compris le problème ?
"
oui.
une solution algorithmique comme celle ci marche tres bien et je suis aterré de voir que des tas d'articles hyper sérieux sont publiés depuis des années sur des trucs qui ne marchent absolument pas sans branchements. et on voit "intel fait la sourde oreille etc". je ne peux pas le croire.
en fait le probleme vient du fait que les gens ne connaissent pas l'assembleur.
sinon la solution avec les CMOV aurait été immédiate.
sans connaitre la crypto, quand j'ai vu le DEBUT de l'article sous google avec les termes "prédiction de branchements", j'ai eu l'intuition du probleme et j'ai pensé dans la meme seconde aux CMOV pour le résoudre. je dois avouer que la solution algorithmique est peut etre plus elegante, meme si ça revient globalement au meme. sans CMOV on peut y arriver aussi bien sur, en faisant des contorsions et des masquages sur les bits des registres, bits dont on s'arrange pour que certains proviennent du résultat de la comparaison concernée. ici c'est encore plus simple vu que ces bits sont deja ceux d'un nombre.
en gros quels que soient les deux cal de calculs ça marche. on a qu'a faire le calcul deux fois et stocker les deux puis faire la comparaison et bouger le bon dans le registre de destination.
et en gros n'importe quelle code conditionnel doit pouvoir se ramener a ça d'ailleurs.
c'est assez evident quand on fait de l'assembleur.(enfin moi j'avais deja reflechi par hasard au moyen de virer les Jcc donc ça doit avoir aidé)
je vais chercher vite fait sur le net parce que comme des gens ont deja donné la solution ici, et que c'est assez idiot, c'est obligé que ça se sache... quoique... d'aut papiers depuis plusieurs années font des trucs super compliqués la dessus... comme le truc sur les caches...
alors encore une fois, je suis aterré (et fier) qu'un n00b comme moi voie ça direkt parce qu'aparemment c officiel que y a pas de solution (intel dit qu'on desactivera le BTB si besoin!!!!)
quand on lit ça dans le papier:
"it especially endangers those cryptographic/algorithmic primitives, whose nature is an intrinsic and input-dependant branch process"
...
on sait qu'on a raison.
comments?
[^] # Re: optimisation du noyau
Posté par helloworld256 . En réponse à la dépêche Sortie du noyau Linux 2.6.17. Évalué à 1.
[quote]
Alignement sur la plus longue possible qui ne pose pas de problèmes même sur du 32 bits, ça doit même pouvoir être mieux.
[/quote]
mmmh gné? pas tout compris.. sur x86 les opcodes ont une taille variable, en nb d'octets entier...
[quote]
C'est pourtant simple (en théorie) : si l'instruction résultante est plus rapide que celle de départ, qui elle est plus générique.
[/quote]
.. et moins rapide qu'elle meme, sans NOPS.
oui oui. ça revient à justifier l'activation de cette technique, si elle est présente ^^. la question est pourquoi utiliser ceci plutot que deux codes compilés différents. sans doute que c'est parce que (comme je l'ignore) le noyau n'est pas fait avec des DLL. auquel cas on peut switcher entre deux noyaux entiers. (mais pas pendant que ça tourne à cause de l'état des variables etc)
pendant que j'y pense: un autre enorme argument en faveur de la compil specifique est que les regles d'optim des compilos varient d'une famille de pross à l'autre ( c'est pas juste une histoire d'utiliser, ou non, les nouvelles instructions). et ça, c'est pas patchable. et je pense que la recherche de performance du code présent dans le kernel n'est pas à négliger...
bien sur probablement que windows aussi par exemple utilise le plus petit denominateur commun admis pour le systeme (quoique c'est pas si sur...) ; ce truc est bien sur intéressant techniquement, mais je pense que c'est faire (tres) à moitié ce qu'on voulait faire.
[quote]
CPU hotplug, gestion des pertes de CPU, distributions avec kernel générique.
[/quote]
ça n'est valable que si le CPU que tu plugge est différent du précédent au point d'avoir une ISA différente. à supposer que ce soit le cas (sachant que le CPU est mis sur le meme socket, mais c'est possible surement, SSE tout ça)
1.on rajoute un CPU qui n'etait pas là ou on en change un qui a claqué: je suppose que c'est de la RAM partagée et que le code est exécuté par un autre CPU, différent...oh my god! :D
[ceci dit, je ne sais pas exactement comment tout ça se passe et je suis preneur de toute explication/lien...]
2. on change le seul CPU (qui marchait): la, ça a l'air de se tenir, mais il faut avoir reussi a arreter tout le bazar de maniere cohérente.
distributions avec kernel générique: argument valable.
Cependant, on est sur d'avoir presque tout le temps un truc sub-optimal.
juste une note: bien que ça n'enleve rien a leur intéret (ou pas?) , tous les commentaires plus haut sous "optim du temps de boot" n'ont strictement rien a voir avec ce sujet
mes pensees la dessus s'arretent la ce soir, les enfants. daysolay si j'ai pu paraitre hautain.
# optimisation du noyau
Posté par helloworld256 . En réponse à la dépêche Sortie du noyau Linux 2.6.17. Évalué à 4.
d'abord c'est pas tres clair la phrase qui en parle.
au début j'ai pensé qu'il switchait at runtime entre differents bouts de code (procedures) precompilés(un par archi).
Ce qui n'est en soi pas neuf, mais qui prend de la place en ram si tout doit rester resident. apres si on a un chargement dynamique de modules on peut ne garder que les bons bouts.)
des jeux font ça pour le SIMD.
Dans ce style y a des trucs bien plus poussés du genre la compil on the fly, j'avais vu un mec dont le moteur 3d generait les routines de tracé optimisées a la volée comme ça...me souviens plus du nom du truc, impressionnant, ça balançait du rendu de Q3, en soft, sur un P4.
en fait il s'avere que ce que ce qui est fait ici est le patch tres localisé (à chaque occurence de l'instruction concernée) pour la remplacer par celle adéquate sur cette famille de pross. "et si elle est plus longue" ai-je tout de suite pensé? si elle est plus courte on rajoute des NOPs. donc ça doit s'aligner sur la plus longue possible. super. on va me dire c'est quoi deux NOPs? c'est ça de perdu dans le pipeline et je vois pas trop de justification... ce serait plus simple d'avoir deja compilé un kernel par archi et de tout switcher au boot...c'est si gros que ça un kernel?(j'y connais pas grand ch.. heu que dalle). ou alors c'est pas assez modulaire pour ça?
bien sur dans ces cas là on peut pas switcher pendant que ça tourne mais je me demande pourquoi on peut avoir besoin de switcher pendant que ça tourne...
de plus d'aut gens emettent l'hypothese que ça pourrait creer des deadlocks (rapport au SMP là).
d'ailleurs c'est appelé SMP alternatives mais ça n'a rien de specifique au multiprocessing, ça a rapport à l'ajout d'instructions dans l'ISA.
quant aux hypotheses sur skynet, faut pas pousser. c'est du patch, pas bien plus mechant que de la resolution d'adresses lors du load d'un exe (moins risqué, meme, je dirais).
mais l'assembleur n'est pas forcément le fort des adeptes de l'open source...mais d'ailleurs qui suis-je pour critiquer? à croire que mon compte ne sert qu'à ça...
bonne nuit.
[^] # Re: Oui
Posté par helloworld256 . En réponse au message Installation .RPM, etc... logiciel DOT/GRAPHVIZ. Évalué à 1.
rpm -i --root truc.rpm ????
vais tenter...
on peut pas voir lextraire des trucs du RPM?
bye