pasBill pasGates a écrit 16169 commentaires

mplayer fait :
1) lecture depuis le disque
2) decodage
3) affichage

Vu le type d'operation effectue, il est evident qu'un model multithreade est plus efficace pour ce type de soft.

Faire sequentiellement de la lecture(qui revient a s'arreter et attendre que le systeme d'I/O complete la requete), decodage, puis affichage, c'est perdre du temps.
Tu peux tout a fait avoir un thread qui lit depuis le disque et stocke les buffer en RAM et d'autres threads qui s'occupent du decodage et de l'affichage pendant que l'operation d'I/O du/des buffers suivants est effectuee, ca c'est un modele qui optimise l'utilisation du CPU et qui te donne un player performant.

J'aurais presque envie d'ajouter quelque mots sur les I/O completion ports, mais je vais aller dormir un peu avant :+)

Tu n'as jamais du faire de softs multithreads pour dire un truc pareil.

Un exemple tres simple pour mplayer, ce qu'il faut faire :
1) lire les donnees
2) les decoder
3) les afficher

Le point 1) implique des acces disque, chose EXTREMEMENT lente par rapport aux acces memoires et autres operations.
Bref, si tu fais un soft monothread, ton soft passe son temps a lire, stopper, decoder, afficher, lire, stopper, decoder, afficher,...

Si tu as 2 threads, tu as un thread qui s'occupe de lire les donnees du disque, pendant que l'autre s'occupe de decoder/afficher.

Resultat des courses:
- Ton soft multithread est plus rapide qu'un soft monothread, car mplayer ne se tourne pas les pouces pendant que les donnees sont lues depuis le disque.

De meme, ce soft multithread pourra faire du boulot EN AVANCE, ce qui evite d'avoir besoin de ressources CPU plus tard, ce qui evite des saccades et autres dans le cas ou elles ne seraient pas disponibles,...

La regle c'est : Fais le boulot quand tu as le temps plutot qu'attendre le derniere moment et te retrouver dans un cul de sac.

Le multithread au total ca prend effectivement quelques cycles de plus, mais en temps, ca en prend moins, car ca gaspille moins de cycles, c'est ca le miracle.
Les machines en general gaspillent un nombre de cycles enorme a ne rien faire, et les lenteurs viennent du fait que plusieurs softs demandent des ressources au meme moment, faire du travail a l'avance, ca evite ces problemes, faire du multithread pour des softs qui font pas mal de calculs sur des donnees lues depuis le disque, c'est gagner enormement en perfs.

Toi non, mais si une autre personne branchee sur ta machine lance un truc un peu lourd, tu l'as dans le fion avec ton film.

Et le fait est que l'on est en train de se diriger vers ce genre de chose pour les PC de maison aussi, avec genre une machine qui est au centre d'un tas de bordel qu'elle controle, et tout ca tourne en arriere plan, et tu n'as aucune idee de ce que tel periph voudra faire demain pendant que toi tu seras en train de regarder ton DivX ou autre, donc autant faire les choses bien des le debut plutot qu'avoir un design limite qui demandera encore plus de changements plus tard.

Ben desole mais je pense au contraire que l'approche threadee est bien plus judicieuse.

Ca permet de :

1) Faire le boulot tant que tu as le temps, tu ne sais pas si dans les 2 minutes qui suivent toto ne va pas lancer une compile avec un make -j 25 pour le fun ou autre truc bourrin qui va etrangler ton mplayer niveau acces CPU

2) Balancer la charge, plutot qu'avoir ton mplayer qui passe de 5 a 20% d'utilisation de temps en temps, la courbe d'utilisation CPU s'adoucit, ce qui est bien mieux point de vue temps de reponse

3) Le design est plus propre, et tire parti au mieux des perfs du systeme. Parce qu'il faut bien se souvenir que les x% de cycles CPU utilises par mplayer pendant un moment donne(et qui auraient pu etre utilise avant quand il n'y avait pas urgence) sont x% de cycles que les autres softs ne peuvent pas utiliser, et peut-etre qu'ils en auraient besoin eux.

Oui, c'est celle de RMS et bcp d'autres, et en meme temps bcp d'autres gens en ont une autre definition, qui est basee sur ce que j'ai explique, l'origine du mot hacker.

Quand a imposer des definitions uniques, ben je suis pas forcement contre, mais reste a savoir quelle definition imposer, et je ne considere certainement pas celle de RMS comme la seule definition valide.

Le truc est que la definition que ESR donne a "hacker", c'est sa definition, ce n'est pas une verite universelle. cf. plus bas, hacker ca vient de "to hack", et quand tu vois le sens du mot, tu te rends compte que ca peut tres bien s'appliquer a quelqu'un qui penetre un reseau informatique ou autre.

Belle exemple de connerie. Le service pack qui enleve les icones, etc... c'est le SP3. Tu m'expliqueras comment t'as fait pour installer un service pack apres ca, vu que le SP4 est pas encore sorti.

Le groupe d'indiens est pas specifiquement responsable de la compilation de Windows, car ils sont partout dans Microsoft, mon chef est indien, le chef de mon chef est indien, je ne sais combien de mes collegues sont indiens,... Sinon, oui effectivement ceux que je vois sont souvent tres bons(pas tous des dieux non plus, mais ils sont bons), cependant je sais pas si ca vient du fait que tous ceux sortant des ecoles en Inde sont forts, ou simplement que le processus de selection aux interviews a vire les mauvais. A mon avis c'est un peu des deux, mais croire que les indiens sont embauches car ils bossent 24h/24 pour pas cher c'est une anerie, ils sont tout aussi bien payes que n'importe qui, c'est simplement que l'Inde de par sa taille et son systeme educatif a un grand nombre d'informaticiens de bon niveau. Il y a surement des boites vereuses qui profitent du fait que les indiens veulent venir aux USA pour les faire trimer comme des anes, mais ca n'enleve rien a leur qualite et a mon avis ce n'est pas la majorite des entreprises.

Que ESR explique que le terme "hacker" signifie un type qui pond du code, je veux bien, ca n'empeche que bcp de gens avant ESR appelaient "hacker" les gens qui se glissaient dans les reseaux et autres.

Ca vient tout simplement du verbe "to hack" qui selon mon cher Larousse veut dire "taillader, tailler a la hache", etc...

Ce qui s'applique tres bien a quelqu'un qui penetre un systeme informatique.

Rien ne t'oblige a l'accepter, il te suffit de prendre une distrib Linux ou un Mac si le contenu de Windows ne te plait pas.

le danger est surtout qu'ils en abusent pour refourguer tout et n'importe quoi dans ce qu'ils appellent un "OS", pour anéantir la concurrence ("Ben pourquoi j'installerais autre chose, ça existe déjà et c'est déjà sur mon OS ?"). Il suffit de voir les ajouts de XP pour s'en rendre compte : Media Player, décompression Zip, IE (bon d'accord il y était déjà avant, mais pour moi ça n'a rien à voir avec l'OS).

Ca te gene pas qu'il y ait une stack TCP/IP dans Windows ?

C'est ou que tu trace la limite pour ce qu'on peut mettre dans un OS ? En quoi cette limite que tu traces serait acceptable pour tout le monde ?

Ouh lala, il est fache dis moi :+)

Quel rapport avec le schmilblick ? T'avais juste envie de jeter ton fiel la maintenant histoire de foutre la merde dans une news qui n'a rien a voir vu qu'ici ca parle de Sun/Java <-> MS ?

Je vais etre gentil pour tout le monde, je vais eviter de plonger dans ton troll(on l'a deja fait 15x celui-la, faut innover sinon c'est pas marrant) histoire que ca reste lisible.

Allez, va prendre un valium, tu te sentiras mieux apres.

Microsoft a essayé de marginaliser la Java en sortant une version incompatible du langage avec Windows

Je tiens a dementir, nous n'avons rien contre ce type de danse chez Microsoft !

PS pour les moderos: Il y a un message subliminal pour vous dans ce post.

Allez hop -->[] avant de recolter mes premiers [-]

Non, ce qu'il faut a Vulcan, c'est savoir ou se trouvent les blocs, jumps, etc...

Dans n'importe quel compilateur, tu as cette etape ou tu transformes en binaire, et c'est la qu'il se greffe.
Vulcan ne depend pas du langage, il ne depend pas du fait que tel langage permet les fonctions virtuelles, ou autre feature. Il a juste besoin de connaitre la tronche de ton binaire au final, et quand je dis au final, ca veut dire une fois transforme en langage machine x86, IA64 ou MSIL.

Israel n'a absolument rien a foutre de l'ONU, sauf quand l'ONU se range de leur cote, ce qui n'arrive quasiment jamais vu les pratiques degueulasses d'Israel.

Resultat: Israel n'a effectivement rien a branler de l'ONU, ils savent que leur petit copain americain va bloquer l'ONU pour les proteger a chaque fois qu'ils font un truc ignoble.

Le jour ou l'ONU cessera d'etre un empire feodal ou 5 seigneurs ont plus de droits que les autres, le monde se sentira bcp mieux, mais d'ici la beaucoup de gratte-ciels vont tomber je sens.

on ne peut pas ce limiter a dire intel et intel sont les mechants, mais on peut s'outre du refue de faire quoi que ce soit de la part de certein.

Qu'est ce que Intel a a voir avec ca ?

ah, tu voulais dire untel, je me disais aussi... :+)

bon ok, je -->[]

Il n'est pas question d'optimisation, les 2 sont possibles.
Vulcan permet de modifier le code, tu peux donc:
1) optimiser
2) corriger
3) etc...

Il prend des infos a la compilation, et les utilise ensuite pour modifier le code de la facon dont tu le veux(tu decide et implemente l'optimisation, Vulcan n'est qu'un outil te permettant de modifier le binaire a ta guise)

Sinon, on ne parle pas d'OO ici, tu peux modifier le binaire obtenu avec du C par exemple, et c'est d'ailleurs ce qui est fait dans Windows vu qu'il en contient une quantite enorme, bref, c'est un outil generique, qui ne demande pas un langage particulier au-dessus, etc...

La jolie petite pique du debut est sans rapport avec le schmilblick, mais bon passons...

Effectivement, on ne peut pas le faire dans tous les cas, tu peux pas remplacer 90% du code a chaud ou grossir des structures existantes, etc... c'est infaisable.

Par contre des petits bouts de code par ci par la, c'est faisable sans probleme, et ca s'applique tres bien aux patches, car ils corrigent le plus souvent des problemes tres localises et qui ne demandent pas de modifier les structures de donnees.
Bref, la plupart des patchs peuvent en tirer parti, mais probablement pas tous, faut pas esperer installer un service pack sans rebooter.

Et si ton programme n'est pas ecrit en SmallTalk ou Java, tu fais comment pour l'updater/optimiser/... ?

C'est ca que resoud Vulcan, il te corrige du code binaire a chaud, que ce soit du C/C++ ou autre n'est pas important.

Ben le truc est que sur Windows, personne d'autre que MS n'est sense modifier les binaires du systeme, il y a meme le SFP(system file protection) pour eviter que les gens ne modifient les binaires systemes.
Resultat, il n'y a aucune raison d'avoir ces infos dans le binaire, ca ne fait que rajouter du poids inutile dans un binaire, grossir la place disque, ralentir le systeme a cause du merdoyage des caches,... sans aucune raison vu que personne a part MS n'en aurait l'utilite.

Il faut bien voir que ce soft a ete developpe dans l'optique d'une utilisation par MS, notamment de par le fait qu'il n'est pas aise de creer un fix applicable "a chaud", il faut savoir exactement ce que fait le code pour decider si oui ou non le fix cree peut etre applique a chaud, et ca quelqu'un en dehors de MS ne peut pas le faire, et finalement nous on ne fait pas de releases frequentes, ce n'etait donc pas un critere de developpement pour le soft.

Ca a le meme rapport que n'importe quelle news sur MS ici.

Il parait selon certains ici qu'il est important de savoir ce que MS fait car c'est le concurrent principal de Linux, et qu'il a une influence enorme sur le monde informatique.

Alors voila, une info de plus, la difference etant que cette fois ce n'est pas une news a troll sur le bien/mal ou autre, mais une news technique qui pourrait en plus interesser nombre de gens qui n'ont rien a foutre du fait que ce soit MS l'auteur de la chose.

Ca ne penalise absolument rien en perf.
Le kernel que tu as sur ta machine est un kernel "propre", sans aucune info non utile, par contre nous en interne on a a la compilation pris les infos sur le binaire, a quoi il ressemble, etc... et Vulcan grace a ces infos pourra patcher le binaire a chaud, le patch qu'on fournira contient toutes les infos necessaires pour que Vulcan fasse le boulot sur ta machine.

Vulcan te permet de modifier un executable qui en train de tourner, ou de modifier un executable sur disque au choix.

Par exemple tu peux lancer des runs de ton soft dans differents scenarios, voir quelles sont les parties de code les plus utilisees, et modifier l'executable pour les rapprocher histoire d'avoir une meilleure utilisation des caches. Ca serait un exemple de modification d'un binaire sur disque.

Un autre exemple c'est de pouvoir patcher un binaire pendant qu'il tourne, plus besoin de rebooter ou arreter ton service pour patcher, c'est fait pendant que le service tourne.
Cet exemple c'est en fait ce qui va se passer dans .NET Server, il sera possible dans bcp de cas(pas tous) de patcher le kernel, les differents services, etc... sans rebooter, et sans arreter le service.

Vulcan se cree au moment de la compilation une representation de l'executable, et ca lui permet de travailler apres sur cet executable, il sait ou est quoi, comment il peut modifier, etc...

C'est justement a cause du point 2) que j'ai dit que c'etait "non-negligeable" plutot que dire que l'approche LL etait la raison principale.

Euh non, ils m'ont dit qu'ils reviendraient l'annee prochaine, la ils sont partis sur leur planete pour les fetes de fin d'annee.