le MMX, SSE truc muche en revanche c'est clairement que du marketing.
Faut arréter les rideaux ! C'est pas bon pour la santé.
Les P4 arrivent à fumer les Athlons pour des applis comme le divx grace au SSE. Sinon la fpu x87 du P4 est 2x plus lente que celle de l'athlon.
Le problème des nouvelles instructions est qu'il faut les utiliser pour bénéficier de leurs avantages qui sont bien réelle.
Le proof of concept est interrescant uniquement si le patch correctif est fournis avec. Faire une charge viral est vraiment trop facile ("\rm -rf /", installation de root kit, ... ) à ajouter un système d'infiltration !
Pour le bripro , il y a beaucoup de linuxiens sur www.smp-fr.com. La carte mère c'est un général de l'Asus.
Les bipro AMD ont le meilleurs rapport qualité/prix et de loin.
Pour ATI/NVIDIA, le problème : veux-tu un truc qui marche avec tout les fonctions activé ou espéré un bon support du libre ... plus tard.
J'ai une ATI mais sans la 3d. A mon avis, une NVIDIA 4200 te fera bien l'affaire (driver 100% proprio sans trop de problème contrairement à celui de ATI...). Ta manipulation d'image ne concerne pas la carte video ce qu'il te faut c'est un 1 Go de RAM ! (ECC pour le bipro qui dispose de 4 slot) (mémoire max 3.5Go)
Finalement, l'article n'indique pas grand chose de neuf.
- droit de perquisition facilité chez les opérateurs.
Qui peut être contre ? C'est le fichage systèmatique qui est dangereux.
- Extension de la porté des personnes inscritent dans le fichiers d'empreinte génétique.
Que ceux qui sont contre l'extention de la porté du fichier m'explique la différence avec celui des empreintes digitals.
Que ceux qui sont contre ce fichier tout court aillent le dire au 3-4 parents dont la fille a été massacré par un récidiviste (alors qu'il aurait pu être arrété immédiatement après son premier crime).
Les prostituers ne veulent pas parler à cause de la menace et son relacher immmédiatement et retourne sur le troittoire. E tla justice ne peut rien faire de plus.
Là, elle peut la mettre 2 mois en tôle et cela fait chier aussi le proxènète mais cela la fera réfléchier pour témoigner. La proposition d'un visa temporaire est fait pour l'y aider.
ton process qui est sense afficher une video est stoppe.
euh ? oui, mais ce n'est pas forcément grave. Ce n'est important que si ton process ne tient pas ses deadlines dans tous les autres cas...
Si tu veux anticipé des brusques indisponnibilités du système, tu utilises des caches. Un asynch io fait le boulot que tu veux faire : lire le bloc suivant pendant que tu traites le bloc courant.
Les thread ne sont pas plus efficaces (sauf lors d'application vraiement interractive et qui ont des phases lente à faire laguer l'affichage comme certain client mail).
Ils sont juste plus facile à coder. L'exemple typique sont les serveurs multi-threadé qui enfle à chaque nouveau connecté. Si TUX (serveur web kernel plus rapide encore que khttpd) déchire tant c'est bien parce que il n'utilise pas un thread par connection !
Non tu perds globalement des perfs sur ton système. Un process qui ne prends que 40 % de cpu se fout du temp passé dans la lecture du disque pour tenir ses deadlines. Dans les 60% non utilisé est compté le temps passé à attendre les io.
Tu ne peux que gaspiller de la puissance dans la gestion des thread et le traching de mémoire cache en faisant plus compliqué.
Tu aura peut-être plus de puissance pour tenir des deadline à 500 images/s mais ce n'est pas ça que l'on demande au codec.
Ce que tu décris s'appelle les acces asynchrones ou non bloquant (asyncIO). Il me semble que la glibc sait faire ça depuis longtemps elle même et que linux 2.4 le prends en charge maintenant commeun grand.
Il est donc parfaitement inutile de programmer un thread pour ça.
De plus, lors d'acces io, si le temps est trop long, le scheduler peut décider de donner la main à un autre process (cela se voit facilement avec l'utilisation d'un lentissime printf). Tu ne perds donc aucun cycle.
Si ta machine ne fait qu'une seule tache, un monothread sans io non bloquante étant bloqué à chaque io, tu perds des perf sur ce process-là uniquement. Mais globalement, ta machine peut faire d'autres trucs. Il n'y a pas de gaspillage.
Si tu veux augmenter les perf c'est-à-dire parraléliser acces disque et calcul, et bien, les io asynchrones ou non bloquantes sont faites pour ça !
Tu m'épates là ! Tes arguments sont complétements à inverser.
1/ Pour faire, la même tâche si tu utilises 2 threads au lieu d'un seul tu perds des cycles à passer de l'un à l'autre. Si TUX (serveur http noyau) déchire, c'est parce qu'il fait de la zero copie et qu'il n'a PAS un thread par utilisateur. Sur un monoprocesseur, à cause des changement de tâche, tu perds du temps. Si quelqu'un lance un gros boulot, le scheduler doit juste scheduler un thread de plus. Cela ne lui fait que perdre du temps.
Sur un bi-pro (ou SMT), tu repartis la charge, genre 2% sur chaque cpu. Or les partages de mémoire font que les caches sont sous utilisé (en SMP) mais pas en SMT. Or en SMT, si des optimisations typé SMP sont utilisé (grosse séparation des flux mémoire pour éviter de trasher les caches) la pression sur les caches devient énorme (les caches miss s'envole aussi). Les optimisations SMT/SMP sont antagonistes sur la gestion des caches.
2/ Vu que l'ordonanceur à un process/thread de plus à traiter, tu le ralentie. Si tu est sur un bi-pro, dans le cas monothread, un cpu est libre donc le temps de réponse est minimal à un événement extérieur. Ce n'est absoluement pas le cas en multi-thread.
3/ Tu tire mieux parti d'un bi-pro certe mais au détriment du temps de réponse. Tu ne fais que perdre du temps sur un monoprocesseur. Le design est bien plus complexe à maintenir. Cela semble sans doute plus propre pour un serveur mais du point de vue performance c'est pas terrible du tout.
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.
A tache égal, un multithread prendra toujours plus de cycle globalement qu'un monothread. Donc, je ne comprends pas ce que tu veux dire.
T'es vache.
Les techno SMT sont beaucoup plus finaudes que ça.
En fait, les process sont également utilisé pour combler les bulles dans chacun des 5 pipelines d'execution. C'est pour cela que le gain de vitesse max , se fait avec un process utilisant le nombre flottant et l'autre les nombres entiers.
Le problème est toujours d'augmenter l'ipc à même fréquence (pour le P4, ils ont choisi de pousser le SSE que d'augmenter l'IPC mais bon). Mais comment faire avec des ISA pas conçu du tout pour ça. Bah, avec des coeurs out-of-order bien complexe.
Augmenter la fréquence pose parfois des problèmes, car elle nécessite des outils de gravure de plus en plus affinés, qui ne sont pas forcément disponibles.
Euh, pour une techno donné le temps de parcoure d'une porte est fixe. Tu peux mettre plein de portes en parrallèle (ipc monte), moins de porte entre 2 registres (pipeline, frequence monte), ou refaire le routage (moins de temps perdu dans les fils, la fréquence monte).
Ou changer de techno. Il n'y a pas de problème d'outils, c'est bettement physique (la NAND elle a besoin de 15 ps, il ira pas plus vite en changeant d'outils).
Et le but originel de faire un ISA simplifié n'était-il pas de faire une microarchitecture plus légère ?
si. L'utilisation de décodage puis de micro instruction, aussi. Mais il ne s'agit pas de mettre un risc derrière le décodeur (cela plutot ressembler à un vliw d'ailleurs).
>(un code ARM thumb est bien plus gros que du code "normal" x86)
J'ai vu ça dans un comparatif de compilation de différent fichier .c, puis gzipper comparant ARM (compilo arm et gcc), x86, Sparc (Leon).
Je dis "normal" pour le x86, car il utilisait -02 au lieu de -0s comme switch pour gcc. Et la différence était assez importante.
Car linux ne se compile QUE avec gcc et gcc ne se compile qu'avec gcc (il me semble) et c'est le seul programme qui ne compile qu'avec -02 -g que j'ai vu.
D'ailleurs le bench peut être : compile de linux 2.4.18 avec tel .config avec gcc 3.2.0.
Pour participer à un projet tu n'as besoin de personne. Tu récupères le CVS, tu fais tourner le bidule, tu corriges 3 bugs et tu envoies le patch aux mainteneurs.
Merci ne pas me considérer comme un raté. :-)
Si cela te touche, c'est bien le problème, non ?
Il est vrai que beaucoup de commentaires ont peu d'intérêt mais est-ce que parce l'on a rien a dire, il se taire ? Ca fait aussi parti de l'ambiance du site.
C'est l'unique interret des votes : faire un trie !!!
Si tu veux lire rapidement la news, tu ne peux pas toujours lire les 200 commentaires qui suivent.
[^] # Re: MplayerXP fork de MPlayer avec support des threads
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Document sur le développement de mplayer. Évalué à 4.
Faut arréter les rideaux ! C'est pas bon pour la santé.
Les P4 arrivent à fumer les Athlons pour des applis comme le divx grace au SSE. Sinon la fpu x87 du P4 est 2x plus lente que celle de l'athlon.
Le problème des nouvelles instructions est qu'il faut les utiliser pour bénéficier de leurs avantages qui sont bien réelle.
"La première sécurité est la liberté"
[^] # Re: /devoice pappy + virux
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Sortie de MISC n° 5. Évalué à 10.
"La première sécurité est la liberté"
# Re: Comment choisir son matos pour Linux
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Comment choisir son matos pour Linux. Évalué à 5.
Les bipro AMD ont le meilleurs rapport qualité/prix et de loin.
Pour ATI/NVIDIA, le problème : veux-tu un truc qui marche avec tout les fonctions activé ou espéré un bon support du libre ... plus tard.
J'ai une ATI mais sans la 3d. A mon avis, une NVIDIA 4200 te fera bien l'affaire (driver 100% proprio sans trop de problème contrairement à celui de ATI...). Ta manipulation d'image ne concerne pas la carte video ce qu'il te faut c'est un 1 Go de RAM ! (ECC pour le bipro qui dispose de 4 slot) (mémoire max 3.5Go)
"La première sécurité est la liberté"
# ben y'a pas grand chose de +...
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Les députés durcissent la loi Sarkozy, entre autres sur l'informatique. Évalué à 1.
"La première sécurité est la liberté"
[^] # Re: Les députés durcissent la loi Sarkozy, entre autres sur l'info
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Les députés durcissent la loi Sarkozy, entre autres sur l'informatique. Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: MplayerXP fork de MPlayer avec support des threads
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Document sur le développement de mplayer. Évalué à 1.
"La première sécurité est la liberté"
[^] # Re: MplayerXP fork de MPlayer avec support des threads
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Document sur le développement de mplayer. Évalué à 1.
euh ? oui, mais ce n'est pas forcément grave. Ce n'est important que si ton process ne tient pas ses deadlines dans tous les autres cas...
Si tu veux anticipé des brusques indisponnibilités du système, tu utilises des caches. Un asynch io fait le boulot que tu veux faire : lire le bloc suivant pendant que tu traites le bloc courant.
Les thread ne sont pas plus efficaces (sauf lors d'application vraiement interractive et qui ont des phases lente à faire laguer l'affichage comme certain client mail).
Ils sont juste plus facile à coder. L'exemple typique sont les serveurs multi-threadé qui enfle à chaque nouveau connecté. Si TUX (serveur web kernel plus rapide encore que khttpd) déchire tant c'est bien parce que il n'utilise pas un thread par connection !
"La première sécurité est la liberté"
# Re: neige ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal neige ?. Évalué à 1.
"La première sécurité est la liberté"
[^] # Re: MplayerXP fork de MPlayer avec support des threads
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Document sur le développement de mplayer. Évalué à 1.
Bien sur, on peut aussi faire ça avec les io async mais cela complique aussi le design de l'application.
"La première sécurité est la liberté"
[^] # Re: MplayerXP fork de MPlayer avec support des threads
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Document sur le développement de mplayer. Évalué à 2.
Tu ne peux que gaspiller de la puissance dans la gestion des thread et le traching de mémoire cache en faisant plus compliqué.
Tu aura peut-être plus de puissance pour tenir des deadline à 500 images/s mais ce n'est pas ça que l'on demande au codec.
"La première sécurité est la liberté"
[^] # Re: MplayerXP fork de MPlayer avec support des threads
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Document sur le développement de mplayer. Évalué à 3.
Il est donc parfaitement inutile de programmer un thread pour ça.
De plus, lors d'acces io, si le temps est trop long, le scheduler peut décider de donner la main à un autre process (cela se voit facilement avec l'utilisation d'un lentissime printf). Tu ne perds donc aucun cycle.
Si ta machine ne fait qu'une seule tache, un monothread sans io non bloquante étant bloqué à chaque io, tu perds des perf sur ce process-là uniquement. Mais globalement, ta machine peut faire d'autres trucs. Il n'y a pas de gaspillage.
Si tu veux augmenter les perf c'est-à-dire parraléliser acces disque et calcul, et bien, les io asynchrones ou non bloquantes sont faites pour ça !
"La première sécurité est la liberté"
[^] # Re: Juste une question ...
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche AMD et INTEL optent pour des technologies opposées.. Évalué à 1.
"La première sécurité est la liberté"
[^] # Re: MplayerXP fork de MPlayer avec support des threads
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Document sur le développement de mplayer. Évalué à 0.
1/ Pour faire, la même tâche si tu utilises 2 threads au lieu d'un seul tu perds des cycles à passer de l'un à l'autre. Si TUX (serveur http noyau) déchire, c'est parce qu'il fait de la zero copie et qu'il n'a PAS un thread par utilisateur. Sur un monoprocesseur, à cause des changement de tâche, tu perds du temps. Si quelqu'un lance un gros boulot, le scheduler doit juste scheduler un thread de plus. Cela ne lui fait que perdre du temps.
Sur un bi-pro (ou SMT), tu repartis la charge, genre 2% sur chaque cpu. Or les partages de mémoire font que les caches sont sous utilisé (en SMP) mais pas en SMT. Or en SMT, si des optimisations typé SMP sont utilisé (grosse séparation des flux mémoire pour éviter de trasher les caches) la pression sur les caches devient énorme (les caches miss s'envole aussi). Les optimisations SMT/SMP sont antagonistes sur la gestion des caches.
2/ Vu que l'ordonanceur à un process/thread de plus à traiter, tu le ralentie. Si tu est sur un bi-pro, dans le cas monothread, un cpu est libre donc le temps de réponse est minimal à un événement extérieur. Ce n'est absoluement pas le cas en multi-thread.
3/ Tu tire mieux parti d'un bi-pro certe mais au détriment du temps de réponse. Tu ne fais que perdre du temps sur un monoprocesseur. Le design est bien plus complexe à maintenir. Cela semble sans doute plus propre pour un serveur mais du point de vue performance c'est pas terrible du tout.
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.
A tache égal, un multithread prendra toujours plus de cycle globalement qu'un monothread. Donc, je ne comprends pas ce que tu veux dire.
"La première sécurité est la liberté"
[^] # Re: AMD et INTEL optent pour des technologies opposées.
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche AMD et INTEL optent pour des technologies opposées.. Évalué à 2.
En général cela tourne autour du nombre de bits même en entier.
"La première sécurité est la liberté"
[^] # Re: L'intérêt de la fréquence
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche AMD et INTEL optent pour des technologies opposées.. Évalué à 1.
Les techno SMT sont beaucoup plus finaudes que ça.
En fait, les process sont également utilisé pour combler les bulles dans chacun des 5 pipelines d'execution. C'est pour cela que le gain de vitesse max , se fait avec un process utilisant le nombre flottant et l'autre les nombres entiers.
"La première sécurité est la liberté"
[^] # Re: N'importe quoi
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche AMD et INTEL optent pour des technologies opposées.. Évalué à 1.
C'est cette expression qui m'a enduit d'erreur. Je croyais que tu parlais d'outils informatique.
On parle de finesse de gravure, de largeur de grille mais pas de finesse des outils de gravures (il n'utilisent pas des burrins de 0.09µm...). :)
"La première sécurité est la liberté"
[^] # Re: N'importe quoi
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche AMD et INTEL optent pour des technologies opposées.. Évalué à 1.
Augmenter la fréquence pose parfois des problèmes, car elle nécessite des outils de gravure de plus en plus affinés, qui ne sont pas forcément disponibles.
Euh, pour une techno donné le temps de parcoure d'une porte est fixe. Tu peux mettre plein de portes en parrallèle (ipc monte), moins de porte entre 2 registres (pipeline, frequence monte), ou refaire le routage (moins de temps perdu dans les fils, la fréquence monte).
Ou changer de techno. Il n'y a pas de problème d'outils, c'est bettement physique (la NAND elle a besoin de 15 ps, il ira pas plus vite en changeant d'outils).
"La première sécurité est la liberté"
[^] # Re: N'importe quoi
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche AMD et INTEL optent pour des technologies opposées.. Évalué à 1.
si. L'utilisation de décodage puis de micro instruction, aussi. Mais il ne s'agit pas de mettre un risc derrière le décodeur (cela plutot ressembler à un vliw d'ailleurs).
>(un code ARM thumb est bien plus gros que du code "normal" x86)
J'ai vu ça dans un comparatif de compilation de différent fichier .c, puis gzipper comparant ARM (compilo arm et gcc), x86, Sparc (Leon).
Je dis "normal" pour le x86, car il utilisait -02 au lieu de -0s comme switch pour gcc. Et la différence était assez importante.
"La première sécurité est la liberté"
[^] # Re: Une nouvelle mesure: MLCPS
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche AMD et INTEL optent pour des technologies opposées.. Évalué à 1.
Car linux ne se compile QUE avec gcc et gcc ne se compile qu'avec gcc (il me semble) et c'est le seul programme qui ne compile qu'avec -02 -g que j'ai vu.
D'ailleurs le bench peut être : compile de linux 2.4.18 avec tel .config avec gcc 3.2.0.
"La première sécurité est la liberté"
[^] # Re: AMD et INTEL optent pour des technologies opposées.
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche AMD et INTEL optent pour des technologies opposées.. Évalué à 1.
"La première sécurité est la liberté"
[^] # Re: Parce que velu ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Pourquoi tant de haine.. Évalué à 0.
Vala, tu as participé à un projet.
"La première sécurité est la liberté"
[^] # Parce queeeeeeeeeeeeeee
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Pourquoi tant de haine.. Évalué à 1.
C'est le seul site de ll en français où y'a du monde ?
Y'a linux dans le titre : " Et Linux : c'est bien".
Les connaissances, c'est comme la confiture,... on aime bien l'étaler (ça m'arrange mieux cette version).
Sinon...
"La première sécurité est la liberté"
[^] # Et hop ! Le gros troll récurent ....
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Gnu/Linux Magazine n° 46 est paru. Évalué à 2.
C'est pas possible de satisfaire tout le monde ! Moi, non plus je ne lis pas la partie blender, et alors ?
Je comprends que cela peut interresser du monde !
"La première sécurité est la liberté"
[^] # Re: AMD et INTEL optent pour des technologies opposées.
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche AMD et INTEL optent pour des technologies opposées.. Évalué à 2.
Mais tu as mal lu, il est question de latence de pipeline !!!! L'addition se fera toujours en un cycle.
"La première sécurité est la liberté"
[^] # Re: Pourquoi tant de haine.
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Pourquoi tant de haine.. Évalué à 1.
Si cela te touche, c'est bien le problème, non ?
Il est vrai que beaucoup de commentaires ont peu d'intérêt mais est-ce que parce l'on a rien a dire, il se taire ? Ca fait aussi parti de l'ambiance du site.
C'est l'unique interret des votes : faire un trie !!!
Si tu veux lire rapidement la news, tu ne peux pas toujours lire les 200 commentaires qui suivent.
"La première sécurité est la liberté"