Quelles machines passeront à la trappe avec Lion ?, Réactions à la publication du 22/10/2010

[xpech]

Elle est 64bit ! même de manière plus souple que les autres (fat binary, kernel 32 lancant des appli 64bits ...)

Seules les applis sont à la traine.

Euh tu dis que Mac OS X est 64 bits, mais que le Noyau est 32bits en général et que la majorité des applications sont 32bits (incluant la nouvelle suite iLife'11). Je te lis bien???

Le noyau est mixte, tu choisis, et en plus ça ne te met pas de restriction sur les autres process, ça existe ailleurs ça ? Toutes les lib cocoa sont dispo en 64bits, quand je lance le moniteur d'activité j'ai 75% des process en 64 bits (107/142) ...
J'ai utilisé avec des linux 64bits, et c'est galère quand on a des process 32 bits, à compiler c'est une galère sans nom, il faut 2 arborescences de lib ... un bordel ... Sous Windows c'est pire avec un 64 bits différent des autres ... Sérieusement, que reprocher à OSX à ce niveau ? c'est souple (totalement transparent), propre (fat) ...

[iAPX]

Hahahaha trop drole, 75% des processus en 64bits!
Et combiern en 32bits, en pourcentage d'occupation CPU?

75% des process en 64bits, ça maximise l'occupation mémoire (les process 64bits occupant "naturellement" plus de place, entre autre à cause des pointeurs longs mais aussi des préfixes d'instructions).
En revanche ces 75% là ne représentent qu'environ 5% à 10% d'occupation processeur quand on utilise intensivement un iPhoto ou iMovie ou GarageBand...

On termine donc dans le meilleur des mondes 64bits: une occupation mémoire maximisée et une performance CPU minimisée!

[silverrrr]

Mon MacBook va pouvoir encore me servir de très bon Mac de secours. Il sera encore là et en forme pour Lion je suppose... C'est quand même plutôt raisonnable qu'une machine Apple puisse supporter 4 à 5 Os ultérieur.

Bref le Core 2 Duo à encore quelques années devant lui.

[Guest_LE geek_*]

Apple pourrait abandonner les processeurs Core duo, en justifiant le fait que Lion nécessite un processeur 64 bits.

Ca serait gonflé quand on voit qu'iLife 11 est en 32 bits ...

[powerdoc]

Je ne crois pas trop a cette news, qui n'est que pure conjecture.

[xpech]

Hahahaha trop drole, 75% des processus en 64bits!
Et combiern en 32bits, en pourcentage d'occupation CPU?

75% des process en 64bits, ça maximise l'occupation mémoire (les process 64bits occupant "naturellement" plus de place, entre autre à cause des pointeurs longs mais aussi des préfixes d'instructions).
En revanche ces 75% là ne représentent qu'environ 5% à 10% d'occupation processeur quand on utilise intensivement un iPhoto ou iMovie ou GarageBand...

On termine donc dans le meilleur des mondes 64bits: une occupation mémoire maximisée et une performance CPU minimisée!

C'est un jeu ?
Justement OS permet de mixer facilement, les 2 ce qui n'est pas le cas, maintenant, je ne vois pas en quoi tu évoques iLife pour parler de l'OS ?
Je vais repasser mon mysql en 8 bit ...

Pour l'occupation CPU, GCC et Mysql sont bien en 64bit ...

je te suis plus là ...

[LeFrettchen]

Mais la plateforme Mac OS X doit passer au 64bits un jour!

Pourquoi ?

Le 64 bits se justifie si les applis ont des instructions longues.
Pour ce qui est des grosses applis, à l'instar de Photoshop, ok, ça vaudra sûrement le coup.
Mais est-ce le cas de la plupart des applis ? "Ouais, super, j'ai un TextEdit 64 bits !" La classe, quoi

Si l'instruction est courte, le passage au 64 bits risque au contraire d'entrainer un ralentissement du système, ou tout du moins, n'apportera pas de gain notable lors de l'utilisation de l'application.
Une application qui utilise des instructions 32 bits par exemple utilisera le même nombre de cycles sur une architecture 32 ou 64 bits, non ?
A moins de pouvoir concaténer 2 instructions 32 bits dans une instruction 64 bits, mais ce n'est pas forcément possible pour toutes les applications.

Ce message a été modifié par LeFrettchen - 22 Oct 2010, 20:21.

[iAPX]

Hahahaha trop drole, 75% des processus en 64bits!
Et combiern en 32bits, en pourcentage d'occupation CPU?

75% des process en 64bits, ça maximise l'occupation mémoire (les process 64bits occupant "naturellement" plus de place, entre autre à cause des pointeurs longs mais aussi des préfixes d'instructions).
En revanche ces 75% là ne représentent qu'environ 5% à 10% d'occupation processeur quand on utilise intensivement un iPhoto ou iMovie ou GarageBand...

On termine donc dans le meilleur des mondes 64bits: une occupation mémoire maximisée et une performance CPU minimisée!

C'est un jeu ?
Justement OS permet de mixer facilement, les 2 ce qui n'est pas le cas, maintenant, je ne vois pas en quoi tu évoques iLife pour parler de l'OS ?
Je vais repasser mon mysql en 8 bit ...

Pour l'occupation CPU, GCC et Mysql sont bien en 64bit ...

je te suis plus là ...

Euh ... qui utilise tous les jours GCC et MySQL sur son Mac?
Les applications utilisées au jour le jour, incluses dans iLife'11, téléchargées comme FireFox, Chrome, OpenOffice, Pages, Number, etc
Elles sont 32bits pas 64bits. Et je te parle pas de la plupart des utilitaires de Mac OS X en 32bits!

Un environnement 64bits c'est une CPU 64bits (de préférence plus rapide en 64bits qu'en 32bits), un noyau 64bits, des utilitaires 64bits, des applications 64bits, une interface 64bits. Pas 5% de la CPU occupée avec du 64bits, et les 95% du travail effectués en 32bits!

[LeFrettchen]

Les applications utilisées au jour le jour, incluses dans iLife'11, téléchargées comme FireFox, Chrome, OpenOffice, Pages, Number, etc
Elles sont 32bits pas 64bits. Et je te parle pas de la plupart des utilitaires de Mac OS X en 32bits!

Si Apple continue à sortir des utilitaires 32 bits, on est pas près de voir un OS X 100% 64 bits alors
Et si Apple continue à sortir des 32 bits, c'est sans doute que passer en 64 bits n'apporterait rien de plus...

Un environnement 64bits c'est une CPU 64bits (de préférence plus rapide en 64bits qu'en 32bits), un noyau 64bits, des utilitaires 64bits, des applications 64bits, une interface 64bits. Pas 5% de la CPU occupée avec du 64bits, et les 95% du travail effectués en 32bits!

Bin oui, des applications 64 bits, c'est bien là le souci : Il ne faut QUE des applis 64 bits !

[Alizés]

La question est peut-être idiote, mais je n'y connais pas grand chose. Une application 32bits qu'on fait tourner sur un système 64bits, elle va tourner plus vite, moins vite ou tourner exactement à l'identique comparer à la même application tournant sur un système 32bits? Y perdrait-on quelque chose à avoir un système 64bits alors que la majorité des applications sont toujours en 32bits?
Si oui, je comprendrais votre soucis, mais si non, alors en quoi ce serait un problème d'avoir un système un peu en avance sur les applis? C'est mieux que le contraire de toutes façons... On ne peut pas passer en 64bits des applis alors que le système est encore en 32bits? Donc c'est presque dans la logique des choses, non? Il faut faire migrer le système avant les applis... Je me trompe?
En fait je ne saisi pas bien toutes ces palabres? Il est où le problème? Les applis suivront maintenant que le système est passé e 64bits... C'est la procédure normale... Qu'est-ce qui vous gène là-dedans? Laissez donc le temps aux développeurs de revoir leurs applis.

Ce message a été modifié par Alizés - 22 Oct 2010, 21:42.

[xpech]

Euh ... qui utilise tous les jours GCC et MySQL sur son Mac?
Les applications utilisées au jour le jour, incluses dans iLife'11, téléchargées comme FireFox, Chrome, OpenOffice, Pages, Number, etc
Elles sont 32bits pas 64bits. Et je te parle pas de la plupart des utilitaires de Mac OS X en 32bits!

Un environnement 64bits c'est une CPU 64bits (de préférence plus rapide en 64bits qu'en 32bits), un noyau 64bits, des utilitaires 64bits, des applications 64bits, une interface 64bits. Pas 5% de la CPU occupée avec du 64bits, et les 95% du travail effectués en 32bits!

Ce n'est pas à priori un problème de l'OS, mais des dev qui soit n'ont pas fait l'effort, soit n'en voient pas l'intérêt. Je te suis sans problème sur le fait qu'Apple devrait montrer l'exemple sur iWork et iLife. Maintenant il est difficile de connaitre les motivations des équipes de dev (accent sur d'autre techno - GC - OCL - , bouts de carbon, compatibilité avec 10.5 ...), quioqu'il en soit la plupart des éditeurs sont sur un marché tendu qui rend les investissements difficiles. Ce n'est pas le même flux de $$ que les ssii.

Pour FireFox, Chrome, OpenOffice ... les projets opensource n'attendent que des compétences comme les tiennes ...

L'interface est 64bits (WindowServer & SystemUiServer).

Maintenant, il faut toujours une période de transition et il me semble qu'Apple est pas mal à ce niveau. Ils ont gardé une seule version d'OS avec une bonne compatibilité.

[iAPX]

Alizés, le système permet de lancer des applications 64bits depuis 5 ans, et on voit où on en est: les utilitaires sont en 32 bits, les applications fournies avec les Mac (iLife) sont 32bits, les drivers sont 32bits (LIMITANT la mémoire maxi utilisable à l'avenir aux limites du PAE 32bits du Pentium Pro de 1995), les applications comme Firefox ou Chrome sont 32bits.

Il y a un gain bien visible de 10% à 30% de performances en 64bits. Tu t'en convaincrais facilement en lançant GeekBench 64bits et GeekBench 32bits sur le même Mac, tu apprendrais que tu pourrais avoir gratos le modèle au-dessus pour le prix du tien!
Pour toi c'est peut-être accessoire, mais beaucoup ici seraient prêt à passer de la performance d'un Core2 Duo 2.4Ghz à un 2.8Ghz, ou d'un Mac Pro 4x2.66 à un 4x3.0, sans débourser un centime!

Il existe des Mac multi-core depuis 10ans maintenant, il n'empêche qu'il y a encore une large majorité d'application principalement mono-threadées. Et ça paraît!
Une des conséquences directe est que l'iMac le plus rapide pour MacWorld est un dual-core (core i5 2x3.6Ghz) devant les iMac Quad-Core 4x2.93Ghz et le Mac Pro Quad-Core nehalem 4x2.66Ghz! Ridicule!

Alors quand je lis "Laissez donc le temps ...", tu en penses quoi? Le 64bits pour 2020 tu veux? 2030? et en attendant être bien bien serré dans les applications existantes et leur limites?

Les application se trainent, elle sous-emploient, pour la plupart nos Mac, y compris les applications professionnelles (en Photo je vous conseille de lire MacPerformanceGuide.com ), et au final on a des fois des Mac qui vont 3 fois moins vite que ce qu'ils devraient!
Comme le Mac Pro 6x3.33Ghz qui ne va pas plus vite que l'iMac 2x3.6Ghz sous Photoshop CS5 (MacWorld SpeedMark 6.5)

Tu peux peut-être te payer la machine la plus puissante qui existe et attendre, mais je pense que beaucoup ne le peuvent pas et souhaiterais que leur Mac aille bien plus vite. Certains se saignent pour un iMac Core i5 voir un Mac Pro, dont finalement ils ne tirent que des performances réelles faiblaes face au prix payé! Est-ce juste?

Ce message a été modifié par iAPX - 22 Oct 2010, 22:30.

[Jean-Jacques Cor...]

À mon humble avis, les machines qui ne peuvent pas démarrer en mode 64 bits aujourd'hui, passeront à la trappe lors de la sortie de Lion. D'autant plus vrai que les portables qui ne peuvent pas démarrer en mode 64 bits sont les mêmes qui ne disposent pas du trackpad multi-points.
Mon MacBook Pro Santa Rosa acheté en décembre 2007 sera donc dans la charrette.

[Alizés]

... (désolée, message effacé)

Ce message a été modifié par Alizés - 22 Oct 2010, 23:57.

[divoli]

Edit: Bon ben j'efface aussi, alors.

Ce message a été modifié par divoli - 22 Oct 2010, 23:58.

[magic_d]

Personnellement, ces histoires de 64 bits contre 32, je n'ai pas encore eu l'occasion d'en ressentir vraiment la différence. Je parle, bien sûr, pour un usage assez standard (pas pousser les process à fond).
Je suis passé d'une GROSSE tour G5 (le bloc d'alim a presque explosé, en flinguant la carte mère au passage) à un Mac Mini. Et j'en suis ravi !!! Même pour un usage pro (graphiste simplement), cette machine me semble suffisante. C'est pas une bombe mais largement aussi performante (si ce n'est plus, mais c'est subjectif) que mon gros G5.

Et pour en revenir au sujet, au vu de la petite présentation du prématuré Lion, je ne vais même pas me demander pour l'instant si mon Mac Mini pourra tourner sous cette nouvelle version. Et c'est encore largement trop tôt pour en décider de toute façon.
Tout le monde semble s'exciter avec cette histoire, alors que l'on vient à peine de voir tourner 3 pauvres petits gadgets.
De là, en plus, à se demander si ces maigres nouveautés tourneront en 32 ou en 64 bits... Désolé mais... il y a probablement plus agréable à faire non ?

OK, de toute façon je sortais...

[iAPX]

Ben voilà où mon argumentaire touche les gens qui comme toi se foutent des spécificité techniques...
Tu es content de ton Mac Mini 2x2Ghz, et tu aurais été aussi content avec les mêmes performances avec le modèle 2x1.83Ghz, si les applications étaient soit 64bit soit multi-threadés. Et avec les deux, un MacBook Air 2x1.4Ghz irait plus vite que ton Mac Mini actuel! Voilà!

Ça te permettrais, et ça nous permettrais à tous, de dépenser moins en (cher) matériel, de changer de Mac moins souvent, bref de garder du budget pour ce qui est plus utile. La famille, les loisirs, etc.

PS: C'est peut-être JUSTEMENT pour ça qu'Apple n'optimise pas ses applications grand-public, les utilitaires d'OS X, etc.!!!

Ce message a été modifié par iAPX - 23 Oct 2010, 01:52.

[Jean-Jacques Cor...]

Et si tout le système et tous les programmes étaient directement écrits en assembleur optimisé, et non dans ces bouses de langages C, C++ et Objective-C avec leurs bibliothèques chargées systématiquement en entier, même si n'a besoin que de quelques unes des fonctions incluses dedans, on pourrait faire tourner Mac OS X sur des machines bien moins puissantes, et donc bien moins chères.

[PSYCHOMOTEL]

Comme d'habitude, Apple n'y va pas par le dos de la cuillère et cela va encore faire mal au porte monnaie des mac addicts: A la fin, Apple va commencer par fatiguer et taper sur le système de certains qui n'auront plus les moyens de suivre financièrement au gré à gré des envies d'humeur de changement de la pomme.

[azulseco]

Bof bof !

Il est normal qu'une société sorte des Os nouveaux et prévoit une obsolescence de fait pour des machines qui ont 4 ans, ça permet de faire face à la concurrence.
Mais, j'en voit ici qui ont des Titaniums et qui ont l'air très heureux. Quand à moi, mon MB coreduo va bien fonctionner avec Léopard encore 2 ou 3 ans : 7 ans de bons et loyaux services, pour un portable, c'est bien non ?
D'ici là, on sera passé à Black Panther ou à Chat Perché. On avisera à se moment là.

[jccochez]

Et si tout le système et tous les programmes étaient directement écrits en assembleur optimisé, et non dans ces bouses de langages C, C++ et Objective-C avec leurs bibliothèques chargées systématiquement en entier, même si n'a besoin que de quelques unes des fonctions incluses dedans, on pourrait faire tourner Mac OS X sur des machines bien moins puissantes, et donc bien moins chères.

Et si tout le système et tous les programmes étaient directement écrits en assembleur optimisé, on prendrait seulement 30 ans pour sortir une application

En plus, je pense un bon compilo fait souvent aussi bien qu'une optimisation manuelle...

[edm]

Bof bof !

Il est normal qu'une société sorte des Os nouveaux et prévoit une obsolescence de fait pour des machines qui ont 4 ans, ça permet de faire face à la concurrence.
Mais, j'en voit ici qui ont des Titaniums et qui ont l'air très heureux. Quand à moi, mon MB coreduo va bien fonctionner avec Léopard encore 2 ou 3 ans : 7 ans de bons et loyaux services, pour un portable, c'est bien non ?
D'ici là, on sera passé à Black Panther ou à Chat Perché. On avisera à se moment là.

Puis ce sera chat botté !

[alcibiade]

Léopard sur un titanium véloce??? ça m'intéresse de savoir comment tu fais Alcibiade...

Il tourne bien sur le Titanium 867 de ma mère, je ne vois pas ou est le problème ... Ram au max, un Western Digital récent et pas de soucis

C'est d'un Titanium 667MHz donc il s'agit. Ce n'est pas tout à fait la même chose.

Houlà, ne me fais pas dire ce que je n'ai pas écrit...

Pour rappel :

Pour exemple, Léopard tourne comme un charme sur mon Titanium (G4 667MHz de 2001) alors qu'il n'est pas sensé être supporté par la machine. C'est la seule version de l'OS à ne pas déclencher les ventilos alors que le portable n'est qu'allumé, sans rien faire d'autre. L'occupation processeur système est bien moindre et la réactivité de la machine meilleure qu'avec n'importe laquelle des versions précédentes.

Si tu veux un Titanium "Véloce", passe le sous OS 9.

Ce que je dis, c'est qu'un système non supporté tourne très bien sur cette machine. C'est a dire sans bugs ni plantages, avec toutes ses fonctionnalités (sauf les éléments cosmétiques désactivés automatiquement par le système parce que la carte graphique n'est pas capable de les encaisser (une Radéon mobility 16 Mo...)

Ce n'est pas d'une rapidité transcendantale mais ça tourne, et oui (mais c'est subjectif) j'ai bien eu l'impression qu'il tourne mieux sous Léopard que sous OS X.4.
MAIS, OS X en général reste trop lourd pour ce type de machine, bien qu'il se soit vraiment amélioré d'une version à l'autre.

Sous X.1 l'ordi ne pouvait faire tourner que le système en mode sèche cheveux hystérique. Il a fallu attendre les . 3 et .4 pour que cela aille mieux.

Il est toujours en activité chez moi, dans le salon (9 ans plus tard ) et me sert de modeste média center.

Il est tout à fait capable de lire les Avi et de les afficher sur la TV que ce soit en recopie ou en bureau étendu. (pas de la HD, Oeuf Corse)
Il gère très bien la musique centralisée sur l'iMac du bureau via iTunes.
Safari et Word tournent aussi dessus sans problème. (Mais bon, c'est pas "fulgurant" non plus, on parle d'un Proc à 667 MHz , mais ça marche )

Pour ces utilisations là, prévoir cependant le casque anti bruit. (surtout pour la vidéo. pour la Zic, ça vas)

Le Finder tourne nickel avec toutes ses options.
La gestion à distance par VNC via iPhone, portables ou iMac tourne super bien.

Il est HYPER Véloce (là oui pour le coup) avec Transmission.

En fait, mon modèle est un 667 "Onyx" dit "Gigabit", c'était le premier à possèder un Ethernet base 1000. Et franchement, pour tout ce qui touche au réseau, cette antiquité dépote vraiment pas mal sous Léopard et en restant discrète.

Ce qui m'amène donc à :

Léopard tourne comme un charme sur mon Titanium (G4 667MHz de 2001) alors qu'il n'est pas sensé être supporté par la machine.

Là tu m'intéresses... J'ai justement un Tinamium identique au tien à reformater pour une amie en ce moment. Tu es certain que Léopard tourne dessus? Mieux que Tiger?
Et côté RAM, tu en as combien? Tu arrives à t'en sortir entre le système et les applications?

Je l'ai monté à 1Go de Ram, j'ai réinstallé dessus le disque Apple d'origine (30 Go). Le samsung (Cf la mythique "Bidouille Gotchi") ayant rendu l'âme.
Un disque plus rapide est un plus indiscutable et indispensable, mais le problème aujourd'hui est de trouver du PATA, 2,5" de moins de 120 Go. Attention, la machine ne gère pas plus.

Lionel avait fait une News sur le sujet, le principe de l'install est "simple" à condition d'avoir Carbon Copy Cloner (facile ) et un Mac PPC supporté (N'importe lequel fait l'affaire G4 ou G5, mais faut en avoir un, cela ne marchera pas avec un Intel pour des raisons de format de partition Disque Dur)

Au passage on notera que c'est couillon, because Léopard PPC boote très bien sur Intel : tout le système est "Universal Binary".
(Génial pour un "rescue disk" externe , Sérieusement, sur ce coup là ils ont assurés chez Apple )

3 façons de procéder :
- Tu clones le disque ou la partoche bootable d'un PPC supporté avec Léopard directement sur le disque du Titanium.
- Tu installes un nouveau système pour ta copine sur un disque externe à partir du PPC supporté, puis tu clones ce disque externe sur le disque du Titanium.
- Tu montes le Titanium en mode Target sur l'autre mac PPC et tu lances l'install de Léopard sur le disque du Titanium qui apparaît comme un périf Firewire (à vérifier, j'ai un doute, je me demande si le clonage n'est pas en fait obligatoire... j'ai fais la manip à la sortie de Léopard, cela remonte un peu... mais essayes, au pire tu ne risques rien ).

Enjoy.


A l'usage, faut l'utiliser un peu en monotache et l'éteindre régulièrement, mais il est assez surprenant de voir que Léopard s'en sort pas mal du tout en sous capacité de mémoire. Le swap n'est pas si important que cela.
(mais bon si tu lances Toshpop, mail, iTunes et un DL BT en même temps, il ne vas pas planter, ça Ok, il va faire le boulot ... leeeeenteeeemeeeeent ET il va surtout te traiter d'abominable esclavagiste via son petit mono-ventilateur, petit mais ... costaud )

[LeFrettchen]

Et si tout le système et tous les programmes étaient directement écrits en assembleur optimisé, et non dans ces bouses de langages C, C++ et Objective-C avec leurs bibliothèques chargées systématiquement en entier, même si n'a besoin que de quelques unes des fonctions incluses dedans, on pourrait faire tourner Mac OS X sur des machines bien moins puissantes, et donc bien moins chères.

Et si tout le système et tous les programmes étaient directement écrits en assembleur optimisé, on prendrait seulement 30 ans pour sortir une application

En plus, je pense un bon compilo fait souvent aussi bien qu'une optimisation manuelle...

Et encore, tu es gentil quand tu dis 30 ans : c'est le temps nécessaire pour développer une application ultra-basique en assembleur...
Mais pour créer un bon gros monstre (genre la suite CS...) en assembleur, compte plutôt 50 ans !
Ce qui donnerait : 2060, Adobe annonce la nouvelle CS 6, trop d'la balle !

Quant aux bibliothèques, elles ne sont pas chargées systématiquement en entier, loin de là...
Même avec un langage plus simple (comme Pascal), les bibliothèques ne sont pas forcément chargées en entier !

Et en ce qui concerne OS X, au vu des messages précédemment postés, il est visiblement possible de faire tourner Leopard sur un Titanium 667MHz...
Je vois pas ce qu'il te faut de plus, un Titanium 667MHz, c'est pas forcément la machine la plus puissante, ni la plus chère, hein

La question est peut-être idiote, mais je n'y connais pas grand chose. Une application 32bits qu'on fait tourner sur un système 64bits, elle va tourner plus vite, moins vite ou tourner exactement à l'identique comparer à la même application tournant sur un système 32bits? Y perdrait-on quelque chose à avoir un système 64bits alors que la majorité des applications sont toujours en 32bits?

Mais oui, faire tourner en 64 bits une application 32 bits ne permet pas de gagner du temps, au contraire.

Si ton appli utilise des instructions 32 bits :

• soit il est possible de coller deux instructions à la suite pour faire du pseudo-64 bits, mais le système doit dé-coller les instructions avant de les traiter, et donc perte de temps,
• soit tu ne peux pas coller les instructions, et il te faut une instruction 64 bits pour ne passer que 32 bits d'instruction. Là aussi, perte de temps pour le système, qui doit gérer une instruction longue (avec donc un adressage long, et plus pesant) plutôt qu'une instruction courte (plus légère).

Il y a un gain bien visible de 10% à 30% de performances en 64bits.

Les application se trainent, elle sous-emploient, pour la plupart nos Mac, y compris les applications professionnelles

Gain de vitesse uniquement sur quelques applications : les plus gourmandes, les plus pointues...

Mais si tu espères gagner du temps avec un Word 64 bits par rapport à un Word 32 bits, c'est raté.
Un Word 32 bits est largement suffisant, le 64 bits n'apporterait aucun gain de rapidité.

D'ailleurs, Apple comme d'autres (Microsoft par exemple) a bien compris cela, et de plus en plus, les logiciels se basent sur l'ergonomie et non plus sur la vitesse.
Aujourd'hui, pour rendre un logiciel plus rapide, mieux vaut bien le débugguer, et optimiser son code, plutôt que de le faire passer en 64 bits.
Comme tu le dis si bien Alizés, il faut laisser le temps aux développeurs : pourquoi forcer ces derniers à passer au 64 bits ?
La tendance matérielle étant à la multiplication des coeurs, mieux vaut axer son développement sur du multi-threading 32 bits plutôt que sur du mono 64.
Alors le 64 bits pour 2020 ou 2030, oui, je vois pas où est le souci.

Enfin, pour se convaincre de l'inutilité du 64 bits, suffit de comparer les consoles de jeux.
La Playstation de première génération (32 bits) est bien plus rapide que la Nintendo 64 (64 bits donc)...
Et la dernière née de Microsoft, la XBox 360 (64 bits), est capable de rivaliser facilement avec la PS3 de Sony (128 bits).

Ce message a été modifié par LeFrettchen - 23 Oct 2010, 16:47.

[iAPX]

Mais si pour Word aussi tu gagnerais en performance, probablement au moins 10%.

En effet, les processeurs qui exécutent le jeu d'instruction 64bits disposent du double de registres interne en 64bits par rapport au mode 32bits (et aux processeurs limités en 32bits), outre qu'ils soient 2 fois plus importants (32bit -> 64bit).
Ces registres en nombre plus important permettent d'éviter des écriture temporaire dans les caches L1, L2, L3 puis la mémoire, en même temps qu'ils permettent d'avoir moins de dépendances inter-instructions, autorisant plus de parallélisme interne dans les processeur moderne out-of-order.

A la fin, ce qu'il reste c'est qu'en moyenne, on gagne 10% à 30% de performance à passer du 32bits au 64bits sur les processeurs existant, qu'elle que soit l'application. Voilà tout. Et ça n'a rien à voir avec la mémoire, l'occupation mémoire ou la taille des données traitées!

Une remarque sur le multi-threading versus 64bits, l'un n'exclut pas l,autre, mais il est très facile de passer un utilitaire correctement écrit en 64bits, ou une application entière, plus compliqué si elle est mal écrite (mais ça c'est un autre débat). Et sur du bon code, c'est facilement un ordre de magnitude plus simple de passer au 64bits que de passer au multi-threading!

Et moi, si mon Mac va 10% à 30% plus vite gratuitement, soit aussi vite qu'un MacBook Pro Core i7 2.66Ghz (j'ai un vieux Core2 Duo 2.8Ghz), ça me plairait, ça serait un upgrade gratuit, ou si on prend leur date de sortie, 12mois d'usage gagné!

PS: Je ne rentrerais pas dans les détails de ton argumentaire. Je préfère pas!

Ce message a été modifié par iAPX - 23 Oct 2010, 17:09.

[Kalm]

PS: C'est peut-être JUSTEMENT pour ça qu'Apple n'optimise pas ses applications grand-public, les utilitaires d'OS X, etc.!!!

Tu peux en être certains.

[vladimok]

Bonjour,

Et sur un 2 core duo de fin 2007, il tournera ou pas ??????

Merci

[jccochez]

Bonjour,

Et sur un 2 core duo de fin 2007, il tournera ou pas ??????

Merci

Tout dépend...

Est ce que tu peux démarrer en kernel 64 sur snow leo?

Parce que, si le proco est compatible avec le 64 bits, il y a une vieille limitation d'apple au niveau du Kernel...

[debians]

Et si tout le système et tous les programmes étaient directement écrits en assembleur optimisé, et non dans ces bouses de langages C, C++ et Objective-C avec leurs bibliothèques chargées systématiquement en entier, même si n'a besoin que de quelques unes des fonctions incluses dedans, on pourrait faire tourner Mac OS X sur des machines bien moins puissantes, et donc bien moins chères.

Et si tout le système et tous les programmes étaient directement écrits en assembleur optimisé, on prendrait seulement 30 ans pour sortir une application

En plus, je pense un bon compilo fait souvent aussi bien qu'une optimisation manuelle...

Et encore, tu es gentil quand tu dis 30 ans : c'est le temps nécessaire pour développer une application ultra-basique en assembleur...
Mais pour créer un bon gros monstre (genre la suite CS...) en assembleur, compte plutôt 50 ans !
Ce qui donnerait : 2060, Adobe annonce la nouvelle CS 6, trop d'la balle !

Quant aux bibliothèques, elles ne sont pas chargées systématiquement en entier, loin de là...
Même avec un langage plus simple (comme Pascal), les bibliothèques ne sont pas forcément chargées en entier !

Et en ce qui concerne OS X, au vu des messages précédemment postés, il est visiblement possible de faire tourner Leopard sur un Titanium 667MHz...
Je vois pas ce qu'il te faut de plus, un Titanium 667MHz, c'est pas forcément la machine la plus puissante, ni la plus chère, hein

La question est peut-être idiote, mais je n'y connais pas grand chose. Une application 32bits qu'on fait tourner sur un système 64bits, elle va tourner plus vite, moins vite ou tourner exactement à l'identique comparer à la même application tournant sur un système 32bits? Y perdrait-on quelque chose à avoir un système 64bits alors que la majorité des applications sont toujours en 32bits?

Mais oui, faire tourner en 64 bits une application 32 bits ne permet pas de gagner du temps, au contraire.

Si ton appli utilise des instructions 32 bits :

• soit il est possible de coller deux instructions à la suite pour faire du pseudo-64 bits, mais le système doit dé-coller les instructions avant de les traiter, et donc perte de temps,
• soit tu ne peux pas coller les instructions, et il te faut une instruction 64 bits pour ne passer que 32 bits d'instruction. Là aussi, perte de temps pour le système, qui doit gérer une instruction longue (avec donc un adressage long, et plus pesant) plutôt qu'une instruction courte (plus légère).

Il y a un gain bien visible de 10% à 30% de performances en 64bits.

Les application se trainent, elle sous-emploient, pour la plupart nos Mac, y compris les applications professionnelles

Gain de vitesse uniquement sur quelques applications : les plus gourmandes, les plus pointues...

Mais si tu espères gagner du temps avec un Word 64 bits par rapport à un Word 32 bits, c'est raté.
Un Word 32 bits est largement suffisant, le 64 bits n'apporterait aucun gain de rapidité.

La Playstation de première génération (32 bits) est bien plus rapide que la Nintendo 64 (64 bits donc)...
Et la dernière née de Microsoft, la XBox 360 (64 bits), est capable de rivaliser facilement avec la PS3 de Sony (128 bits).

Ouvre un VRAI document Word, plusieurs centaines de pages, avec éventuellement quelques macros et tu verras si ça ne peut pas supporter un gain en vitesse.

Quant à comparer des hardwares totalement différents, ça n'a rien à voir encore une fois.

ET la Nintendo 64 EST plus puissante que la Playstation.
Elle a été très mal exploitée, mais au niveau puissante brute, il n'y avait pas photo.

Et non la XBOX 360 ne rivalise pas "facilement" avec la PS3...
Encore une fois deux architectures différentes :

Tu mets en avant la différence en nombre de bits.
Je vais te mettre en avance que la XBOX a 3 COEURS alors que la PS3 n'a qu'un seul coeur, avec un tas de DSP.
Au niveau puissance de calcul brute :
Sur des calculs entiers, la XBOX met un facteur 2 à la PS3.
Sur des calculs à virgule flottante, c'est la PS3 qui met un facteur 2 à la XBOX. (En utilisant les DSP...)

Sans les DSP, la PS3 se ferait exploser, et ça n'a strictement rien à voir avec le nombre de bits, mais c'est tout simplement dû au surnombre de coeurs.

En outre, la XBOX a une bande passante mémoire presque 5 fois plus grande que la PS3.

Bref, à CONFIGURATION égale, le 64 bits est loin d'être une idiotie, et même en émulation 32 bits, ça fonctionne parfaitement, ça peut même dans certains cas être plus rapide qu'en 32 bits natif!

Ce message a été modifié par debians - 24 Oct 2010, 18:15.

[MacNiaque]

Et si tout le système et tous les programmes étaient directement écrits en assembleur optimisé, et non dans ces bouses de langages C, C++ et Objective-C avec leurs bibliothèques chargées systématiquement en entier, même si n'a besoin que de quelques unes des fonctions incluses dedans, on pourrait faire tourner Mac OS X sur des machines bien moins puissantes, et donc bien moins chères.

Et si tout le système et tous les programmes étaient directement écrits en assembleur optimisé, on prendrait seulement 30 ans pour sortir une application

En plus, je pense un bon compilo fait souvent aussi bien qu'une optimisation manuelle...

Et encore, tu es gentil quand tu dis 30 ans : c'est le temps nécessaire pour développer une application ultra-basique en assembleur...
Mais pour créer un bon gros monstre (genre la suite CS...) en assembleur, compte plutôt 50 ans !
Ce qui donnerait : 2060, Adobe annonce la nouvelle CS 6, trop d'la balle !

Faut pas abuser. Coder en assembleur ne prend pas réellement plus de temps que coder en C (et ce malgrès que l'assembleur x86 soit une bouse immonde). Seulement c'est beaucoup plus difficile à maintenir ensuite et le code est quasi non réutilisable.

Le vrai problème c'est qu'aujourd'hui les processeurs sont devenus tellement complexes avec leur jeux d'instructions supplémentaires que le temps des 68k et des 486 est bien fini et qu'un compilateur comme gcc est capable d'optimiser du code bien mieux que s'il avait été développé en assembleur. A condition par contre qu'il soit développé dans un langage quand même d'assez bas niveau et surtout proche de la machine (C, Pascal...).

Quant aux bibliothèques, elles ne sont pas chargées systématiquement en entier, loin de là...
Même avec un langage plus simple (comme Pascal), les bibliothèques ne sont pas forcément chargées en entier !

En fait, ça c'est géré par l'OS. MacOS 9 chargé systématiquement toutes les bibliothèque au démarrage de la machine (d'où ses temps de démarrage extrèmement longs). Sous les Unix, seul le nécessaire est chargé en temps réel, les bibliothèques dynamiques ne sont jamais chargés dans leur intégralité. Quand au bibliothèques statiques, le compilateur ne met que ce dont il a besoin, les fonctions inutilisés ne sont pas incluses.

ET la Nintendo 64 EST plus puissante que la Playstation.
Elle a été très mal exploitée, mais au niveau puissante brute, il n'y avait pas photo.

Je ne pense pas qu'elle a été mal exploitée; elle est beaucoup plus puissante que la play et la saturn en terme de puissance brute et écrase ces dernière encore plus en terme de 3D.
Il n'y a qu'à voir les jeux de Rare, que ce soit Conkers ou Perfect Dark et même Turok III qui lors de sa sortie était vraiment bluffant alors qu'à l'époque on parlais de la Dreamcast et de la PS2.
Et si tu n'y crois pas, regarde Mission Impossible qui a été développé pour la N64 et ensuite porté sur Play du fait de son succès : c'est injouable tant il y a de fog et les textures on vu leur résolution baisser énormément rendant le jeu affreux.
Mais le processeur n'est pas ce qui fait le plus la différence sur une console, la N64 avait pour elle avant tout son processeur 3D de SG avec le fameux micro-code ainsi que son support de stockage.