Win3x.Org

Il serait possible d'exécuter du code 16bits sous un OS 64bits si le kernel switch d'abord en mode 32bits pour ensuite y exécuter l'appli en mode vm86. Ca pose en revanche plusieurs problèmes de protection de la mémoire le kernel doit bien calculer son coup mais c'est possible en théorie.

Dans l'époque de Windows 95 on considérait déjà Windows 3.1 exécutait les programmes 16 bits plus rapidement que Windows 95. C'est donc finalement le même phénomène qui se produit entre systèmes 64 bits et programmes 32 bits?

Un certains nombre de phénomènes participèrent à cette régression en performances:

• Le code d'un noyau 32 bits est nettement plus gros que du code 16 bits, puisque beaucoup d'offsets et de constantes passent de 16 à 32 bits.
  Ce phénomène est encore plus criant pour le passage au 64 bits, car le code 16 bits utilisait souvent des pointeurs far "32 bits" formés d'un sélecteur de segment 16 bits et d'un offset 16 bits, alors que le code 32 bits n'utilise habituellement pas de pointeurs 48 bits.
  
  Bien sûr, les caches L1 et L2 étant limitées, la taille du code influe directement sur les performances.
• Comme tous les Windows, Windows 95 a été conçu pour tirer parti optimalement du matériel moderne de l'époque.
  Certaines optimisations de la gestion de la pile réseau, du disque dur ou de la gestion de la RAM, améliorent les performances pour des ordinateurs rapides mais les dégradent pour des vieux ordinateurs.
  Entre autres, toutes ces optimisations demandent une RAM inertielle importante (en gros, 8 méga pour Win95).
  Ainsi, ceux qui mirent à jour leur Windows sur leur vieux 486 DX 33 avec 4 Mo de RAM, purent se plaindre de performances exécrables. Il faut dire que le coeur du système d'exploitation va swapper à mort.
  Par contre, si on compare, sur un ordinateur un peu plus puissant, les performances d'une carte réseau ethernet 100 Mb/s sous Windows 95 par rapport à Windows 3.1, ce dernier se traîne. Quant à MS-DOS, il est difficile de dépasser les 20 Ko/s avec TCP/IP avec de l'ethernet 100 Mb/s.
  Je suppose que Windows 3.1 et MS-DOS ont tendance à effectuer les tâches de manière plus synchrone (réception du paquet -> traitement du paquet par l'application) et à utiliser moins de tampons intermédiaires, ce qui réduit les latences, si on reçoit très peu de paquets, ainsi que la mémoire nécessaire pour les données et le code, mais est inadapté aux gros débits.
• Toujours plus de fonctions et un shell plus extensible.
  L'explorateur de Win95 supporte un modèle COM complexe, permettant de nombreuses extensions.
  ça ralentit pas mal, mais surtout ça augmente énormément la taille du code résident en mémoire. ole32.dll prend facilement 1Mo de RAM. Windows 3.1 pouvait tourner avec seulement 1Mo!
• Windows 3.x est multitâche coopératif. Windows 95 est multitâche préemptif.
  Quand une seule application principale tourne, le multitâche coopératif peu réduire un peu les performances pour quelques task switches, surtout s'il y a quelques tâches de fond. On s'en rend compte en augmentant la priorité d'un processus sous Windows 95. Les performances augmentent un peu.
  Même si on a un seul processus lancé, Windows 95 va laisser le timer système réveiller le noyau avec une interruption matérielle à intervalle régulier (un tick), ce qui ralentit un peu le programme.
  
  Le multitâche préemptif nécessite aussi de nombreuses fonctions de synchronisation, mutexes, sémaphores, événements, qui peuvent ralentir le code des programmes, mais aussi du noyau s'il est multi-threadé.
• On pourrait se dire que les appels système des programmes 16 bits sont ralentis par la conversion des paramètres de la fonction en 32 bits, mais je crois qu'en fait, cette conversion est négligeable.

Certains de ces points s'appliquent aussi au passage de Windows XP à Windows Vista ou Windows 7.
En bref, le ralentissement s'applique essentiellement aux vieux ordinateurs et est plus dû à l'évolution du système d'exploitation plutôt qu'à la transition 16 -> 32 ou 32 -> 64 bits.

Comme le dit SuperKoko, un système multitâche coopératif peut donner l'impression d'un manque de performance si une application utilise toute la puissance de calcul et refuse de laisser la main. Mais le coopératif est pourtant un poile plus performant car le noyau n'est pas interrompu en permanence par l'horloge système pour passer la main au processus. Pourtant certain OS comme linux 2.6 ont opté pour une nouvelle solution : le tickless preemption. Le noyau programme l'horloge à la volé en fonction des besoin. Ainsi dans le cas hypothétique où un seul processus est actif sur la machine. L'horloge système ne réveille pas le noyau et il n'y a ainsi aucun cycle perdu pour une préemption inutile. Aussi, l'avantage de ce système est que le CPU n'est pas réveillé en permanence quand le processeur est au repos. (man powertop). On économise ainsi en énergie et en autonomie de batterie.

Pour ce qui est de la lenteur de DOS sur le réseau par exemple. La raison est là aussi assez simple. Peu de buffer, et pilote peu optimisé, réveille de la carte réseau pour chaque paquet, donc interruption traitement par du code 16bits, voir repassage en 32bit sous windows 3.1, bref tout une machinerie lourde très lourde qui fait que pour le réseau, un OS 32bits s'en sort finalement mieux. Même s'il occupe plus de mémoire, il permet moins de changement de contextes, plus de buffer, moins d'interruption et donc au final une conso cpu plus faible que pour réaliser le même job sous DOS.

Il n'y a qu'a comparer DOS avec et sans cache disque pour se rendre compte de l'importance des buffers. Sans cache le disque dur est utilisé pour tout et n'importe quoi, avec le cache le nombre de cycle de lecture et d'écriture diminue grandement c'est la RAM qui fait tampon.

Pour ce qui est de Windows 3.1, il permet l'utilisation de pilote réseau NDIS 2 et 3. L'avantage ici est l'utilisation de pilote 32bits. Windows peut en théorie communiquer directement avec le matériel sans changer de contexte et surtout éviter le BIOS. Avec ce type de pilote sur une machine d époque j'ai pus sans problème transférer dans les 400 kilo /seconde. Par contre une seconde limite intervient : celle du bus physique de la machine (ISA) très lent.

SuperKoko a écrit :

Par contre, là où le bât blesse, c'est que pour bénéficier du mode 64 bits, les OS doivent passer dans un nouveau mode du processeur (le mode LONG), dans lequel il est facile de faire coopérer des segments 64 bits et 32 bits, mais dans lequel les segments 16 bits de code ne peuvent être directement accessible à partir du code 64 bits, car il n'existe pas de call gates pour sauter d'un segment 64 bits à un segment 16 bits (pour un programme Windows 3.x).

Cela explique pourquoi les applications Windows 3.x ne sont plus reconnues sous Vista 64 bits

tombcore a écrit :

De plus rectification : le cpu 32bits ne peut peut adresser par définition que 4 giga ! Depuis le pentium II il existe une extension (PAE) qui permet d'utiliser des bits supplémentaires pour adresser 64Giga mais ça revient à effectuer une segmentation.

corwintirnanog a écrit :

Du point de vue d'une application sur processeur Pentium c'est 32 bits. Par contre il y a un truc tordu qui permet d'adresser d'avantage de mémoire dans le même esprit que les XMS d'autrefois. http://en.wikipedia.org/wiki/Physical_Address_Extension

Il est vrai que XP et Vista 32 bits ne reconnaissent pas la mémoire au-delà de 4 Go.
Pour précision, l'article de Wikipédia signale une alternative au PAE, le PSE-36.



Merci à tous de vos réponses.

Mais Le Super Microsoft Vas Tout Changer Avec Windows 7 , Il Va Reconnaitre Jusqu'a 6 Giga De Ram

avec 3go crysis demo tourne donc il ne faut pas plus de ram sur les pc non serveur

Avec 1 giga sans swap crysis tourne sur mon vieux coucou et même plutôt bien d'ailleurs. Après windows chargé : 50 mega de ram consommé donc tout le reste est pour le jeu.