Windows sur le mainframe

Bonjour,

Le Thu, 25 Jun 2009 06:48:34 +0000 (UTC),
JKB <knatschke@koenigsberg.fr> a écrit :

En raison des
problèmes d'alignement mémoire [entre autres], si tu n'as pas besoin
d'adresser plus de 2 Go de mémoire [ou 4 sous Solaris] par processus,
un exécutable compilé en 32 bits sera un poil plus véloce que le même
en 64 bits).

Pourrais-tu nous en dire en plus sur ces problèmes d'alignement
mémoire ?
Je suis sincèrement très curieux.
(Je suppose que des comparatifs ont déjà été réalisés.)


--
Yannick Palanque

Le 16-07-2009, ? propos de
32 vs. 64 bits [était Re: Windows sur le mainframe],
Yannick Palanque ?crivait dans fr.comp.os.linux.debats :

Bonjour,

Le Thu, 25 Jun 2009 06:48:34 +0000 (UTC),
JKB <knatschke@koenigsberg.fr> a écrit :

En raison des
problèmes d'alignement mémoire [entre autres], si tu n'as pas besoin
d'adresser plus de 2 Go de mémoire [ou 4 sous Solaris] par processus,
un exécutable compilé en 32 bits sera un poil plus véloce que le même
en 64 bits).

Pourrais-tu nous en dire en plus sur ces problèmes d'alignement
mémoire ?
Je suis sincèrement très curieux.
(Je suppose que des comparatifs ont déjà été réalisés.)

Les unités internes du processeur fonctionnent par défaut sur des
registres de taille fixe (si on prend un i386, ce sont des registres de
32 bits). Sur un tel processeur, on peut utiliser des données (au moins)
de 8, 16, 32 ou 64 bits. Les types de 64 bits sont émulés et ne posent
pas de problèmes. Par contre, les données de 8 ou 16 bits peuvent sur
certains processeurs être n'importe où en mémoire, ce qui veut dire que
le processeur est contraint d'adresser la mémoire un peu bizarrement
(une donnée de 16 bits peut être à cheval sur deux mots). Résultat des
courses, le processeur peut générer plusieurs adresses pour lire un mot
et surtout doit effectuer en interne un certain nombre d'opérations pour
que les données soient correctement récupérées dans les registres.

Pour ceux qui codent en Fortran, il existe une foultitude de
logical*(1/2/4/8/16) destinés à palier à ce genre de problème
d'alignement sur des processeurs qui n'utilisent pas d'alignement
mémoire.

Historiquement, les processeurs x86 ont fait le choix (qui ne se
justifie plus) de mémoire non alignée parce que lorsque ces processeurs
ont été conçus, la mémoire était chère. C'est pour les mêmes raisons que
les codes op n'ont pas de longueur fixe. Ce choix se paie et peut se
payer cher sur certains applications.

Maintenant, soit ton architecture demande un alignement mémoire (au
hasard Sparc). L'image mémoire (pas le fichier exécutable) sera plus
grosse car elle sera plein de 'trous' et, à l'exécution, il y aura plus
de défauts de cache. C'est entre autre pour cela que les UltraSPARC
II/450 MHz possèdent 4 Mo de cache contre pas beaucoup pour un Pentium
II de la même époque. Ces défauts de cache pénalisent les performances.
Si ton architecture ne demande pas d'alignement mémoire (au hasard x86
par _défaut_), tu auras moins de défauts de cache, mais ton processeur devra
aligner en interne ses données. Tu auras plus d'opérations d'alignement
en 64 bits qu'en 32 bits, d'où une baisse de performance. Cette baisse
de performance peut aller dans les deux cas de 2 à 3% dans un cas moyen à
beaucoup plus (20%) si tu fais exprès d'écrire un bout de code fait pour mettre
en évidence le phénomène. Ça se mesure sur les x86, mais c'est
plus difficile car gcc est sournois, il se permet souvent d'aligner la
mémoire dans le dos de l'utilisateur.

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/06/2009 08:48, JKB a écrit :

Le 24-06-2009, ? propos de
Re: Windows sur le mainframe,
Jerome Lambert ?crivait dans fr.comp.os.linux.debats :

JKB a écrit :

Le 24-06-2009, ? propos de
Re: Windows sur le mainframe,
Jerome Lambert ?crivait dans fr.comp.os.linux.debats :

JKB a écrit :

Le 24-06-2009, ? propos de
Re: Windows sur le mainframe,
Cajoigooo ?crivait dans fr.comp.os.linux.debats :

Thierry B a formulé ce mercredi :

On 2009-06-24, Cajoigooo<_@> wrote:

Les logiciels professionnels comme PHotoshop ne sont pas là, OpenOffice
est bien, mais c'est loin d'être Word, les jeux du moment sont aussi au

A quoi ça sert Photoshop sur le desktop ? Gimp et/ou Krita ça suffit
très amplement. Openoffice aussi, si c'est pour faire les même
documents moisis que fait Word...

Non, un professionnel veut Photoshop, pas Grimp

Un professionnel, il veut que son truc fonctionne, donc que la
mémoire soit bien utilisée, donc il prend un Gimp avec une distribution
64 bits.

Mais non, il prend fromage *et* dessert: Photoshop sous Mac OS X

Même problème. MacOS X est encore en 32 bits pour l'immense majorité
des Macs.

Euh, l'immense majorité, ça se résume quand même à des machines assez
vieilles style G4 et aux 1ers Macintel à Core Solo et Duo vendues la
1ère moitié de 2006. Toutes les autres, à base de PPC G5 ou de Core 2
Duo sont en 64 bits. Par contre tous les programmes sont loin d'en tirer
parti... :-(

Et alors ? Ce n'est pas parce qu'un processeur est 64 bits que l'OS
l'est. Mon IBM P70 était un vrai 32 bits (pas un 386SX ou EX) et seul
OS/2 était 32 bits. MacOS X commence à embarquer des bouts de 64 bits
mais seul snow leopard sera 64 bits. Bref, j'ai encore acheté un Mac
récemment (avec un core2duo) et le truc est en _32_ bits, pas en _64_
bits. Je rajouterai même que tu peux très bien faire tourner une
distribution linux i386 sur un core2duo (je le fais, parce que le 64
bits, ce n'est pas la panacée. En raison des problèmes d'alignement
mémoire [entre autres], si tu n'as pas besoin d'adresser plus de 2 Go de
mémoire [ou 4 sous Solaris] par processus, un exécutable compilé en 32
bits sera un poil plus véloce que le même en 64 bits).

Sur x86, la différence entre un exécutable 32 bits et 64 bits ne se
limite pas qu'à cela. La différence la plus importante est le nombre de
registres généraux qui passe de 8 à 16, ce qui a permis de concevoir une
ABI différente autorisant le passage des premiers paramètres d'une
fonction par registre, au lieu de la pile. Ceci a rendu les appels de
fonctions plus rapides, et rend, en général, les applications plus
rapides en 64 bits qu'en 32 bits. Bien sûr, il y a plein de situations
particulières et un programme peut être plus rapide en 32 ou en 64 bits
en fonction de sa conception.

--
Richard

On 16 juil, 12:49, JKB <knatsc...@koenigsberg.fr> wrote:

        Les unités internes du processeur fonctionnent par dé faut sur des
registres de taille fixe (si on prend un i386, ce sont des registres de
32 bits). Sur un tel processeur, on peut utiliser des données (au moins )
de 8, 16, 32 ou 64 bits. Les types de 64 bits sont émulés et ne posen t
pas de problèmes. Par contre, les données de 8 ou 16 bits peuvent sur
certains processeurs être n'importe où en mémoire, ce qui veut dire que
le processeur est contraint d'adresser la mémoire un peu bizarrement
(une donnée de 16 bits peut être à cheval sur deux mots). Résulta t des
courses, le processeur peut générer plusieurs adresses pour lire un m ot
et surtout doit effectuer en interne un certain nombre d'opérations pou r
que les données soient correctement récupérées dans les registres .

        Pour ceux qui codent en Fortran, il existe une foultitude de
logical*(1/2/4/8/16) destinés à palier à ce genre de problème
d'alignement sur des processeurs qui n'utilisent pas d'alignement
mémoire.

En fait pratiquement aucun rapport avec les problèmes d'alignement !

En Fortran le type LOGICAL de base fait la même taille que le type
INTEGER, soit en général 32 bits. Pour stocker 1 bit d'information,
c'est pas très rentable.

Certains compilateurs fournissent donc des types LOGICAL(n), qui /
peuvent/ éventuellement occuper moins de 32 bits, dans le but
d'économiser de la mémoire. Mais d'une part la portabilité n'a rien d e
garantie (la norme ne requiert que le type LOGICAL de base) et d'autre
part un LOGICAL(1) quand il existe peut fort bien occuper en réalité
32 bits (la norme n'imposant aucune taille pour les types LOGICAL
supplémentaires).

De toute façon la "philosophie" du Fortran est généralement de faire
abstraction de la façon dont sont représentées les données en mém oire.
Les LOGICAL(n) ne sont donc pas trop dans l'esprit Fortran.

--
pehache

On 24 juin, 22:14, JKB <knatsc...@koenigsberg.fr> wrote:

> Non, un professionnel veut Photoshop, pas Grimp

        Un professionnel, il veut que son truc fonctionne, donc q ue la
mémoire soit bien utilisée, donc il prend un Gimp avec une distributi on
64 bits.

Photoshop sous 64 bits le fait très bien.

> Une secrétaire ne veut pas d'Open Office

        Une secrétaire, elle prend ce qu'on lui donne. Si la mi enne n'est
pas contente, elle change de boulot.

C'est marrant comme un promoteur du libre devient rapidement
autoritaire quand il s'agit d'imposer les choses dans ce sens-là :-)

> Je croyais que l'univers avait 15 milliards d'année, je me trompais

        Faux.

Tu as des infos de première main sur le sujet pour être aussi
affirmatif :-) ?

> Les cinglés bibliques prétendent qu'il a 6000 ans

        Faux.

Ah bon ? Pourtant c'est bien ce me disent ceux qui sonnent à ma porte
de temps en temps...

--
pehache

Le 16-07-2009, ? propos de
Re: 32 vs. 64 bits [était Re: Windows sur le mainframe],
pehache-tolai ?crivait dans fr.comp.os.linux.debats :

On 16 juil, 12:49, JKB <knatsc...@koenigsberg.fr> wrote:

        Les unités internes du processeur fonctionnent par défaut sur des
registres de taille fixe (si on prend un i386, ce sont des registres de
32 bits). Sur un tel processeur, on peut utiliser des données (au moins)
de 8, 16, 32 ou 64 bits. Les types de 64 bits sont émulés et ne posent
pas de problèmes. Par contre, les données de 8 ou 16 bits peuvent sur
certains processeurs être n'importe où en mémoire, ce qui veut dire que
le processeur est contraint d'adresser la mémoire un peu bizarrement
(une donnée de 16 bits peut être à cheval sur deux mots). Résultat des
courses, le processeur peut générer plusieurs adresses pour lire un mot
et surtout doit effectuer en interne un certain nombre d'opérations pour
que les données soient correctement récupérées dans les registres.

        Pour ceux qui codent en Fortran, il existe une foultitude de
logical*(1/2/4/8/16) destinés à palier à ce genre de problème
d'alignement sur des processeurs qui n'utilisent pas d'alignement
mémoire.

En fait pratiquement aucun rapport avec les problèmes d'alignement !

Si. Les logical* proviennent des extension VAX et sont justement là
pour éviter d'avoir des problèmes d'aligement dans les structures (elles
aussi en extension VAX). C'est même leur seul intérêt (gâcher de la
place pour gagner en vitesse).

En Fortran le type LOGICAL de base fait la même taille que le type
INTEGER, soit en général 32 bits. Pour stocker 1 bit d'information,
c'est pas très rentable.

Ça, c'est _ton_ point de vue. S'il existe un logical*16 dans le
compilo Digital, ce n'est pas exactement pour faire joli.

Certains compilateurs fournissent donc des types LOGICAL(n), qui /
peuvent/ éventuellement occuper moins de 32 bits, dans le but
d'économiser de la mémoire. Mais d'une part la portabilité n'a rien de
garantie (la norme ne requiert que le type LOGICAL de base) et d'autre
part un LOGICAL(1) quand il existe peut fort bien occuper en réalité
32 bits (la norme n'imposant aucune taille pour les types LOGICAL
supplémentaires).

Les déclarations X*Y proviennent des extensions VAX et le Y est le
nombre d'octets de la variable. J'aimerais que tu nous donnes ici un
seul compilo fortran qui pour logical*1 positionne autre chose d'un
drapeau sur un octet (au passage, ces trucs ont été normalisés, enfin
presque, dans un draft qui s'appelle Fortran-84, ce qui fait que lorsque
tu vois extensions VAX sur un compilo, c'est quelque chose de _très_
précis).

Au passage, LOGICAL*1 et LOGICAL(1), ce n'est pas la même chose. Je
te laisse chercher un peu.

De toute façon la "philosophie" du Fortran est généralement de faire
abstraction de la façon dont sont représentées les données en mémoire.
Les LOGICAL(n) ne sont donc pas trop dans l'esprit Fortran.

Il y a longtemps que tu n'as pas vu un code Fortran, toi !

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 16-07-2009, ? propos de
Re: Windows sur le mainframe,
Richard Delorme ?crivait dans fr.comp.os.linux.debats :

Le 25/06/2009 08:48, JKB a écrit :

Le 24-06-2009, ? propos de
Re: Windows sur le mainframe,
Jerome Lambert ?crivait dans fr.comp.os.linux.debats :

JKB a écrit :

Le 24-06-2009, ? propos de
Re: Windows sur le mainframe,
Jerome Lambert ?crivait dans fr.comp.os.linux.debats :

JKB a écrit :

Le 24-06-2009, ? propos de
Re: Windows sur le mainframe,
Cajoigooo ?crivait dans fr.comp.os.linux.debats :

Thierry B a formulé ce mercredi :

On 2009-06-24, Cajoigooo<_@> wrote:

Les logiciels professionnels comme PHotoshop ne sont pas là, OpenOffice
est bien, mais c'est loin d'être Word, les jeux du moment sont aussi au

A quoi ça sert Photoshop sur le desktop ? Gimp et/ou Krita ça suffit
très amplement. Openoffice aussi, si c'est pour faire les même
documents moisis que fait Word...

Non, un professionnel veut Photoshop, pas Grimp

Un professionnel, il veut que son truc fonctionne, donc que la
mémoire soit bien utilisée, donc il prend un Gimp avec une distribution
64 bits.

Mais non, il prend fromage *et* dessert: Photoshop sous Mac OS X

Même problème. MacOS X est encore en 32 bits pour l'immense majorité
des Macs.

Euh, l'immense majorité, ça se résume quand même à des machines assez
vieilles style G4 et aux 1ers Macintel à Core Solo et Duo vendues la
1ère moitié de 2006. Toutes les autres, à base de PPC G5 ou de Core 2
Duo sont en 64 bits. Par contre tous les programmes sont loin d'en tirer
parti... :-(

Et alors ? Ce n'est pas parce qu'un processeur est 64 bits que l'OS
l'est. Mon IBM P70 était un vrai 32 bits (pas un 386SX ou EX) et seul
OS/2 était 32 bits. MacOS X commence à embarquer des bouts de 64 bits
mais seul snow leopard sera 64 bits. Bref, j'ai encore acheté un Mac
récemment (avec un core2duo) et le truc est en _32_ bits, pas en _64_
bits. Je rajouterai même que tu peux très bien faire tourner une
distribution linux i386 sur un core2duo (je le fais, parce que le 64
bits, ce n'est pas la panacée. En raison des problèmes d'alignement
mémoire [entre autres], si tu n'as pas besoin d'adresser plus de 2 Go de
mémoire [ou 4 sous Solaris] par processus, un exécutable compilé en 32
bits sera un poil plus véloce que le même en 64 bits).

Sur x86, la différence entre un exécutable 32 bits et 64 bits ne se
limite pas qu'à cela. La différence la plus importante est le nombre de
registres généraux qui passe de 8 à 16, ce qui a permis de concevoir une
ABI différente autorisant le passage des premiers paramètres d'une
fonction par registre, au lieu de la pile. Ceci a rendu les appels de
fonctions plus rapides, et rend, en général, les applications plus
rapides en 64 bits qu'en 32 bits. Bien sûr, il y a plein de situations
particulières et un programme peut être plus rapide en 32 ou en 64 bits
en fonction de sa conception.

Nous sommes bien d'accord. Je compare des choses comparables,
surtout au niveau du nombre de registres. Comparer brutalement un proc
avec 8 registres de 32 bits à un autre avec 16 de 64 bits n'a aucun
sens, la comparaison doit être plus fine.

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 16-07-2009, ? propos de
Re: Windows sur le mainframe,
pehache-tolai ?crivait dans fr.comp.os.linux.debats :

On 24 juin, 22:14, JKB <knatsc...@koenigsberg.fr> wrote:

> Non, un professionnel veut Photoshop, pas Grimp

        Un professionnel, il veut que son truc fonctionne, donc que la
mémoire soit bien utilisée, donc il prend un Gimp avec une distribution
64 bits.

Photoshop sous 64 bits le fait très bien.

Je ne vois pas l'intérêt de payer un truc alors qu'un autre ne coûte
pas un rond et fait le même boulot.

> Une secrétaire ne veut pas d'Open Office

        Une secrétaire, elle prend ce qu'on lui donne. Si la mienne n'est
pas contente, elle change de boulot.

C'est marrant comme un promoteur du libre devient rapidement
autoritaire quand il s'agit d'imposer les choses dans ce sens-là :-)

On voit que ce n'est pas toi qui a un budget informatique a tenir.
Je préfère un truc qui fonctionne bien à un autre plus cher et qui ne
fonctionne pas.

> Je croyais que l'univers avait 15 milliards d'année, je me trompais

        Faux.

Tu as des infos de première main sur le sujet pour être aussi
affirmatif :-) ?

Oui. N'importe quel article d'astrophysique.

> Les cinglés bibliques prétendent qu'il a 6000 ans

        Faux.

Ah bon ? Pourtant c'est bien ce me disent ceux qui sonnent à ma porte
de temps en temps...

Alors ils se trompent dans leurs calculs.

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.

On 2009-06-25, JKB <knatschke@koenigsberg.fr> wrote:

Et alors ? Ce n'est pas parce qu'un processeur est 64 bits que l'OS
l'est. Mon IBM P70 était un vrai 32 bits (pas un 386SX ou EX) et seul

Euh, logiciellement parlant, je suis quasiment certain que le 386sx
était un vrai 32 bits, tout autant que le 386dx. La grosse différence
portant sur les largeurs des bus externes, limitant ainsi l'espace
d'adressage physique. Mais vu de l'OS je ne pense pas qu'il y ait
de différence significative. Oui/non/nsp ?


--
COBOL: USEing a COLT 45 HANDGUN, AIM gun at LEG.FOOT, THEN place
ARM.HAND.FINGER on HANDGUN.TRIGGER and SQUEEZE, THEN return
HANDGUN to HOLSTER. CHECK whether shoelace needs to be retied.

Le 16-07-2009, ? propos de
Re: Windows sur le mainframe,
Thierry B ?crivait dans fr.comp.os.linux.debats :

On 2009-06-25, JKB <knatschke@koenigsberg.fr> wrote:

Et alors ? Ce n'est pas parce qu'un processeur est 64 bits que l'OS
l'est. Mon IBM P70 était un vrai 32 bits (pas un 386SX ou EX) et seul

Euh, logiciellement parlant, je suis quasiment certain que le 386sx
était un vrai 32 bits, tout autant que le 386dx. La grosse différence
portant sur les largeurs des bus externes, limitant ainsi l'espace
d'adressage physique. Mais vu de l'OS je ne pense pas qu'il y ait
de différence significative. Oui/non/nsp ?

On est d'accord. Mais dans le cas qui nous concerne, le i386DX16
mettait la pâtée au i386SX33 en raison de son bus _externe_ 32 bits
avec un OS identique. Maintenant, en jouant à l'époque avec Warp3 (vrai
OS 32 bits), le i386SX33 était à la ramasse par rapport au
DX16. Mon rêve, à l'époque, un i386DX33... Mais c'était trop cher dans
le catalogue IBM PS/2 :-(

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.