Vista Vs XP !!!

Jean-Pierre Roche

02/02/2007 à 15:18

Ben le dos 2.11, était pas si mal.

Courage ! C/PM n'est plus loin.

--
Jean-Pierre Roche

enlever sanspub pour m'écrire...

http://jpierreroche.free.fr/

personnel

02/02/2007 à 15:22

Le Fri, 02 Feb 2007 14:03:18 +0000, Boulu a écrit :

Le Fri, 02 Feb 2007 12:35:10 +0100, CoolFox
écrivait:

Un seul conseil donc: si vous êtes sous XP surtout gardez le.... c'est
une belle merde mais largement moins que VISTA.

J'ai toujours entendu ça !

95 moins bien que 3.11, 98 moins bien que 95,
Milenium moins bien que 98, Xp moins bien que milenium.
Bref, à vous écouter, autant retourner à DOS 3.3, !!!

bonjour!

Ben le dos 2.11, était pas si mal.
Non pas sur la tête, c'est beau de se moquer.

A+
jpierre

cfranco

02/02/2007 à 15:27

Boulu wrote:

Un seul conseil donc: si vous êtes sous XP surtout gardez le.... c'est
une belle merde mais largement moins que VISTA.

J'ai toujours entendu ça !

95 moins bien que 3.11, 98 moins bien que 95,
Milenium moins bien que 98

Moi aussi tout cela je l'ai pas mal entendu, et je n'en pense pas moins
(encore que 95 ou 98, c'est kif-kif)

Xp moins bien que milenium.

Là par contre, ça je ne l'ai jamais entendu, et je ne pense pas que
quiconque ayant utilisé les deux oserait le dire...

--
Christophe Franco

Nina Popravka

02/02/2007 à 15:33

On Fri, 2 Feb 2007 15:27:37 +0100, (Christophe
Franco) wrote:

Là par contre, ça je ne l'ai jamais entendu, et je ne pense pas que
quiconque ayant utilisé les deux oserait le dire...
Si si, c'est une idée qui traîne parfois chez les laïcs grand public

:-) Y en a même qui viennent ici.
(moi je suis pour W2k, na)
--
Nina

JKB

02/02/2007 à 16:38

Le 02-02-2007, à propos de
Re: Vista Vs XP !!!,
Nicolas George écrivait dans fr.comp.sys.pc :

JKB wrote in message
:
Ah bon... Alors là, tu es fort. Comment faire rentrer dans le même
volume d'instructions (en octets) des pointeurs deux fois plus long
par rapport aux 32 bits ?

Deux devant et deux derrière, comme pour les éléphants.

Sérieusement, le code, c'est essentiellement du code, justement, des
instructions, pas des pointeurs, la taille ne change pas le moins du monde
lors du passage de 32 à 64 bits. Les fois où il y a des pointeurs dans le
code, c'est essentiellement pour les sauts, et ce sont principalement des
adresses relatives sur 8 ou 16 bits.

Et les OP codes ? Je n'ai pas encore vu un processeur 64 bits avec
des OP codes de 32 bits.

JKB

Alain Naigeon

02/02/2007 à 17:44

"Boulu" a écrit dans le message de news:

Le Fri, 02 Feb 2007 12:35:10 +0100, CoolFox
écrivait:

Un seul conseil donc: si vous êtes sous XP surtout gardez le.... c'est
une belle merde mais largement moins que VISTA.

J'ai toujours entendu ça !

Mais pas du tout, XP est *beaucoup* mieux que 98, notamment
infiniment plus stable.

--

Français *==> "Musique renaissance" <==* English
midi - facsimiles - ligatures - mensuration
http://anaigeon.free.fr | http://www.medieval.org/emfaq/anaigeon/
Alain Naigeon - - Oberhoffen/Moder, France

G.T

02/02/2007 à 18:18

Salut,

Mais pas du tout, XP est *beaucoup* mieux que 98, notamment
infiniment plus stable.
Si on peut se passer du look Playmobil (certes beaucoup moins austère) et

qu'on n'aime pas du tout le thème d'écran XP, utiliser w2k c'est une bonne
idée.
Millenium, j'ai connu 2 types de cas : 1 qui passait sous 2000, 1 qui
retournait sous 98. Le seul gros avantage de ME, c'est que les clés USB
étaient reconnues sans pilote spécifique (grosse faiblesse de 98).
Perso j'utilise w2k pro SP4 ou XP pro SP1 suivant la machine, et je ne m'en
porte que mieux. J'ai XP pro SP2 au boulot, mbooof y'a rien à voir. Si, il
est plus lourd, mais là-bas j'ai la sauce :-)

a+,
--
G.T
205 Diesel & turbo-Diesel : www.205d.com

Nina Popravka

02/02/2007 à 18:22

On Fri, 2 Feb 2007 17:44:27 +0100, "Alain Naigeon"
wrote:

Mais pas du tout, XP est *beaucoup* mieux que 98, notamment
infiniment plus stable.
Chuuuttttttt, IOBA risque de te lire :-)

--
Nina

personnel

02/02/2007 à 18:36

Le Fri, 02 Feb 2007 15:18:57 +0100, Jean-Pierre Roche a écrit :

Ben le dos 2.11, était pas si mal.

Courage ! C/PM n'est plus loin.

bonsoir!

Heu, un sinclair zx81 sinon rien;-)

Et pour pas dire que du mal, le dos permet pour certains encore plein de
choses!Des jeux!Flasher son bios....
De plus des "dos", il y en a pleins!
DR dos, opendos entre autre!avec même des pilotes dvd et usb, sisi, c'est
possible;-)

Pour le dos 2.11, il y avait un ultra portable pc l'atari portfolio qui
embarquait cette version microsoft et c'était hyper rapide avec un
processeur low energie à 4 mega de fréquence...!
Le dos était en rom, et il y avait lotus123 compatible, un editeur, une
base de donnée.
Incroyable comme on causait brutalement aux imprimante laser, un simple
enter et l'engin à pile taille carnet de chêque faisait se réveiller
l'armoire laser;-)
Le dos gérait même un ram disque en C virtuel comme quoi...

A+
jpierre

Nicolas George

02/02/2007 à 20:03

JKB wrote in message
:

Et les OP codes ? Je n'ai pas encore vu un processeur 64 bits avec
des OP codes de 32 bits.

Juste ouvre les yeux. On parle d'x86, ici, il me semble. Voyons ce que ça
donne : j'ai compilé le code à la con suivant :

int foo(int a, int b)
{
int x;

x = a * a;
return(x * b - b / a);
}

C'est vraiment du code qui ne sert à rien, mais il y aura quelques opcodes.
Voyons, en 32 bits :

00000000 <foo>:
0: 55 push %ebp
1: 89 e5 mov %esp,%ebp
3: 53 push %ebx
4: 83 ec 04 sub $0x4,%esp
7: 8b 4d 08 mov 0x8(%ebp),%ecx
a: 8b 45 0c mov 0xc(%ebp),%eax
d: 89 cb mov %ecx,%ebx
f: 0f af d9 imul %ecx,%ebx
12: 0f af d8 imul %eax,%ebx
15: 8b 45 0c mov 0xc(%ebp),%eax
18: 99 cltd
19: f7 f9 idiv %ecx
1b: 89 45 f8 mov %eax,0xfffffff8(%ebp)
1e: 29 c3 sub %eax,%ebx
20: 5a pop %edx
21: 89 d8 mov %ebx,%eax
23: 5b pop %ebx
24: 5d pop %ebp
25: c3 ret

Et en 64 :

0000000000000000 <foo>:
0: 89 f1 mov %esi,%ecx
2: 89 fe mov %edi,%esi
4: 89 c8 mov %ecx,%eax
6: 99 cltd
7: f7 ff idiv %edi
9: 0f af f7 imul %edi,%esi
c: 0f af f1 imul %ecx,%esi
f: 29 c6 sub %eax,%esi
11: 89 f0 mov %esi,%eax
13: c3 retq

Maintenant, comptons : en 32 bits, 7 opcodes d'un octet, 5 opcodes de deux,
et 7 de trois, soit 38 octets au total. En 64 bits, 2 opcodes d'un, 6 de
deux, et 2 de trois, soit 20 octets au total. Presque deux fois moins.

Maintenant, tu peux dire que c'est un hasard, que c'est parce que le
protocole de passage d'arguments est meilleur, etc. Voyons un vrai exemple :
qsort, tel que présent dans la glibc, en version Etch (2.3.6.ds1-10) :

version 1 2 3 4 5 6 7 8 9 10 total moyenne
32 bits 5 19 36 7 11 12 3 0 0 0 327 3.5
64 bits 7 5 24 23 14 3 5 1 0 1 322 3.9

Donc des opcodes en moyenne un peu plus long (moins de 12% de plus), mais un
code plus compact au total.

Sur l'ensemble de la glibc, on trouve que la version 64 bits est 7% plus
grosse que la version 32 bits. Et si on ne considère que la section de code
(qui est le paramètre le plus important, par son impact sur les caches), la
différence est de 1.3%. Bref, complètement négligeable.

JKB wrote in message
<slrnes6mn1.gvb.knatschke@schroedinger.systella.fr>:

Et les OP codes ? Je n'ai pas encore vu un processeur 64 bits avec
des OP codes de 32 bits.

Juste ouvre les yeux. On parle d'x86, ici, il me semble. Voyons ce que ça
donne : j'ai compilé le code à la con suivant :

int foo(int a, int b)
{
int x;

x = a * a;
return(x * b - b / a);
}

C'est vraiment du code qui ne sert à rien, mais il y aura quelques opcodes.
Voyons, en 32 bits :

00000000 <foo>:
0: 55 push %ebp
1: 89 e5 mov %esp,%ebp
3: 53 push %ebx
4: 83 ec 04 sub $0x4,%esp
7: 8b 4d 08 mov 0x8(%ebp),%ecx
a: 8b 45 0c mov 0xc(%ebp),%eax
d: 89 cb mov %ecx,%ebx
f: 0f af d9 imul %ecx,%ebx
12: 0f af d8 imul %eax,%ebx
15: 8b 45 0c mov 0xc(%ebp),%eax
18: 99 cltd
19: f7 f9 idiv %ecx
1b: 89 45 f8 mov %eax,0xfffffff8(%ebp)
1e: 29 c3 sub %eax,%ebx
20: 5a pop %edx
21: 89 d8 mov %ebx,%eax
23: 5b pop %ebx
24: 5d pop %ebp
25: c3 ret

Et en 64 :

0000000000000000 <foo>:
0: 89 f1 mov %esi,%ecx
2: 89 fe mov %edi,%esi
4: 89 c8 mov %ecx,%eax
6: 99 cltd
7: f7 ff idiv %edi
9: 0f af f7 imul %edi,%esi
c: 0f af f1 imul %ecx,%esi
f: 29 c6 sub %eax,%esi
11: 89 f0 mov %esi,%eax
13: c3 retq

Maintenant, comptons : en 32 bits, 7 opcodes d'un octet, 5 opcodes de deux,
et 7 de trois, soit 38 octets au total. En 64 bits, 2 opcodes d'un, 6 de
deux, et 2 de trois, soit 20 octets au total. Presque deux fois moins.

Maintenant, tu peux dire que c'est un hasard, que c'est parce que le
protocole de passage d'arguments est meilleur, etc. Voyons un vrai exemple :
qsort, tel que présent dans la glibc, en version Etch (2.3.6.ds1-10) :

version 1 2 3 4 5 6 7 8 9 10 total moyenne
32 bits 5 19 36 7 11 12 3 0 0 0 327 3.5
64 bits 7 5 24 23 14 3 5 1 0 1 322 3.9

Donc des opcodes en moyenne un peu plus long (moins de 12% de plus), mais un
code plus compact au total.

Sur l'ensemble de la glibc, on trouve que la version 64 bits est 7% plus
grosse que la version 32 bits. Et si on ne considère que la section de code
(qui est le paramètre le plus important, par son impact sur les caches), la
différence est de 1.3%. Bref, complètement négligeable.

Vous avez filtré cet utilisateur ! Consultez son message

JKB wrote in message
:

Et les OP codes ? Je n'ai pas encore vu un processeur 64 bits avec
des OP codes de 32 bits.

Juste ouvre les yeux. On parle d'x86, ici, il me semble. Voyons ce que ça
donne : j'ai compilé le code à la con suivant :

int foo(int a, int b)
{
int x;

x = a * a;
return(x * b - b / a);
}

C'est vraiment du code qui ne sert à rien, mais il y aura quelques opcodes.
Voyons, en 32 bits :

00000000 <foo>:
0: 55 push %ebp
1: 89 e5 mov %esp,%ebp
3: 53 push %ebx
4: 83 ec 04 sub $0x4,%esp
7: 8b 4d 08 mov 0x8(%ebp),%ecx
a: 8b 45 0c mov 0xc(%ebp),%eax
d: 89 cb mov %ecx,%ebx
f: 0f af d9 imul %ecx,%ebx
12: 0f af d8 imul %eax,%ebx
15: 8b 45 0c mov 0xc(%ebp),%eax
18: 99 cltd
19: f7 f9 idiv %ecx
1b: 89 45 f8 mov %eax,0xfffffff8(%ebp)
1e: 29 c3 sub %eax,%ebx
20: 5a pop %edx
21: 89 d8 mov %ebx,%eax
23: 5b pop %ebx
24: 5d pop %ebp
25: c3 ret

Et en 64 :

0000000000000000 <foo>:
0: 89 f1 mov %esi,%ecx
2: 89 fe mov %edi,%esi
4: 89 c8 mov %ecx,%eax
6: 99 cltd
7: f7 ff idiv %edi
9: 0f af f7 imul %edi,%esi
c: 0f af f1 imul %ecx,%esi
f: 29 c6 sub %eax,%esi
11: 89 f0 mov %esi,%eax
13: c3 retq

Maintenant, comptons : en 32 bits, 7 opcodes d'un octet, 5 opcodes de deux,
et 7 de trois, soit 38 octets au total. En 64 bits, 2 opcodes d'un, 6 de
deux, et 2 de trois, soit 20 octets au total. Presque deux fois moins.

Maintenant, tu peux dire que c'est un hasard, que c'est parce que le
protocole de passage d'arguments est meilleur, etc. Voyons un vrai exemple :
qsort, tel que présent dans la glibc, en version Etch (2.3.6.ds1-10) :

version 1 2 3 4 5 6 7 8 9 10 total moyenne
32 bits 5 19 36 7 11 12 3 0 0 0 327 3.5
64 bits 7 5 24 23 14 3 5 1 0 1 322 3.9

Donc des opcodes en moyenne un peu plus long (moins de 12% de plus), mais un
code plus compact au total.

Sur l'ensemble de la glibc, on trouve que la version 64 bits est 7% plus
grosse que la version 32 bits. Et si on ne considère que la section de code
(qui est le paramètre le plus important, par son impact sur les caches), la
différence est de 1.3%. Bref, complètement négligeable.

Vista Vs XP !!!

10 réponses

Veuillez sélectionner un problème