Une pré-version de Flash en 64 bits, Réactions à la publication du 16/09/2010

[GStepper]

@ SartMatt

Mais une application 64 bits tournant sur un noyau 32 bits avec PAE dispose de plus de 4Go de mémoire virtuelle non ?

[FabriceB]

@ SartMatt

Mais une application 64 bits tournant sur un noyau 32 bits avec PAE dispose de plus de 4Go de mémoire virtuelle non ?

En règle générant non, parce que une application 64 bits ne peut pas tourner sur un noyau 32 bits. Seul Apple avait fait un système un peu bâtard avec un noyau 32 bits capable de lancer des applis 64 bits. Elles avaient alors droit à plus de 4Go en effet. Mais ce n'était pas lié au PAE je pense.

[SartMatt]

@ SartMatt

Mais une application 64 bits tournant sur un noyau 32 bits avec PAE dispose de plus de 4Go de mémoire virtuelle non ?

En règle générant non, parce que une application 64 bits ne peut pas tourner sur un noyau 32 bits. Seul Apple avait fait un système un peu bâtard avec un noyau 32 bits capable de lancer des applis 64 bits. Elles avaient alors droit à plus de 4Go en effet. Mais ce n'était pas lié au PAE je pense.

Yep, normalement c'est pas possible, sauf avec les bidouilles d'Apple. Je me demande bien comment ils ont fait d'ailleurs, parce que il me semble que le processeur peut pas passer à la volée du mode 32 bits au mode 64 bits s'il a pas été initialisé en 64 bits. Je me demande en fait si y aurait pas un bout de code 64 bits qui charge le noyau en mode compatibilité 32 bits.

Dans ce cas, l'appli 64 bits peut disposer d'un espace d'adressage virtuel de plus de 4 Go, sans qu'il y ait aucun rapport avec le PAE : même si le kernel n'est capable que de gérer 4 Go de mémoire physique, il peut très bien allouer des espaces d'adressage plus grand que 4 Go aux applications (tout comme un OS 32 bits allouera généralement toujours des espaces virtuels de 4 Go, même si y a que 512 Mo de RAM sur la machine). Ça va swapper à mort si l'application utilise beaucoup de mémoire, mais il peut le faire.

C'est justement à ça que sert la virtualisation de la mémoire : permettre d'allouer aux applications bien plus d'espace que ce qui est disponible physiquement, l'OS gérant ensuite un mécanisme de swap sur le stockage de masse pour conserver toutes les pages mémoires qui ne rentrent pas dans la RAM, et les y recopier quand elles sont accédées.

Ce message a été modifié par SartMatt - 16 Sep 2010, 18:23.

[Ar_H]

Y'en a qui écoutent encore Korn ?

Des sourds surement, sinon je vois pas

[zaxxon]

C'est justement à ça que sert la virtualisation de la mémoire : permettre d'allouer aux applications bien plus d'espace que ce qui est disponible physiquement, l'OS gérant ensuite un mécanisme de swap sur le stockage de masse pour conserver toutes les pages mémoires qui ne rentrent pas dans la RAM, et les y recopier quand elles sont accédées.

Sauf qu'avec un noyau en 32 bits et des pages de 4 kiB à gérer, le noyau va finir par utiliser une bonne partie de sa mémoire pour ça dès qu'on voudra exploiter quelques dizaines de GiB. C'est la raison donnée par Ars Technica (je trouve ça un peu limite).
Je préfère voir l'aspect dépoussiérage d'API avec passage des paramètres par les registres (plus nombreux) et non plus par la pile, pour les applications qui peuvent en avoir l'usage manipulation d'entiers sur 64 bits (contre quelques instructions 32 bits pour faire la même chose). De plus un processeur 64 bits étant plus récent on peut également bénéficier à coup sur d'autres extensions du jeu d'instruction comme SSE2, lorsqu'on compile en 32 bits on vise quoi ? (i486, Pentium, MMX, SSE...) chez Apple c'est un peu plus facile vu que c'est au minimum l'architecture Core.

[SartMatt]

lorsqu'on compile en 32 bits on vise quoi ? (i486, Pentium, MMX, SSE...)

On utilise un compilo suffisamment intelligent, qui va compiler certaines portions du code en plusieurs versions exploitant différentes extensions du x86, pour faire un binaire qui va ensuite brancher vers la meilleurs version en s'appuyant sur les features flags du processeur ;-)

[xpech]

[dans les ~800 Mo que l'OS arrive pas à adresser directement (à cause des adresses "bouffées" par le mappage des I/O)

C'est pas plutôt 80 Mo ? 800 Mo, ça me semble énorme. Tu parle de l'adressage physique ?

Oui, adressage physique. Le BIOS ne reporte qu'environ 3200 Mo de mémoire, parfois même moins. Le reste c'est des adresses réservées pour mapper des IO, et une partie de la mémoire vidéo des cartes PCI-Express (rien que ça, c'est de l'ordre de 256 Mo il me semble).

On faisait le même chose sur MacOS7 sur certains mac 68k. On pouvait mettre 10mo de ram (mdr) mais seuls 8 étaient utilisables par les appli mais certains outils permettaient de faire un ram disk dans les 2 autres Mo plus qu'une disquette !!

.., lorsqu'on compile en 32 bits on vise quoi ? (i486, Pentium, MMX, SSE...) ...

2 choses:
* on a des lib/environnement qui ne sont pas encore passé en 64 bits pour plein de bonnes ou mauvaises raisons (technique, fiabilité ...)
* sur certains algo, on y perd, le volume de données (x2) pénalise les traitements.

En gros le plus gros problème d'optimisation sont les accès mémoires. Hors doubler la taille des données (un tableau de pointeur ou d'entier sera 2 fois plus grand) ça pénalise la bande passante mémoire et le cache. Donc ça peut être très mauvais.
En plus les calculs en 64 bits sont tout de même pris en compte par les cpu, donc bon .... c'est pas systématiquement indispensable.

Dans les encombres pour passer en 64 bits, il y a le problème de Windows (si un veut garder une portabilité), le mode 64bits de ce dernier étant différent du reste du monde. (merci m$)

Ce message a été modifié par xpech - 16 Sep 2010, 21:02.

[os2]

Pas forcément. Sur Snow Leopard les plugins sont exécutés dans un process séparé donc Safari 64-bit peut utiliser des plugins 32-bit.

Seulement Safari et Chrome. Les gens (comme moi) qui utilisent Firefox n'ont pas encore cette chance, mais ça s'en vient.

firefox existe en 64 bits au moins pour linux

[SartMatt]

[dans les ~800 Mo que l'OS arrive pas à adresser directement (à cause des adresses "bouffées" par le mappage des I/O)

C'est pas plutôt 80 Mo ? 800 Mo, ça me semble énorme. Tu parle de l'adressage physique ?

Pour info, voilà comment sont mappés les 4 premiers Go sur ma machine : http://share.lurl.eu/macb/memory-map.png

La ligne sélectionnée correspond grosso modo à la mémoire qui sera utilisable par un système 32 bits sans PAE. Elle correspond à 3326 Mo sur les 4096 et démarre à l'adresse 1 Mo. Je sais pas si les autres lignes "carte système" correspondent toutes à de la mémoire utilisable, mais ça change pas grand chose (ça porte le total à 3329 Mo environ).

Le gros consommateur d'adresses est le bus PCI, qui squatte 749 Mo dont 256 Mo pour la carte graphique (qui ne mappe heureusement pas toute sa RAM dans l'espace d'adressage du processeur, sinon ça ferait mal avec une carte 1 Go ^^).

Marrant de voir encore dans cette map mémoire les bons vieux vestiges de la rétrocomptabilité : le bloc de RAM de 640 Ko tout au début, suivis immédiatement des 128 Ko de RAM vidéo pour le mode texte et le mode VGA :-)

Ce message a été modifié par SartMatt - 16 Sep 2010, 23:35.

[proulout]

Un peu HS mais un peu dedans quand même: pour pousser le débat HTML5 - Flash

Pour ma part j'ai fait le tour de la question.

On est rapidement limités en HTML5 quand il s'agit de faire des applis web avec images, texte, couleurs, rotation des éléments, sauvegarde... J'en suis venu à cette conclusion après plusieurs mois de recherche et de mise sur le coup de plusieurs developpeurs. Les démos HTML5 que j'ai vues sont plus lentes, ont moins de possibilités. Est-ce dû à la manière dont c'est développé ou est-ce dû au langage lui-même moins adapté?...

J'espère enfin que Flash va se libérer sur l'iPhone et sur l'iPad rapidement.

[GStepper]

@SartMatt & FabriceB

Merci pour vos lumières.

En fait, je demandais cela car j'ai un iMac late 2009 avec 8Go de RAM que je dédie à un usage de M.A.O.

Logic 9 pouvant fonctionner en 64 bits au dessus du noyau 32 bits, je voulais comprendre la "bidouille" faite par Apple pour rendre cela possible.

Je trouve cette solution très pratique dans la mesure où mon matériel audio n'est livré qu'avec des pilotes 32 bits (pour le moment) et il me semble que c'est une bonne démarche de transition 32/64 bits qui a été entreprise par Apple.