Macbidouille vient de publier un premier aperçu du nouveau système d'exploitation d'Apple, Mac os X Snow Léopard. [1]
Le léopard des neiges tout mignon (une fois le sang enlevé [2]) a donc pour avantages (et 30€):
* Réactivité du Finder ;
* Design QuickTime X ;
* Puissance des réseaux Wifi intégré au menu.
Bien que la communication soit portée sur des changements de fonctionnement interne (passage total au 64bits car on doit comprendre que léopard était 64bits que sur les pubs, abandon des machines power pc pour faire plaisir aux actionnaires), à ce rythme là, on peut prendre notre temps pour évoluer les logiciels libres.
[1] http://www.macbidouille.com/articles/300/page3
[2] http://www.mac4ever.com/news/47033/un_leopard_des_neiges_veg(...)
Journal Nouvelles fonctionnalités de Snow Léopard
28
août
2009
# Pas 30, mais 29
Posté par manatlan (site web personnel) . Évalué à -6.
(ce qui est encore trop cher par rapport à ma ubu ;-)
[^] # Re: Pas 30, mais 29
Posté par suJeSelS . Évalué à 9.
[^] # Re: Pas 30, mais 29
Posté par manatlan (site web personnel) . Évalué à -3.
[^] # Re: Pas 30, mais 29
Posté par B16F4RV4RD1N . Évalué à 4.
Bref pour moi la nouvelle m'intéresse autant qu'une mise à jour de l'iphone ou du nouveau mixeur SEB.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
# fun
Posté par manatlan (site web personnel) . Évalué à -2.
en bas de page : http://www.macbidouille.com/articles/300/page2
WOUAWWWWWWWWWWWWWWWW !
# Grand Central Dispatch
Posté par Buf (Mastodon) . Évalué à 6.
Concrètement, Grand Central est une nouvelle API et des extensions aux langages C/C++/Objective-C qui permettent de définir des blocks de code indépendants, puis de les distribuer entre les différents coeurs/CPU du système où ils pourront être exécutés en parallèle.
Une application optimisée pour Snow Leopard pourra ainsi facilement exploiter un processeur multicoeur sans avoir à gérer la complexité de la programmation multithread. En pratique, je ne sais pas trop ce que ça va donner, mais ça me semble très prometteur sur le papier.
[^] # Re: Grand Central Dispatch
Posté par benoar . Évalué à 5.
Je ne connaissais pas.
Mais à ma connaissance, ce n'est pas standarisé, non ? Apple qui fait une extension non-standard au C, je suis pas sûr que ça tienne longtemps ... au fait, ça a été intégré dans le gcc upstream ?
[^] # Re: Grand Central Dispatch
Posté par Buf (Mastodon) . Évalué à 3.
Dans tous les cas, même si les modifications d'Apple ne sont pas inclue upstream (ça m'étonnerait que la FSF accepte ces extensions), gcc reste en GPL, ce qui signifie que le code d'Apple sera disponible et réutilisable.
[^] # Re: Grand Central Dispatch
Posté par Fabien Penso (site web personnel, Mastodon) . Évalué à 2.
[^] # Re: Grand Central Dispatch
Posté par alberthier (site web personnel) . Évalué à 1.
Comment est-ce qu'on peut utiliser ça, dans quels cas, etc..
[^] # Re: Grand Central Dispatch
Posté par Thomas Douillard . Évalué à 3.
http://www.adahome.com/Discover/Examples/multiprocessing.ada
avec derrirère un scheduler qui gère l'attribution des tâches que tu veux parraléliser aux coeurs/processeurs ...
Quelqu'un peut confirmer ?
[^] # Re: Grand Central Dispatch
Posté par Buf (Mastodon) . Évalué à 2.
L'avantage (au moins en théorie) de Grand Central, c'est que le scheduler est géré directement par l'OS, il va donc connaitre le nombre de coeurs, avec la charge sur chacun d'eux et devrait donc être capable de distribuer les tâches plus intelligemment que si c'était géré au niveau applicatif.
Sur le papier, je trouve ça vraiment joli et élégant (surtout comparé à la programmation multithread), reste à voir le gain que ça peut apporter en pratique.
[^] # Re: Grand Central Dispatch
Posté par Thomas Douillard . Évalué à 4.
Et surtout qui te permet de te rendre compte du gap qui existe parfois entre les technos utilisées massivement et les technos qui existent, quand tu dois refaire du parallélisme en java ou en C. ADA avait pourtant le potentiel pour percer dans l'industrie ... c'est un langage injustement mal aimé.
Avec les multicoeurs qui se démocratise, il est temps que ça vienne de toute façon.
[^] # Re: Grand Central Dispatch
Posté par med . Évalué à 2.
[^] # Re: Grand Central Dispatch
Posté par Thomas Douillard . Évalué à 5.
Après en ayant regardé rapidement, en ADA toutes les constructions sont au niveau langage, ce n'est pas une API, la syntaxe est cohérente donc, t'as pas des pragmas ou des constructions bizares dans le lagages.
Tu dois avoir (je suis plus très sur) la notion de canal de communication en ADA, que j'ai pas vue en OpenMP, des tâches gardées - tu peux lancer des tâches sous certaines conditions, je crois.
Après ce que je raconte est à prendre avec des pincettes, c'est des souvenirs.
[^] # Re: Grand Central Dispatch
Posté par Thomas Douillard . Évalué à 2.
[^] # Re: Grand Central Dispatch
Posté par geb . Évalué à 1.
[^] # Re: Grand Central Dispatch
Posté par Buf (Mastodon) . Évalué à 1.
Avec Grand Central, il faut repenser son programme en terme de tâches indépendantes, et le système va ensuite s'occuper de les distribuer entre les différents coeurs disponibles. C'est particulièrement intéressant pour les applications interactives, parce que ça permet d'exécuter les traitements lourds de façon asynchrone en gardant une très bonne réactivité au niveau de l'interface utilisateur.
[^] # Re: Grand Central Dispatch
Posté par med . Évalué à 4.
Comme les threads en somme. J'ai du mal à voir ce que Grand Central a de particulièrement innovant.
[^] # Re: Grand Central Dispatch
Posté par Buf (Mastodon) . Évalué à 2.
- ça abstrait une bonne partie de la complexité. Ça ne va évidemment pas faire disparaitre par magie tous les pièges qu'on peut avoir quand on développe une application concurrente, mais ça offre déjà un certains nombres d'outils qui permettent d'éviter les erreurs les plus fréquentes.
- le fait que ça soit l'OS lui-même qui gère le dispatching des tâches lui permet d'optimiser au mieux le nombre de threads et la distribution des tâches en fonction du nombre et de la charge des différents coeurs. C'est surement là le point le plus intéressant : le scheduling des tâches est fait globalement pour le système, en tenant compte de toutes les applications en cours d'exécution.
# 64/2
Posté par lepoulpe . Évalué à 3.
D'après ce que j'ai pu lire, le système bootera sur un kernel 32 bits par défaut sur les Macs. Pour être en full 64 bits, il faudra presser simultanément les touches 6 et 4 au démarrage...
http://www.clubic.com/actualite-294898-apple-snow-leopard-32(...)
[^] # Re: 64/2
Posté par claudex . Évalué à 10.
Tout en se tenant à cloche pied un soir de pleine lune au milieu d'un cercle de statuette enroulées dans du jambon?
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: 64/2
Posté par Nonolapéro . Évalué à 2.
[^] # Re: 64/2
Posté par GeneralZod . Évalué à 6.
Pour pouvoir passer au tout 64bits, y a quelques trucs à régler:
* portage des pilotes: y a quasiment rien de fait.
* finir le portage des dernières applis carbon en cocoa.
* ne pas brusquer les propriétaires de machine à base de core duo qui ne supportent pas le long mode. Les dernières machines commercialisés datent d'août 2007 (sans compter les machine vendues via le refurb).
La transition 32->64bits va durer encore longtemps, mais c'est un gros pas qui a été franchi.
Snow Leopard est une transition, on s'est débarassé du passé (PPC, Classic, Rosetta, Carbon, etc ...), les fondations sont là (Cocoa, les CoreAPI, OpenCL, LLVM, etc ...)
L'abandon total du 32bits se fera avec la 10.7 voire la 10.8 selon la durée séparant Snow Leopard de son futur successeur.
En comparaison, Windows est encore à la traine, et quant à GNU/Linux, si le gros du boulot a été fait et que depuis un certain temps, toutes les machines en vente sont équipés de CPU x86_64, les utilisateurs rechignent encore à installer une distribution x86_64.
C'est compréhensible du fait que l'utilisateur de base a du mal à voir le gain qu'il peut en tirer, contrairement à la précédente transition 16->32 bits.
[^] # Re: 64/2
Posté par BAud (site web personnel) . Évalué à 3.
http://smolt.fedoraproject.org/static/stats/stats.html
peut-être faudrait-il croiser cette stat avec la quantité de RAM et les procs capables de gérer le 64 bits pour identifier
- si ceux qui sont en 64 bits ont systématiquement plus de 4 Go de RAM
- si ceux en 32 bits ont en majorité un proc qui gèrerait le 64 bits (mais peut-être pas assez de RAM ?)
Je ne sais pas si les données de smolt sont disponibles, cela permettrait à un bon statisticien de proposer cette analyse selon ces axes ?
à défaut, il y a hardware4linux qui met à disposition des données anonymisées qui doivent contenir l'info àmha http://hardware4linux.info/about/tos/
cela permettrait de compléter les stats existantes
http://hardware4linux.info/stats2/ les distros supportant le mieux le plus de matériel
http://hardware4linux.info/stats/ les distros ayant le plus de systèmes remontés
http://hardware4linux.info/best/ les meilleurs composants utilisés par le plus de monde
surtout que le nombre de paquets dispos en x86_64 est quasi le même qu'en i586
http://sophie.zarb.org/stat/Mandriva,2009.1
(je n'ai pas retrouvé les stats de pterjan, identifiant le nombre de paquets manquant, 'fin il y a http://wiki.mandriva.com/fr/Histoire_de_la_distribution_Mand(...) mais il y a eu un "oubli" de mise à jour pour la 2009.0 et la 2009.1 :/ je vais voir si ça peut être complété tiens...). À peu près un peu moins de 1000 paquets manquant pour x86_64...
[^] # Re: 64/2
Posté par netsurfeur . Évalué à 2.
Le 64 bits n'est indispensable que si on a des process qui ont besoin de plus de 3 Go.
[^] # Re: 64/2
Posté par patrick_g (site web personnel) . Évalué à 2.
Heu avec le faible nombre de registres de l'archi x86 (à peine 8 ça fait pitié) je trouve que la nouveauté la plus importante du x86-64 c'est le passage à 16 registres.
Toutes les applications en tirent bénéfice !
[^] # Re: 64/2
Posté par Zenitram (site web personnel) . Évalué à 1.
Ah? à partir de combien de "pour mille" (car %, c'est trop) tu considères qu'une application en tire bénéfice?
J'ai fait quelques tests rapides sur mon appli que je développe, certes ça ne fait pas une généralité mais ça permet de casser le "toutes", sur une même machine même distro même config vierge, et tout ce que j'ai pu noter, c'est que la marge d'erreur des mesures (faire tourner le test plusieurs fois) est supérieur au gain (des fois, le test 64 bits est plus rapide que le test 32 bits précédent, des fois le test 32 bits est plus rapide que le test 64 bits précédent).
Idem sous une machine Windows.
Bref, 8 registres de plus fait certainement quelques pourcents/pour mille de CPU (et encore), ramené à la place du CPU dans la vraie vie (partage du temps avec la RAM, le disque dur...), on ne peut pas vraiment dire que toutes les applis en tirent bénéfice (j'ai testé avec deux compilateurs : GCC sous Linux, MSVC2008 sous Windows, peut-être que plus tard ils optimiseront plus?)
Je veux bien croire que certaines applis avec plein d'algorithmes sans besoin de RAM et de disque dur en tirent un gros bénéfice, mais sinon j'ai du mal à voir... le passage en x86_64 aurait mérité plus d'évolutions, et du coup on a juste quelques applis qui en profitent : les applis mathématiques et les applis consommant plus de 3 Go de RAM. Ca fait pas beaucoup (parait que les jeux commerciaux comme Crysis commencent toutefois à se sentir à l'étroit dans 3 Go de RAM, et qu'ils profitent bien du 64 bits du coup, d'autres exemples "de la vraie vie", pas des proof of concept ou de démos?)
[^] # Re: 64/2
Posté par Buf (Mastodon) . Évalué à 2.
L'intérêt d'un espace d'adressage sur 64 bits, c'est pas seulement de pouvoir utiliser plus de RAM, ça permet aussi de mapper beaucoup plus de choses en mémoire (des fichiers ou la mémoire vidéo par exemple)
Ça ne se traduit pas forcément par un gain impressionnant en performance, mais ça peut considérablement simplifier la programmation (code plus simple => potentiellement moins de bugs)
[^] # Re: 64/2
Posté par Troy McClure (site web personnel) . Évalué à 2.
[^] # Re: 64/2
Posté par Ghis . Évalué à 1.
Mais il est possible de modifier ce comportement.
Par contre il semble que tout le reste du système soit en 64bits, en effet, quand mon mac mini à fini de booter et que je liste les processus, tous sont en mode 64bit sauf le noyau.
# C'est triste
Posté par yellowiscool . Évalué à 7.
Envoyé depuis mon lapin.
# du mordernisme marketing.
Posté par geb . Évalué à 2.
Alors ça c'est une fonctionnalité qui tue, inédite, incroyable, vraiment moderne, userfriendly etc...
Tellement moderne que je le faisais avec FVWM il y a 5 ans...
[^] # Re: du mordernisme marketing.
Posté par vincent_k (site web personnel) . Évalué à 5.
[^] # Re: du mordernisme marketing.
Posté par Joris Dedieu (site web personnel) . Évalué à 2.
[^] # Re: du mordernisme marketing.
Posté par Tom D . Évalué à 0.
PS: pourtant, il y avait un indice pas si bien caché dans la dernière phrase du journal.
Tom
[^] # Re: du mordernisme marketing.
Posté par Bruce Le Nain (site web personnel) . Évalué à 2.
Il y a une réduction considérable du code, et une amélioration des performances et de l'IHM générales, l'accent n'a pas été mis sur les nouveautés.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.