j'aimerais avoir des avis (plus ou moins) objectifs concernant Linux et
les machines 64 bits, et, d'une manière général, sur les machines 64 bits.
Tout d'abord, si j'ai bien compris l'avantage du 64 bit, c'est de faire
passer les registres du prcesseur de 32 à 64 bits. Ca peut sembler être
une Lapalissade, mais c'est bon de le préciser. Donc, le (seul ?)
avantage du 64 bits pour les application ne demandant pas de calculs
avec des chiffres (relativement) enorme, c'est l'augmentation de
l'espace d'addressage ? Le terme "64 bits" ne serait donc qu'une astuce
marketing ?
De plus, il faut en toute logique que les applications soit compilées
par un gcc en "mode 64bits" (?): ce mode "est il au point" ? Ne
change-t-il vraiment rien d'autre que quelques broutilles concernant
l'addressage ?
Si le prémice du paragraphe précédent est correct, existe-t-il beaucoup
d'applications Linux compatible 64bits ? Une liste existe-t-elle ?
Enfin, est-il possible d'émuler des applications 32 bits sur un kernel
"compilé en mode 64 bits", et cela ralentit-il l'application ? Notez que
je préferrerais utiliser Debian (ma station de travail actuelle en 32
bits), mais qu'en est-il de l'avancement des distributions Linux par
rapport "au 64 bit" ?
Vous l'aurez compris,si je post ici et maintenant ce message, c'est pour
me décider à l'achat d'un futur et hypothètique ordinateur portable. Je
pensais me porter vers un Intel Core 2 Duo. Quelques remarques par
rapport à ce type de processeur ?
Pour finir, je tiens à préciser que je n'ai trouvé que des sujets (pas
tellement réjouissant) datant de 2004/2005/2006 sur internet, très peu
de (fin) 2007.
Non, je dis simplement qu'on traîne un truc idiot pour raison de compatibilité et qu'on paie cette compatibilité. Et qu'en cela le fait de dire que le code obtenu n'est pas deux fois plus gros est une argutie.
Compacter le code au maximum, à la x86, a au moins l'utilité de fourrer un maximum de code dans le cache, même si aprés il va être décodé, transformé en instructions RISC, pipeliné je ne sais pas comment dans le processeur. Or tout le monde peut constater que les effets de cache sont très importants sur la vitesse de calcul. Dès qu'on dépasse la taille du cache on a un ralentissement important et très visible.
Mon énoncé était très clair. Sur une machine de calcul faisant tourner de quatre à six threads _simultanément_, une SS20 avec 2 SM71 est bien plus lente qu'une U1E/140, machines qui sont de puissance de calcul par ailleurs égales. Et cette comparaison n'a d'objet que lorsqu'on fait tourner plus de threads que de processeurs. Cela permet de voir l'overhead rajouté par la gestion multipro (contre l'overhead rajouté par le multitâche).
L'overhead spécifiquement multiproc, il est -dans le scheduler, mais je croyais que Linux avait des queues de processus runnables par processeur, ce qui devrait rendre le coût assez négligeable. Evidemment si on fait des changements de contexte incessants, ça peut coûter. -et au niveau matériel, avec les invalidations de cache multiprocs. Là aussi je cryais que les processeurs modernes avaient du "cache snooping" pour diminuer ce coût.
Toujours est-il que sur des programmes que j'ai fait j'ai vu des performances multipliées sensiblement par 2 sur un biproc en utilisant des threads tournant en parallèle. Evidemment chacun d'entre eux fait un boulot conséquent et je ne m'amuse pas à découper un petit calcul en deux, style vectorisation automatique, parceque ça, ça coute effectivement la peau des fesses.
Si tu veux voir un exemple publié de performances multithreadés sur un octoprocesseur, avec mysql: http://people.freebsd.org/~kris/scaling/scaling.png on voit bien que l'optimum est obtenu avec 8 threads sur 8 processeurs et n'est pas si différent de 8 fois la performance à un thread. Au delà on tombe sur les inefficacités de trop de threads, coûts de scheduler, coûts de locks, etc. J'ai vu un truc similaire avec Bind.
JKB
--
Michel TALON
JKB <knatschke@koenigsberg.fr> wrote:
Non, je dis simplement qu'on traîne un truc idiot pour raison de
compatibilité et qu'on paie cette compatibilité. Et qu'en cela le
fait de dire que le code obtenu n'est pas deux fois plus gros est
une argutie.
Compacter le code au maximum, à la x86, a au moins l'utilité de fourrer un
maximum de code dans le cache, même si aprés il va être décodé,
transformé en instructions RISC, pipeliné je ne sais pas comment dans le
processeur. Or tout le monde peut constater que les effets de cache sont
très importants sur la vitesse de calcul. Dès qu'on dépasse la taille du
cache on a un ralentissement important et très visible.
Mon énoncé était très clair. Sur une machine de calcul faisant
tourner de quatre à six threads _simultanément_, une SS20 avec 2
SM71 est bien plus lente qu'une U1E/140, machines qui sont de
puissance de calcul par ailleurs égales. Et cette comparaison n'a
d'objet que lorsqu'on fait tourner plus de threads que de
processeurs. Cela permet de voir l'overhead rajouté par la gestion
multipro (contre l'overhead rajouté par le multitâche).
L'overhead spécifiquement multiproc, il est
-dans le scheduler, mais je croyais que Linux avait des queues de
processus runnables par processeur, ce qui devrait rendre le coût assez
négligeable. Evidemment si on fait des changements de contexte incessants,
ça peut coûter.
-et au niveau matériel, avec les invalidations de cache multiprocs. Là
aussi je cryais que les processeurs modernes avaient du "cache snooping"
pour diminuer ce coût.
Toujours est-il que sur des programmes que j'ai fait j'ai vu des
performances multipliées sensiblement par 2 sur un biproc en utilisant
des threads tournant en parallèle. Evidemment chacun d'entre eux fait un
boulot conséquent et je ne m'amuse pas à découper un petit calcul en
deux, style vectorisation automatique, parceque ça, ça coute
effectivement la peau des fesses.
Si tu veux voir un exemple publié de performances multithreadés sur un
octoprocesseur, avec mysql:
http://people.freebsd.org/~kris/scaling/scaling.png
on voit bien que l'optimum est obtenu avec 8 threads sur 8 processeurs
et n'est pas si différent de 8 fois la performance à un thread. Au delà
on tombe sur les inefficacités de trop de threads, coûts de scheduler,
coûts de locks, etc.
J'ai vu un truc similaire avec Bind.
Non, je dis simplement qu'on traîne un truc idiot pour raison de compatibilité et qu'on paie cette compatibilité. Et qu'en cela le fait de dire que le code obtenu n'est pas deux fois plus gros est une argutie.
Compacter le code au maximum, à la x86, a au moins l'utilité de fourrer un maximum de code dans le cache, même si aprés il va être décodé, transformé en instructions RISC, pipeliné je ne sais pas comment dans le processeur. Or tout le monde peut constater que les effets de cache sont très importants sur la vitesse de calcul. Dès qu'on dépasse la taille du cache on a un ralentissement important et très visible.
Mon énoncé était très clair. Sur une machine de calcul faisant tourner de quatre à six threads _simultanément_, une SS20 avec 2 SM71 est bien plus lente qu'une U1E/140, machines qui sont de puissance de calcul par ailleurs égales. Et cette comparaison n'a d'objet que lorsqu'on fait tourner plus de threads que de processeurs. Cela permet de voir l'overhead rajouté par la gestion multipro (contre l'overhead rajouté par le multitâche).
L'overhead spécifiquement multiproc, il est -dans le scheduler, mais je croyais que Linux avait des queues de processus runnables par processeur, ce qui devrait rendre le coût assez négligeable. Evidemment si on fait des changements de contexte incessants, ça peut coûter. -et au niveau matériel, avec les invalidations de cache multiprocs. Là aussi je cryais que les processeurs modernes avaient du "cache snooping" pour diminuer ce coût.
Toujours est-il que sur des programmes que j'ai fait j'ai vu des performances multipliées sensiblement par 2 sur un biproc en utilisant des threads tournant en parallèle. Evidemment chacun d'entre eux fait un boulot conséquent et je ne m'amuse pas à découper un petit calcul en deux, style vectorisation automatique, parceque ça, ça coute effectivement la peau des fesses.
Si tu veux voir un exemple publié de performances multithreadés sur un octoprocesseur, avec mysql: http://people.freebsd.org/~kris/scaling/scaling.png on voit bien que l'optimum est obtenu avec 8 threads sur 8 processeurs et n'est pas si différent de 8 fois la performance à un thread. Au delà on tombe sur les inefficacités de trop de threads, coûts de scheduler, coûts de locks, etc. J'ai vu un truc similaire avec Bind.
JKB
--
Michel TALON
Nicolas George
JKB , dans le message , a écrit :
Mais oui (en supposant que j'ai réussi à comprendre ta phrase)... Tes connaissances de machines séquentielles me font sourire.
Mais oui.
Ah bon ? De quoi parles-tu dans ce cas ?
Du x86_64 en mode 64 bits et en mode 32 bits. Il y a compatibilité ascendante en mode 32 bits, mais pas en mode 64 bits. Rien n'imposait de garder les mêmes schémas d'opcodes en mode 64 bits.
Au niveau processeur, si. Les caches sont _séparés_.
Mais dans ce cas, le cache d'instructions est en général nettement plus petit.
Reste dans ton monde. C'est toi qui dit "pour certains calculs", pas moi.
Bon, on va s'y prendre autrement : tu as sorti cet exemple dont je conteste la pertinence pour prouver, ou au moins illustrer, un propos. Saurais-tu énoncer précisément l'affirmation que l'exemple est censé illustrer ?
JKB , dans le message <slrnfgkiau.3at.knatschke@fermat.systella.fr>, a
écrit :
Mais oui (en supposant que j'ai réussi à comprendre ta phrase)...
Tes connaissances de machines séquentielles me font sourire.
Mais oui.
Ah bon ? De quoi parles-tu dans ce cas ?
Du x86_64 en mode 64 bits et en mode 32 bits. Il y a compatibilité
ascendante en mode 32 bits, mais pas en mode 64 bits. Rien n'imposait de
garder les mêmes schémas d'opcodes en mode 64 bits.
Au niveau processeur, si. Les caches sont _séparés_.
Mais dans ce cas, le cache d'instructions est en général nettement plus
petit.
Reste dans ton monde. C'est toi qui dit "pour certains calculs", pas
moi.
Bon, on va s'y prendre autrement : tu as sorti cet exemple dont je conteste
la pertinence pour prouver, ou au moins illustrer, un propos. Saurais-tu
énoncer précisément l'affirmation que l'exemple est censé illustrer ?
Mais oui (en supposant que j'ai réussi à comprendre ta phrase)... Tes connaissances de machines séquentielles me font sourire.
Mais oui.
Ah bon ? De quoi parles-tu dans ce cas ?
Du x86_64 en mode 64 bits et en mode 32 bits. Il y a compatibilité ascendante en mode 32 bits, mais pas en mode 64 bits. Rien n'imposait de garder les mêmes schémas d'opcodes en mode 64 bits.
Au niveau processeur, si. Les caches sont _séparés_.
Mais dans ce cas, le cache d'instructions est en général nettement plus petit.
Reste dans ton monde. C'est toi qui dit "pour certains calculs", pas moi.
Bon, on va s'y prendre autrement : tu as sorti cet exemple dont je conteste la pertinence pour prouver, ou au moins illustrer, un propos. Saurais-tu énoncer précisément l'affirmation que l'exemple est censé illustrer ?
remy
ah bien merde alors et au faite l'on parle de quoi ? d'alu ,de registre ,de timer ,de pipe-line, de quoi
On parle de vrais programmes qui font des choses. Si un jour tu sais manier poll() et gettimeofday(), peut-être que tu comprendras. bingo
Dans ce cas, on suppose que l'horloge CMOS de la machine est configurée sur le temps local, et que l'on doit l'augmenter de cette valeur pour obtenir le temps UTC
horloge CMOS == horloge temps reel
bisous ma puce :-)
remy
ah bien merde alors et au faite l'on parle de quoi ?
d'alu ,de registre ,de timer ,de pipe-line, de quoi
On parle de vrais programmes qui font des choses. Si un jour tu sais manier
poll() et gettimeofday(), peut-être que tu comprendras.
bingo
Dans ce cas, on suppose que l'horloge CMOS de la machine est configurée
sur le temps local, et que l'on doit l'augmenter de cette valeur pour
obtenir
le temps UTC
Dans ce cas, on suppose que l'horloge CMOS de la machine est configurée sur le temps local, et que l'on doit l'augmenter de cette valeur pour obtenir le temps UTC
horloge CMOS == horloge temps reel
bisous ma puce :-)
remy
Nicolas George
remy , dans le message <fedhtt$g6$, a écrit :
suis désolé mais les appels system je ne les connais pas tous se qui serait intéressant c'est de voir se qu'il y a derrière
Non, il n'y a pas besoin de savoir ce qu'il y a derrière pour constater qu'il faut de l'arithmétique au delà de 32 bits pour les utiliser confortablement.
Et merci de poster en français.
remy , dans le message <fedhtt$g6$1@s1.news.oleane.net>, a écrit :
suis désolé mais les appels system je ne les connais pas tous
se qui serait intéressant c'est de voir se qu'il y a derrière
Non, il n'y a pas besoin de savoir ce qu'il y a derrière pour constater
qu'il faut de l'arithmétique au delà de 32 bits pour les utiliser
confortablement.
suis désolé mais les appels system je ne les connais pas tous se qui serait intéressant c'est de voir se qu'il y a derrière
Non, il n'y a pas besoin de savoir ce qu'il y a derrière pour constater qu'il faut de l'arithmétique au delà de 32 bits pour les utiliser confortablement.
Et merci de poster en français.
talon
remy wrote:
sur le meme ordi ? avec un code compiler pour du 32 bit et le meme programme compiler pour du 64 bit avec le meme calcul
Oui, le même ordi, sur lequel est installé le maple 32 bits et le maple
64 bits, et le même calcul.
remy
--
Michel TALON
remy <remy@fctpas.fr> wrote:
sur le meme ordi ?
avec un code compiler pour du 32 bit et le meme programme
compiler pour du 64 bit avec le meme calcul
Oui, le même ordi, sur lequel est installé le maple 32 bits et le maple
sur le meme ordi ? avec un code compiler pour du 32 bit et le meme programme compiler pour du 64 bit avec le meme calcul
Oui, le même ordi, sur lequel est installé le maple 32 bits et le maple
64 bits, et le même calcul.
remy
--
Michel TALON
Nicolas George
remy , dans le message <fedi9c$g6$, a écrit :
Dans ce cas, on suppose que l'horloge CMOS de la machine est configurée sur le temps local, et que l'on doit l'augmenter de cette valeur pour obtenir le temps UTC
horloge CMOS == horloge temps reel
On se fout de l'horloge CMOS quand on programme une application. Encore une fois, tu prouves que tu n'as rien compris.
remy , dans le message <fedi9c$g6$2@s1.news.oleane.net>, a écrit :
Dans ce cas, on suppose que l'horloge CMOS de la machine est configurée
sur le temps local, et que l'on doit l'augmenter de cette valeur pour
obtenir
le temps UTC
horloge CMOS == horloge temps reel
On se fout de l'horloge CMOS quand on programme une application. Encore une
fois, tu prouves que tu n'as rien compris.
Dans ce cas, on suppose que l'horloge CMOS de la machine est configurée sur le temps local, et que l'on doit l'augmenter de cette valeur pour obtenir le temps UTC
horloge CMOS == horloge temps reel
On se fout de l'horloge CMOS quand on programme une application. Encore une fois, tu prouves que tu n'as rien compris.
JKB
Le 08-10-2007, à propos de Re: De l'utilité du 64 bit sous Linux, Nicolas George écrivait dans fr.comp.os.linux.debats :
JKB , dans le message , a écrit :
Mais oui (en supposant que j'ai réussi à comprendre ta phrase)... Tes connaissances de machines séquentielles me font sourire.
Mais oui.
Ah bon ? De quoi parles-tu dans ce cas ?
Du x86_64 en mode 64 bits et en mode 32 bits. Il y a compatibilité ascendante en mode 32 bits, mais pas en mode 64 bits. Rien n'imposait de garder les mêmes schémas d'opcodes en mode 64 bits.
Si. Il y a une raison fondamentale qui t'échapppe.
Au niveau processeur, si. Les caches sont _séparés_.
Mais dans ce cas, le cache d'instructions est en général nettement plus petit.
Et alors ? On peut _toujours_ doubler sa taille, même s'il est petit, et ton argument tombe de lui-même.
Reste dans ton monde. C'est toi qui dit "pour certains calculs", pas moi.
Bon, on va s'y prendre autrement : tu as sorti cet exemple dont je conteste la pertinence pour prouver, ou au moins illustrer, un propos. Saurais-tu énoncer précisément l'affirmation que l'exemple est censé illustrer ?
L'argument est simple. À puissance de calcul équivalente, une machine bipro est plus mauvaise qu'une monopro, c'est tout et ça ne va pas plus loin.
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 08-10-2007, à propos de
Re: De l'utilité du 64 bit sous Linux,
Nicolas George écrivait dans fr.comp.os.linux.debats :
JKB , dans le message <slrnfgkiau.3at.knatschke@fermat.systella.fr>, a
écrit :
Mais oui (en supposant que j'ai réussi à comprendre ta phrase)...
Tes connaissances de machines séquentielles me font sourire.
Mais oui.
Ah bon ? De quoi parles-tu dans ce cas ?
Du x86_64 en mode 64 bits et en mode 32 bits. Il y a compatibilité
ascendante en mode 32 bits, mais pas en mode 64 bits. Rien n'imposait de
garder les mêmes schémas d'opcodes en mode 64 bits.
Si. Il y a une raison fondamentale qui t'échapppe.
Au niveau processeur, si. Les caches sont _séparés_.
Mais dans ce cas, le cache d'instructions est en général nettement plus
petit.
Et alors ? On peut _toujours_ doubler sa taille, même s'il est
petit, et ton argument tombe de lui-même.
Reste dans ton monde. C'est toi qui dit "pour certains calculs", pas
moi.
Bon, on va s'y prendre autrement : tu as sorti cet exemple dont je conteste
la pertinence pour prouver, ou au moins illustrer, un propos. Saurais-tu
énoncer précisément l'affirmation que l'exemple est censé illustrer ?
L'argument est simple. À puissance de calcul équivalente, une
machine bipro est plus mauvaise qu'une monopro, c'est tout et ça ne
va pas plus loin.
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 08-10-2007, à propos de Re: De l'utilité du 64 bit sous Linux, Nicolas George écrivait dans fr.comp.os.linux.debats :
JKB , dans le message , a écrit :
Mais oui (en supposant que j'ai réussi à comprendre ta phrase)... Tes connaissances de machines séquentielles me font sourire.
Mais oui.
Ah bon ? De quoi parles-tu dans ce cas ?
Du x86_64 en mode 64 bits et en mode 32 bits. Il y a compatibilité ascendante en mode 32 bits, mais pas en mode 64 bits. Rien n'imposait de garder les mêmes schémas d'opcodes en mode 64 bits.
Si. Il y a une raison fondamentale qui t'échapppe.
Au niveau processeur, si. Les caches sont _séparés_.
Mais dans ce cas, le cache d'instructions est en général nettement plus petit.
Et alors ? On peut _toujours_ doubler sa taille, même s'il est petit, et ton argument tombe de lui-même.
Reste dans ton monde. C'est toi qui dit "pour certains calculs", pas moi.
Bon, on va s'y prendre autrement : tu as sorti cet exemple dont je conteste la pertinence pour prouver, ou au moins illustrer, un propos. Saurais-tu énoncer précisément l'affirmation que l'exemple est censé illustrer ?
L'argument est simple. À puissance de calcul équivalente, une machine bipro est plus mauvaise qu'une monopro, c'est tout et ça ne va pas plus loin.
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.
remy
Dans ce cas, on suppose que l'horloge CMOS de la machine est configurée sur le temps local, et que l'on doit l'augmenter de cette valeur pour obtenir le temps UTC
horloge CMOS == horloge temps reel
On se fout de l'horloge CMOS quand on programme une application. Encore une fois, tu prouves que tu n'as rien compris. mais oui mais oui tu vient de dire une connerie
Dans ce cas, on suppose que l'horloge CMOS de la machine est configurée
sur le temps local, et que l'on doit l'augmenter de cette valeur pour
obtenir
le temps UTC
horloge CMOS == horloge temps reel
On se fout de l'horloge CMOS quand on programme une application. Encore une
fois, tu prouves que tu n'as rien compris.
mais oui mais oui tu vient de dire une connerie
Dans ce cas, on suppose que l'horloge CMOS de la machine est configurée sur le temps local, et que l'on doit l'augmenter de cette valeur pour obtenir le temps UTC
horloge CMOS == horloge temps reel
On se fout de l'horloge CMOS quand on programme une application. Encore une fois, tu prouves que tu n'as rien compris. mais oui mais oui tu vient de dire une connerie
Nicolas George
JKB , dans le message , a écrit :
Si. Il y a une raison fondamentale qui t'échapppe.
Je t'écoute...
Et alors ? On peut _toujours_ doubler sa taille, même s'il est petit, et ton argument tombe de lui-même.
Doubler la taille, ça coûte aussi.
L'argument est simple. À puissance de calcul équivalente, une machine bipro est plus mauvaise qu'une monopro
Très bien. Eh bien je dis : si elle est plus mauvaise, c'est qu'elle n'a pas la même « puissance de calcul », pour toute définition vaguement pertinente de ce terme.
JKB , dans le message <slrnfgkjg9.3at.knatschke@fermat.systella.fr>, a
écrit :
Si. Il y a une raison fondamentale qui t'échapppe.
Je t'écoute...
Et alors ? On peut _toujours_ doubler sa taille, même s'il est
petit, et ton argument tombe de lui-même.
Doubler la taille, ça coûte aussi.
L'argument est simple. À puissance de calcul équivalente, une
machine bipro est plus mauvaise qu'une monopro
Très bien. Eh bien je dis : si elle est plus mauvaise, c'est qu'elle n'a pas
la même « puissance de calcul », pour toute définition vaguement pertinente
de ce terme.
Si. Il y a une raison fondamentale qui t'échapppe.
Je t'écoute...
Et alors ? On peut _toujours_ doubler sa taille, même s'il est petit, et ton argument tombe de lui-même.
Doubler la taille, ça coûte aussi.
L'argument est simple. À puissance de calcul équivalente, une machine bipro est plus mauvaise qu'une monopro
Très bien. Eh bien je dis : si elle est plus mauvaise, c'est qu'elle n'a pas la même « puissance de calcul », pour toute définition vaguement pertinente de ce terme.
Nicolas George
remy , dans le message <fedj4b$vo$, a écrit :
mais oui mais oui tu vient de dire une connerie
Non. D'ailleurs, tu serais bien incapable de trouver une seule application utilisant l'horloge CMOS pour programmer un réveil à un instant particulier.
remy , dans le message <fedj4b$vo$1@s1.news.oleane.net>, a écrit :
mais oui mais oui tu vient de dire une connerie
Non. D'ailleurs, tu serais bien incapable de trouver une seule application
utilisant l'horloge CMOS pour programmer un réveil à un instant particulier.
Non. D'ailleurs, tu serais bien incapable de trouver une seule application utilisant l'horloge CMOS pour programmer un réveil à un instant particulier.
