Pour que l'on soit bien en phase, peux-tu confirmer et compléter ce tableau ?
Windows | linux | taille | usage ---------+-------+--------+------- C: | sda1 | 300 Go | Windows D: | sda2 | 300 Go | Recovery (ça me parait un peu gros) cachée | sda3 | 20 Go | ? cachée | sda4 | 20 Go | ?
Je ne suis pas allée voir les partitions cachées, mais a priori, c'est ça. Pour les numéros, par contre, je ne suis pas trop sûre : quand je tente l'installation, Ubuntu nomme sda3 (NTFS) la partition de 162,5 Gb dans laquelle il voudrait mettre ce qu'il appelle les « Fichiers » (et il précise qu'il a besoin de 8,5 Gb), et il nomme sda4 (ext4) l'autre partition (« intitulée Ubuntu »).
Si tu as un liveCD,
J'ai !
la sortie de « fdisk -l /dev/sda » serait intéressante.
Je me fais enguirlander : « Impossible d'ouvrir /dev/sda » (pourtant, j'ai enlevé mes moufles avant de taper la commande).
À l'installation, Ubuntu « voit » évidemment le disque SCSI2 de 640 Go et il propose de prendre 162,5 Gb pour les fichiers, et 157,1 Go pour Ubuntu lui-même.
De les prendre où (remplacer D:, redimensionner C: et D:, etc.) ?
C'était précisément le sens de ma question ! (:
Aucune idée. Personnellement, j'utilise l'alternate CD en mode expert qui me permet le partitionnement manuel. Pour un novice, je pense que le plus simple est de passer par <http://gparted.sourceforge.net/livecd.php> et de créer son partitionnement avant d'installer genre :
* redimensionner C: (sda1) à 200 Go * redimensionner D: (sda2) à 200 Go et le faire commencer à la suite de C: * créer une partition de type ext4 de 30 Go pour / * créer une partition de type ext4 de 165 Go pour /home * creér une partition de type swap de 5 Go pour le swap
Noter le nom des partitions (sda5, sda6, etc.) et lors de l'installation d'Ubuntu indiquer les bonnes.
Apparemment, il est possible de repartitionner manuellement à partir de ce CD d'installation, mais j'hésite beaucoup car tout ça est assez obscur.
Pour que l'on soit bien en phase, peux-tu confirmer et compléter ce
tableau ?
Windows | linux | taille | usage
---------+-------+--------+-------
C: | sda1 | 300 Go | Windows
D: | sda2 | 300 Go | Recovery (ça me parait un peu gros)
cachée | sda3 | 20 Go | ?
cachée | sda4 | 20 Go | ?
Je ne suis pas allée voir les partitions cachées, mais a priori, c'est ça.
Pour les numéros, par contre, je ne suis pas trop sûre : quand je tente
l'installation, Ubuntu nomme sda3 (NTFS) la partition de 162,5 Gb dans
laquelle il voudrait mettre ce qu'il appelle les « Fichiers » (et il
précise qu'il a besoin de 8,5 Gb), et il nomme sda4 (ext4) l'autre
partition (« intitulée Ubuntu »).
Si tu as un liveCD,
J'ai !
la sortie de « fdisk -l /dev/sda » serait
intéressante.
Je me fais enguirlander : « Impossible d'ouvrir /dev/sda » (pourtant, j'ai
enlevé mes moufles avant de taper la commande).
À l'installation, Ubuntu « voit » évidemment le disque SCSI2 de 640 Go
et il propose de prendre 162,5 Gb pour les fichiers, et 157,1 Go pour
Ubuntu lui-même.
De les prendre où (remplacer D:, redimensionner C: et D:, etc.) ?
C'était précisément le sens de ma question ! (:
Aucune idée. Personnellement, j'utilise l'alternate CD en mode expert
qui me permet le partitionnement manuel. Pour un novice, je pense que le
plus simple est de passer par
<http://gparted.sourceforge.net/livecd.php> et de créer son
partitionnement avant d'installer genre :
* redimensionner C: (sda1) à 200 Go
* redimensionner D: (sda2) à 200 Go et le faire commencer à la suite de
C:
* créer une partition de type ext4 de 30 Go pour /
* créer une partition de type ext4 de 165 Go pour /home
* creér une partition de type swap de 5 Go pour le swap
Noter le nom des partitions (sda5, sda6, etc.) et lors de l'installation
d'Ubuntu indiquer les bonnes.
Apparemment, il est possible de repartitionner manuellement à partir de ce
CD d'installation, mais j'hésite beaucoup car tout ça est assez obscur.
Pour que l'on soit bien en phase, peux-tu confirmer et compléter ce tableau ?
Windows | linux | taille | usage ---------+-------+--------+------- C: | sda1 | 300 Go | Windows D: | sda2 | 300 Go | Recovery (ça me parait un peu gros) cachée | sda3 | 20 Go | ? cachée | sda4 | 20 Go | ?
Je ne suis pas allée voir les partitions cachées, mais a priori, c'est ça. Pour les numéros, par contre, je ne suis pas trop sûre : quand je tente l'installation, Ubuntu nomme sda3 (NTFS) la partition de 162,5 Gb dans laquelle il voudrait mettre ce qu'il appelle les « Fichiers » (et il précise qu'il a besoin de 8,5 Gb), et il nomme sda4 (ext4) l'autre partition (« intitulée Ubuntu »).
Si tu as un liveCD,
J'ai !
la sortie de « fdisk -l /dev/sda » serait intéressante.
Je me fais enguirlander : « Impossible d'ouvrir /dev/sda » (pourtant, j'ai enlevé mes moufles avant de taper la commande).
À l'installation, Ubuntu « voit » évidemment le disque SCSI2 de 640 Go et il propose de prendre 162,5 Gb pour les fichiers, et 157,1 Go pour Ubuntu lui-même.
De les prendre où (remplacer D:, redimensionner C: et D:, etc.) ?
C'était précisément le sens de ma question ! (:
Aucune idée. Personnellement, j'utilise l'alternate CD en mode expert qui me permet le partitionnement manuel. Pour un novice, je pense que le plus simple est de passer par <http://gparted.sourceforge.net/livecd.php> et de créer son partitionnement avant d'installer genre :
* redimensionner C: (sda1) à 200 Go * redimensionner D: (sda2) à 200 Go et le faire commencer à la suite de C: * créer une partition de type ext4 de 30 Go pour / * créer une partition de type ext4 de 165 Go pour /home * creér une partition de type swap de 5 Go pour le swap
Noter le nom des partitions (sda5, sda6, etc.) et lors de l'installation d'Ubuntu indiquer les bonnes.
Apparemment, il est possible de repartitionner manuellement à partir de ce CD d'installation, mais j'hésite beaucoup car tout ça est assez obscur.
-- Pascale http://www.la-grille-verte.net
Benoit Izac
Bonjour,
le 13/07/2011 à 20:04, Pascale a écrit dans le message :
la sortie de « fdisk -l /dev/sda » serait intéressante.
Je me fais enguirlander : « Impossible d'ouvrir /dev/sda » (pourtant, j'ai enlevé mes moufles avant de taper la commande).
C'est du Ubuntu... sudo fdisk -l /dev/sda
Apparemment, il est possible de repartitionner manuellement à partir de ce CD d'installation, mais j'hésite beaucoup car tout ça est assez obscur.
Je comprends et sans être sûr de ce qui va se passer, je ne le ferai pas (d'où la suggestion de le faire à la main avant).
-- Benoit Izac
Bonjour,
le 13/07/2011 à 20:04, Pascale a écrit dans le message
<XnF9F21CC3279D59mouflette@alussinan.org> :
la sortie de « fdisk -l /dev/sda » serait
intéressante.
Je me fais enguirlander : « Impossible d'ouvrir /dev/sda » (pourtant,
j'ai enlevé mes moufles avant de taper la commande).
C'est du Ubuntu...
sudo fdisk -l /dev/sda
Apparemment, il est possible de repartitionner manuellement à partir
de ce CD d'installation, mais j'hésite beaucoup car tout ça est assez
obscur.
Je comprends et sans être sûr de ce qui va se passer, je ne le ferai pas
(d'où la suggestion de le faire à la main avant).
le 13/07/2011 à 20:04, Pascale a écrit dans le message :
la sortie de « fdisk -l /dev/sda » serait intéressante.
Je me fais enguirlander : « Impossible d'ouvrir /dev/sda » (pourtant, j'ai enlevé mes moufles avant de taper la commande).
C'est du Ubuntu... sudo fdisk -l /dev/sda
Apparemment, il est possible de repartitionner manuellement à partir de ce CD d'installation, mais j'hésite beaucoup car tout ça est assez obscur.
Je comprends et sans être sûr de ce qui va se passer, je ne le ferai pas (d'où la suggestion de le faire à la main avant).
-- Benoit Izac
Lucas Levrel
Le 13 juillet 2011, Pascale a écrit :
J'ai bien lu des choses sur le partitionnement, mais lire et comprendre, c'est pas la même chose : est-ce que le partitionnement de Windows et celui d'Ubuntu sont 2 choses totalement distinctes ou pas ?
Pas du tout. Le partitionnement est physique : le disque est saucissonné en morceaux décrits dans la bien nommée « table de partitions ». Quand tu démarres Windows, il nomme ces morceaux C:, D:, etc. (s'il sait lire leur contenu, donc ceux qui sont au format FAT et NTFS essentiellement). Quand tu démarres Linux, il nomme ces morceaux sda1, sda2, etc.
Par exemple, est-ce qu'Ubuntu s'installe indifféremment sur ce que Windows appelle C: et D: ou est-ce qu'il tient compte de ce partitionnement là ?
Donc le système d'installation Ubuntu voit les partitions telles qu'elles sont actuellement, disons sda1 == C:, sda2 == D:, sda3 == ?, sda4 == ? (que sont les deux petites partitions cachées ? comment les as-tu vues ?).
Windows est dans C:. Ubuntu doit créer une partition pour s'installer. Comment ? D'après ce que tu rapportes, on dirait qu'il veut virer une ou deux des cachées, raccourcir D: (NTFS, qui contient actuellement 8,5 Go) à 162,5 Go et la nomme « Fichiers », et dans l'espace ainsi libéré créer sa partition « Ubuntu ».
Donc il *semblerait* qu'il ne veuille pas toucher à Windows. Il ne te dit pas qu'il y a une partoche de 300 Go qu'il va laisser tranquille ?
Je fais quoi, là ?
Tu te méfies ! Si ça existe, tu utilises un mode « expert », c'est-à-dire manuel, où c'est toi, et pas un script, qui décide ce qui va se passer...
-- LL
Le 13 juillet 2011, Pascale a écrit :
J'ai bien lu des choses sur le partitionnement, mais lire et comprendre,
c'est pas la même chose : est-ce que le partitionnement de Windows et celui
d'Ubuntu sont 2 choses totalement distinctes ou pas ?
Pas du tout. Le partitionnement est physique : le disque est saucissonné
en morceaux décrits dans la bien nommée « table de partitions ». Quand tu
démarres Windows, il nomme ces morceaux C:, D:, etc. (s'il sait lire leur
contenu, donc ceux qui sont au format FAT et NTFS essentiellement). Quand
tu démarres Linux, il nomme ces morceaux sda1, sda2, etc.
Par exemple, est-ce qu'Ubuntu s'installe indifféremment sur ce que
Windows appelle C: et D: ou est-ce qu'il tient compte de ce
partitionnement là ?
Donc le système d'installation Ubuntu voit les partitions telles qu'elles
sont actuellement, disons sda1 == C:, sda2 == D:, sda3 == ?, sda4 == ?
(que sont les deux petites partitions cachées ? comment les as-tu vues ?).
Windows est dans C:. Ubuntu doit créer une partition pour s'installer.
Comment ? D'après ce que tu rapportes, on dirait qu'il veut virer une ou
deux des cachées, raccourcir D: (NTFS, qui contient actuellement 8,5 Go) à
162,5 Go et la nomme « Fichiers », et dans l'espace ainsi libéré créer sa
partition « Ubuntu ».
Donc il *semblerait* qu'il ne veuille pas toucher à Windows. Il ne te dit
pas qu'il y a une partoche de 300 Go qu'il va laisser tranquille ?
Je fais quoi, là ?
Tu te méfies ! Si ça existe, tu utilises un mode « expert », c'est-à-dire
manuel, où c'est toi, et pas un script, qui décide ce qui va se passer...
J'ai bien lu des choses sur le partitionnement, mais lire et comprendre, c'est pas la même chose : est-ce que le partitionnement de Windows et celui d'Ubuntu sont 2 choses totalement distinctes ou pas ?
Pas du tout. Le partitionnement est physique : le disque est saucissonné en morceaux décrits dans la bien nommée « table de partitions ». Quand tu démarres Windows, il nomme ces morceaux C:, D:, etc. (s'il sait lire leur contenu, donc ceux qui sont au format FAT et NTFS essentiellement). Quand tu démarres Linux, il nomme ces morceaux sda1, sda2, etc.
Par exemple, est-ce qu'Ubuntu s'installe indifféremment sur ce que Windows appelle C: et D: ou est-ce qu'il tient compte de ce partitionnement là ?
Donc le système d'installation Ubuntu voit les partitions telles qu'elles sont actuellement, disons sda1 == C:, sda2 == D:, sda3 == ?, sda4 == ? (que sont les deux petites partitions cachées ? comment les as-tu vues ?).
Windows est dans C:. Ubuntu doit créer une partition pour s'installer. Comment ? D'après ce que tu rapportes, on dirait qu'il veut virer une ou deux des cachées, raccourcir D: (NTFS, qui contient actuellement 8,5 Go) à 162,5 Go et la nomme « Fichiers », et dans l'espace ainsi libéré créer sa partition « Ubuntu ».
Donc il *semblerait* qu'il ne veuille pas toucher à Windows. Il ne te dit pas qu'il y a une partoche de 300 Go qu'il va laisser tranquille ?
Je fais quoi, là ?
Tu te méfies ! Si ça existe, tu utilises un mode « expert », c'est-à-dire manuel, où c'est toi, et pas un script, qui décide ce qui va se passer...
-- LL
pehache
Le 12/07/11 23:28, Nicolas George a écrit :
pehache , dans le message, a écrit :
C'est tellement faux que je n'ai jamais noté une différence signification de temps de calcul en compilant en 32 ou 64 bits.
Peut-être que tu n'es pas capable de mener des benchmarks significatifs, aussi.
Le fait est que x86_64 est une architecture largement différente de x86_32, avec plus de registres, une ABI flottante différente et plus efficace, etc. La différence de vitesse sur des programmes CPU-bounds est potentiellement considérable.
J'avais fait quelques "benchmarks" (un bien grand mot) sur les codes de calcul que j'ai l'habitude de manipuler, dont certains sont CPU-bound. Et je n'ai jamais rencontré de cas où la version 64 bits était plus rapide que la 32 bits (dans les cas où tout tient dans la mémoire allouable en 32 bits, évidemment).
-- pehache
Le 12/07/11 23:28, Nicolas George a écrit :
pehache , dans le message<983rugF8ioU1@mid.individual.net>, a écrit :
C'est tellement faux que je n'ai jamais noté une différence
signification de temps de calcul en compilant en 32 ou 64 bits.
Peut-être que tu n'es pas capable de mener des benchmarks significatifs,
aussi.
Le fait est que x86_64 est une architecture largement différente de x86_32,
avec plus de registres, une ABI flottante différente et plus efficace, etc.
La différence de vitesse sur des programmes CPU-bounds est potentiellement
considérable.
J'avais fait quelques "benchmarks" (un bien grand mot) sur les codes de
calcul que j'ai l'habitude de manipuler, dont certains sont CPU-bound.
Et je n'ai jamais rencontré de cas où la version 64 bits était plus
rapide que la 32 bits (dans les cas où tout tient dans la mémoire
allouable en 32 bits, évidemment).
C'est tellement faux que je n'ai jamais noté une différence signification de temps de calcul en compilant en 32 ou 64 bits.
Peut-être que tu n'es pas capable de mener des benchmarks significatifs, aussi.
Le fait est que x86_64 est une architecture largement différente de x86_32, avec plus de registres, une ABI flottante différente et plus efficace, etc. La différence de vitesse sur des programmes CPU-bounds est potentiellement considérable.
J'avais fait quelques "benchmarks" (un bien grand mot) sur les codes de calcul que j'ai l'habitude de manipuler, dont certains sont CPU-bound. Et je n'ai jamais rencontré de cas où la version 64 bits était plus rapide que la 32 bits (dans les cas où tout tient dans la mémoire allouable en 32 bits, évidemment).
-- pehache
Nicolas George
pehache , dans le message , a écrit :
J'avais fait quelques "benchmarks" (un bien grand mot) sur les codes de calcul que j'ai l'habitude de manipuler, dont certains sont CPU-bound. Et je n'ai jamais rencontré de cas où la version 64 bits était plus rapide que la 32 bits (dans les cas où tout tient dans la mémoire allouable en 32 bits, évidemment).
Qu'est-ce que tu veux que je te dise ? Il suffit de lancer « openssl speed » pour se rendre compte de la différence, et quasiment n'importe quel autre programme bien optimisé subira des conséquences similaires.
Donc au choix (1) tu es un gros nul incapable de mener un benchmark ou optimiser un programme, (2) tu dis n'importe quoi exprès.
Je pense que c'est les deux à la fois.
pehache , dans le message <986o99Ff8jU1@mid.individual.net>, a écrit :
J'avais fait quelques "benchmarks" (un bien grand mot) sur les codes de
calcul que j'ai l'habitude de manipuler, dont certains sont CPU-bound.
Et je n'ai jamais rencontré de cas où la version 64 bits était plus
rapide que la 32 bits (dans les cas où tout tient dans la mémoire
allouable en 32 bits, évidemment).
Qu'est-ce que tu veux que je te dise ? Il suffit de lancer « openssl speed »
pour se rendre compte de la différence, et quasiment n'importe quel autre
programme bien optimisé subira des conséquences similaires.
Donc au choix (1) tu es un gros nul incapable de mener un benchmark ou
optimiser un programme, (2) tu dis n'importe quoi exprès.
J'avais fait quelques "benchmarks" (un bien grand mot) sur les codes de calcul que j'ai l'habitude de manipuler, dont certains sont CPU-bound. Et je n'ai jamais rencontré de cas où la version 64 bits était plus rapide que la 32 bits (dans les cas où tout tient dans la mémoire allouable en 32 bits, évidemment).
Qu'est-ce que tu veux que je te dise ? Il suffit de lancer « openssl speed » pour se rendre compte de la différence, et quasiment n'importe quel autre programme bien optimisé subira des conséquences similaires.
Donc au choix (1) tu es un gros nul incapable de mener un benchmark ou optimiser un programme, (2) tu dis n'importe quoi exprès.
Je pense que c'est les deux à la fois.
pehache
Le 14/07/11 10:23, Nicolas George a écrit :
pehache , dans le message, a écrit :
J'avais fait quelques "benchmarks" (un bien grand mot) sur les codes de calcul que j'ai l'habitude de manipuler, dont certains sont CPU-bound. Et je n'ai jamais rencontré de cas où la version 64 bits était plus rapide que la 32 bits (dans les cas où tout tient dans la mémoire allouable en 32 bits, évidemment).
Qu'est-ce que tu veux que je te dise ? Il suffit de lancer « openssl speed » pour se rendre compte de la différence, et quasiment n'importe quel autre programme bien optimisé subira des conséquences similaires.
Donc au choix (1) tu es un gros nul incapable de mener un benchmark ou optimiser un programme, (2) tu dis n'importe quoi exprès.
Je pense que c'est les deux à la fois.
Les optimisations (non algorithmiques) dans les codes de calcul scientifique sur les architectures courantes actuelles consistent essentiellement à minimiser les cache miss, et à chercher la vectorisation. Le reste c'est l'affaire du compilateur, chacun son boulot.
Lundi je posterai un exemple de code, et tu m'expliqueras ce qu'il faut faire pour qu'il tourne plus vite en 64 bits qu'en 32 bits.
-- pehache
Le 14/07/11 10:23, Nicolas George a écrit :
pehache , dans le message<986o99Ff8jU1@mid.individual.net>, a écrit :
J'avais fait quelques "benchmarks" (un bien grand mot) sur les codes de
calcul que j'ai l'habitude de manipuler, dont certains sont CPU-bound.
Et je n'ai jamais rencontré de cas où la version 64 bits était plus
rapide que la 32 bits (dans les cas où tout tient dans la mémoire
allouable en 32 bits, évidemment).
Qu'est-ce que tu veux que je te dise ? Il suffit de lancer « openssl speed »
pour se rendre compte de la différence, et quasiment n'importe quel autre
programme bien optimisé subira des conséquences similaires.
Donc au choix (1) tu es un gros nul incapable de mener un benchmark ou
optimiser un programme, (2) tu dis n'importe quoi exprès.
Je pense que c'est les deux à la fois.
Les optimisations (non algorithmiques) dans les codes de calcul
scientifique sur les architectures courantes actuelles consistent
essentiellement à minimiser les cache miss, et à chercher la
vectorisation. Le reste c'est l'affaire du compilateur, chacun son boulot.
Lundi je posterai un exemple de code, et tu m'expliqueras ce qu'il faut
faire pour qu'il tourne plus vite en 64 bits qu'en 32 bits.
J'avais fait quelques "benchmarks" (un bien grand mot) sur les codes de calcul que j'ai l'habitude de manipuler, dont certains sont CPU-bound. Et je n'ai jamais rencontré de cas où la version 64 bits était plus rapide que la 32 bits (dans les cas où tout tient dans la mémoire allouable en 32 bits, évidemment).
Qu'est-ce que tu veux que je te dise ? Il suffit de lancer « openssl speed » pour se rendre compte de la différence, et quasiment n'importe quel autre programme bien optimisé subira des conséquences similaires.
Donc au choix (1) tu es un gros nul incapable de mener un benchmark ou optimiser un programme, (2) tu dis n'importe quoi exprès.
Je pense que c'est les deux à la fois.
Les optimisations (non algorithmiques) dans les codes de calcul scientifique sur les architectures courantes actuelles consistent essentiellement à minimiser les cache miss, et à chercher la vectorisation. Le reste c'est l'affaire du compilateur, chacun son boulot.
Lundi je posterai un exemple de code, et tu m'expliqueras ce qu'il faut faire pour qu'il tourne plus vite en 64 bits qu'en 32 bits.
-- pehache
Nicolas George
pehache , dans le message , a écrit :
Les optimisations (non algorithmiques) dans les codes de calcul scientifique sur les architectures courantes actuelles consistent essentiellement à minimiser les cache miss, et à chercher la vectorisation. Le reste c'est l'affaire du compilateur, chacun son boulot.
Et tu arrives à pourrir le boulot du compilateur, chapeau bas.
Lundi je posterai un exemple de code, et tu m'expliqueras ce qu'il faut faire pour qu'il tourne plus vite en 64 bits qu'en 32 bits.
Ne compte pas sur moi pour faire ton travail à ta place.
J'ai énoncé des faits en correction des informations erronées que tu as publié ici, je pense que ça suffit amplement pour les lecteurs. Quant à toi, continue à penser qu'il n'y a aucune différence, ça ne me fait ni chaud ni froid.
pehache , dans le message <989cn7Fp2gU1@mid.individual.net>, a écrit :
Les optimisations (non algorithmiques) dans les codes de calcul
scientifique sur les architectures courantes actuelles consistent
essentiellement à minimiser les cache miss, et à chercher la
vectorisation. Le reste c'est l'affaire du compilateur, chacun son boulot.
Et tu arrives à pourrir le boulot du compilateur, chapeau bas.
Lundi je posterai un exemple de code, et tu m'expliqueras ce qu'il faut
faire pour qu'il tourne plus vite en 64 bits qu'en 32 bits.
Ne compte pas sur moi pour faire ton travail à ta place.
J'ai énoncé des faits en correction des informations erronées que tu as
publié ici, je pense que ça suffit amplement pour les lecteurs. Quant à toi,
continue à penser qu'il n'y a aucune différence, ça ne me fait ni chaud ni
froid.
Les optimisations (non algorithmiques) dans les codes de calcul scientifique sur les architectures courantes actuelles consistent essentiellement à minimiser les cache miss, et à chercher la vectorisation. Le reste c'est l'affaire du compilateur, chacun son boulot.
Et tu arrives à pourrir le boulot du compilateur, chapeau bas.
Lundi je posterai un exemple de code, et tu m'expliqueras ce qu'il faut faire pour qu'il tourne plus vite en 64 bits qu'en 32 bits.
Ne compte pas sur moi pour faire ton travail à ta place.
J'ai énoncé des faits en correction des informations erronées que tu as publié ici, je pense que ça suffit amplement pour les lecteurs. Quant à toi, continue à penser qu'il n'y a aucune différence, ça ne me fait ni chaud ni froid.
pehache
Le 15/07/11 01:43, Nicolas George a écrit :
pehache , dans le message, a écrit :
Les optimisations (non algorithmiques) dans les codes de calcul scientifique sur les architectures courantes actuelles consistent essentiellement à minimiser les cache miss, et à chercher la vectorisation. Le reste c'est l'affaire du compilateur, chacun son boulot.
Et tu arrives à pourrir le boulot du compilateur, chapeau bas.
Tu sais lire ??
Lundi je posterai un exemple de code, et tu m'expliqueras ce qu'il faut faire pour qu'il tourne plus vite en 64 bits qu'en 32 bits.
Ne compte pas sur moi pour faire ton travail à ta place.
Traduction : tu crains de ne pas savoir faire.
Au passage, cela ne sera pas "faire mon travail à ma place", car il s'agira d'un bête exemple de démonstration construit pour illustrer le problème.
J'ai énoncé des faits en correction des informations erronées que tu as publié ici,
En matière d'information erronée, ton affirmation :
"Quasiment n'importe quel autre programme bien optimisé subira des conséquences similaires"
en est une belle également car je peux te poster plein d'exemples où ce ne sera pas le cas (voire où la version 64 bits est légèrement plus lente). Cela fait donc un partout.
-- pehache
Le 15/07/11 01:43, Nicolas George a écrit :
pehache , dans le message<989cn7Fp2gU1@mid.individual.net>, a écrit :
Les optimisations (non algorithmiques) dans les codes de calcul
scientifique sur les architectures courantes actuelles consistent
essentiellement à minimiser les cache miss, et à chercher la
vectorisation. Le reste c'est l'affaire du compilateur, chacun son boulot.
Et tu arrives à pourrir le boulot du compilateur, chapeau bas.
Tu sais lire ??
Lundi je posterai un exemple de code, et tu m'expliqueras ce qu'il faut
faire pour qu'il tourne plus vite en 64 bits qu'en 32 bits.
Ne compte pas sur moi pour faire ton travail à ta place.
Traduction : tu crains de ne pas savoir faire.
Au passage, cela ne sera pas "faire mon travail à ma place", car il
s'agira d'un bête exemple de démonstration construit pour illustrer le
problème.
J'ai énoncé des faits en correction des informations erronées que tu as
publié ici,
En matière d'information erronée, ton affirmation :
"Quasiment n'importe quel autre programme bien optimisé subira des
conséquences similaires"
en est une belle également car je peux te poster plein d'exemples où ce
ne sera pas le cas (voire où la version 64 bits est légèrement plus
lente). Cela fait donc un partout.
Les optimisations (non algorithmiques) dans les codes de calcul scientifique sur les architectures courantes actuelles consistent essentiellement à minimiser les cache miss, et à chercher la vectorisation. Le reste c'est l'affaire du compilateur, chacun son boulot.
Et tu arrives à pourrir le boulot du compilateur, chapeau bas.
Tu sais lire ??
Lundi je posterai un exemple de code, et tu m'expliqueras ce qu'il faut faire pour qu'il tourne plus vite en 64 bits qu'en 32 bits.
Ne compte pas sur moi pour faire ton travail à ta place.
Traduction : tu crains de ne pas savoir faire.
Au passage, cela ne sera pas "faire mon travail à ma place", car il s'agira d'un bête exemple de démonstration construit pour illustrer le problème.
J'ai énoncé des faits en correction des informations erronées que tu as publié ici,
En matière d'information erronée, ton affirmation :
"Quasiment n'importe quel autre programme bien optimisé subira des conséquences similaires"
en est une belle également car je peux te poster plein d'exemples où ce ne sera pas le cas (voire où la version 64 bits est légèrement plus lente). Cela fait donc un partout.
-- pehache
Nicolas George
pehache , dans le message , a écrit :
Traduction : tu crains de ne pas savoir faire.
J'ai donné des faits (plus de registres, ABI flottante plus rapide) et des références (openssl speed). Ça suffit pour convaincre les lecteurs de bonne foi. Toi, je m'en fiche, tu n'as aucune valeur.
En matière d'information erronée, ton affirmation :
"Quasiment n'importe quel autre programme bien optimisé subira des conséquences similaires"
en est une belle également
C'est vrai.
pehache , dans le message <98a2csF633U1@mid.individual.net>, a écrit :
Traduction : tu crains de ne pas savoir faire.
J'ai donné des faits (plus de registres, ABI flottante plus rapide) et des
références (openssl speed). Ça suffit pour convaincre les lecteurs de bonne
foi. Toi, je m'en fiche, tu n'as aucune valeur.
En matière d'information erronée, ton affirmation :
"Quasiment n'importe quel autre programme bien optimisé subira des
conséquences similaires"
J'ai donné des faits (plus de registres, ABI flottante plus rapide) et des références (openssl speed). Ça suffit pour convaincre les lecteurs de bonne foi. Toi, je m'en fiche, tu n'as aucune valeur.
En matière d'information erronée, ton affirmation :
"Quasiment n'importe quel autre programme bien optimisé subira des conséquences similaires"
en est une belle également
C'est vrai.
Pascale
Lucas Levrel écrivait news::
Donc le système d'installation Ubuntu voit les partitions telles qu'elles sont actuellement, disons sda1 == C:, sda2 == D:, sda3 == ?, sda4 == ? (que sont les deux petites partitions cachées ? comment les as-tu vues ?).
Windows est dans C:. Ubuntu doit créer une partition pour s'installer. Comment ? D'après ce que tu rapportes, on dirait qu'il veut virer une ou deux des cachées, raccourcir D: (NTFS, qui contient actuellement 8,5 Go) à 162,5 Go et la nomme « Fichiers », et dans l'espace ainsi libéré créer sa partition « Ubuntu ».
Donc il *semblerait* qu'il ne veuille pas toucher à Windows. Il ne te dit pas qu'il y a une partoche de 300 Go qu'il va laisser tranquille ?
Désolée de ne pas avoir répondu plus tôt (non, je n'ai pas défilé hier...).
Dans le processus d'installation, j'ai bien précisé que je ne voulais pas qu'il touche à Windows (3 choix proposés : installer à côté de Windows sans rien effacer, installer à la place de Windows et autre).
Si je clique sur partitionnement avancé, il me dit ça :
(l'écran précédent mentionnait bien deux partitions cachées).
-- Pascale http://www.la-grille-verte.net
Lucas Levrel <lucas.levrel@u-pec.fr> écrivait
news:alpine.LNX.2.00.1107132204410.4684@coulomb.univ-paris12.fr:
Donc le système d'installation Ubuntu voit les partitions telles
qu'elles sont actuellement, disons sda1 == C:, sda2 == D:, sda3 == ?,
sda4 == ? (que sont les deux petites partitions cachées ? comment les
as-tu vues ?).
Windows est dans C:. Ubuntu doit créer une partition pour s'installer.
Comment ? D'après ce que tu rapportes, on dirait qu'il veut virer une
ou deux des cachées, raccourcir D: (NTFS, qui contient actuellement
8,5 Go) à 162,5 Go et la nomme « Fichiers », et dans l'espace ainsi
libéré créer sa partition « Ubuntu ».
Donc il *semblerait* qu'il ne veuille pas toucher à Windows. Il ne te
dit pas qu'il y a une partoche de 300 Go qu'il va laisser tranquille ?
Désolée de ne pas avoir répondu plus tôt (non, je n'ai pas défilé hier...).
Dans le processus d'installation, j'ai bien précisé que je ne voulais pas
qu'il touche à Windows (3 choix proposés : installer à côté de Windows sans
rien effacer, installer à la place de Windows et autre).
Si je clique sur partitionnement avancé, il me dit ça :
Donc le système d'installation Ubuntu voit les partitions telles qu'elles sont actuellement, disons sda1 == C:, sda2 == D:, sda3 == ?, sda4 == ? (que sont les deux petites partitions cachées ? comment les as-tu vues ?).
Windows est dans C:. Ubuntu doit créer une partition pour s'installer. Comment ? D'après ce que tu rapportes, on dirait qu'il veut virer une ou deux des cachées, raccourcir D: (NTFS, qui contient actuellement 8,5 Go) à 162,5 Go et la nomme « Fichiers », et dans l'espace ainsi libéré créer sa partition « Ubuntu ».
Donc il *semblerait* qu'il ne veuille pas toucher à Windows. Il ne te dit pas qu'il y a une partoche de 300 Go qu'il va laisser tranquille ?
Désolée de ne pas avoir répondu plus tôt (non, je n'ai pas défilé hier...).
Dans le processus d'installation, j'ai bien précisé que je ne voulais pas qu'il touche à Windows (3 choix proposés : installer à côté de Windows sans rien effacer, installer à la place de Windows et autre).
Si je clique sur partitionnement avancé, il me dit ça :
