Hypothèse: ces 200 nouvelles instructions pourraient être un SSE2-like. A priori, pour le reste (ALU), le Godson avait déjà tout, y compris une licence MIPS officielle pour supporter les instructions de load/store non-alignés. À moins que ces instructions comportent également des instructions gérant l'état de la machine x86 (codes condition, etc.)?
Quant à l'estimation des performances, je pense que l'avocat s'est trompé ou est très imprécis/incertain. Il a sans doute voulu le faire par rapport à leurs propres technologies/produits passés. Ce chiffre de 80%, tout d'abord, c'est 80% de quoi (quel coeur?), à quelle fréquence? Ensuite, la solution la plus rapide qu'Intel ait produite est purement logicielle.
Les performances de IA-32 EL sont de 65% de la performance native sur les entiers, i.e. comparaison binaire x86 via IA-32 EL et binaire IA-64. Par rapport à un x86 réel, c'était très appréciable: 5% plus rapide qu'un Xeon @ 1.6 GHz, l'Itanium 2 n'était qu'à 1.5 GHz.
Source: http://www.microarch.org/micro36/html/pdf/goldenberg-IA32Exe(...)
Ensuite, on peut voir aussi que les performances de l'émulateur HW pour IA-64 étaient... euh, assez faibles pour le dire poliment. Pour s'en rendre compte, l'équipe de DynamoRIO avait travaillé sur un accélérateur logiciel (pré-datant IA-32 EL) qui consistait à produire du code IA-64 (natif donc) pour des hot traces et laisser faire le mode IA-32 du CPU pour le reste. Et bien, les performances du logiciel étaient meilleures que l'émulateur HW de 40% environ, malgré le surcoût des mode switches induits. Et encore, c'était qu'un essai, pas avec une armada de technos d'optimisations du moment. Donc en aucun cas, les solutions d'émulation x86 HW d'Intel pouvaient atteindre ces fameux 80%. Source: http://www.cag.lcs.mit.edu/rio/tim-meng-thesis.pdf
Encore une fois, l'émulation HW x86 est très complexe. Et encore plus pour le mode privilégié (segmentation, page tables, etc.). On verra bien s'ils s'en sortent au niveau perfs. Je dirais inférieures ou équivalentes à un Atom à 1 GHz. Pure spéculation, bien sûr. ;-)
Si on regarde du côté des processeurs chinois, 2009 sera l'année du Godson 3
En fait, je le casais dans 2010 dans une configuration accessible à des vrais gens. Dans mon souvenir, c'était d'abord prévu pour des serveurs. C'est clair que du quad core sous 10W, c'est balaise. De quand date le tape-out du Godson 3? Pour comparaison, le 2F c'était en juillet 2007, et les premiers produits Lemote sont sortis en février ou juin 2008 je crois, on a donc un peu de marge hein. ;-)
Il semblerait que le Godson 3 soit en mesure d'émuler les instructions x86
Oui, et s'ils le font en HW, on va voir s'ils se sont mieux débrouillés que IBM (PowerPC 615) ou même Intel (Itanium).
À mon avis, on a plus d'opportunités d'optimisation au niveau SW que HW car on a une vision plus grande que le CPU au niveau de son décodeur. e.g. cache de code natif plus grand, élimination du calcul de certains codes condition, optimisation de traces, spécialisation de fonction, et même appel d'équivalents natifs (cf. Transitive, entre autres). Mais je crains que leur ambition initiale était d'émuler un x86 intégralement (mode privilégié compris) de sorte à exécuter Windows...
On pourrait croire qu'il "suffit" de caser un décodeur x86 -> ISA interne dans le CPU et hop ça roule, mais la réalité n'est pas si simple. Il me tarde de voir cela, et là, c'est sûr que je m'en prends un pour l'exploit technologique!
Non, les plug-ins Java ne sont pas supportés. Ceux utilisant l'API OJI ne le seront jamais, a priori. En théorie, il devrait être possible de supporter le nouveau plug-in Java de Sun, qui utilise NPAPI et NPRuntime. En pratique, c'est un peu plus complexe car il semble exister encore des bouts de XPCOM dedans, ce qui n'est pas supporté. Quant au plug-in Java d'IcedTea, je n'ai pas encore regardé mais (i) il exécute déjà l'appletviewer dans un autre processus me semble-t-il, et (ii) il est disponible nativement.
Oui, il y a des MIDs et netbooks de prévus à base de NVIDIA Tegra. Par contre, je pense que la "fenêtre d'opportunité" de NVIDIA est étroite, je dirais 12 à 18 mois avec une grosse louche. i.e. Tegra sera compétitif sur ce secteur tant que Intel n'aura pas lancé sa plate-forme Moorestown (le CPU Lincroft en 32 nm). À noter aussi que les machines sous Tegra ne sont prévues qu'avec Windows, il me semble.
Ah, autre chose, il ne faut pas se méprendre, les chinois ont montré leur capacité à designer des CPUs potables. Bien sûr, il manque un GPU voire un VPU qui tienne la route, mais au niveau CPU pur, ils ont bien progressé. J'attends de voir s'ils oseront implémenter l'AVX d'Intel, pas au niveau encodage/format des instructions, mais bien au niveau des mnémoniques comme ils ont fait pour leur MMX-like. Ca, ce serait encore plus impressionnant: émulation x86 "contemporaine", captation facile de développeurs maîtrisant déjà ce jeu d'instruction, etc. Soyons fous, rêvons un peu... ou pas. ;-)
C'est 2010 qui sera intéressante au niveau CPU je pense. 2009 le serait juste au niveau logiciel pour se mettre à niveau/supporter les technologies du moment.
Je pense que ça arrive quand même trop tard, trop cher. Ce que je trouve inquiétant est le prix spécial développeur, donc a priori réduit, de 250 EUR. Ca veut dire que la version retail sera plus chère. Combien? 299 - 349 EUR? Cela dit, pour 250 EUR, ça reste très compétitif par rapport à des solutions sous Geode (ça, c'est pas compliqué non plus). Mais si ça se positionne sur la fourchette 299 - 349 EUR, c'est beaucoup trop cher par rapport à des solutions sous Atom.
Un exemple, un constructeur qui n'a pourtant pas l'habitude de casser ses prix mais plutôt de se remplir les poches avec des machines sous-équipées, Dell: le Mini 12 est proposé à 399 EUR. Il a un écran plus grand (12"), 1 Go de RAM, 40 Go de DD et... un Poulsbo pour le décodage HW de vidéos.
Le G-dium n'a aucune puce de décodage vidéo, ni de puce 3D. Bon, le SM502 sait faire du yuv2rgb en HW, mais ce n'est bon que pour implémenter Xv, pas pour offloader des vidéos. Même si le Godson 2F est plus performant que l'Atom Z à 1.33 GHz (je dirais même 1.6 GHz aussi), c'est pas pour autant qu'il saura décoder des vidéos dans une empreinte énergétique potable, voire juste pouvoir les décoder en fait. À moins de transcoder ses fichiers avant de partir avec le portable. Après, ça dépend de l'utilisation qu'on souhaite en faire.
À noter aussi qu'une pléthore de netbooks sous Atom Z + Poulsbo devrait être lancée en H1 2009, dans une gamme de prix sans doute inférieure au Dell mais en 10". Ceux-là seront les concurrents du G-dium. Puis, H1 2010 verra arriver les plate-formes en Intel Moorestown, avec un gros SoC (CPU + GPU + VPU + I/O). Tiens, peut-être qu'AMD aussi, mais j'ai un peu perdu espoir.
Cela dit, c'est toujours intéressant d'avoir du MIPS, ça fait un autre jouet architectural. ;-) Surtout la partie SIMD inhabituelle pour cette famille. i.e. ce n'est pas du MIPS-3D/MDMX mais ça ressemble plutôt à du MMX d'après les patches GCC. C'est assez pratique d'implémenter des instructions aux sémantiques équivalentes à du MMX, surtout si l'on veut émuler du x86 en SW, voire en HW s'ils insistent vraiment même si l'autre approche est meilleure à mon sens.
Euh, oui, il y avait des fuites de mémoire dans le bridge NPRuntime jusqu'à la version 1.1.6. Je ne sais pas si c'est ton problème en particulier, mais c'est ce que j'avais remarqué lors de ma phase de review du code.
Si tu suspectes encore des fuites de mémoire dans la version 1.2.0, il est également possible de ne lancer valgrind que sur nspluginwrapper, et donc les plug-ins, i.e. on ne s'embête pas à valgrind'er sur tout le browser. Pour ce faire, démarre juste le browser en le préfixant de la variable NPW_USE_VALGRIND=yes.
Par exemple:$ NPW_USE_VALGRIND=yes NPW_VALGRIND_OPTIONS="--leak-check=full" firefox file:///path/to/file.pdf 2>&1|tee l
Ca fait un peu fonctionnalité secrète mais a priori ce n'était utile que pour moi. ;-) Ah oui, si tu vois une tripotée de variables utilisées avant d'être initialisées, t'en fais pas, c'est "normal" pour les plug-ins d'Adobe, ou bien est-ce valgrind qui ne détecte pas bien ces cas?
Pour info, Intel, enfin Tungsten Graphics|VMware, utilise également TTM pour certains de leurs drivers. Par ailleurs, vous pouvez consulter le Wiki de X.org pour plus d'informations sur le TTM: http://www.x.org/wiki/ttm
Désolé, mais le Dell Mini 9 est basé sur un Atom N et un GMA900 (i945). Aucun des deux ne fournit d'accélération matérielle du décodage vidéo.
Quant à utiliser des shaders, je crois que ce n'est pas trivial non plus à gérer. De toutes façons, je pense pas qu'une telle approche ait un avenir car la plupart des puces du moment possèdent une unité de décodage vidéo dédiée, i.e. totalement indépendante de la puce 3D. Ainsi, si l'on peut croire Wikipedia (ahem), la partie graphique du Poulsbo est en fait double: un SGX535 (puce 3D), et un VXD370 (puce de décodage vidéo). D'ailleurs, ce ne sont pas des technologies propres à Intel, et c'est pour cela que, je pense, il y aura peu de chances d'avoir des drivers libres.
A priori, sans doute jamais venant d'AMD ou de NVIDIA. L'un et l'autre ayant leurs propres solutions: XvBA et VDPAU. Cependant, dans la mesure où VDPAU fournit un niveau de possibilités supérieur à VA API mais que ce dernier nécessite de détailler davantage les blocs de contrôle, on peut tout à fait imaginer de créer un backend VDPAU pour VA API. Idem pour XvBA. Ca fait un peu solution du pauvre (ne pas taper direct soi même dans le HW), mais au moins, ça permettra de ne conserver qu'une seule API. Parce que bon, 3 APIs ça va 5 minutes pour jouer/tester, mais à maintenir pour un vrai produit, c'est nul...
Avec une bonne architecture logicielle et une méthodologie rigoureuse, il n'y a pas à chercher un juste milieu: tu obtiens les deux critères d'un coup. Et, typiquement je pense, les problèmes de sécurité étant des buffer overflow, c'est bien quelque chose qui peut-être facilement évité avec un peu de rigueur...
Bref, les OEMs se sont mechamment plantes dans leur config, le SP3 lui-meme n'etait pas la cause du probleme, sur une installation correcte il s'installait sans probleme, et on ne peut evidemment pas garantir une installation correcte du SP sur une mauvaise image.
Tu t'auto-trolles je pense. Tu dis que Microsoft prend le temps de tester avant de sortir des updates. Or, tu sais très bien que le gros du business de Microsoft est l'OEM et ils n'auraient pas rencontré ces problèmes avant?
Et puis, si l'image était incorrecte, genre il manquait typiquement un module, non? Dans ce cas, pourquoi ne pas l'installer pendant la mise à jour? Ce n'est pas très compliqué de détecter les composants HW d'un système et d'en installer les éléments manquants lors d'une mise à jour... Au pire, sachant que ça ne fonctionnerait pas, le logiciel de mise à jour pourrait en interdire l'installation.
Après, il y a peut-être un problème architectural dans l'OS de Microsoft qui empêche de prendre ce genre de mesures.
Le plugin utilisera toujours autant de RAM qu'il soit exécuté via le browser en direct ou via nspluginwrapper. i.e. ce que tu économises dans Firefox, tu le retrouves dans le process de nspluginwrapper. Idem en terme d'occupation CPU, c'est juste que tu le vois plus facilement via nspluginwrapper vu que c'est un autre process...
En fait, tu voudrais une ABI ILP32 qui utilise un seul registre pour représenter un pointeur 64-bit? Cela n'avait pas été spécifié pour Linux. Des gens n'y voyaient pas vraiment d'intérêt à l'époque non plus pour prévoir cela au niveau CPU. Par contre, ce modèle est effectivement usuellement implémenté pour MIPS (pour se cadrer sur l'ABI N32 de SGI), ou IA-64 (mais HP-UX uniquement, pas Linux).
Pour x86_64, des patches existent je crois chez Code Sourcery pour VxWorks. Par contre, ça utilise le préfixe addr32 ce qui n'est pas recommandé (en termes de performances, selon les docs d'Intel).
La JVM server consomme plus de mémoire vive, démarre les logiciels un peu plus lentement mais, en contrepartie, compile bien plus de bytecode en code natif.
Ce n'est pas tout à fait exact. En fait, il y a des optimisations de code plus poussées et comparables à un compilateur statique dans HotSpot server. Par exemple, dans mon souvenir, HotSpot server fait une allocation de registres par coloration hiérarchique de graphe alors que HotSpot client utilise l'algo linear scan (variante de Poletto?). Une autre différence, je crois, c'est que hotspot server optimise au niveau super bloc (traces) alors que hotspot client le fait "juste" au niveau bloc de base. HotSpot server ferait aussi de l'inlining et de la spécialisation de méthode.
La forme est abrupte mais, dans le fond, Ulrich a raison et ça fait quelques années que plus personne ne prend de tarballs "officiels" pour builder la glibc, un peu comme pour binutils ou gcc d'ailleurs.
Un point qui a sûrement motivé Roland (l'autre mainteneur) de ne plus se taper les tarballs à faire était sûrement que la glibc tourne principalement sous Linux et tous les distributeurs/maintainers utilisaient justement des snapshot CVS depuis des années.
Prendre au moins le CVS de la branche stable te soulage de quelques (enfin, plus d'une dizaine) patches que tu aurais appliqués par la suite de toutes façons... IOW, pour quelque chose d'aussi critique que la glibc, ça ne sert pas à grand chose de chercher des fixes qui existeraient déjà dans le CVS.
Bah, il y a des phrases types dont on reconnaît facilement les auteurs. Et "Tarballs are a completely outdated concept" était à coup sûr une phrase d'Ulrich. ;-) Il en a écrit de bonnes, il doit faire un concours avec Linus je pense.
C'est tout à fait possible, et Fedora est déjà assez bas, mais ça s'améliore petit à petit. Les pires de toutes sont Ubuntu, Debian, Gentoo, dans cet ordre (vers la pire) et selon mes critères d'un point de vue utilisation, organisation, et développement.
Si on osait caser la compatibilité i386, je pense que l'on pourrait aussi avoir un mode 32 bits plus rapide que le 64 bits sur x86_64.
Il n'est pas possible d'utiliser les nouveaux registres en mode 32-bit. IIRC, il avait existé un tel mode dans les premiers prototypes mais personne n'en voulait à l'époque...
Cependant, on pourrait imaginer une ABI ILP32 en long mode, donc avec tous les registres, en utilisant le préfixe ADDR32 pour forcer des load/stores en 32-bit d'adresse[*]. Mais ce genre de LCP n'est pas un usage recommandé et nécessite quelques cycles supplémentaires pour le décodage, dans mon souvenir sur de l'Intel en tout cas. Par contre, il me semble que la nouvelle ABI de vxworks suive un modèle similaire de nos jours.
[*] Au niveau organisation des libs, j'avais imaginé que cela se case dans du */lib32 (comme les équivalents mips N32) vs du */lib (mips O32), et le x86_64 dans */lib64, classiquement. C'est pour ça, et pour d'autres raisons, que je maudis toutes les distributions qui bâtardisent ce système en conservant les libs 64-bit dans */lib et poussent le vice à créer spécialement du */lib32 pour du i386 legacy, ce qui est un total non-sens...
En fait, tout dépend du type de ton application. Un media player par exemple se fait très bien avec Clutter ou Pigment. Ce dernier est le coeur d'Elisa, le media center de Fluendo, avec beaucoup de Python donc tu pourrais y trouver ton bonheur.
Ceci dit, je préfère nettement Clutter. Malgré sa jeunesse, elle fait déjà pas mal de choses que Pigment ne gère pas apparemment. La prise en main me semble intuitive malgré GObject (le C++ du pauvre^Wgtk). Elle supporte OpenGL ES aussi.
Je précise que Clutter fournit la base (canvas, événements, effets, etc.) et pas de widgets (boutons & co). Il en est de même pour Pigment. Donc, si tu veux un toolkit avec des widgets complets, il faudrait se tourner vers une autre solution ou bien les implémenter soi-même.
PS: j'utilise un snapshot de Clutter/trunk d'il y a un mois + "quelques" autres patches, ça me convient tout à fait.
J'avais lu pas mal d'articles dénonçant le manque de mises à jour de firmware de la part de Nokia, un peu comme s'ils laissaient tomber le E65 au profit du E51. Ca marche bien quand même, y compris pour le Wifi? C'est important pour moi, surtout que j'ai un Freephone et je peux donc récupérer tous les 2 mois mes certificats. ;-)
Au fait, j'ai lu également que le E65 proposé par Orange (à 89 EUR avec abonnement 2+ ans) est assez bridé même si l'abonnement au final est moins cher que chez SFR (et ce, même s'ils le proposent à 69 EUR). En l'espèce, les fonctions Wifi seraient assez limitées. Je vais donc sans doute passer chez SFR pour 2 ans, c'est pas un pb en attendant que Free arrive peut-être à déployer son réseau. Mais je voudrais m'assurer de la qualité du téléphone. ;-)
Il y aussi les options de compilation des logiciels ou des bibliothèques.
Il est clair aussi que ce n'est pas le compilateur qui va auto-améliorer les algorithmes inefficaces de certains développeurs. Par ailleurs, des optimisations à d'autres niveaux (e.g. glibc / DT_GNU_HASH) permettent aussi d'avoir des gains d'un autre ordre, par exemple réduction des temps de chargement des applications dans ce cas-là.
D'une manière générale, sur du x86 par exemple, il n'est pas raisonnable d'attendre des gains de performances importants uniquement par de magiques incantations du compilateur. Y compris pour l'auto-vectorisation, actuellement.
Cela dit, sur d'autres architectures type in-order (e.g. ia64, Cell) où la sélection et l'ordonnancement des instructions sont importants, le compilateur peut pas mal aider. e.g. sur Cell, -mtune=cell (+ -mno-gen-microcode, implicite sur certains compilateurs) permet des gains en moyenne de +10% et des peaks à +34%. En outre, ça aide les applications multithreadées.
L'AMD64 (athlon64, opteron, etc.) "gobe" aussi bien du code optimisé pour -march=nocona que pour -march=athlon64. Certaines distributions préféraient alors compiler en -mtune=nocona (affecte le scheduling uniquement), où les gains étaient plutôt sensibles sur les flottants (SSE) sur des processeurs EM64T. De nos jours, tout le monde utilise -mtune=generic qui représente un compromis intéressant pour les deux parties.
Donc il n'est pas étonnant que les gains éventuels obtenus dans ses tests soient très marginaux (< 2%). En plus, soyons clairs, ça représente 3 fps sur 222. i.e. rien du tout pour ton oeil...
[^] # Re: Prix public?
Posté par Gwenole Beauchesne . En réponse à la dépêche Emtec lance le programme One Laptop Per Hacker. Évalué à 3.
Quant à l'estimation des performances, je pense que l'avocat s'est trompé ou est très imprécis/incertain. Il a sans doute voulu le faire par rapport à leurs propres technologies/produits passés. Ce chiffre de 80%, tout d'abord, c'est 80% de quoi (quel coeur?), à quelle fréquence? Ensuite, la solution la plus rapide qu'Intel ait produite est purement logicielle.
Les performances de IA-32 EL sont de 65% de la performance native sur les entiers, i.e. comparaison binaire x86 via IA-32 EL et binaire IA-64. Par rapport à un x86 réel, c'était très appréciable: 5% plus rapide qu'un Xeon @ 1.6 GHz, l'Itanium 2 n'était qu'à 1.5 GHz.
Source: http://www.microarch.org/micro36/html/pdf/goldenberg-IA32Exe(...)
Ensuite, on peut voir aussi que les performances de l'émulateur HW pour IA-64 étaient... euh, assez faibles pour le dire poliment. Pour s'en rendre compte, l'équipe de DynamoRIO avait travaillé sur un accélérateur logiciel (pré-datant IA-32 EL) qui consistait à produire du code IA-64 (natif donc) pour des hot traces et laisser faire le mode IA-32 du CPU pour le reste. Et bien, les performances du logiciel étaient meilleures que l'émulateur HW de 40% environ, malgré le surcoût des mode switches induits. Et encore, c'était qu'un essai, pas avec une armada de technos d'optimisations du moment. Donc en aucun cas, les solutions d'émulation x86 HW d'Intel pouvaient atteindre ces fameux 80%. Source: http://www.cag.lcs.mit.edu/rio/tim-meng-thesis.pdf
Encore une fois, l'émulation HW x86 est très complexe. Et encore plus pour le mode privilégié (segmentation, page tables, etc.). On verra bien s'ils s'en sortent au niveau perfs. Je dirais inférieures ou équivalentes à un Atom à 1 GHz. Pure spéculation, bien sûr. ;-)
[^] # Re: Prix public?
Posté par Gwenole Beauchesne . En réponse à la dépêche Emtec lance le programme One Laptop Per Hacker. Évalué à 4.
Pour l'AVX d'Intel:
http://software.intel.com/sites/avx/
Pour le SSE5 d'AMD:
http://developer.amd.com/CPU/SSE5/Pages/default.aspx
[^] # Re: Prix public?
Posté par Gwenole Beauchesne . En réponse à la dépêche Emtec lance le programme One Laptop Per Hacker. Évalué à 2.
En fait, je le casais dans 2010 dans une configuration accessible à des vrais gens. Dans mon souvenir, c'était d'abord prévu pour des serveurs. C'est clair que du quad core sous 10W, c'est balaise. De quand date le tape-out du Godson 3? Pour comparaison, le 2F c'était en juillet 2007, et les premiers produits Lemote sont sortis en février ou juin 2008 je crois, on a donc un peu de marge hein. ;-)
Il semblerait que le Godson 3 soit en mesure d'émuler les instructions x86
Oui, et s'ils le font en HW, on va voir s'ils se sont mieux débrouillés que IBM (PowerPC 615) ou même Intel (Itanium).
À mon avis, on a plus d'opportunités d'optimisation au niveau SW que HW car on a une vision plus grande que le CPU au niveau de son décodeur. e.g. cache de code natif plus grand, élimination du calcul de certains codes condition, optimisation de traces, spécialisation de fonction, et même appel d'équivalents natifs (cf. Transitive, entre autres). Mais je crains que leur ambition initiale était d'émuler un x86 intégralement (mode privilégié compris) de sorte à exécuter Windows...
On pourrait croire qu'il "suffit" de caser un décodeur x86 -> ISA interne dans le CPU et hop ça roule, mais la réalité n'est pas si simple. Il me tarde de voir cela, et là, c'est sûr que je m'en prends un pour l'exploit technologique!
[^] # Re: et java
Posté par Gwenole Beauchesne . En réponse à la dépêche nspluginwrapper 1.2.0. Évalué à 3.
[^] # Re: Prix public?
Posté par Gwenole Beauchesne . En réponse à la dépêche Emtec lance le programme One Laptop Per Hacker. Évalué à 4.
Ah, autre chose, il ne faut pas se méprendre, les chinois ont montré leur capacité à designer des CPUs potables. Bien sûr, il manque un GPU voire un VPU qui tienne la route, mais au niveau CPU pur, ils ont bien progressé. J'attends de voir s'ils oseront implémenter l'AVX d'Intel, pas au niveau encodage/format des instructions, mais bien au niveau des mnémoniques comme ils ont fait pour leur MMX-like. Ca, ce serait encore plus impressionnant: émulation x86 "contemporaine", captation facile de développeurs maîtrisant déjà ce jeu d'instruction, etc. Soyons fous, rêvons un peu... ou pas. ;-)
C'est 2010 qui sera intéressante au niveau CPU je pense. 2009 le serait juste au niveau logiciel pour se mettre à niveau/supporter les technologies du moment.
# Prix public?
Posté par Gwenole Beauchesne . En réponse à la dépêche Emtec lance le programme One Laptop Per Hacker. Évalué à 10.
Un exemple, un constructeur qui n'a pourtant pas l'habitude de casser ses prix mais plutôt de se remplir les poches avec des machines sous-équipées, Dell: le Mini 12 est proposé à 399 EUR. Il a un écran plus grand (12"), 1 Go de RAM, 40 Go de DD et... un Poulsbo pour le décodage HW de vidéos.
Le G-dium n'a aucune puce de décodage vidéo, ni de puce 3D. Bon, le SM502 sait faire du yuv2rgb en HW, mais ce n'est bon que pour implémenter Xv, pas pour offloader des vidéos. Même si le Godson 2F est plus performant que l'Atom Z à 1.33 GHz (je dirais même 1.6 GHz aussi), c'est pas pour autant qu'il saura décoder des vidéos dans une empreinte énergétique potable, voire juste pouvoir les décoder en fait. À moins de transcoder ses fichiers avant de partir avec le portable. Après, ça dépend de l'utilisation qu'on souhaite en faire.
À noter aussi qu'une pléthore de netbooks sous Atom Z + Poulsbo devrait être lancée en H1 2009, dans une gamme de prix sans doute inférieure au Dell mais en 10". Ceux-là seront les concurrents du G-dium. Puis, H1 2010 verra arriver les plate-formes en Intel Moorestown, avec un gros SoC (CPU + GPU + VPU + I/O). Tiens, peut-être qu'AMD aussi, mais j'ai un peu perdu espoir.
Cela dit, c'est toujours intéressant d'avoir du MIPS, ça fait un autre jouet architectural. ;-) Surtout la partie SIMD inhabituelle pour cette famille. i.e. ce n'est pas du MIPS-3D/MDMX mais ça ressemble plutôt à du MMX d'après les patches GCC. C'est assez pratique d'implémenter des instructions aux sémantiques équivalentes à du MMX, surtout si l'on veut émuler du x86 en SW, voire en HW s'ils insistent vraiment même si l'autre approche est meilleure à mon sens.
[^] # Re: mem leak
Posté par Gwenole Beauchesne . En réponse à la dépêche nspluginwrapper 1.2.0. Évalué à 9.
Si tu suspectes encore des fuites de mémoire dans la version 1.2.0, il est également possible de ne lancer valgrind que sur nspluginwrapper, et donc les plug-ins, i.e. on ne s'embête pas à valgrind'er sur tout le browser. Pour ce faire, démarre juste le browser en le préfixant de la variable NPW_USE_VALGRIND=yes.
Par exemple:
$ NPW_USE_VALGRIND=yes NPW_VALGRIND_OPTIONS="--leak-check=full" firefox file:///path/to/file.pdf 2>&1|tee lCa fait un peu fonctionnalité secrète mais a priori ce n'était utile que pour moi. ;-) Ah oui, si tu vois une tripotée de variables utilisées avant d'être initialisées, t'en fais pas, c'est "normal" pour les plug-ins d'Adobe, ou bien est-ce valgrind qui ne détecte pas bien ces cas?
[^] # Re: GEM précisions
Posté par Gwenole Beauchesne . En réponse à la dépêche Le noyau Linux 2.6.28 est disponible. Évalué à 2.
[^] # Re: Apport de Gallium3D pour VA API ?
Posté par Gwenole Beauchesne . En réponse au journal Support VA API pour MPlayer. Évalué à 6.
Quant à utiliser des shaders, je crois que ce n'est pas trivial non plus à gérer. De toutes façons, je pense pas qu'une telle approche ait un avenir car la plupart des puces du moment possèdent une unité de décodage vidéo dédiée, i.e. totalement indépendante de la puce 3D. Ainsi, si l'on peut croire Wikipedia (ahem), la partie graphique du Poulsbo est en fait double: un SGX535 (puce 3D), et un VXD370 (puce de décodage vidéo). D'ailleurs, ce ne sont pas des technologies propres à Intel, et c'est pour cela que, je pense, il y aura peu de chances d'avoir des drivers libres.
[^] # Re: VA API dans drivers nvidia et AMD?
Posté par Gwenole Beauchesne . En réponse au journal Support VA API pour MPlayer. Évalué à 5.
[^] # Re: C'est un choix, çà ?
Posté par Gwenole Beauchesne . En réponse au journal Vitesse vs. Qualite, vous choisissez quoi ?. Évalué à 4.
[^] # Re: Windows aussi en casse des choses...
Posté par Gwenole Beauchesne . En réponse au journal Vitesse vs. Qualite, vous choisissez quoi ?. Évalué à 8.
Tu t'auto-trolles je pense. Tu dis que Microsoft prend le temps de tester avant de sortir des updates. Or, tu sais très bien que le gros du business de Microsoft est l'OEM et ils n'auraient pas rencontré ces problèmes avant?
Et puis, si l'image était incorrecte, genre il manquait typiquement un module, non? Dans ce cas, pourquoi ne pas l'installer pendant la mise à jour? Ce n'est pas très compliqué de détecter les composants HW d'un système et d'en installer les éléments manquants lors d'une mise à jour... Au pire, sachant que ça ne fonctionnerait pas, le logiciel de mise à jour pourrait en interdire l'installation.
Après, il y a peut-être un problème architectural dans l'OS de Microsoft qui empêche de prendre ce genre de mesures.
[^] # Re: la vraion raison
Posté par Gwenole Beauchesne . En réponse au journal Flash version 64 bits pour linux exclusivement!. Évalué à 3.
[^] # Re: la vraion raison
Posté par Gwenole Beauchesne . En réponse au journal Flash version 64 bits pour linux exclusivement!. Évalué à 2.
Pour x86_64, des patches existent je crois chez Code Sourcery pour VxWorks. Par contre, ça utilise le préfixe addr32 ce qui n'est pas recommandé (en termes de performances, selon les docs d'Intel).
[^] # Re: la vraion raison
Posté par Gwenole Beauchesne . En réponse au journal Flash version 64 bits pour linux exclusivement!. Évalué à 4.
Ce n'est pas tout à fait exact. En fait, il y a des optimisations de code plus poussées et comparables à un compilateur statique dans HotSpot server. Par exemple, dans mon souvenir, HotSpot server fait une allocation de registres par coloration hiérarchique de graphe alors que HotSpot client utilise l'algo linear scan (variante de Poletto?). Une autre différence, je crois, c'est que hotspot server optimise au niveau super bloc (traces) alors que hotspot client le fait "juste" au niveau bloc de base. HotSpot server ferait aussi de l'inlining et de la spécialisation de méthode.
[^] # Re: et d'un !
Posté par Gwenole Beauchesne . En réponse au journal Flash version 64 bits pour linux exclusivement!. Évalué à 3.
Sans doute pour la 3.1 car il existe déjà des binaires x86_64 pour les nightly builds.
[^] # Re: Releases are available by CVS branch checkout only.
Posté par Gwenole Beauchesne . En réponse au journal glibc m'a tuer. Évalué à 3.
Un point qui a sûrement motivé Roland (l'autre mainteneur) de ne plus se taper les tarballs à faire était sûrement que la glibc tourne principalement sous Linux et tous les distributeurs/maintainers utilisaient justement des snapshot CVS depuis des années.
Prendre au moins le CVS de la branche stable te soulage de quelques (enfin, plus d'une dizaine) patches que tu aurais appliqués par la suite de toutes façons... IOW, pour quelque chose d'aussi critique que la glibc, ça ne sert pas à grand chose de chercher des fixes qui existeraient déjà dans le CVS.
[^] # Re: Releases are available by CVS branch checkout only.
Posté par Gwenole Beauchesne . En réponse au journal glibc m'a tuer. Évalué à 0.
[^] # Re: Releases are available by CVS branch checkout only.
Posté par Gwenole Beauchesne . En réponse au journal glibc m'a tuer. Évalué à 1.
Mais d'un autre côté, l'accès à CVS a toujours été mentionné et, comme tout développeur(?), tu n'y serais pas allé jeter un oeil?
[^] # Re: pire?
Posté par Gwenole Beauchesne . En réponse au journal x86_64. Évalué à 1.
C'est tout à fait possible, et Fedora est déjà assez bas, mais ça s'améliore petit à petit. Les pires de toutes sont Ubuntu, Debian, Gentoo, dans cet ordre (vers la pire) et selon mes critères d'un point de vue utilisation, organisation, et développement.
[^] # Re: soixante-quatre bites powaaaa !
Posté par Gwenole Beauchesne . En réponse au journal x86_64. Évalué à 1.
Il n'est pas possible d'utiliser les nouveaux registres en mode 32-bit. IIRC, il avait existé un tel mode dans les premiers prototypes mais personne n'en voulait à l'époque...
Cependant, on pourrait imaginer une ABI ILP32 en long mode, donc avec tous les registres, en utilisant le préfixe ADDR32 pour forcer des load/stores en 32-bit d'adresse[*]. Mais ce genre de LCP n'est pas un usage recommandé et nécessite quelques cycles supplémentaires pour le décodage, dans mon souvenir sur de l'Intel en tout cas. Par contre, il me semble que la nouvelle ABI de vxworks suive un modèle similaire de nos jours.
[*] Au niveau organisation des libs, j'avais imaginé que cela se case dans du */lib32 (comme les équivalents mips N32) vs du */lib (mips O32), et le x86_64 dans */lib64, classiquement. C'est pour ça, et pour d'autres raisons, que je maudis toutes les distributions qui bâtardisent ce système en conservant les libs 64-bit dans */lib et poussent le vice à créer spécialement du */lib32 pour du i386 legacy, ce qui est un total non-sens...
# Clutter
Posté par Gwenole Beauchesne . En réponse au journal Librairie graphique pour prototype d'application embarquée ?. Évalué à 2.
Ceci dit, je préfère nettement Clutter. Malgré sa jeunesse, elle fait déjà pas mal de choses que Pigment ne gère pas apparemment. La prise en main me semble intuitive malgré GObject (le C++ du pauvre^Wgtk). Elle supporte OpenGL ES aussi.
Je précise que Clutter fournit la base (canvas, événements, effets, etc.) et pas de widgets (boutons & co). Il en est de même pour Pigment. Donc, si tu veux un toolkit avec des widgets complets, il faudrait se tourner vers une autre solution ou bien les implémenter soi-même.
PS: j'utilise un snapshot de Clutter/trunk d'il y a un mois + "quelques" autres patches, ça me convient tout à fait.
[^] # Re: E65
Posté par Gwenole Beauchesne . En réponse au journal Téléphone portable. Évalué à 1.
Au fait, j'ai lu également que le E65 proposé par Orange (à 89 EUR avec abonnement 2+ ans) est assez bridé même si l'abonnement au final est moins cher que chez SFR (et ce, même s'ils le proposent à 69 EUR). En l'espèce, les fonctions Wifi seraient assez limitées. Je vais donc sans doute passer chez SFR pour 2 ans, c'est pas un pb en attendant que Free arrive peut-être à déployer son réseau. Mais je voudrais m'assurer de la qualité du téléphone. ;-)
[^] # Re: Il n'y a pas que les options du compilateur
Posté par Gwenole Beauchesne . En réponse au journal Comparatif entre Debian compilé contre Debian générique.. Évalué à 6.
Il est clair aussi que ce n'est pas le compilateur qui va auto-améliorer les algorithmes inefficaces de certains développeurs. Par ailleurs, des optimisations à d'autres niveaux (e.g. glibc / DT_GNU_HASH) permettent aussi d'avoir des gains d'un autre ordre, par exemple réduction des temps de chargement des applications dans ce cas-là.
D'une manière générale, sur du x86 par exemple, il n'est pas raisonnable d'attendre des gains de performances importants uniquement par de magiques incantations du compilateur. Y compris pour l'auto-vectorisation, actuellement.
Cela dit, sur d'autres architectures type in-order (e.g. ia64, Cell) où la sélection et l'ordonnancement des instructions sont importants, le compilateur peut pas mal aider. e.g. sur Cell, -mtune=cell (+ -mno-gen-microcode, implicite sur certains compilateurs) permet des gains en moyenne de +10% et des peaks à +34%. En outre, ça aide les applications multithreadées.
[^] # Re: ...
Posté par Gwenole Beauchesne . En réponse au journal Comparatif entre Debian compilé contre Debian générique.. Évalué à 4.
Donc il n'est pas étonnant que les gains éventuels obtenus dans ses tests soient très marginaux (< 2%). En plus, soyons clairs, ça représente 3 fps sur 222. i.e. rien du tout pour ton oeil...