Des fuites opportunes sur Windows 8, Réactions à la publication du 01/07/2010

[Lionel]

Des fuites sur Windows 8 tombent à point nommé. On y apprend quelques nouveautés sur la prochaines version majeure de l'OS de Microsoft parmi lesquelles on trouve:

• Un système optimisant la vitesse de démarrage des PC qui serait quasiment instantané.
  
• Optimisations poussées de l'OS afin qu'il soit aussi réactif que possible
  
• L'immense majorité des ordinateurs ayant une Webcam, il y aura un système de reconnaissance faciale.

Ces informations pour un système prévu pour dans un an tombent à point. Elles montrent que Microsoft travaille à améliorer ce que les utilisateurs peuvent reprocher à Windows 7 mais aussi, alors que Mac OS X présente une croissance insolente que MS sait aussi innover.
On attend avec impatience la réponse d'Apple à la montée en puissance de windows. Il va bien falloir qu'ils relancent la machine à innover d'OS X que l'on peut considérer en panne depuis un moment. 
PS: En mode ironique, Windows 8,  tout comme Windows 7 depuis un moment, supporterai le TRIM.
Par Lionel

[Orikawa]

Lionel,

Peut être faudrait-il réviser un peu. J'ai pris le temps d'écrire ça :

Open CL est inutilisable pour une simple et bonne raison. Il ne fonctionne pratiquement pas sur les Radeon. Donc aucun dev n'a envie de faire un soft qui ramera sur une bonne partie des mac récents.

C'est quoi la preuve ou la raison de cela. Je ne suis pas devant mon iMac 27 pouces. Si tu as une machine avec des cartes Radeons récentes, peux-tu télécharger ce projet du site d'Apple :

https://developer.apple.com/mac/library/sam...tion/Intro.html

C'est un exemple de projet qui calcule un problème à N corps en utilisant OpenCL pour accélérer le calcul sur GPU. Est ce que tu peux l'essayer sur ton Mac si tu as Xcode? Le programme se lance en plein écran et le bouton d'interface sur le coté droit permet de basculer entre différents modes qui définissent le hardware sur lequel les kernels tournent, CPU-scalar, CPU-vector, multi CPU-vector et GPU. Pour quitter le programme, l'habituel pomme+q.

Est ce que cela "rame" sur le GPU?

J'essaierai de mon côté ce soir!

Grand central apporte un petit plus aux devs pour la gestion multi CPU c'est vrai, mais bon comme le GPU est aux abonnés absents...

Quel rapport avec le GPU puisque Grand Central est pensé pour programmer un processeur multi-core ou non d'ailleurs avec un modèle qui n'est pas nécessairement cantonné au modèle de parallélisme des données des GPUs. Grand Central permet de développer avec un modèle de parallélisme de taches qui n'est pas adapté au GPU, puisque de toute manière les GPU sont conçus par essence pour traiter des masses de données en parallèle. Grand Central justement permet de faire de parallélisme de données sur le CPU mais surtout de faire également du parallélisme de taches. Si un développeur veut faire du parallélisme de données, il pourra directement utiliser OpenCL et baser son code sur des kernels qui seront de toute manière exécutés en parallèle par le runtime d'OpenCL. Pas besoin de GCD dans ce cas.

Si par contre un développeur veut faire du parallélisme de taches, c'est à dire exécuter plusieurs taches de manière concurrente soit en multicores ou sur un seul core comme sur iPhone car IOS 4 supporte Grand Central, il devra utiliser Grand Central et son modèle de queue et de blocks qui permet vraiment d'écrire du code concurrent sans avoir à penser en terme de threads et de leur management. Grand Central permet de définir des taches qui seront automatiquement exécutés par Grand Central suivant un modèle de queue. Le développeur n'a même pas à savoir combien de cores sont disponibles sur la machine, Grand Central se charge de créer les threads au plus bas niveau en fonction des ressources de la machine. Donc si un développeur veut que son application soit plus réactive, et qu'une tache ne bloque pas toute l'application, GCD permet d'implémenter cela avec vraiment peu d'effort. Plus besoin de penser en terme de threads, le système se charge de cela.

GCD n'a pas de sens d'exister sur le GPU, puisque il n'est pas exclusivement conçu pour le type de taches qu'un GPU effectue. Pour cela, OpenCL existe.

On notera qu'il est également possible d'écrire du code qui fait du parallélisme de données à destination du CPU avec OpenCL. C'est notamment intéressant puisque OpenCL supporte les vecteurs de données et qu'il est donc possible de tirer parti des unités vectorielles des CPUs, en plus du multi-core tout en étant multi-plateforme. Sur Mac OS X, OpenCL s'appuie sur GCD pour le multi-core sur CPU.

Je crois que tu ne comprends pas bien ce que GCD et OpenCL sont réellement.

Le 64 bit c'est vrai que c'est bien, pour un petite frange de pro qui ont acheté la CS5 essentiellement. Et en plus, je rappelle que les extensions sont chargées en mode 32 par défaut. Donc le seul avantage, c'est de dépasser les 999 Mo de ram par application.

C'est vrai qu'en terme de gain en terme de mémoire adressable, le 64 bits n'est pas utilisé par toutes les personnes. Avoir à adresser plus de 4 GB de mémoire sur un seul thread n'est pas quelque chose dont tout le monde a vraiment besoin. Mais ne pas être limité par la quantité de mémoire adressable n'est pas seulement bénéfique à la CS5, c'est vraiment et réducteur et un peu surréaliste d'un site de la part d'un site Mac de dire cela. Puisque les applications scientifiques en bénéficient, les applis de création 3D, de création vidéo, de création audio, de création photos, bref un large panel d'utilisation et beaucoup de personnes concernées. Apple vend également des machines à des pros.......et je rappelle qu'Apple une seule version de son OS qui doit répondre à tous les besoins.

De plus on notera d'autres gains très important avec le 64 bits:

- D'abord le kernel bootant en 64 bits sur les Mac Pros/Xserves a plusieurs avantages:
- Un plus grand espace mémoire permet au kernel de garder d'avantage de données en mémoire améliorant considérablement les performances sur des applis manipulant beaucoup de données. Le kernel est également plus efficace. Il faut 64 octets pour décrire une page de 4 Ko, ce qui veut dire qu'il faut 1.5 Go de mémoire virtuelle pour décrire 96 Go de mémoire RAM. 1.5 Go sont donc utilisés par l'espace mémoire du kernel pour représenter les 96 Go de mémoire RAM, ce qui peut conduire à atteindre une limite puisque le kernel doit également stocker d'autres données. En d'autres termes, le kernel 32 bits n'a plus d'espace adresses suffisant. Le kernel 64 bits permet de s'affranchir de cette limite.

- Les appels systèmes sont plus rapides. 250% plus rapide que le kernel 32 bits.

- Les copies de mémoire de l'espace utilisateur vers l'espace kernel sont 70% plus rapide que le kernel 32 bits.

- Avec le kernel 32 bits, le nombre total de processus que le système peut gérer était de 2500 processus quel que soit la mémoire disponible. Avec le kernel 64 bits, la limite est dynamique avec la mémoire disponible.

- Les applications 64 bits ont accès à deux fois plus de registres que les applications 32 bits sur processeurs X86, 16 contre 8. Cela avantage toutes les applications qui font des taches intensives, et cela peut être un simple encodeur H264 ou mp3, ou iMovie, etc....

- Les applications compilés en 64 bits sont automatiquement compilées avec le support du bit NX pour la mémoire de pile ET de tas. Le bit NX permet de marquer ces zones mémoire manipulées par l'application comme étant non exécutables. Donc si quelqu'un essaye d'injecter du code dans ces zones mémoire avec pour but de l'exécuter, cela est rendu très difficile avec cette protection. Les applications 32 bits supportent le bit NX que pour la mémoire pile. Donc le 64 bits apportent un niveau de sécurité qui est loin d'être négligeable.

De l'autre côté, ils ont dévasté les performances Open GL des cartes graphiques.

Apple n'a rien dévasté, réfléchis un peu!

Je rappelle encore et encore que les drivers des cartes graphiques sont développés par nVidia et ATI, Apple assurant l'implémentation de son OS. Il est évident qu'Apple doit résoudre ses problèmes de perf OpenGl mais cela doit passer par un meilleur développement chez ATI et nVidia de leur drivers.

Allons, c'est une évidence, toutes les ressources sont orientés vers iOS. S'ils en avaient autant consacré à OS X. On en serait probablement à la XI.

Bien sûr, bien sûr!!! Si tu consacrais tes ressources à apprendre et réfléchir un peu, Macbidouille serait un site de meilleur qualité au niveau technique.

Ce message a été modifié par Orikawa - 1 Jul 2010, 14:04.