[Linux] perfs 32 vs 64 bits

[Cyril Chaboisseau]

* Victor Stinner <victor.stinner@::1> [2010-01-11 16:41 +0100]:

> Le jeudi 31 décembre 2009 10:17:11, Cyril Chaboisseau a écrit :
> > dernier point : l'un des arguments invoqué pour hésiter à passer en 64b
> > c'est le support des applications 32 bits

tu n'as pas tenu compte de la phrase qui suivait mon assertion :
"et bien non seulement ça marche très bien..."

j'aurais plutôt dû tourner ma phrase comme ça :

l'un des arguments qui était auparavant invoqué pour hésiter à passer en
64b...

> Euh, quelles applications ? Il y a 5 ans, OpenOffice, Firefox, Flash, Java, 
> ... n'étaient pas compatibles. Aujourd'hui je ne vois pas ce qui pourrait 
> bloquer.

bien sûr que _maintenant_ tout marche très bien et c'est justement le
message que j'essayais de faire passer pour tenter de convaincre les
derniers sceptiques

> > (personnellement, j'ai juste Wine que j'utilise extrêmement rarement
> > dans un but de test et Acroread pour me rendre compte à quel point il
> > est moins bien qu'Okular)
> 
> Pour Windows, j'utilise Qemu : vitesse correcte avec kqemu, et très correcte 
> avec kvm. Pour kvm, il faut un CPU récent qui a les instructions pour 
> accélérer la virtualisation, kvm les exploite justement. Fedora a bossé pour 
> fusionner kvm et qemu.

qemu (y compris avec kqemu) est un veau (ou une usine à gaz) par rapport
à Wine
les 2 ne jouent clairement pas dans la même cour :
qemu est une vraie machine virtuelle qui a besoin de l'OS (et donc d'un
licence) tandis que Wine, comme son nom l'indique n'est pas un émulateur
mais va traduire à la volée les appels à l'API Win32 de MS en
équivalents sous Linux
ça a l'énorme inconvénient que l'émulation est loin d'être parfaite mais
en contrepartie, la rapidité est au rendez-vous au point qu'un programme
peut tourner + vite sous Linux+Wine que sous Windows en natif sur la
même machine physique
sans compter que lorsque Wine64 sera stabilisé, on pourra faire tourner
des programmes windows 32 bits en natif 64 bits sous Linux avec un
espace d'adressage largement + grand que celui pour lequel ils avaient
été initialement conçu !

> Pour Acroread, je n'en ai jamais eu besoin. Okular est effectivement très bon 
> (et arrive à ouvrir tous les types de PDF)... alors que que je trouve Evince 
> très lent lors qu'on affiche un diaporama plein écran, bien qu'Evince et 
> Okular sont basés sur la même bibliothèque.

ben qu'est ce que ça doit être avec Evince :

j'ai remarqué que Okular quoique convenable est quand même assez lent
par rapport à Acroread sur de gros PDF complexes (beaucoup de textes et
d'images) lorsque l'on passe très rapidement les pages

mais bon, c'est pas encore ça qui va me le faire changer mais il y a
certainement des optimisations à faire (probablement sur le moteur de
rendu)

sinon, j'aime bien certaines fonctionnalités que d'autres non pas (y
compris Acroread) :

- la possibilité de lire plein de formats différents tel que le
  PostScript et d'autres grâce entre autre au paquet okular-extra-backend

- le fait que l'on puisse lui passer un URL en paramètre ou bien un
  fichier compressé .gz ou .bz2 sans avoir besoin de le téléchargé
  d'abord ou de décompresser le fichier en question
ça parait tout bête mais de nombreux autres reader ne le font pas et ça
simplifie grandement les choses pour traiter les appels mime-type /
mailcap à partir d'autres programmes (mutt par ex.)

- le fait de pouvoir annoter un fichier PDF
n.b. : Evince le permet aussi mais ni l'un ni l'autre ne gère ça
correctement (i.e. sous la forme d'un fichier .fdf) comme on pourrait
l'espérer ce qui serait vraiment une "killer feature" et permettrait de
s'affranchir de la suite Adobe Acrobat (payante) pour tout un tas de
travaux sur les fichiers PDF

- dernière fonctionnalité sympa : le non respect (si on le désire) des
  anti-fonctionnalités (anti-features) du format pdf tels que la
restriction sur l'impression ou l'extraction (copie) de texte

cf. http://lwn.net/Articles/335415/


-- 
	Cyril Chaboisseau