Journal Nouvelles fonctionnalités de Snow Léopard

Posté par  .
Étiquettes : aucune
-4
28
août
2009
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(...)
  • # Pas 30, mais 29

    Posté par  (site web personnel) . Évalué à -6.

    Apparemment, ça sera à 29 euros, et non 30 ...le prix de la màj ;-)
    (ce qui est encore trop cher par rapport à ma ubu ;-)
    • [^] # Re: Pas 30, mais 29

      Posté par  . Évalué à 9.

      Payer n'est pas forcement un problème, mais ne pas être libre en est un vrai.
      • [^] # Re: Pas 30, mais 29

        Posté par  (site web personnel) . Évalué à -3.

        ... j'ai pas dit le contraire !
      • [^] # Re: Pas 30, mais 29

        Posté par  . Évalué à 4.

        en plus c'est le prix de la mise à jour, pas du système neuf, et pas installable sur n'importe quelle machine.

        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  (site web personnel) . Évalué à -2.

    "On termine sur la plus grosse évolution de l'environnement utilisateur de Mac OS X : Exposé intégré dans le Dock, en maintenant un clic long sur l'icône de l'application."

    en bas de page : http://www.macbidouille.com/articles/300/page2


    WOUAWWWWWWWWWWWWWWWW !
  • # Grand Central Dispatch

    Posté par  (Mastodon) . Évalué à 6.

    Une nouveauté que je trouve intéressante sur le plan technique, c'est Grand Central Dispatch. J'attends avec impatience de voir si ça peut apporter un gain réel de performance.

    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  . Évalué à 5.

      http://images.apple.com/macosx/technology/docs/GrandCentral_(...)

      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  (Mastodon) . Évalué à 3.

        Non effectivement, ce n'est pas standardisé. Maintenant, faut voir, peut-être que d'autres OS (Linux, par exemple) vont intégrer une technologie équivalente, et à ce moment-là, ça risque bien de se baser sur les extensions existantes et pousser à une standardisation (à priori, les modifications au niveau du langage sont indépendantes de l'implémentation du truc)

        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  (site web personnel) . Évalué à 1.

      Quelqu'un a des détails concrets sur le fonctionnement de ce système. j'ai trouvé que du blabla marketing à ce sujet.
      Comment est-ce qu'on peut utiliser ça, dans quels cas, etc..
      • [^] # Re: Grand Central Dispatch

        Posté par  . Évalué à 3.

        J'en sais pas grand chose, mais ça me fait penser, côté langage, à ce qu'on peut faire en ADA (depuis longtemps) question multitache et programmation parallèle, cf. par exemple :

        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  (Mastodon) . Évalué à 2.

          C'est à peu près l'idée, en effet.

          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  . Évalué à 4.

            C'est très simple, ayant touché à l'ADA // au début de mes études, je peux dire que depuis je me suis toujours demandé, en pleurant, pourquoi ils avaient pas encore mis ce genre de fonctionalité dans les autres langages ... Je me souvient avoir fait très rapidement et simplement un simulateur de PC (matériel) , avec les différents composants qui tournaient en parallèle, processeur, bus, et l'horloge qui donnait le "tic" pour synchroniser le travail du tout ... projet bidon mais qui laisse entrevoir les possibilités, tellement c'est simple à réaliser.

            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  . Évalué à 2.

              Par curiosité, c'est quoi la différence avec un truc comme OpenMP par exemple ?
              • [^] # Re: Grand Central Dispatch

                Posté par  . Évalué à 5.

                Je connais pas openMP, et pas assez bien ADA pour répondre, perso.

                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  . Évalué à 2.

                Par contre j'ai vu que OpenMP permettait un genre de gestion du scheduling des tâche, je sais pas du tout si c'est possible en ADA.
      • [^] # Re: Grand Central Dispatch

        Posté par  . Évalué à 1.

        ça ressemble for au genre d'optimisation que sait faire llvm (ou peut faire avec des algos plus poussés)
        • [^] # Re: Grand Central Dispatch

          Posté par  (Mastodon) . Évalué à 1.

          Non, ça n'a rien à voir avec ce qu'un compilateur peut faire. Un compilateur, il va faire des optimisations locales, en remplaçant par exemple une boucle par un traitement en parallèle. Mais fondamentalement, on garde une sémantique de programme exécuté séquentiellement.

          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  . Évalué à 4.

            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.

            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  (Mastodon) . Évalué à 2.

              Je vois deux avantages importants :
              - ç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  . Évalué à 3.

    Finalement, il semble que le passage total au 64 bits ne soit pas pour ce coup-ci non plus.

    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  . Évalué à 10.

      Pour être en full 64 bits, il faudra presser simultanément les touches 6 et 4 au démarrage...

      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  . Évalué à 2.

        Rien de bien étonnant à cette combinaison de touches, MAC rime in peu avec Emacs :)
    • [^] # Re: 64/2

      Posté par  . Évalué à 6.

      En même temps, faut pas pousser la charrue avant les boeufs.
      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  (site web personnel) . Évalué à 3.

        c'est clair que le x86_64 semble sous-utilisé à voir smolt, que ~30 % de x86_64 ça semble faible :/
        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  . Évalué à 2.

          Sans compter qu'on peut avoir plus de 4 Go de RAM avec un noyau 32 bits (j'ai quelques serveurs avec 8 ou 16 Go de RAM dans ce cas).

          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  (site web personnel) . Évalué à 2.

            >>> Le 64 bits n'est indispensable que si on a des process qui ont besoin de plus de 3 Go

            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  (site web personnel) . Évalué à 1.

              Toutes les applications en tirent bénéfice !

              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  (Mastodon) . Évalué à 2.

                les applis consommant plus de 3 Go de RAM

                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  (site web personnel) . Évalué à 2.

                moi j'ai observé entre 10 - 15% de gain de perfs, je crois d'ailleurs que c'est ce qui était annoncé quand les premiers amd64 sont sortis. Pas completement negligeable, mais pas non plus suffisant pour justifier à lui seul le passage au 64-bit
                • [^] # Re: 64/2

                  Posté par  . Évalué à 1.

                  par défaut le noyau démarre en 32 bit sur les machines desktops, et 64 pour les serveurs.
                  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  . Évalué à 7.

    C'est triste d'avoir un score si négatif alors que je voulais juste indiquer que du cotés d'apple, on ne se refuse rien…

    Envoyé depuis mon lapin.

  • # du mordernisme marketing.

    Posté par  . Évalué à 2.

    * Puissance des réseaux Wifi intégré au menu.

    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...

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.