Windows est rapide, Microsoft est meilleure

On 2009-07-27, Nicolas George wrote:

Bruno Ducrot , dans le message
<4a6dabf4$0$17783$ba4acef3@news.orange.fr>, a écrit :

Justement, lisez plus attentivement ma reponse sur le probleme des
northbrides version mobile de chez Intel.

Je ne vois pas ce que je suis censé avoir manqué.

Un exemple concret demontrant sans doute possible que votre explication
de BIOS buggue ou mal configure est douteux, du moins pour les
ordinateurs portables a base de chipset Intel, ce qui represente la
majorite des ordinateurs portables vendus actuellement.

Il n'y a pas de fumees sans feu (j'avoue que mon argument est completement
foireux, mais le votre l'est tout autant).

Le fait que certains voient de la RAM manquante indique que quelque chose
fait manquer la RAM, mais pas que ce quelque chose est matériel, ça peut
très bien être un BIOS buggé ou mal configuré.

Le BIOS se contente d'enumerer les MMIO des peripheriques actives.
Il faudrait vraiment que le dev soit le plus naze de tous les nazes pour
se vautrer sur cette partie-la, et comme le plus naze des dev travaille
pour la boite qui m'emploit et qu'il n'ecrit pas de BIOS a ma connaissance,
il est clair que votre explication ne peut tenir la route.

Pardon ?

Une limite absolue d'un matériel, c'est quelque chose de différent. C'est
comme pour les barrettes mémoire double face : les vieux chipsets n'en
voyaient qu'une face.

Si quelqu'un met 4 Go dans un matériel qui est limité à 3 Go, et le vend
comme 4 Go, c'est un escroc, c'est tout.

Un utilisateur rajoute de la RAM, mais vois que ca ne marche pas. Je
ne vois pas en quoi le vendeur est fautif s'il a prevenu que son
materiel est limite.

--
Bruno Ducrot

-- Which is worse: ignorance or apathy?
-- Don't know. Don't care.

Le 27/07/2009 16:39, pehache-tolai a écrit :

On 27 juil, 16:31, Toxico Nimbus<T...@free.fr> wrote:

Le 27/07/2009 14:32, pehache-tolai a écrit :

Que je sache, une FFT est un truc qui est implantable en userland,
et strictement en userland.

Et alors ? Je ne sais bien que ça n'aurait que peu d'intérêt de
l'implémenter dans un kernel, mais rien n'empêche de le faire non
plus. Ce ne serait pas la première fois qu'on verrait dans un kernel
un truc dont on se demande ce qu'il fout là.
Bref, ma comparaison est valide.

Surement pas, une lib de FFT n'a aucun besoin d'être en kernelland alors
qu'une gestion correcte de threading - j'entends par là des threads
préemptifs et gérant le multiprocesseur - ne peut exister entièrement en
userland, justement parce que l'on ne peut se permettre d'ignorer les
problèmes d'atomicité.

La spécification POSIX dit-elle que les threads doivent
obligatoirement tourner sur plusieurs proc ? Si la réponse est non,
une implémentation en userland qui du coup est restreinte à un
processeur unique est valide. Sans grand intérêt certes (sinon de
permettre une portabilité directe d'un code Posix), mais valide.

Je ne connais pas la spec POSIX (je n'ai pas les moyens ni l'intérêt de
l'acheter). Pour ce qui est de l'implémentation en userland, ce n'est
pas sis simple que cela, puisque pour ne pas avoir à gérer l'atomicité,
il faut du multithreading coopératif. Or il ne me semble pas évidant que
du code prévu pour tourner sous un multithreading préemptif tourne aussi
bien en coopératif, puisque dans le coopératif, c'est le développeur qui
donne la main.

--
Toxico Nimbus

Le 24-07-2009, ? propos de
Re: Windows est rapide, Microsoft est meilleure,
Stephane TOUGARD ?crivait dans fr.comp.os.linux.debats :

JKB wrote:

On émule des fonctionnalités qui ne sont pas présentes sur le
système hôte. Je ne vois toujours pas où est le problème. D'ailleurs,
'implémenter', c'est tout sauf français.

On ne les emule pas, on les implemente*. C'est a dire on les fait, on les
developpe. Meme la fonction sleep() n'est pas supportee par defaut dans
Windows, ca n'empeche pas a Cygwin de la supporter. Ca n'a rien d'une
emulation. C'est une implementation*.

* "implementer" est un anglicisme, mais son utilisation est courante et
acceptee. Sa veritable traduction est "mise en oeuvre".

Mouarf ! C'est ce que tu fais depuis le début en évitant
soigneusement de répondre à la question posée parce que tu en es
parfaitement incapable.

Parce que ca n'a strictement aucun rapport avec la choucroute. Je suis
en train de te parler de la definition de certains mots dans certains
contextes.

Ensuite, j'ai pas envie de jouer a du mesurage de bites. J'ai des
domaines d'intervention dans l'informatique qui sont bien precis et
visiblement tres differents des tiens. Mais qui ont en commun qu'ils
repondent a des normes et que les grandes problematiques restent les
memes. Je te rassure, tu ne suivrais pas plus la ou j'interviens.

Tu n'as de toute façon pas répondu à la question posée, qui était
une question _précise_.

Ca s'appelle noyer le poisson.

Tu nous as sorti une fois de plus une connerie plus grosse que toi.
Ta seule réponse est de pointer du doigt un raccourci d'écriture parce
que tu ne sais pas répondre à la question. Point barre. La seule
personne qui noie le poisson, ici, c'est toi.

Je te rappelle que tu prétends pouvoir implanter les pthreads en
userland sous Windows. Je te repose donc la question : comment fais-tu
pour implanter un mécanisme aussi simple qu'un mutex _strictement_ en
userland lorsque les mécanismes d'atomicité ne sont pas disponibles à
partir d'API sur le système hôte ?

J'attends toujours ma réponse.

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.

Le 25-07-2009, ? propos de
Re: Windows est rapide, Microsoft est meilleure,
Stephane TOUGARD ?crivait dans fr.comp.os.linux.debats :

JKB wrote:

Et bien regarde dans petit bob. Dans le seul dictionnaire que j'ai
sous la main et qui comporte ce mot, j'ai en GROS 'anglicisme' et
'barbarisme',
que tu le veuilles ou non. En français, on dit 'implanter', comme on dit
'decryptement' et non 'décryptage' (bien que là encore, le Larousse est
permissif, mais je ne vais pas dire ici ce que je pense du Larousse !).

Je suis mort de rire. On essaie depuis une semaine de te faire
comprendre la simple definition des mots "emulation", "norme" et
"implementation" (ou sa traduction) et tu viens nous donner des lecons
de lecture de dictionnaire.

Les cons, ca ose tout. C'est meme a ca qu'on les reconnait.

Parfait. Il y a certains cons ici qui ne reconnaissent surtout pas
leurs torts lorsqu'on leur colle leur nez dans leur merde.

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.

Le 25-07-2009, ? propos de
Re: Windows est rapide, Microsoft est meilleure,
Stephane TOUGARD ?crivait dans fr.comp.os.linux.debats :

Jerome Lambert wrote:

Et toi, tu n'as toujours pas montré l'ombre d'une indication de _quel_
périphérique occuperait cette mémoire.

Mais on s'en fout! Depuis le début je te parle de *principe*, principe
que comme par hasard tu n'as *jamais* remis en question, mais pour ne
pas perdre la face tu t'accroches désespérément à cet exemple précis.
Bref, tu t'agites sur la forme pour masquer le fond, comme d'habitude.

Finalement, les reactions de JKB et du petit Nicolas sont tres
similaires en soit.

Ce sont des gens qui sont relativement bons, techniquement parlant, mais
qui, se faisant, sont incapables de penser avec une couche
d'abstraction.

Continue, tu m'amuses. Quand à dire que tu es sur la bonne voie, il
y a un fossé que je me garderais bien de franchir. Tu es le prototype du
rigolo qui toise les gens de haut et qui refuse systématiquement de
répondre à des questions simples dès lors qu'on lui met le nez dans sa
merde. Là où tu es vraiment pathétique, c'est avec ta façon de noyer le
poisson.

Si en plus tu étais bon techniquement...

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.

Le 27-07-2009, ? propos de
Re: Windows est rapide, Microsoft est meilleure,
Toxico Nimbus ?crivait dans fr.comp.os.linux.debats :

Le 27/07/2009 14:32, pehache-tolai a écrit :

Que je sache, une FFT est un truc qui est implantable en userland,
et strictement en userland.

Et alors ? Je ne sais bien que ça n'aurait que peu d'intérêt de
l'implémenter dans un kernel, mais rien n'empêche de le faire non
plus. Ce ne serait pas la première fois qu'on verrait dans un kernel
un truc dont on se demande ce qu'il fout là.

Bref, ma comparaison est valide.

Surement pas, une lib de FFT n'a aucun besoin d'être en kernelland alors
qu'une gestion correcte de threading - j'entends par là des threads
préemptifs et gérant le multiprocesseur - ne peut exister entièrement en
userland, justement parce que l'on ne peut se permettre d'ignorer les
problèmes d'atomicité.

C'est donc une bibliothèque totalement
indépendante de l'OS (si on l'écrit bien, mais c'est un autre débat).
En écrivant une FFT, on n'a absolument pas besoin de gérer des trucs
aussi abscons que l'atomicité.

Je ne vois pas ce que l'atomicité a d'abscons, mais passons.

Et en toute rigueur, et comme ça a été dit dans d'autres réponses de
ce fil, on n'a pas absolument besoin non plus de gérer l'atomicité
pour implémenter une API de threads.

L'atomicité est inhérente au parallélisme. Dans un environnement
parallèle, le développeur doit forcément pouvoir s'assurer l'atomicité
des ses sections critiques. Or Il ne peut pas le faire sans avoir à
recourir au noyau.

Ssiiiii ! Stéphane Tougard va nous donner une explication et de sa
grande hauteur, il va nous donner un exemple de code implantant la
libpthread en userland ;-)

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.

Le 27-07-2009, ? propos de
Re: Windows est rapide, Microsoft est meilleure,
pehache-tolai ?crivait dans fr.comp.os.linux.debats :

On 27 juil, 16:31, Toxico Nimbus <T...@free.fr> wrote:

Le 27/07/2009 14:32, pehache-tolai a écrit :

>>          Que je sache, une FFT est un truc qui est implantable en userland,
>> et strictement en userland.

> Et alors ? Je ne sais bien que ça n'aurait que peu d'intérêt de
> l'implémenter dans un kernel, mais rien n'empêche de le faire non
> plus. Ce ne serait pas la première fois qu'on verrait dans un kernel
> un truc dont on se demande ce qu'il fout là.

> Bref, ma comparaison est valide.

Surement pas, une lib de FFT n'a aucun besoin d'être en kernelland alors
qu'une gestion correcte de threading - j'entends par là des threads
préemptifs et gérant le multiprocesseur - ne peut exister entièrement en
userland, justement parce que l'on ne peut se permettre d'ignorer les
problèmes d'atomicité.

La spécification POSIX dit-elle que les threads doivent
obligatoirement tourner sur plusieurs proc ?

Je viens de parcourir les specs (en diagonale, hein, je n'ai pas que
ça à faire) Posix 1003c. Le draft laisse la question ouverte. Par
contre, on voit un peu partout le terme 'model n+m' qui signifie
implanter un séquenceur permettant de faire tourner n threads sur m
porcesseurs.

Si la réponse est non,
une implémentation en userland qui du coup est restreinte à un
processeur unique est valide. Sans grand intérêt certes (sinon de
permettre une portabilité directe d'un code Posix), mais valide.

La question n'est pas là. Posix 1c et 4 demande un ordonnanceur
préemptif. Dans ce cas, tu ne maîtrises pas les changements de threads
puisqu'ils sont imposés par le noyau et tu dois passer par une API du
noyau pour assurer l'atomicité. Donc on a encore passer par un bout de
noyau, si celui-ci existe et est accessible, c'est simple, sinon, on est
un peu embêté. Pour fixer les idées, concidère que tu veux implanter un
sémaphore (un sémaphore est un truc scabreux entier qui bloque un thread
lorsqu'il devient nul. Tu as grosso modo deux instructions, l'une pour
le décrémenter, l'autre pour l'incrémenter) :

sem_wait() // décrémente
while(semaphore == 0);
semaphore--;
return;

sem_post() // incrémente
semaphore++;
return;

Considère maintenant que deux threads appellent en même temps
sem_wait(). semaphore vaut 0. Un troisième thread relache le sémaphore
en appelant sem_post(). Très bien, tu te retrouves donc avec semaphore
qui vaut 1. Comme tu ne maîtrises pas l'atomicité, tu peux débloquer les
deux threads bloqués et te retrouver avec une valeur de -1 pour
sémaphore. Au passage, deux threads ont été libérés au lieu d'un seul.

Pour régler ce problème, la première implantation des threads sous
Linux considérait que tous les threads concurrents tournaient sur le même
processeur. La seconde (linuxthreads), pour que l'atomicité soit respectée,
utilisait une opération assembleur atomique pour la décrémentation et la
comparaison. Inconvénient, cette approche n'est pas Posix parce qu'elle
viole le côté async safe de sem_post() sur certains processeurs (dont
les sparc et i386 [je n'ai pas écrit amd64]). On en est maintenant à la
troisième qui est réellement Posix, mais qui comporte des bouts en
kernelland (pour l'atomicité) et en userland (pour attaquer l'API du
noyau).

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.

Le 27-07-2009, ? propos de
Re: Windows est rapide, Microsoft est meilleure,
Toxico Nimbus ?crivait dans fr.comp.os.linux.debats :

Le 27/07/2009 16:39, pehache-tolai a écrit :

On 27 juil, 16:31, Toxico Nimbus<T...@free.fr> wrote:

Le 27/07/2009 14:32, pehache-tolai a écrit :

Que je sache, une FFT est un truc qui est implantable en userland,
et strictement en userland.

Et alors ? Je ne sais bien que ça n'aurait que peu d'intérêt de
l'implémenter dans un kernel, mais rien n'empêche de le faire non
plus. Ce ne serait pas la première fois qu'on verrait dans un kernel
un truc dont on se demande ce qu'il fout là.
Bref, ma comparaison est valide.

Surement pas, une lib de FFT n'a aucun besoin d'être en kernelland alors
qu'une gestion correcte de threading - j'entends par là des threads
préemptifs et gérant le multiprocesseur - ne peut exister entièrement en
userland, justement parce que l'on ne peut se permettre d'ignorer les
problèmes d'atomicité.

La spécification POSIX dit-elle que les threads doivent
obligatoirement tourner sur plusieurs proc ? Si la réponse est non,
une implémentation en userland qui du coup est restreinte à un
processeur unique est valide. Sans grand intérêt certes (sinon de
permettre une portabilité directe d'un code Posix), mais valide.

Je ne connais pas la spec POSIX (je n'ai pas les moyens ni l'intérêt de
l'acheter). Pour ce qui est de l'implémentation en userland, ce n'est
pas sis simple que cela, puisque pour ne pas avoir à gérer l'atomicité,
il faut du multithreading coopératif. Or il ne me semble pas évidant que
du code prévu pour tourner sous un multithreading préemptif tourne aussi
bien en coopératif, puisque dans le coopératif, c'est le développeur qui
donne la main.

Les threads Posix te permettent d'utiliser sched_yield() pour passer
d'un thread à un autre. Maintenant, si tu n'utilises pas cette fonction,
l'implantation risque de surcharger certaines fonctions par l'équivalent
sur le système hôte du sched_yield. Et mine de rien, ça peut assez
rapidement être assez contraignant.

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.

JKB :

Je te rappelle que tu prétends pouvoir implanter les pthreads en
userland sous Windows. Je te repose donc la question : comment fais-tu
pour implanter un mécanisme aussi simple qu'un mutex _strictement_ en
userland lorsque les mécanismes d'atomicité ne sont pas disponibles à
partir d'API sur le système hôte ?

Windows c'est pourri mais y'a quand même des mutex, des threads et tout
le tralala utilisable. Qu'est ce qui empêche alors ?

Le 27-07-2009, ? propos de
Re: Windows est rapide, Microsoft est meilleure,
Patrick Lamaizière ?crivait dans fr.comp.os.linux.debats :

JKB :

Je te rappelle que tu prétends pouvoir implanter les pthreads en
userland sous Windows. Je te repose donc la question : comment fais-tu
pour implanter un mécanisme aussi simple qu'un mutex _strictement_ en
userland lorsque les mécanismes d'atomicité ne sont pas disponibles à
partir d'API sur le système hôte ?

Windows c'est pourri mais y'a quand même des mutex, des threads et tout
le tralala utilisable. Qu'est ce qui empêche alors ?

J'ai arrêté de contribuer à Cygwin au debut d'XP (en fait par
paresse parce que j'en avais marre de me coltiner des workarounds pour
Cygwin et le C/Windows). Il y avait un défaut d'atomicité qui faisait
que les mutexes (et les sémaphores parce que le problème est strictement
le même) fonctionnaient _presque_. Dans l'immense majorité des cas, ça
passait sans problème, mais un défaut d'atomicité faisait que tu pouvais
te retrouver dans des blocages de threads définitifs (ou avec un
sémaphore qui faisait le tour du cadran, ce qui est aussi gênant). Il y
avait un autre problème inhérent à la présence d'un fork() dans un
programme multithreadé car le fork() laisse les mutexes dans un état
indéterminé, ce qu'on règle en C/Posix à grands coups de
pthread_mutex_trylock(). Si le fork() arrivait lors d'un changement de
thread sur un système SMP, le mutex en question pouvait se retrouver ni
vraiment verrouillé, ni déverrouillé et le résultat était indéterminé
(un mutex, ce n'est pas qu'un drapeau, c'est un peu plus compliqué que
ça).

Bref, ce n'est pas si simple.

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.