Je sais pas pour Google, mais pour Apple, leur browser ne contient absolument aucun codec vidéo, tout est délégué à QuickTime (et ça tombe, c'est justement son rôle) Par défaut, QuickTime lit plusieurs dizaines de formats différents, dont H.264.
Pour lire une vidéo Theora dans Safari, il suffit d'ajouter le codec à QuickTime, et ça marche sans rien faire d'autre.
Atlassian soutient le logiciel libre en fournissant des licences gratuites de ses produits et en contribuant aux bibliothèques qu'ils utilisent. Mais ça ne rend pas leurs produits libres (ni même open source) pour autant, leur business, c'est de vendre du proprio.
Non, Confluence n'est pas libre, ni même open source.
Dans la mention en bas de page, il faut bien grouper les mots, on parle de "free (...) Open Source Project License", c'est-à-dire d'une licence gratuite pour projet open source (le free ici est bien à prendre dans le sens "gratuit"). Le "Open Source" ne s'applique pas à Confluence lui-même.
Peut-être, mais ce n'est pas le but recherché. De toute façon, la musique est encore le plus souvent vendue sur CD, qui est un support non compressé.
Non, l'intérêt, c'est d'avoir un rendu plus flatteur quand on écoute la musique dans un environnement bruyant. Ça permet de vendre plus facilement les CD, parce qu'un CD enregistré fort et avec peu de dynamique donnera l'impression d'avoir un meilleur son quand on l'écoute en magasin (même si le son sera en fait mauvais dès qu'on l'écoutera au calme)
Non, ce n'est pas réversible. Cette compression correspond à une perte d'information. Une fois perdue, aucun algorithme ne permet de la retrouver (pour te donner une idée, c'est un peu comme si on applique un filtre de flou sur une image)
Et comme une image explique mieux les choses, il suffit d'ouvrir des fichiers musicaux dans Audacity (ou tout autre logiciel du genre) pour rendre assez évident tout le mal que fait la compression.
Ensuite, un truc récent (en l'occurrence, The Killers, mais ça pourrait être à peu près n'importe quoi sorti ces dernières années) : http://sd765.sivit.org/~lbuffler/killers.png
La différence s'entend surtout au niveau de la batterie. Pour Led Zeppelin, chaque coup est net et bien audible, sur l'autre chanson, c'est juste un vague bruit de fond.
D'ailleurs à quoi ça sert de stocker des données dans le Swap quand la plupart de la RAM est inutilisée ?
Un système où "la plupart de la RAM est inutilisée" est un système qui vient juste de booter. Dès le moment où on commence à travailler avec, l'utilisation de la mémoire va s'approcher rapidement de 100% (et c'est normal, ça ne sert à rien d'avoir de la mémoire inutilisée)
Et cacher des fichier sur le disque lui-même, ça n'apporte pas grand chose
Effectivement, c'est même parfaitement débile, c'est d'ailleurs pour ça que l'OS ne le fait jamais. Le cache disque, c'est évidemment toujours en mémoire physique.
Entre 512 Mio de mémoire et 512 Mio de swap, et 1 Gio de mémoire et 0 de swap, le second fonctionne mieux, ça me suffit.
Je suis d'accord, mais c'est absolument pas de ça dont je parle.
Ce que je dis, ce que 1 go de RAM avec 1 go de swap, c'est encore mieux que 1 go RAM sans swap, parce que ça permettra à l'OS de mieux optimiser la gestion de la RAM, en décidant par exemple qu'un cache disque plus gros apporte plus de performances que de garder des données peu utilisées en mémoire physique.
Mais bon, vu qu'apparemment tu veux rien comprendre, continue à ne pas mettre de swap et à avoir des performances dégradées pour rien.
Ben je sais pas comment tu utilises ta machine, mais chez moi, même avec 8 go de RAM, j'ai toujours quelques dizaines de mo utilisés en swap, même si je suis sûr que mes applications n'ont à aucun moment consommé toute la mémoire physique.
C'est juste normal et souhaitable, ça signifie que le gestionnaire de mémoire fait son boulot et décide d'utiliser de façon utile la mémoire qu'il a à disposition.
Tes 2 Go, ils seront forcément (et rapidement) utilisés : en partie pour les données des applications, le reste pour le cache disque.
Le swap n'est pas juste un moyen de compenser un manque de mémoire physique, c'est un élément à part entière du gestionnaire de mémoire (qui est conçu pour travailler avec) Si tu penses savoir la gérer mieux que l'OS, libre à toi, mais il n'empêche que ça reste sous-optimal, vu que tu empêches la possibilité d'étendre le cache disque au détriment de zones de données peu ou pas utilisées.
Non, l'habitude, c'est de ne pas mettre de swap sur des machines qui ont plus d'un gibioctet de mémoire.
Ce qui est parfaitement stupide...
Ne pas mettre de swap, ça revient à décider à la place de l'OS que la mémoire de travail de tes applications est toujours plus importantes que le cache disque.
En pratique, c'est juste faux, il y a des pages de données auxquelles on accède si peu souvent qu'il vaut mieux les virer de la RAM pour les mettre en swap. Ok, on aura une pénalité au moment où on voudra y accéder, mais en attendant, ça libère de la place pour le cache disque qui permet d'améliorer les performances générales. Au final, on y aura gagné, et retirer le swap, c'est retirer à l'OS la possibilité de faire ce genre d'optimisations.
Au passage, j'ai aussi lu dans ce journal que le swap ne serait utilisé que quand la mémoire est pleine : c'est faux. Le swap commence à être utilisé bien avant, toujours dans le but de garder suffisamment de RAM pour le cache disque.
Tout à fait. J'ai utilisé un moment un SSD connecté en externe en firewire 800, ce qui limitait fortement le débit max (60-70 mo/s environ), c'était donc moins que ce que pouvait me sortir un bon disque dur sata.
Pourtant, au niveau du ressenti à l'utilisation, le système est nettement plus réactif, même avec un ssd au débit complètement bridé, justement parce que ce qui est intéressant, c'est les temps d'accès très faible sur les accès aléatoires.
[Et bientôt sur vos écrans, Google Poste : vos couriers sont scannés à la réception par Google, au lieu d'être distribués chez vous. Vous pouvez les consulter à volonté sur GPoste.com, voir même les imprimer à vos frais.]
Je sais pas si Google prévoit d'offrir ce genre de services, mais la poste suisse le fait déjà : http://swisspostbox.com/fr/
Oublie pas la TVA ! Pour comparer les prix en euros et en dollars, faut pas oublier de tenir compte du fait que le prix en dollars est presque toujours HT alors que le prix en euro est généralement TTC.
Bref, un PC à 1000 $, il est à 678 € HT, et donc plus de 800 € TTC
Petite précision : dans ce qui suit, je parle des firmwares pour des cartes style carte réseau ou wifi, pas des pseudo firmware qui sont en fait des OS complets qu'on trouve sur les smartphones par exemple (et qui sont sur des mémoires non volatiles, donc de toute façon, c'est hors-sujet par rapport aux "blobs" du noyau) Les firmwares dont je parle ici sont plutôt petits, et de très bas niveau.
Un firmware libre, faut pas trop compter dessus, pour un certain nombre de raisons plus ou moins bonnes :
- conformité aux normes légales (je pense en particulier aux cartes wifi ou aux puces gsm/3g ici)
- un firmware a un accès très bas niveau au matériel, ce qui signifie qu'il peut potentiellement l'endommager (ou pire, endommager le matériel auquel il est connecté)
- obstacles légaux : le code n'appartient pas forcément complètement au constructeur, il peut aussi y avoir des NDA sur certaines partie du matériel
Bref, faut voir le firmware comme faisant un tout avec le matériel.
Maintenant, là où je critique la position de la FSF, c'est qu'elle est complètement hypocrite par rapport à ça. Prenons deux cartes, A et B. A possède sont firmware en RAM, B en flash. En dehors de ça, les deux cartes sont absolument identiques, le firmware est aussi le même.
Pour la FSF, un driver pour la carte A sera "mauvais", parce qu'il devra inclure un firmware non libre, ce qui lui fera déconseillé n'importe quel OS qui supportera cette carte. Il n'y aura en revanche aucun problème pour la carte B.
Là où je trouve que c'est hypocrite, c'est que la carte B n'aura rien de plus libre que la carte A, sont firmware étant absolument identique ! Mais au nom d'un idéal de "pureté" des distributions, on se retrouve à conseiller des cartes qui ne sont en aucun cas plus libre, mais par contre, elles seront assurément plus chères (la flash est plus couteuse que la ram) pour une fonctionnalité absolument équivalente. Au final, le libre et l'utilisateur n'y gagnent rien, superbe exemple d'aberration qu'on obtient quand on suit aveuglément une idéologie.
La position d'OpenBSD (on inclut les firmwares du moment que leur licence autorise la redistribution) est bien plus cohérente.
Attention à pas mélanger 2 choses qui n'ont pas grand chose à voir :
- les firmwares sous forme de binaire, envoyés vers la ram du matériel par le driver et exécuté par un processeur embarqué
- les drivers binaires, qui seront cette fois exécutés directement dans le noyau, sur le processeur central
C'est dans la deuxième catégorie qu'on trouve entre autres les drivers pour les winmodems et autres trucs du genre (dont certainement le driver pour ta webcam) Je suis d'accord que ces drivers-là sont très problématiques.
Par contre, je n'ai aucun problème avec la première catégorie, c'est un très bon moyen de réduire le cout du matériel (en évitant de devoir ajouté une mémoire non volatile) tout en permettant des mises à jour faciles.
La FSF rejette les deux, les *BSD seulement la deuxième catégorie, d'où une certaine confusion, ce que les BSD appellent "blobs", c'est uniquement les drivers binaires, là où la FSF utilise ce terme pour tout ce qui est "données binaires contenues dans un driver", même si ce code est uniquement destiné à être envoyé dans la RAM du périphérique.
C'est complètement stupide de différencier de cette façon, le choix entre mémoire flash et RAM est, à mon avis, un simple détail d'implémentation du matériel (pour des raisons de cout et de facilité de mise à jour principalement), mais fondamentalement, il n'y a aucune différence entre les deux.
Le firmware est un composant du matériel, peu importe qu'il soit enregistré de manière non volatile ou qu'il soit chargé à chaque boot par l'OS.
J'ai un peu de mal à comprendre ce qui pose tant de problèmes à certains avec ces blobs...
Apparemment LLVM ne supporte vraiment que C et C++ pour l'instant (et qques autres en développement)
Il y a en fait 2 front-ends (la partie qui va lire le code) :
- gcc
- CLang
Avec le frontend gcc, ça supporte les mêmes langages que gcc, avec les mêmes extensions non-standard.
CLand est un parseur indépendant réécrit de zéro, qui supporte relativement bien C, mais pour le reste, c'est pas encore ça (mais vu qu'Apple travaille sur LLVM, on peut s'attendre à avoir rapidement un bon support Objective-C)
Jamais un #ifdef n'est sur une architecture, seulement sur un OS.
Ça, c'est faux.
Il y a plusieurs cas où ça arrive qu'on teste sur l'architecture :
- code assembleur inline
- test d'endianness (c'est pas un test d'architecture au sens strict, mais ça revient au même)
- 32 ou 64 bits (idem qu'au dessus)
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)
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.
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.
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: H264 et GIF
Posté par Buf (Mastodon) . En réponse au journal De youtube, html5, H264 et ubuntu. Évalué à 6.
Pour lire une vidéo Theora dans Safari, il suffit d'ajouter le codec à QuickTime, et ça marche sans rien faire d'autre.
[^] # Re: Vraiment pas libre ?
Posté par Buf (Mastodon) . En réponse au journal Un projet GNU utilise un outil propriétaire. Évalué à 7.
[^] # Re: Vraiment pas libre ?
Posté par Buf (Mastodon) . En réponse au journal Un projet GNU utilise un outil propriétaire. Évalué à 7.
Dans la mention en bas de page, il faut bien grouper les mots, on parle de "free (...) Open Source Project License", c'est-à-dire d'une licence gratuite pour projet open source (le free ici est bien à prendre dans le sens "gratuit"). Le "Open Source" ne s'applique pas à Confluence lui-même.
[^] # Re: Intérêt?
Posté par Buf (Mastodon) . En réponse au journal Un article sur la compression sonore (compression de la dynamique). Évalué à 2.
Non, l'intérêt, c'est d'avoir un rendu plus flatteur quand on écoute la musique dans un environnement bruyant. Ça permet de vendre plus facilement les CD, parce qu'un CD enregistré fort et avec peu de dynamique donnera l'impression d'avoir un meilleur son quand on l'écoute en magasin (même si le son sera en fait mauvais dès qu'on l'écoutera au calme)
[^] # Re: Décompression?
Posté par Buf (Mastodon) . En réponse au journal Un article sur la compression sonore (compression de la dynamique). Évalué à 4.
[^] # Re: Mieux vaut écouter Led Zeppelin…
Posté par Buf (Mastodon) . En réponse au journal Un article sur la compression sonore (compression de la dynamique). Évalué à 10.
D'abord, Led Zeppelin, Stairway to Heaven : http://sd765.sivit.org/~lbuffler/led_zep.png
Ensuite, un truc récent (en l'occurrence, The Killers, mais ça pourrait être à peu près n'importe quoi sorti ces dernières années) : http://sd765.sivit.org/~lbuffler/killers.png
La différence s'entend surtout au niveau de la batterie. Pour Led Zeppelin, chaque coup est net et bien audible, sur l'autre chanson, c'est juste un vague bruit de fond.
[^] # Re: Quelle rigolade
Posté par Buf (Mastodon) . En réponse au journal Consommation de ressources de Windows et Debian. Évalué à 1.
Un système où "la plupart de la RAM est inutilisée" est un système qui vient juste de booter. Dès le moment où on commence à travailler avec, l'utilisation de la mémoire va s'approcher rapidement de 100% (et c'est normal, ça ne sert à rien d'avoir de la mémoire inutilisée)
[^] # Re: Quelle rigolade
Posté par Buf (Mastodon) . En réponse au journal Consommation de ressources de Windows et Debian. Évalué à 1.
Le mettre à 0 peut être utile dans certains cas particuliers, mais certainement pas dans le cadre d'une utilisation "normale".
[^] # Re: Quelle rigolade
Posté par Buf (Mastodon) . En réponse au journal Consommation de ressources de Windows et Debian. Évalué à 1.
Et cacher des fichier sur le disque lui-même, ça n'apporte pas grand chose
Effectivement, c'est même parfaitement débile, c'est d'ailleurs pour ça que l'OS ne le fait jamais. Le cache disque, c'est évidemment toujours en mémoire physique.
Entre 512 Mio de mémoire et 512 Mio de swap, et 1 Gio de mémoire et 0 de swap, le second fonctionne mieux, ça me suffit.
Je suis d'accord, mais c'est absolument pas de ça dont je parle.
Ce que je dis, ce que 1 go de RAM avec 1 go de swap, c'est encore mieux que 1 go RAM sans swap, parce que ça permettra à l'OS de mieux optimiser la gestion de la RAM, en décidant par exemple qu'un cache disque plus gros apporte plus de performances que de garder des données peu utilisées en mémoire physique.
Mais bon, vu qu'apparemment tu veux rien comprendre, continue à ne pas mettre de swap et à avoir des performances dégradées pour rien.
[^] # Re: Quelle rigolade
Posté par Buf (Mastodon) . En réponse au journal Consommation de ressources de Windows et Debian. Évalué à 2.
C'est juste normal et souhaitable, ça signifie que le gestionnaire de mémoire fait son boulot et décide d'utiliser de façon utile la mémoire qu'il a à disposition.
[^] # Re: Quelle rigolade
Posté par Buf (Mastodon) . En réponse au journal Consommation de ressources de Windows et Debian. Évalué à 7.
Le swap n'est pas juste un moyen de compenser un manque de mémoire physique, c'est un élément à part entière du gestionnaire de mémoire (qui est conçu pour travailler avec) Si tu penses savoir la gérer mieux que l'OS, libre à toi, mais il n'empêche que ça reste sous-optimal, vu que tu empêches la possibilité d'étendre le cache disque au détriment de zones de données peu ou pas utilisées.
[^] # Re: Quelle rigolade
Posté par Buf (Mastodon) . En réponse au journal Consommation de ressources de Windows et Debian. Évalué à 5.
Ce qui est parfaitement stupide...
Ne pas mettre de swap, ça revient à décider à la place de l'OS que la mémoire de travail de tes applications est toujours plus importantes que le cache disque.
En pratique, c'est juste faux, il y a des pages de données auxquelles on accède si peu souvent qu'il vaut mieux les virer de la RAM pour les mettre en swap. Ok, on aura une pénalité au moment où on voudra y accéder, mais en attendant, ça libère de la place pour le cache disque qui permet d'améliorer les performances générales. Au final, on y aura gagné, et retirer le swap, c'est retirer à l'OS la possibilité de faire ce genre d'optimisations.
Au passage, j'ai aussi lu dans ce journal que le swap ne serait utilisé que quand la mémoire est pleine : c'est faux. Le swap commence à être utilisé bien avant, toujours dans le but de garder suffisamment de RAM pour le cache disque.
[^] # Re: J'ai sauté le pas ...
Posté par Buf (Mastodon) . En réponse au journal Faut-il craquer pour du SSD ?. Évalué à 2.
Pourtant, au niveau du ressenti à l'utilisation, le système est nettement plus réactif, même avec un ssd au débit complètement bridé, justement parce que ce qui est intéressant, c'est les temps d'accès très faible sur les accès aléatoires.
[^] # Re: 21ème siècle
Posté par Buf (Mastodon) . En réponse au journal Chiottes de "plateformes" de renseignement. Évalué à 1.
Je sais pas si Google prévoit d'offrir ce genre de services, mais la poste suisse le fait déjà : http://swisspostbox.com/fr/
[^] # Re: C'est 50$ pour un PC à 1000$ soit environ 5% en moyenne
Posté par Buf (Mastodon) . En réponse au journal Quand Microsoft communique sur le prix de la vente liée de Windows. Évalué à 6.
Bref, un PC à 1000 $, il est à 678 € HT, et donc plus de 800 € TTC
[^] # Re: Blobs et blobs
Posté par Buf (Mastodon) . En réponse au journal Le système que j'utilise est-il libre ?. Évalué à 5.
Un firmware libre, faut pas trop compter dessus, pour un certain nombre de raisons plus ou moins bonnes :
- conformité aux normes légales (je pense en particulier aux cartes wifi ou aux puces gsm/3g ici)
- un firmware a un accès très bas niveau au matériel, ce qui signifie qu'il peut potentiellement l'endommager (ou pire, endommager le matériel auquel il est connecté)
- obstacles légaux : le code n'appartient pas forcément complètement au constructeur, il peut aussi y avoir des NDA sur certaines partie du matériel
Bref, faut voir le firmware comme faisant un tout avec le matériel.
Maintenant, là où je critique la position de la FSF, c'est qu'elle est complètement hypocrite par rapport à ça. Prenons deux cartes, A et B. A possède sont firmware en RAM, B en flash. En dehors de ça, les deux cartes sont absolument identiques, le firmware est aussi le même.
Pour la FSF, un driver pour la carte A sera "mauvais", parce qu'il devra inclure un firmware non libre, ce qui lui fera déconseillé n'importe quel OS qui supportera cette carte. Il n'y aura en revanche aucun problème pour la carte B.
Là où je trouve que c'est hypocrite, c'est que la carte B n'aura rien de plus libre que la carte A, sont firmware étant absolument identique ! Mais au nom d'un idéal de "pureté" des distributions, on se retrouve à conseiller des cartes qui ne sont en aucun cas plus libre, mais par contre, elles seront assurément plus chères (la flash est plus couteuse que la ram) pour une fonctionnalité absolument équivalente. Au final, le libre et l'utilisateur n'y gagnent rien, superbe exemple d'aberration qu'on obtient quand on suit aveuglément une idéologie.
La position d'OpenBSD (on inclut les firmwares du moment que leur licence autorise la redistribution) est bien plus cohérente.
[^] # Re: Blobs et blobs
Posté par Buf (Mastodon) . En réponse au journal Le système que j'utilise est-il libre ?. Évalué à 10.
- les firmwares sous forme de binaire, envoyés vers la ram du matériel par le driver et exécuté par un processeur embarqué
- les drivers binaires, qui seront cette fois exécutés directement dans le noyau, sur le processeur central
C'est dans la deuxième catégorie qu'on trouve entre autres les drivers pour les winmodems et autres trucs du genre (dont certainement le driver pour ta webcam) Je suis d'accord que ces drivers-là sont très problématiques.
Par contre, je n'ai aucun problème avec la première catégorie, c'est un très bon moyen de réduire le cout du matériel (en évitant de devoir ajouté une mémoire non volatile) tout en permettant des mises à jour faciles.
La FSF rejette les deux, les *BSD seulement la deuxième catégorie, d'où une certaine confusion, ce que les BSD appellent "blobs", c'est uniquement les drivers binaires, là où la FSF utilise ce terme pour tout ce qui est "données binaires contenues dans un driver", même si ce code est uniquement destiné à être envoyé dans la RAM du périphérique.
[^] # Re: Blobs et blobs
Posté par Buf (Mastodon) . En réponse au journal Le système que j'utilise est-il libre ?. Évalué à 1.
Le firmware est un composant du matériel, peu importe qu'il soit enregistré de manière non volatile ou qu'il soit chargé à chaque boot par l'OS.
J'ai un peu de mal à comprendre ce qui pose tant de problèmes à certains avec ces blobs...
[^] # Re: LLVM IR n'est pas portable
Posté par Buf (Mastodon) . En réponse au journal LLVM dans un gestionnaire de paquets ?. Évalué à 2.
(et un développeur qui écrirait un code pareil aujourd'hui devrait être viré immédiatement)
[^] # Re: Intéressant
Posté par Buf (Mastodon) . En réponse au journal LLVM dans un gestionnaire de paquets ?. Évalué à 1.
Il y a en fait 2 front-ends (la partie qui va lire le code) :
- gcc
- CLang
Avec le frontend gcc, ça supporte les mêmes langages que gcc, avec les mêmes extensions non-standard.
CLand est un parseur indépendant réécrit de zéro, qui supporte relativement bien C, mais pour le reste, c'est pas encore ça (mais vu qu'Apple travaille sur LLVM, on peut s'attendre à avoir rapidement un bon support Objective-C)
[^] # Re: Bytecode vraiment portable ?
Posté par Buf (Mastodon) . En réponse au journal LLVM dans un gestionnaire de paquets ?. Évalué à 8.
Ça, c'est faux.
Il y a plusieurs cas où ça arrive qu'on teste sur l'architecture :
- code assembleur inline
- test d'endianness (c'est pas un test d'architecture au sens strict, mais ça revient au même)
- 32 ou 64 bits (idem qu'au dessus)
[^] # Re: 64/2
Posté par Buf (Mastodon) . En réponse au journal Nouvelles fonctionnalités de Snow Léopard. É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: Grand Central Dispatch
Posté par Buf (Mastodon) . En réponse au journal Nouvelles fonctionnalités de Snow Léopard. É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.
[^] # Re: Grand Central Dispatch
Posté par Buf (Mastodon) . En réponse au journal Nouvelles fonctionnalités de Snow Léopard. É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 Buf (Mastodon) . En réponse au journal Nouvelles fonctionnalités de Snow Léopard. É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.