Personne ne parle ici de portage en 64 bits.
Maintenant, Windows 64 bits est disponible tant pour x64 (AMD64 / Pentium 4
64 bits) qu'Itanium, la quasi totalité des machines neuves vendues à la
rentrée seront 64 bits et le platform SDK téléchargeable contient un
compilateur C++ final et gratuit en 64 bits
J'ai écrit plusieurs message sur le sujet:
http://gilles-vollant.developpez.com/visual-cpp/sdk64vs2005/
en anglais (mais on peut discuter ici en français):
http://forum.winimage.com/index.php?c=8
on peut même jouer en terminal server avec un Itanium
http://forum.winimage.com/viewtopic.php?t=172
Je veux dire par la que, contrairement à l'OpenMP où le compilateur essaye de parallèliser de lui même, on est en programation C++ classique Windows : si on veux plusieurs thread dans l'application, il faudra faire soit même les CreateThread et cie...
Ce sont généralement les OS qui parallèlisent l'ordonnancement, parce que si c'est le programmeur qui doit gérer ça, bonjour le bin's...
-- AMcD®
http://arnold.mcdonald.free.fr/
Gilles Vollant wrote:
Je veux dire par la que, contrairement à l'OpenMP où le compilateur
essaye de parallèliser de lui même, on est en programation C++
classique Windows : si on veux plusieurs thread dans l'application,
il faudra faire soit même les CreateThread et cie...
Ce sont généralement les OS qui parallèlisent l'ordonnancement, parce que si
c'est le programmeur qui doit gérer ça, bonjour le bin's...
Je veux dire par la que, contrairement à l'OpenMP où le compilateur essaye de parallèliser de lui même, on est en programation C++ classique Windows : si on veux plusieurs thread dans l'application, il faudra faire soit même les CreateThread et cie...
Ce sont généralement les OS qui parallèlisent l'ordonnancement, parce que si c'est le programmeur qui doit gérer ça, bonjour le bin's...
-- AMcD®
http://arnold.mcdonald.free.fr/
Arnaud Debaene
Vincent Burel wrote:
De quoi parlez vous ? Je parle de programmer en utiliser Windows 64 bits avec le jeux d'instruction 64 bits (surtout sur les Pentium 4 EM64T et AMD Athlon 64). Cela n'a pas d'impact sur la bande passante du bus mémoire.
Ha bon !? alors vous conservez toutes les données sur 32 bits... mais alors pourquoi utiliser un jeux d'instruction 64 bits ? :-)
D'après ce que je peux en voir de loin et sans avoir encore mis le nez dedans sérieusement, l'intérêt principal du 64 bits, c'est essentiellement d'exploser la barrière des 2GO de mémoire virtuelle accessible... Les instructions qui manipulent des données sur 64 bits, bof, c'est pas utile très souvent... (la plupart des opérations sur 64 bits peuvent d'ailleurs très bien être faites sur des machines 32 bits. Par exemple tous les Interlocked* sont disponibles en 64 bits, même sur les x86...).
Arnaud
Vincent Burel wrote:
De quoi parlez vous ?
Je parle de programmer en utiliser Windows 64 bits avec le jeux
d'instruction 64 bits (surtout sur les Pentium 4 EM64T et AMD Athlon
64). Cela n'a pas d'impact sur la bande passante du bus mémoire.
Ha bon !? alors vous conservez toutes les données sur 32 bits... mais
alors pourquoi utiliser un jeux d'instruction 64 bits ? :-)
D'après ce que je peux en voir de loin et sans avoir encore mis le nez
dedans sérieusement, l'intérêt principal du 64 bits, c'est essentiellement
d'exploser la barrière des 2GO de mémoire virtuelle accessible... Les
instructions qui manipulent des données sur 64 bits, bof, c'est pas utile
très souvent... (la plupart des opérations sur 64 bits peuvent d'ailleurs
très bien être faites sur des machines 32 bits. Par exemple tous les
Interlocked* sont disponibles en 64 bits, même sur les x86...).
De quoi parlez vous ? Je parle de programmer en utiliser Windows 64 bits avec le jeux d'instruction 64 bits (surtout sur les Pentium 4 EM64T et AMD Athlon 64). Cela n'a pas d'impact sur la bande passante du bus mémoire.
Ha bon !? alors vous conservez toutes les données sur 32 bits... mais alors pourquoi utiliser un jeux d'instruction 64 bits ? :-)
D'après ce que je peux en voir de loin et sans avoir encore mis le nez dedans sérieusement, l'intérêt principal du 64 bits, c'est essentiellement d'exploser la barrière des 2GO de mémoire virtuelle accessible... Les instructions qui manipulent des données sur 64 bits, bof, c'est pas utile très souvent... (la plupart des opérations sur 64 bits peuvent d'ailleurs très bien être faites sur des machines 32 bits. Par exemple tous les Interlocked* sont disponibles en 64 bits, même sur les x86...).
Arnaud
Vincent Burel
"Arnaud Debaene" wrote in message news:42cac286$0$3697$
Vincent Burel wrote:
>> De quoi parlez vous ? >> Je parle de programmer en utiliser Windows 64 bits avec le jeux >> d'instruction 64 bits (surtout sur les Pentium 4 EM64T et AMD Athlon >> 64). Cela n'a pas d'impact sur la bande passante du bus mémoire. > > Ha bon !? alors vous conservez toutes les données sur 32 bits... mais > alors pourquoi utiliser un jeux d'instruction 64 bits ? :-)
D'après ce que je peux en voir de loin et sans avoir encore mis le nez dedans sérieusement, l'intérêt principal du 64 bits, c'est essentiellement d'exploser la barrière des 2GO de mémoire virtuelle accessible... Les instructions qui manipulent des données sur 64 bits, bof, c'est pas utile très souvent... (la plupart des opérations sur 64 bits peuvent d'ailleurs très bien être faites sur des machines 32 bits. Par exemple tous les Interlocked* sont disponibles en 64 bits, même sur les x86...).
oui, vous avez raison, (on utilise déjà depuis longtemps le double -64bit float-, les registres 128 bits MMX ou SSE, et puis Microsoft mets le type __int64 à disposition depuis des lustres - enfin je veux dire 15 ans par exemple :-)... Bref, c'est pourquoi, le 64bit, je pense qu'on y viendra lentement... Et puis pour l'instant 2Go de mémoire seulement, c'est pas génant pour le commun des applications :-).
VB
"Arnaud Debaene" <adebaene@club-internet.fr> wrote in message
news:42cac286$0$3697$626a14ce@news.free.fr...
Vincent Burel wrote:
>> De quoi parlez vous ?
>> Je parle de programmer en utiliser Windows 64 bits avec le jeux
>> d'instruction 64 bits (surtout sur les Pentium 4 EM64T et AMD Athlon
>> 64). Cela n'a pas d'impact sur la bande passante du bus mémoire.
>
> Ha bon !? alors vous conservez toutes les données sur 32 bits... mais
> alors pourquoi utiliser un jeux d'instruction 64 bits ? :-)
D'après ce que je peux en voir de loin et sans avoir encore mis le nez
dedans sérieusement, l'intérêt principal du 64 bits, c'est essentiellement
d'exploser la barrière des 2GO de mémoire virtuelle accessible... Les
instructions qui manipulent des données sur 64 bits, bof, c'est pas utile
très souvent... (la plupart des opérations sur 64 bits peuvent d'ailleurs
très bien être faites sur des machines 32 bits. Par exemple tous les
Interlocked* sont disponibles en 64 bits, même sur les x86...).
oui, vous avez raison, (on utilise déjà depuis longtemps le double -64bit
float-, les registres 128 bits MMX ou SSE, et puis Microsoft mets le type
__int64 à disposition depuis des lustres - enfin je veux dire 15 ans par
exemple :-)... Bref, c'est pourquoi, le 64bit, je pense qu'on y viendra
lentement... Et puis pour l'instant 2Go de mémoire seulement, c'est pas
génant pour le commun des applications :-).
"Arnaud Debaene" wrote in message news:42cac286$0$3697$
Vincent Burel wrote:
>> De quoi parlez vous ? >> Je parle de programmer en utiliser Windows 64 bits avec le jeux >> d'instruction 64 bits (surtout sur les Pentium 4 EM64T et AMD Athlon >> 64). Cela n'a pas d'impact sur la bande passante du bus mémoire. > > Ha bon !? alors vous conservez toutes les données sur 32 bits... mais > alors pourquoi utiliser un jeux d'instruction 64 bits ? :-)
D'après ce que je peux en voir de loin et sans avoir encore mis le nez dedans sérieusement, l'intérêt principal du 64 bits, c'est essentiellement d'exploser la barrière des 2GO de mémoire virtuelle accessible... Les instructions qui manipulent des données sur 64 bits, bof, c'est pas utile très souvent... (la plupart des opérations sur 64 bits peuvent d'ailleurs très bien être faites sur des machines 32 bits. Par exemple tous les Interlocked* sont disponibles en 64 bits, même sur les x86...).
oui, vous avez raison, (on utilise déjà depuis longtemps le double -64bit float-, les registres 128 bits MMX ou SSE, et puis Microsoft mets le type __int64 à disposition depuis des lustres - enfin je veux dire 15 ans par exemple :-)... Bref, c'est pourquoi, le 64bit, je pense qu'on y viendra lentement... Et puis pour l'instant 2Go de mémoire seulement, c'est pas génant pour le commun des applications :-).
VB
Gilles Vollant
"AMcD®" a écrit dans le message de news: 42ca6f26$0$31213$
Gilles Vollant wrote:
Je parle des processeurs x64, qui n'ont rien à voir avec l'Itanium, qui est resté cher et, surtout, très très imparfaitement compatible x86.
Ben moi, quand je te lis, je vois marqué "portage en 64 bits", j'en ai déduit arcitecture 64 bits...
OK, c'est une questions de terminologie alors.
Je peux comprendre que l'on dise que l'architecture des AMD64 et Intel Pentium 4/EM64T n'est pas "pure" 64 bits, dans le sens qu'elle est ajouté sur des architectures processeurs conçu uniquement pour le jeux d'instruction 32 bits il y a quelques années.
Mais le jeux d'instruction x64 (AMD64/EM64T) a beau être dériver du jeux d'instruction 32 bits, il est vraiment 64 bits dans le sens ou toutes ses opérations peuvent être fait sur 64 bits (adressage mémoire, calcul...). Ou alors, en poussant les choses à l'extrème, si on considère que c'est un faux 64 bits parce que son jeux d'instruction est dérivé du jeux 32 bits, on peut dire la même chose du jeux d'instruction i386, extension sur 32 bits des instructions 16 bits. Mais c'est Intel lui même a mis le bazar dans la terminologie, en parlant d'extension 64 bits de la famille IA32 pour EM64T et d'IA64 pour l'itanium
Mais j'aurais peut être du parler de "test compatibilité Windows 64 bits pour x64 et recompilation des applications en x64"
Parce que EMT et cie, c'est pas du 64 bits, c'est du support 64 bits, nuance.
Vous pouvez très bien le considérer au niveau architecture du processeur, mais au niveau développement, surtout si on ne programme pas en assembleur, x64 a toutes les caractèristique de la programmation 64 bits, dont la principale, un adressage mémoire sur 64 bits. Et donc Windows 64 bits pour x64 est lui parfaitement 64 bits.
Un vrai processeurs 64 bits, c'est par
Le full 64 bits, attends encore un petit peu mon gars, ça coûte cher de réecrire les grosses applis de plusieurs millions de lignes, comme d'habitude, on commencera par avoir des applis qui tournent en mode legacy, puis des applis qui compilent, puis enfin des applis réécrites. C'est pas pour demain...
Cela viendra progressivement, mais je ne pense pas qu'il faille parler de réécriture.
Les choses se feront progressivement. Si dans un premier temps, tout le monde s'assure de la compatibilité des ses applications 32 bits avec Windows x64, et commence à produire, au fur et à mesure des sorties de nouvelle version, des executables x64, ce sera déjà par mal.
Quand à l'Itanium, il semble désormais destiné à rester cantonné aux serveurs équipés de nombreux processeurs. Du reste, Windows XP pour Itanium a été arrêté (seul subsiste Windows 2003 server pour Itanium).
Enfin, je crois que l'on peut sans risque prédire que le jeux d'instruction x64 a de longues années devant lui, et que petit à petit la majorité des utilisateurs Windows l'utiliseront.
Mon pronostic est que le gros du basculement se fera à la sortie de Longhorn, qui sera probablement installé majoritairement en x64.
"AMcD®" <arnold.mcdonald@free.fr> a écrit dans le message de news:
42ca6f26$0$31213$636a15ce@news.free.fr...
Gilles Vollant wrote:
Je parle des processeurs x64, qui n'ont rien à voir avec l'Itanium,
qui est resté cher et, surtout, très très imparfaitement compatible
x86.
Ben moi, quand je te lis, je vois marqué "portage en 64 bits", j'en ai
déduit arcitecture 64 bits...
OK, c'est une questions de terminologie alors.
Je peux comprendre que l'on dise que l'architecture des AMD64 et Intel
Pentium 4/EM64T n'est pas "pure" 64 bits, dans le sens qu'elle est ajouté
sur des architectures processeurs conçu uniquement pour le jeux
d'instruction 32 bits il y a quelques années.
Mais le jeux d'instruction x64 (AMD64/EM64T) a beau être dériver du jeux
d'instruction 32 bits, il est vraiment 64 bits dans le sens ou toutes ses
opérations peuvent être fait sur 64 bits (adressage mémoire, calcul...). Ou
alors, en poussant les choses à l'extrème, si on considère que c'est un faux
64 bits parce que son jeux d'instruction est dérivé du jeux 32 bits, on peut
dire la même chose du jeux d'instruction i386, extension sur 32 bits des
instructions 16 bits.
Mais c'est Intel lui même a mis le bazar dans la terminologie, en parlant
d'extension 64 bits de la famille IA32 pour EM64T et d'IA64 pour l'itanium
Mais j'aurais peut être du parler de "test compatibilité Windows 64 bits
pour x64 et recompilation des applications en x64"
Parce que EMT et cie, c'est pas du 64 bits, c'est du support 64 bits,
nuance.
Vous pouvez très bien le considérer au niveau architecture du processeur,
mais au niveau développement, surtout si on ne programme pas en assembleur,
x64 a toutes les caractèristique de la programmation 64 bits, dont la
principale, un adressage mémoire sur 64 bits.
Et donc Windows 64 bits pour x64 est lui parfaitement 64 bits.
Un vrai processeurs 64 bits, c'est par
Le full 64 bits, attends encore un petit peu mon gars, ça coûte cher de
réecrire les grosses applis de plusieurs millions de lignes, comme
d'habitude, on commencera par avoir des applis qui tournent en mode
legacy, puis des applis qui compilent, puis enfin des applis réécrites.
C'est pas pour demain...
Cela viendra progressivement, mais je ne pense pas qu'il faille parler de
réécriture.
Les choses se feront progressivement. Si dans un premier temps, tout le
monde s'assure de la compatibilité des ses applications 32 bits avec Windows
x64, et commence à produire, au fur et à mesure des sorties de nouvelle
version, des executables x64, ce sera déjà par mal.
Quand à l'Itanium, il semble désormais destiné à rester cantonné aux
serveurs équipés de nombreux processeurs. Du reste, Windows XP pour Itanium
a été arrêté (seul subsiste Windows 2003 server pour Itanium).
Enfin, je crois que l'on peut sans risque prédire que le jeux d'instruction
x64 a de longues années devant lui, et que petit à petit la majorité des
utilisateurs Windows l'utiliseront.
Mon pronostic est que le gros du basculement se fera à la sortie de
Longhorn, qui sera probablement installé majoritairement en x64.
"AMcD®" a écrit dans le message de news: 42ca6f26$0$31213$
Gilles Vollant wrote:
Je parle des processeurs x64, qui n'ont rien à voir avec l'Itanium, qui est resté cher et, surtout, très très imparfaitement compatible x86.
Ben moi, quand je te lis, je vois marqué "portage en 64 bits", j'en ai déduit arcitecture 64 bits...
OK, c'est une questions de terminologie alors.
Je peux comprendre que l'on dise que l'architecture des AMD64 et Intel Pentium 4/EM64T n'est pas "pure" 64 bits, dans le sens qu'elle est ajouté sur des architectures processeurs conçu uniquement pour le jeux d'instruction 32 bits il y a quelques années.
Mais le jeux d'instruction x64 (AMD64/EM64T) a beau être dériver du jeux d'instruction 32 bits, il est vraiment 64 bits dans le sens ou toutes ses opérations peuvent être fait sur 64 bits (adressage mémoire, calcul...). Ou alors, en poussant les choses à l'extrème, si on considère que c'est un faux 64 bits parce que son jeux d'instruction est dérivé du jeux 32 bits, on peut dire la même chose du jeux d'instruction i386, extension sur 32 bits des instructions 16 bits. Mais c'est Intel lui même a mis le bazar dans la terminologie, en parlant d'extension 64 bits de la famille IA32 pour EM64T et d'IA64 pour l'itanium
Mais j'aurais peut être du parler de "test compatibilité Windows 64 bits pour x64 et recompilation des applications en x64"
Parce que EMT et cie, c'est pas du 64 bits, c'est du support 64 bits, nuance.
Vous pouvez très bien le considérer au niveau architecture du processeur, mais au niveau développement, surtout si on ne programme pas en assembleur, x64 a toutes les caractèristique de la programmation 64 bits, dont la principale, un adressage mémoire sur 64 bits. Et donc Windows 64 bits pour x64 est lui parfaitement 64 bits.
Un vrai processeurs 64 bits, c'est par
Le full 64 bits, attends encore un petit peu mon gars, ça coûte cher de réecrire les grosses applis de plusieurs millions de lignes, comme d'habitude, on commencera par avoir des applis qui tournent en mode legacy, puis des applis qui compilent, puis enfin des applis réécrites. C'est pas pour demain...
Cela viendra progressivement, mais je ne pense pas qu'il faille parler de réécriture.
Les choses se feront progressivement. Si dans un premier temps, tout le monde s'assure de la compatibilité des ses applications 32 bits avec Windows x64, et commence à produire, au fur et à mesure des sorties de nouvelle version, des executables x64, ce sera déjà par mal.
Quand à l'Itanium, il semble désormais destiné à rester cantonné aux serveurs équipés de nombreux processeurs. Du reste, Windows XP pour Itanium a été arrêté (seul subsiste Windows 2003 server pour Itanium).
Enfin, je crois que l'on peut sans risque prédire que le jeux d'instruction x64 a de longues années devant lui, et que petit à petit la majorité des utilisateurs Windows l'utiliseront.
Mon pronostic est que le gros du basculement se fera à la sortie de Longhorn, qui sera probablement installé majoritairement en x64.
Gilles Vollant
"AMcD®" a écrit dans le message de news: 42cabf71$0$14018$
Ce sont généralement les OS qui parallèlisent l'ordonnancement, parce que si c'est le programmeur qui doit gérer ça, bonjour le bin's...
Oui, bien sur, je parlait juste du découpage en thread.
"AMcD®" <arnold.mcdonald@free.fr> a écrit dans le message de news:
42cabf71$0$14018$636a15ce@news.free.fr...
Ce sont généralement les OS qui parallèlisent l'ordonnancement, parce que
si c'est le programmeur qui doit gérer ça, bonjour le bin's...
Oui, bien sur, je parlait juste du découpage en thread.
"AMcD®" a écrit dans le message de news: 42cabf71$0$14018$
Ce sont généralement les OS qui parallèlisent l'ordonnancement, parce que si c'est le programmeur qui doit gérer ça, bonjour le bin's...
Oui, bien sur, je parlait juste du découpage en thread.
Frederic Bonroy
Gilles Vollant a écrit :
Suis-je le seul interessé?
Ben si vous pouvez me donner le nom d'un débogueur 64 bits, on sera au moins deux...
Un débogueur simple suffit, genre OllyDbg... je ne vais pas acheter Visual Studio ou un autre programme énorme de ce genre pour les trois programmes assembleur que j'écris.
Gilles Vollant a écrit :
Suis-je le seul interessé?
Ben si vous pouvez me donner le nom d'un débogueur 64 bits, on sera au
moins deux...
Un débogueur simple suffit, genre OllyDbg... je ne vais pas acheter
Visual Studio ou un autre programme énorme de ce genre pour les trois
programmes assembleur que j'écris.
Ben si vous pouvez me donner le nom d'un débogueur 64 bits, on sera au moins deux...
Un débogueur simple suffit, genre OllyDbg... je ne vais pas acheter Visual Studio ou un autre programme énorme de ce genre pour les trois programmes assembleur que j'écris.
Gilles Vollant
"Frederic Bonroy" a écrit dans le message de news: dagds7$m6s$
Ben si vous pouvez me donner le nom d'un débogueur 64 bits, on sera au moins deux...
Un débogueur simple suffit, genre OllyDbg... je ne vais pas acheter Visual Studio ou un autre programme énorme de ce genre pour les trois programmes assembleur que j'écris.
Que faite vous en assembleur, et avec quel outils compilez vous?
"Frederic Bonroy" <bidonavirus@yahoo.fr> a écrit dans le message de news:
dagds7$m6s$1@online.de...
Ben si vous pouvez me donner le nom d'un débogueur 64 bits, on sera au
moins deux...
Un débogueur simple suffit, genre OllyDbg... je ne vais pas acheter Visual
Studio ou un autre programme énorme de ce genre pour les trois programmes
assembleur que j'écris.
"Frederic Bonroy" a écrit dans le message de news: dagds7$m6s$
Ben si vous pouvez me donner le nom d'un débogueur 64 bits, on sera au moins deux...
Un débogueur simple suffit, genre OllyDbg... je ne vais pas acheter Visual Studio ou un autre programme énorme de ce genre pour les trois programmes assembleur que j'écris.
C'est ce que je craignais... :-) Je trouve ce truc convivial comme un cactus.
Que faite vous en assembleur, et avec quel outils compilez vous?
J'utilise MASM en version 32 et 64 bits. Je ne sais plus où j'avais déniché la version 64 bits. Quant à ce que je fais, bof, rien de spécial en fait... c'est de l'expérimentation plus que de véritables programmes.
C'est ce que je craignais... :-) Je trouve ce truc convivial comme un
cactus.
Que faite vous en assembleur, et avec quel outils compilez vous?
J'utilise MASM en version 32 et 64 bits. Je ne sais plus où j'avais
déniché la version 64 bits. Quant à ce que je fais, bof, rien de spécial
en fait... c'est de l'expérimentation plus que de véritables programmes.
C'est ce que je craignais... :-) Je trouve ce truc convivial comme un cactus.
Que faite vous en assembleur, et avec quel outils compilez vous?
J'utilise MASM en version 32 et 64 bits. Je ne sais plus où j'avais déniché la version 64 bits. Quant à ce que je fais, bof, rien de spécial en fait... c'est de l'expérimentation plus que de véritables programmes.
C'est ce que je craignais... :-) Je trouve ce truc convivial comme un cactus.
Peut-être (quoique les dernières vesion de WinDBG on fait de gros progrès), mais si tu trouves un debogeur plus puissant que et qui permet d'examiner autant d'aspects du fonctionement d'un programme / du système, je suis preneur ;-)
C'est ce que je craignais... :-) Je trouve ce truc convivial comme un
cactus.
Peut-être (quoique les dernières vesion de WinDBG on fait de gros progrès),
mais si tu trouves un debogeur plus puissant que et qui permet d'examiner
autant d'aspects du fonctionement d'un programme / du système, je suis
preneur ;-)
C'est ce que je craignais... :-) Je trouve ce truc convivial comme un cactus.
Peut-être (quoique les dernières vesion de WinDBG on fait de gros progrès), mais si tu trouves un debogeur plus puissant que et qui permet d'examiner autant d'aspects du fonctionement d'un programme / du système, je suis preneur ;-)
Arnaud
Gilles Vollant
"Frederic Bonroy" a écrit dans le message de news: dagpn5$6kb$