reno a écrit 3886 commentaires

>OpenGL imposait que tout soit fait en hard,

*N'importe quoi*: Mesa une implémentation purement logicielle d'OpenGL existe depuis 1993, Microsoft a acheté l'entreprise qui a fait Direct3D en 1995.
OpenGL est une API pour faire des rendus 2D/3D, c'est l'API et le résultat qui sont spécifiés mais ou est fait le rendu, ça ne l'est pas!

Ton API multi-OS c'est OpenGL, je suis d'accord avec ragoutoutou que Direct3D est un moyen pour Microsoft de lier les jeux avec leur propre API pour diminuer la concurrence (Apple avait fait la même chose, sans succès): il a fallut attendre DirectX 9 pour que J Carmack considère que l'API de Direct3D soit aussi bonne que celle d'OpenGL..

Bah, ils ont probablement utilisé des binaires fournit avec le matériel pour pouvoir faire une démo plus rapidement..
Ca n'a rien de bizarre, développer du code prend du temps.

Il y en a qui ont sous-titré ce dont je les remercie fortement, mais il n'est pas possible que de voire le texte de l'interview sans la vidéo??

C'est mal fichu: lire un texte ça va quand même *beaucoup* plus vite que de regarder une vidéo, alors vu que le travail est fait..

>, il s'est fait plumer parce que en gros M6 l'a invité dans toutes les émissions à la con que cette chaine diffuse......en le facturant pour chaque passage,

Curieux, depuis quand les artistes payent pour passer dans les emissions a la télé?

Bon je ne regarde pas la télé donc j'ignore de quoi il s'agit..

>Admettons qu'ils consacrent un coeur à leur AVX :

Non, je pense que chaque coeur aura son AVX comme a l'heure actuelle chaque coeur a son SSE.

>On a 15 registres 256 bits. En admettant qu'ils arrivent à faire exécuter toutes les opérations en un cycle, avec la possibilité d'exécuter plusieurs opérations en même temps

En général sur chaque coeur une seule operation SIMD est faite a un moment, par contre on peut avoir un load/store et un calcul entier en parallele.

Tes caculs de FLOPS sont plutôt mal fichu, le calcul est:
nombre de coeur * nombre instruction flottante en // par coeur * frequence.
Le nombre de registre n'a rien a voir la dedans..
4 coeur * 4 (a priori) * 3GHz ~= 50 GFlops
Mais bon ce nombre (tout comme celui des GPU) ne veut pas dire grand chose: les performances de la mémoire, des caches ont une grande importance en pratique, ainsi que la facilité de programmation.

Les GPUs sont plus puissantes, mais beaucoup plus dure a programmer donc les unités SIMD ont une niche non-négligeable: c'est beaucoup plus simple de faire un ensemble de librairie de calculs pour SSE (et plus tard AVX )(ça existe déjà d'ailleurs) que pour les GPU (a ma connaissance une libraire n'existe pas encore je crois)..

>GPL c'est libre, ce qui est un cran au-dessus au niveau liberté que OpenSource

Tu chipotes..

[coupé]
>eux par contre aurait le droit d'en faire ce qu'ils veulent, même publier le code source il me semble

Tout a fait, ce qui explique donc pour le GPL n'est pas en général pas payant (ou tres peu) puisqu'il suffit d'un client qui rediffuse l'appli pour que tout le monde puisse la récupérer (légalement) sans payer, donc le GPL payant en théorie ça existe, en pratique pas souvent..
Donc sur le fond tu as raison, c'est quand même assez limite comme argumentation..

Tout a fait. Mais avec en plus des vecteurs 256 bits au lieu de 128 (Altivec et SSE).

256bit = 4*64bit: ça va faire plaisir aux scientifiques qui utilisent des flottants sur 64b et non pas 32b comme pour les jeux.

Bref tout comme SSE..

Sinon tu parlais de compilation: AVX a des instructions a 3 registres (voire 4 pour la multiplication-addition) contrairement au SSE qui modifiait une des sources, ce qui devrait simplifier pas mal le travail du compilateur|programmeur au niveau de la gestion des registres.

Un meilleur lien sur le debat GEM / TTM:
http://aseigo.blogspot.com/2008/05/i915-and-gem.html

Un lien qui montre la différence de performance en GEM et TTM:
http://www.phoronix.com/scan.php?page=news_item&px=NjQ3N(...)

>Je suppose que déjà le système de parallélisation automatique du x86 doit prendre une certaine place sur la puce...

Bof, pas tant que ça maintenant (en pourcentage), c'est pour ça que les x86 ont finis par rattrapper les RISCs..
Je pense que les scientifiques vont être très, très satisfait d'avoir l'AVX, les calculs scientifiques se faisant sur 64bit de précision en général.

>Si on l'enlevait et qu'on passait à du VLIW on devrait gagner une place non négligeable

Pour les VLIW, il reste le probleme du compilateur, a part pour du code tres regulier un VLIW n'est pas exploité au mieux donc ce n'est pas du tout évident que le VLIW soit la bonne voie: le POWER est tout à fait compétitif par rapport a l'Itanium.

Bof, tu sous entends qu'on ne peut pas comparer BeOS et un desktop sous Linux parce qu'ils seraient trop différent?

Je ne suis pas d'accord: Interface graphique évoluée (mis a part les effets 3D récent), protection mémoire, scheduler prémptif, etc BeOS était tres similaire a un desktop Unix (sauf qu'il avait une réactivité bien supérieure)..


Par contre, il y a plusieurs énormes différence entre Windows3.1 et des systèmes d'exploitations moderne (BeOS, Linux et autres):
-scheduler préemptif vs coopératif.
-protection mémoire.
-...

>Sachant que ce qui est lent sous linux, c'est le démarrage des services et la découverte des périphériques

Pas uniquement: KDE tout seul peut mettre plus de temps a demarrer que BeOS n'en mettait pour booter au total (kernel boot+IHM).

>je pense que BeOS n'avait pas beaucoup de service activé par défaut.

Ce qui est une bonne conception, ne serait-ce que du point de vue sécurité..

>Coté driver, il devait être limité

Le matériel compatible était limité oui, mais en quoi cela explique un boot plus lent ou plus rapide?

>mais si j'ai bien compris son architecture micro noyau lui permettait de réutiliser les drivers linux. Donc, la phase d'init est la même.

Non, je ne pense pas que BeOS réutilisait les drivers Linux, ne serait-ce que d'un point de vue licence cela ne passerait pas..

>Il ne faut pas oublier que le kernel Linux utilise du shell pour démarrer dans la plupart des distributions :)

Ce qui donne en final que BeOS sur un Celeron333 mettait moins de 20s pour demarrer (hors BIOS, depuis GRUB jusqu'a l'IHM utilisable), mais une distribution Linux peut mettre facilement plus de 3 fois le temps sur du matériel bien plus puissant.

Ca n'a pas de rapport avec la choucroute juste pour montrer que si un point n'a "pas d'importance" comme le temps de démarrage, au final ça peut devenir du n'importe quoi.

[[DragonflyBSD a une approche différente (sujet du fork originel). Leur proposition est relativement bien documenté sur leur site web.]]

Pour info, le but de DragonflyBSD a changé, au départ c'était effectivement d'utiliser une autre approche pour le SMP, maintenant le centre d'interet sont les clusters..
Donc coté monté en charge en SMP, FreeBSD est beaucoup plus performant que DragonflyBSD..

>Tu parles de sémaphores et de mutex. Tu dis que c'est la même chose ou le laisse entendre.

Bof, il dit juste qu'il y a un mouvement pour remplacer les sémaphore par des mutex.

Le reste, c'est toi qui extrapoles je pense..

>mais Linus a opté pour la seconde.

Non c'est la troisième dans ta liste.

un point que je trouve perfectible aussi, c'est que dans la liste tu marque 'complexifier l'implémentation des sémaphores' ce qui aurait tendance a faire croire que ce serait nouveau, alors que ce n'est pas le cas.. Je mettrais plutôt 'revenir a l'ancienne implémentation (complexe mais performantes) des sémaphores'.

En tout cas, merci pour le poste!

>D'un point de vue théorique avec un petit modèle, son argumentation est idiote.

Ahem, les modèles étant souvent simpliste, ça me parait très exagéré de qualifier une argumentation "d'idiote" sur cette base.

>La consomation est P=k*fV². Si tu ne baisses que la fréquence, tu augmentes le temps de calculs, l'énergie nécessaire pour le calcul est inchangé.

La preuve dans le cas présent: les CPUs attendent souvent la mémoire, les IOs, et se tourner les pouces plus lentement (a frequence plus basse), ça consomme moins d'énergie que le faire plus rapidement..

Si ma mémoire est bonne VIA n'est pas un fondeur, ils utilisent les services de fondeurs tels que TSMC..

J'ai adoré lire cet article qui expose tres clairement les problèmes actuels:
http://radian.org/notebook/sic-transit-gloria-laptopi

Il mérite probablement un sujet indépendant tellement il est bon..

>Si il y a eu des bourdes dans Ubuntu 8.04, Firefox 3 n'en fait pas partie.

Pas d'accord..

>Ce qui aurait crétin, aurait été de faire la maj dans le cycle de support.

La nous sommes d'accord, donc pour moi la seule solution 'correcte' aurait été de rester en FF2 pendant tous le cycle de support: c'est ce genre de chose que fait RHE..

Ou alors il faut renommer LTS, car prétendre avoir un support a long terme en utilisant des beta-versions pour diminuer les futurs couts de support, c'est trompeur je trouve.

Bin pour Fedora ça a un sens, après tout c'est une distrib pour que RedHat integre des nouvelles technos (c'est la même logique qui fait installer KDE4), si tu veux du stable utilise une autre distrib..

Mais pour Ubuntu l'integrer dans une version soi-disant 'support a long terme', je suis d'accord c'est du n'importe quoi.

Avec une bourde pareille, Ubuntu LTS n'est pas près de concurrencer RHE!

La diversité peut aider a faire passer la qualité inferieure: il existe deja des packs de jeux pour Windows..

Dans ces packs la qualité de chaque jeux est n'est pas si elevée que ça..

Bof honetement quand tu regardes les autres laptops, au niveau robustesse, consommation d'energie, ecran lisible au soleil, ils ne font pas trop le poids par rapport a l'OLPC (ok cote puissance CPU c'est le contraire, mais qui s'en soucie?)..

La seule chose que je trouve bizarre dans le projet OLPC c'est que l'approche 'constructioniste', c'est bien beau mais ce n'est pas suffisant et je n'ai pas tellement entendu parler de ce qui se passait pour pouvoir avoir des manuels installable sur les laptops..

J'imagine que ca se fait pays par pays les manuels étant différents, mais on n'en entend pas parler, c'est pourtant un enjeu important je pense..

Il y a plusieurs incohérences dans ses propos:
- il critique les 'fondamentalistes open-source' en disant que c'est à cause d'eux qu'ils n'ont pas pu intégré Flash alors qu'il me semble que la licence d'Adobe empêche de redistribuer Flash.

- d'un coté il critique Sugar en disant qu'il a manqué d'un architecte et de l'autre il dit qu'ils peuvent porter Sugar sur Windows.
Ce n'est pas vraiment incohérent, juste curieux..

- au départ il insistait que le projet OLPC était un projet éducatif le laptop étant juste un support et maintenant le but c'est de mettre un laptop entre les mains de chaque enfants..

Soit ce sont ceux qui rapportent ces propos qui les déforment (ou bien j'ai mal compris), soit j'ai du mal à le suivre..