La Fibre
Datacenter et équipements réseaux => Équipements réseaux => 
Matériel informatique (réseaux domestiques) => Discussion démarrée par: Leon le 29 octobre 2016 à 09:02:49
-
Bonjour à tous,
Je m'aperçois que je n'ai toujours pas assimilé les différences entre les machines/OS/Logiciels 32bits et 64 bits.
Beaucoup de sites essayent d'expliquer ça, mais la plupart sont très confus.
Désolé si ces questions vous paraissent basiques, mais c'est le brouillard complet dans mon esprit.
Du coup, j'ai plusieurs questions :
* quel sont les vrais avantages du 64 bits?
- La capacité à gérer plus de RAM? Si c'est juste ça, l'intérêt est quand même faible pour des applications bureautique & multimédia (=90% des usages des particuliers).
- La vitesse de transfert de données?
- L'exécution d'instructions sur des données 64 bits?
- Le fait d'avoir plus d'instructions processeur qu'avant?
- autre chose que j'aurais loupé?
* un OS 32 bits sur une machine 64bits, est-ce que ça sera plus rapide que sur une machine 32 bits? (toutes choses égales par ailleurs) Au moins pour les transferts de donnée (DMA?) qui se feraient en 64bits?
* Sous un windows 64bits, quasiment toutes les applications bureautique & multimédia sont en 32 bits. Pourquoi? Est-ce que ça ne bride pas les performances? Je suppose que ces applications n'utilisent aucune instruction 64bits, et manipulent des données sur 32 bits et non sur 64 bits.
D'ailleurs, Microsoft recommande toujours de déployer des applications en 32bits pour assurer un maximum de compatibilité...
* Une application 32bits est-elle plus rapide sur une machine 64bits et un windows 64bits? (toutes choses égales par ailleurs) Si oui, pourquoi?
* Les manipulations de données par une application 32bits sur une machine+OS 64bits se font bien 32 bits par 32bits? Si oui, ça n'exploite pas du tout les capacités en débit des machines 64 bits...
Je parle bien hors transferts DMA qui doivent se faire en 64bits.
* Toujours sous Windows 64bits, avec des applications 32bits, est-ce que tous les "services" de l'OS, et couches basses (kernel?) de l'OS s'exécutent en 64 bits, malgré que les appels des applications passent sans doute en 32 bits?
* Il y a visiblement des instructions spécifiques 64bits sur les processeurs 64 bits. Mais sont-elles vraiment utilisées dans la vraie vie, vu le peu d'applications 64bits?
Merci d'avance pour votre éclairage de lanterne! :)
Leon.
-
J'essaye de répondre à ce que je connais...
Du coup, j'ai plusieurs questions :
* quel sont les vrais avantages du 64 bits?
- La capacité à gérer plus de RAM? Si c'est juste ça, l'intérêt est quand même faible pour des applications bureautique & multimédia (=90% des usages des particuliers).
Plus de RAM globalement non, car l'extension PAE des processeurs 32 bits permet d'aller bien au-delà du max de RAM supporté par les cartes mères grand publics (64Go). On "remerciera" juste Microsoft de refuser de l'utiliser (cf post de Vivien OS 32bits avec 16Go de ram (https://lafibre.info/systeme-exploitation/os-32bits-avec-16go-de-ram/)).
Plus de RAM par process oui : sous Windows 32bits, tu ne peux pas donner plus de 2Go de RAM par process. Est-ce embêtant ? Figure-toi que ma femme arrive à faire exploser la consommation RAM de Firefox simplement en chargeant des photos sur des pages Facebook.
- La vitesse de transfert de données?
Joker.
- L'exécution d'instructions sur des données 64 bits?
Oui car les registres étant 64bits, tu peux effectuer des opérations en une seule fois.
- Le fait d'avoir plus d'instructions processeur qu'avant?
En mode x86-64, certaines instructions ont même disparues, celles liées à la segmentation mémoire par exemple. Il y a aussi de nouvelles instructions qui permettent d'effectuer des opérations plus rapidement là où avant il en fallait plusieurs.
- autre chose que j'aurais loupé?
La spec x86-64 amène plus de registres généraux, cela rend le processeur plus efficace (moins d'appel à la pile, au cache, etc).
* un OS 32 bits sur une machine 64bits, est-ce que ça sera plus rapide que sur une machine 32 bits? (toutes choses égales par ailleurs) Au moins pour les transferts de donnée (DMA?) qui se feraient en 64bits?
Un OS32 bits tourne au mieux à vitesse identique sur un CPU compatible x86-64. Il y a tellement d'écarts entre les CPU d'aujourd'hui et ceux d'avant qu'il serait difficile de dire si un OS32 bits tourne plus vite ou plus lentement (en relatif).
Comme le mode x86-64 n'est pas activé, un OS32 bits ne peut pas bénéficier d'une quelconque amélioration autre que le cache amélioré ou un pipeline plus efficace.
Exception: les CPU Itanium qui étaient natifs 64bits et ne pouvaient gérer du 32bits que par émulation.
* Sous un windows 64bits, quasiment toutes les applications bureautique & multimédia sont en 32 bits. Pourquoi? Est-ce que ça ne bride pas les performances? Je suppose que ces applications n'utilisent aucune instruction 64bits, et manipulent des données sur 32 bits et non sur 64 bits.
D'ailleurs, Microsoft recommande toujours de déployer des applications en 32bits pour assurer un maximum de compatibilité...
Oui on perd en perf car le CPU passe d'un mode (32b) à l'autre (64b) à la volée. Je n'ai pas de chiffre mais je pense que ça doit être négligeable.
* Une application 32bits est-elle plus rapide sur une machine 64bits et un windows 64bits? (toutes choses égales par ailleurs) Si oui, pourquoi?
Pour moi, non. Vu la remarque précédente, il est même possible qu'elle soit un plus lente.
* Les manipulations de données par une application 32bits sur une machine+OS 64bits se font bien 32 bits par 32bits? Si oui, ça n'exploite pas du tout les capacités en débit des machines 64 bits...
Je parle bien hors transferts DMA qui doivent se faire en 64bits.
Comme tu ne peux pas utiliser tes registres en mode 64 ni les nouveaux, tout reste en 32 bits.
P'tet que la gestion du cache en prédictif est plus efficace en chargeant par 64bits, faudrait vérifier.
* Toujours sous Windows 64bits, avec des applications 32bits, est-ce que tous les "services" de l'OS, et couches basses (kernel?) de l'OS s'exécutent en 64 bits, malgré que les appels des applications passent sans doute en 32 bits?
Les couches basses, oui. Les services en principe aussi mais ils peuvent tourner en 32.
* Il y a visiblement des instructions spécifiques 64bits sur les processeurs 64 bits. Mais sont-elles vraiment utilisées dans la vraie vie, vu le peu d'applications 64bits?
SSE fait partie de la spec x86-64. Il y a aussi des optimisations sur l'adressage par rapport au pointeur d'instruction, plus pratique pour les libs.
https://fr.wikipedia.org/wiki/AMD64
-
Du coup, de ce que j'en comprends, les applications 32 bits windows n'exploitent pas du tout les performances accrues d'un processeur 64bits.
Or, la majorité des applications windows bureautique & multimedia diffusées aujourd'hui sont en 32 bits : Firefox, VLC, Thunderbird, Office, etc...
Et là, je ne comprends vraiment pas la situation actuelle. Pourquoi les applications ne sont-elles pas diffusées majoritairement en 64bits? Ou alors avec des "binaires" 32bits et 64bits pour s'adapter à chaque machine?
Leon.
-
* quel sont les vrais avantages du 64 bits?
L'espace d'adresses plat (sans structure, sans délimitation) plus grand, comme IPv6 vs. IPv4.
- La capacité à gérer plus de RAM?
La capacité de gérer la RAM en général n'a rien à voir avec la taille de l'adressage plat.
Si c'est juste ça, l'intérêt est quand même faible pour des applications bureautique & multimédia (=90% des usages des particuliers).
L'intérêt pour la sécurité est de faire une vraie randomisation des adresses.
* Sous un windows 64bits, quasiment toutes les applications bureautique & multimédia sont en 32 bits. Pourquoi?
La flemme.
-
Oui car les registres étant 64bits, tu peux effectuer des opérations en une seule fois.
Précision pour ceux qui ne parlent pas couramment l'asm, précisons que cela ne concerne que les registres stockant des nombres entiers :
- entiers : prévus pour toutes les opérations arithmétiques et binaires (et, ou, ou-ex, neg)
- adresses : additions et soustractions
Les registres pour nombres à virgule flottante sur Intel sont en 80 bits (mais on peut configurer le processeur pour presque faire comme si ils étaient sur 64 bits). Il y a aussi des opérateurs flottants rapides sur flottants 32 bits.
-
La plupart des jeux récents (Battlefield 1, Titanfall 2, Mafia III, etc...) ne s'installent que sur des OS en 64 bits.
-
Est-ce qu'ils prennent beaucoup de mémoire?
-
La spec x86-64 amène plus de registres généraux, cela rend le processeur plus efficace (moins d'appel à la pile, au cache, etc).
D'un autre coté, les pointeurs sont deux fois plus gros, donc certaines structures de données prennent beaucoup plus de place en RAM, remplissent plus vite le cache, etc.
Oui on perd en perf car le CPU passe d'un mode (32b) à l'autre (64b) à la volée. Je n'ai pas de chiffre mais je pense que ça doit être négligeable.
Si c'est au moment du changement de mode (via une soft interrupt, une porte ou autre) je pense que ça peut être gratuit puisque de toute façon tu dois tout sauvegarder/purger/sanitiser.
-
Remarque préliminaire :
Comme d'hab, les idées me viennent au fur et à mesure.
Comme d'hab, je les poste comme elles arrivent (c'est un forum, pas un ouvrage de synthèse).
Comme d'hab, ça fait plusieurs messages à la suite. Merci de ne pas appeler ça du "flood" puisque chaque message est différent des autres et aborde des points disjoints.
L'adressage mémoire large et plat permet de faire de grands mapping (mise en correspondance) de l'espace d'adressage de la mémoire avec un fichier du disque :
TDB with 64-bit and 32-bit JVMs
TDB runs on both 32-bit and 64-bit Java Virtual Machines. The same file formats are used on both systems and database files can be transferred between architectures (no TDB system should be running for the the database at the time of copy). The difference is that a different file access mechanism used.
The file access mechanism can be set explicitly, but this is not a good idea for production usage, only for experimentation - see the File Access mode option.
64-bit Java
On 64-bit Java, TDB uses memory mapped files and the operating system handles much of the caching between RAM and disk. The amount of RAM used for file caching increases and decreases as other application run on the machine. The fewer other programs running on the machine, the more RAM will be available for file caching.
TDB is faster on a 64 bit JVM because more memory is available for file caching.
32-bit Java
On 32-bit Java, TDB uses it's own file caching to enable large databases. 32-bit Java limits the address space of the JVM to about 1.5Gbytes (the exact size is JVM-dependent), and this includes memory mapped files, even though they are not in the Java heap. The JVM heap size may need to be increased to make space for the disk caches used by TDB.
Disk Format
The on-disk file format is compatible between 32 and 64 bit systems and databases can be transferred between systems by file copy if the databases are not in use (no TDB or Fuseki instance is accessing them at the time). Databases can not be copied while TDB is running, even if TDB is not actively processing a query or update.
Copyright © 2011–2016 The Apache Software Foundation, Licensed under the Apache License, Version 2.0.
https://jena.apache.org/documentation/tdb/tdb_system.html
-
La plupart des jeux récents (Battlefield 1, Titanfall 2, Mafia III, etc...) ne s'installent que sur des OS en 64 bits.
Je pense que c'est à cause des instructions SSE qui sont apparues avec.
Un jeu n'a que faire du 64bits pour la RAM ou les fichiers (ou alors les devs codent avec leurs pieds).
-
Un jeu n'a que faire du 64bits pour la RAM ou les fichiers (ou alors les devs codent avec leurs pieds).
Il faudrait regarder combien de mémoire le processus a mappé.
-
- La vitesse de transfert de données?
Logiquement oui, vu que le mot est plus grand, tu as plus de données à vitesse constante
cf https://fr.wikipedia.org/wiki/Transfer_(informatique)
Sinon, la majorité des logiciels de qualités sont natifs 64b
On parle quand même de l'architecture la plus utilisée au monde, et qui a plus de 10 ans d'âge ..
Un jeu n'a que faire du 64bits pour la RAM ou les fichiers (ou alors les devs codent avec leurs pieds).
La ram en 32b est très limitée;
-
Un programme 64bits est-il plus rapide qu'un programme 32bits ?
Cela dépend !
Certains programme tel que la compression .gz transformer un fichier .waw en MP3 avec Lame sont plus rapides en 32bits.
La plupart des programmes ont toutefois un gain en 64bits. C'est le cas de la compression .bz2 et .xz de la transformaiotn d'un fichier .waw en .ogg avec oggenc et de trés nombreux autres programmes.
Le gain de performance global sur les tests que j'ai réalisés avec 12 programmes varie de 10% à 25% en fonction du processeur (même un Pentium IV). Attention ces tests sont réalisés avec un PC qui a suffisamment de ram.
Faut-il installer un système d’exploitation 32bits ou 64bits sur un PC avec 3Go de Ram ?
32bits sans hésiter : on perdra en peu en performance processeur, mais il y a un gain important pour l’utilisateur lié au fait qu'un système d’exploitation 32bits utilise sensiblement moins de ram qu'un système 64bits. Su un PC avec 2 Go de ram, Windows 10 32bits utilise 700Mo de ram. C'est 1Go de ram sur le même OS en 64bits.
Vu la consommation aujourd'hui des logiciels, diminuer la consommation de ram de 30% des logiciels permet un gain important en utilisant moins de swap (ou en cachant plus de données lue sur le disque dur si on n'utilise pas la swap en 64bits)
Bref, a moins d'être sur d'avoir suffisamment de ram pour le programme qui v à tourner, il faut installer un OS 32bits sur un PC avec 3Go de ram ou moins.
(https://lafibre.info/testdebit/linux/vieux_pc_quel_linux_installer.webp)
Pour un PC avec 4Go de ram ou plus, le 64bits est par contre indispensable pour utiliser toute la précieuse mémoire et il ne faut pas hésiter à installer un OS 64bits, surtout sous Windows :
(https://lafibre.info/testdebit/windows10/201610_windows10_32bits_1.png)
-
Logiquement oui, vu que le mot est plus grand, tu as plus de données à vitesse constante
cf https://fr.wikipedia.org/wiki/Transfer_(informatique)
Non, ça n'a absolument aucun rapport.
On parle ici des REGISTRES entiers et du nombre bit significatif dans les ADRESSES.
On NE parle PAS du bus de données.
Encore une fois, jack nous donne une idée de sa méconnaissance de l'informatique.
-
Certains programme tel que la compression .gz transformer un fichier .waw en MP3 avec Lame sont plus rapides en 32bits.
Transcoder un fichier est plus lent avec des pointeurs plus larges? J'aimerais bien savoir pourquoi.
La plupart des programmes ont toutefois un gain en 64bits. C'est le cas de la compression .bz2 et .xz de la transformaiotn d'un fichier .waw en .ogg avec oggenc et de trés nombreux autres programmes.
Le gain de performance global sur les tests que j'ai réalisés avec 12 programmes varie de 10% à 25% en fonction du processeur (même un Pentium IV). Attention ces tests sont réalisés avec un PC qui a suffisamment de ram.
Je me demande dans quelle mesure le résultat est sensible à la moindre modification du programme ou un compilateur.
Faut-il installer un système d’exploitation 32bits ou 64bits sur un PC avec 3Go de Ram ?
32bits sans hésiter : on perdra en peu en performance processeur, mais il y a un gain important pour l’utilisateur lié au fait qu'un système d’exploitation 32bits utilise sensiblement moins de ram qu'un système 64bits. Su un PC avec 2 Go de ram, Windows 10 32bits utilise 700Mo de ram. C'est 1Go de ram sur le même OS en 64bits.
Mais moins de protection contre certains exploits qui permettent de prendre le contrôle partiel ou total de la machine.
-
Et surtout n'oublions pas que ces processeurs sont une évolution (compatible) depuis le 8086 qui a des registres entiers de 16 bits, qui ont été étendus à 32 bits sur le 386!!!
On a vraiment des artefacts historiques dans les processeurs x86, qui n'existent pas dans les autres familles.
-
Bon j'ai retrouvé l'info concernant les transferts : https://en.wikipedia.org/wiki/Front-side_bus#Intel_processors
Depuis l'architecture Pentium la largeur du bus est de 64 bits. Il a fallu attendre l'architecture du P4 pour voir un gain significatif donc cela n'a rien à voir avec le jeu d'instructions x86-64.
A partir du Core i7, tout a changé : plus de FSB avec le Northbridge qui a disparu, le CPU échange avec la RAM en direct ainsi qu'avec les périphériques PCI-Express dont chaque bus est dédié. L'architecture est devenue point-à-point.
A lire:
Architecture Core i7: http://pnrsolution.org/Datacenter/Vol3/Issue2/68.pdf
CPU en général: http://www.tomshardware.com/reviews/processor-cpu-apu-specifications-upgrade,3566-2.html
Ce dernier article explique pourquoi un Pentium (ou son équivalent) se prend pour un 8088 au démarrage jusqu'à ce que quelqu'un lui dise "hé ducon, t'es un Pentium !"
-
Ça m’épate que Windows 10 se fasse encore en 32 bits. :o
-
Moi aussi, je pensais que Microsoft abandonnerait le 32bits avec Windows 10, au lieu de repartir sur un support de 10 ans.
Le support du 32bits est assuré jusqu'en 2025. Je ne sais pas ce qu'il sera possible de faire en 2025 avec 3Go de ram...
A partir du Core i7, tout a changé : plus de FSB avec le Northbridge qui a disparu, le CPU échange avec la RAM en direct ainsi qu'avec les périphériques PCI-Express
Core i7 de quelle génération ? (on en a 7 maintenant des génération de Core i7)
Un Xeon X3450, qui est très proche d'un Core i7 en bénéficie aussi ?
Ce Core i7-640UM (http://ark.intel.com/fr/products/47700/Intel-Core-i7-640UM-Processor-4M-Cache-1_20-GHz)de 2 cœurs à 1,2 Ghz en bénéficie ?
Comment savoir si il en bénéficie en lisant la fiche ?
-
Tu as beaucoup d'applications qui ne tiennent pas dans 3 Go? ? ? !!!!
-
J'ai séparé le HS : Firefox 64bits vs 32bits (https://lafibre.info/navigateurs/firefox-64bits-vs-32bits/)
-
Core i7 de quelle génération ? (on en a 7 maintenant des génération de Core i7)
i7 9xx sorti en 2008 : http://ark.intel.com/fr/products/37147/Intel-Core-i7-920-Processor-8M-Cache-2_66-GHz-4_80-GTs-Intel-QPI
QPI = Quick Path Interconnect, liens point-à-point.
Un Xeon X3450, qui est rés proche d'un Core i7 en bénéficie aussi ?
http://ark.intel.com/products/42929/Intel-Xeon-Processor-X3450-8M-Cache-2_66-GHz
Oui, pas de FSB, c'est un DMI. La différence avec QPI est juste qu'un composant sur la carte mère est nécessaire pour la RAM alors que QPI est direct.
Ce Core i7-640UM (http://ark.intel.com/fr/products/47700/Intel-Core-i7-640UM-Processor-4M-Cache-1_20-GHz)de 2 cœurs à 1,2 Ghz en bénéficie ?
Comment savoir si il en bénéficie en lisant la fiche ?
Il supporte nativement PCI-Express (qui est point-à-point).
L'équivalent chez AMD est Hyper-Transport (je ne sais pas si l'appellation a été conservée).
-
Exception: les CPU Itanium qui étaient natifs 64bits et ne pouvaient gérer du 32bits que par émulation.
Attention, Itanium est un modèle très différent de la famille "Intel" traditionnelle; tellement radicalement différent qu'il n'a jamais pris!
SSE fait partie de la spec x86-64.
Streaming SIMD Extensions, généralement abrégé SSE, est un jeu de 70 instructions supplèmentaires pour microprocesseurs x86, apparu en 1999 sur le Pentium III en réponse au 3DNow! d'AMD apparu 1 an plus tôt
-
Attention, Itanium est un modèle très différent de la famille "Intel" traditionnelle; tellement radicalement différent qu'il n'a jamais pris!
HP et Siemens/Fujitsu en ont vendu. L'Itanium 1 était une énorme daube. Le 2 par contre a bien pris chez HP pour remplacer ses PA-RISC. IBM a pris le large avec son Power ainsi que Sun avec SPARC puis les bases Opteron avec Solaris-x86.
x86-64 a été défini par AMD qui y a intégré SSE. Avant les AMD n'avaient que 3DNow et SSE était l'exclusivité d'Intel.
-
A propos du SSE, voici ce que dit le release note de Firefox 48 :
After version 48, SSE2 CPU extensions are going to be required on Windows
Source : Release Notes Firefox 48 (https://www.mozilla.org/en-US/firefox/48.0/releasenotes/)
Je me demande si les instructions SSE2 sont utilisées pour les version de Firefox 48.0.2 et inférieur.
J'imagine que SSE2 n'est utilisé qu'a partir de Firefox 49, d'où une incompatibilité pour les ordinateur sans SSE2.
SSE2 a été introduit par Intel en 2000 dans les Pentium 4 et a été mis également sur les Pentium III pour portable conçu après cette date.
-
Tous les compilateurs (ou presque) sont aujourd'hui capables de générer des instructions SSE2, il y a certains mainteneurs de logiciel qui font le choix ne pas les utiliser pour conserver une compatibilité matérielle plus large.
-
OK pour Linux (ou chaque distribution compile son Firefox), mais là je parlait de Windows : Un seul binaire est proposé et pour conserver la compatibilité, je suppose qu'ils n'utilisent pas les extension récentes.
-
un même binaire peut dynamiquement utiliser ou pas les extensions. y'a pas forcement besoin de faire plusieurs binaires donc.
gcc sait faire cela directement (googler "GCC Function Multiversioning") ou le programmeur peut utiliser des libs externes qui différent suivant ce que le cpu supporte.
-
un même binaire peut dynamiquement utiliser ou pas les extensions. y'a pas forcement besoin de faire plusieurs binaires donc.
Ça ne diminue pas les performances tout en augmentant la taille des binaires de faire cela ?
-
Transcoder un fichier est plus lent avec des pointeurs plus larges? J'aimerais bien savoir pourquoi.
Je me demande dans quelle mesure le résultat est sensible à la moindre modification du programme ou un compilateur.
Ça peut effectivement beaucoup dépendre du compilateur, mais certains programmes sont pénalisés par la plus grande taille du code et des pointeurs en 64 bits, par rapport aux caches L1/L2.
Les CPU les plus anciens (P4 et Core 2 il me semble) n'ont pas toutes leur micro-optimisations sur le code 64 bits.
Bien sûr un test réalisé avec les options par défaut des compilateurs pourra être plus rapide en 64 bits grâce au SSE2 activé par défaut, et à l'optimisation pour des CPU plus récents (même si par exemple la version "i386" d'Ubuntu nécessite un CPU i686 avec CMOV (Pentium Pro/Pentium II, ...)).
-
Tu as beaucoup d'applications qui ne tiennent pas dans 3 Go? ? ? !!!!
La plupart des bases de données sérieuses.
-
Ça ne diminue pas les performances tout en augmentant la taille des binaires de faire cela ?
non, la taille augmente mais les perfs aussi si le cpu supporte les extensions. si le cpu ne supporte pas les extensions les perfs sont les memes.
La sélection du code a exécuter se fait une fois (au démarrage de l'application) et pas a chaque fois qu'on a besoin d'un code particulier d'ou la non perte de perfs si y'a pas des extensions dispo.
en gros: le programme démarre, teste le cpu pour savoir ce qu'il supporte et se spécialise lui-meme (se réécrit) pour que les meilleurs parties de code pour ce cpu soient utilisées (je simplifie un peu mais c'est l'idée).
-
HP et Siemens/Fujitsu en ont vendu.
HP en vend toujours, c'est la seule archi encore vendue pour HPUX (rigolez pas on en installe encore sous 11iv3 chez quelques grands comptes français, souvent avec IVM).
-
Je connais encore 2 ou 3 Superdome encore en prod :)
-
La plupart des bases de données sérieuses.
Les BdD sérieuses consomment combien de RAM?
-
de quelques Go à plusieurs centaines de Go.
-
Il est possible d'avoir de grosses base de données sans consommer beaucoup de ram.
C'est la taille du cache, la complexité ds requêtes et le nombre de requêtes en // qui va déterminer la consommation mémoire de MySQL.
Pour Firefox, je suppose que si ils retirent la compatibilité avec les PC sans SSE2, c'est simplement pour limiter les tests à faire et que le parc de CPU sans SSE2 qui utilise Firefox est très faible (les derniers processeurs à ne pas intégrer le SSE2, c'est le Pentium III Tualatin à 1400 Mhz (Pentium III 1400S, sortie en janvier 2002)
-
Il est possible d'avoir de grosses base de données sans consommer beaucoup de ram.
Pas quand tu as du trafic. Sinon tu fais tomber ta machine sous les requètes.
Je crois que la plus grosse BDD qu'on aie en cache RAM doit faire 200-300Go (la BDD fait quelques To de mémoire, beaucoup d'ORM dedans)
Et on arrive à faire des chiffres pas dégueu grace en partie au cache : (https://pbs.twimg.com/media/Ctg1DpsWgAENL0F.jpg)
https://twitter.com/daevel_fr/status/781433305870766081
-
Il est possible d'avoir de grosses base de données sans consommer beaucoup de ram.
C'est la taille du cache, la complexité ds requêtes et le nombre de requêtes en // qui va déterminer la consommation mémoire de MySQL.
Pour les BDD Relationnelles & ACID (typiquement Oracle DB), il est généralement plus efficace de mettre le cache au niveau de la base de données qu'au niveau du filesystem, le moteur SGBD étant en général plus compétent pour gérer les blocs chauds.
J'ai rarement vu des bases de Prod Oracle conséquentes avec moins de 4 Go de SGA, donc 64 bits indispensable.
-
Pour Firefox, je suppose que si ils retirent la compatibilité avec les PC sans SSE2, c'est simplement pour limiter les tests à faire et que le parc de CPU sans SSE2 qui utilise Firefox est très faible (les derniers processeurs à ne pas intégrer le SSE2, c'est le Pentium III Tualatin à 1400 Mhz (Pentium III 1400S, sortie en janvier 2002)
Tu as encore oublié les AMD...
SSE2 est arrivé sur Athlon64 donc en 2003. Sur AthlonXP c'est donc uniquement SSE.
Bon on est d'accord y'a plus que les brouettes >13 ans à ne plus l'avoir.
-
(...)
Je crois que la plus grosse BDD qu'on aie en cache RAM doit faire 200-300Go (la BDD fait quelques To de mémoire, beaucoup d'ORM dedans)
Au boulot, la plus grosse base fat environ 15 To sur disque (la partie données uniquement, donc il y a en plus OS / binaires / journaux log) et la base Oracle associé a une SGA de 450 Go, le tout sur du power avec 512 Go de Ram.
C'est pour de l'ERP, et pas du "en mémoire" qui devrait à terme probablement remplacer ce qui tourne actuellement sur les unix power / superdome en base de données.
Sinon pour revenir à la question de base et comme dit par d'autres, l'espace d'adressage plat me semble le plus intéressant pour ne plus avoir de 32b à moins de besoin très spécifiques.