reno a écrit 3881 commentaires

> merci pour ta réponse, le coup du "modulo 7 pas efficace" m'a calmé :)

Euh, il ne faudrait pas me prendre pour un gourou, hein!
Il me *semble* que le modulo ce n'est pas efficace (pas d'instruction pour ça directement) et faire mieux que la fonction de gtk n'est pas si facile, c'est quand même juste un load, la mémoire est lente certes, mais ça ne fait quand même pas beaucoup de cycle..

> je pensais que pour tout ce qui était manipulations de bits, l'architecture x86 était la plus aboutie.

Ah? Ca n'est pas ma perception..
En tout cas, je ne l'ai pas trouvé 'count-leading-1' (ou 0) sur x86, ni sur SPARC d'ailleurs (pour ne pas taper que sur x86) et ni sur IA64 (Intel ne m'aide décidement pas).

J'ai répondu a coté: count_leading_1 est très différent de ffs:
count_leading_1 te donne le nombre de 1 consécutif du coté poids fort, pas l'index du premier bit a 1 en partant du coté poids faible comme ffs..

Euh le code C est trivial, le probleme c'est l'efficacité..
J'ai fait un google sur ffs.c et je suis tombé sur:
>>
int ffs(mask)
register int mask;
{
register int bit;

if (mask == 0)
return(0);
for (bit = 1; !(mask & 1); bit++)
mask >>= 1;
return(bit);
}
<<
Et je ne pense pas qu'un compilateur soit capable de remplacer ce code la, par l'instruction assembleur correspondante, pourtant la il s'agit de darwin qui tournait a l'origine sur PPC qui possède cette instruction (enfin l'équivalent qui compte le nombre de 0)..

Quelqu'un a un PPC pour vérifier si ce code est bien compilé en assembleur par un not suivi de cntlzw?
Si oui alors les compilateurs sont vraiment plus fort que je ne le pensais..

En fait, l'instruction qui approxime la table n'est pas le compte du nombre de bit mais le compte du nombre de 1 au début de l'octet:

si x est un octet pour 0<= x < 0xfe
on peut calculer les valeurs de la table tres rapidement par count_leading_1(0x80 | x), ce qui doit se traduire sur les archis ayant count_leading_1 par deux/trois instructions assembleurs s'exécutant chacune en un cycle (difficile de faire mieux!).

Le probleme c'est pour associer 1 a 0xfe et 0xff.

En théorie c'est simple:
(x >= 0xfe) || count_leading_1(0x80 | x)

Mais le || par court-circuit n'est pas forcément efficace, c'est la ou je sèche pour trouver une formule efficace de manière "portable" (enfin efficace pour les archi qui ont count_leading_1, je ne sais pas si elles ont toutes CMOV)..

J'avais envisagé aussi count_leading_1(0x81 | x) %7 mais le modulo ce n'est pas efficace non plus.

count-leading-1 (ou count-leading-0, c'est la même chose a un non-binaire pres) existe sur PPC, ARMv5+, MIPS32, Alpha avec CIX, mais pas les x86 mais bon "x86 sucks" comme d'habitude :-(

Voila, c'est de mémoire, je ne garanti pas qu'il n'y ait pas d'erreur..

Tu peux m'envoyer un mail si tu veux discuter du sujet.

Pas d'accord: AmigaOS était comme ça mais:
1) avec des accélérateurs matériels dédié, BeOS tournait sur des PC normaux , pas de matériel "spécifique".
2) sans protection mémoire!
Ca aide bien pour les performances le fait de ne pas avoir de MMU a gerer: d'ailleurs travaillant chez Microsoft tu doits bien le savoir si tu connais leur recherches sur un OS ne faisant pas appel au MMU pour la protection mémoire (le nom m'échappe): leur papier montre un gain de performance sympa sur les appels systèmes.

Bref BeOS est des temps "moderne" tournant sur des PC normaux donc on peut le comparer a un Linux ou un Windows, AmigaOS ne l'est pas..

De la même manière tu pourrais dire que les antiquités étaient innovantes car elles bootaient très vite, cependant c'était parce que l'OS était en ROM (et une configuration fixe ça aide) ce qui n'est pas très interressant..
Par contre BeOS bootaient en 14s jusqu'a un GUI fonctionnel (pas comme celui d'XP qui est inutilisable au tout début) ce qui est bien rapide que Windows sur mon PC actuel (bien plus puissant) et ne parlons pas de Linux..

>Je me demande quand même combien de gens ont besoin d'écrire des algos bit à bit en C..

Ce n'est pas si fréquent mais ça arrive: un example ou ce serait utile:
http://primates.ximian.com/~federico/news-2005-10.html#31

J'ai essayé de le faire en faisant des manipulations de bit, mais je n'ai réussi a optimiser qu'en utilisant une instruction assembleur qui compte le nombre de bit mis a 1 dans un mot, ce qui n'existe pas sur x86, forcément ça limite beaucoup l'interet de "l'optimisation"..

> il n'invente rien, il est "simplement" bien écrit.

Ce qui pour moi est une innovation, une innovation tellement difficile a faire que Windows et Linux n'ont toujours pas réussi a la reproduire..

Et pourtant si les applications Linux avaient la même réactivité que celles de BeOS avait, ça serait une "killer feature" pour lutter contre Windows, et Linux en a bien besoin..

>AMA Rien de vraiment novateur au niveau OS depuis longtemps.

Bof, c'est que tu ne regardes pas vraiment..

Les applications sous BeOS avait une fluidité supérieure a celle qu'ont Windows ou Linux actuellement sur des machines 10* plus puissante.

Faut-il en déduire que a) les developpeurs de ces applications étaient des dieux b) BeOS étaient un OS novateur (meilleure utilisation du threading)?

Je penche pour (b) personellement..

Et puis au niveau de la sécurité il y a encore pas mal de recherche: EROS et d'autres (dont Microsoft).

Il te reste a prouver que c'est le noyau qui fait une différence entre un OS desktop tel BeOS et une distrib Linux: a mon avis, c'est plutot les surcouches.

>>En avance il y a 10 ans. Si Haïku réussit à sortir une version parfaitement identique au dernier BeOS, comment cela va-t-il supporter la comparaison avec les Linux/Windows/MacOSX de maintenant ?<<

Très bien à mon avis: la réactivité des GUI sous BeOS était bien supérieur a un Linux/Windows/MacOSX de maintenant (et accessoirement sur la vitesse de boot aussi), ce qui est *très* agréable.

Maintenant il restera toujours le probleme du manque d'appli..

Hein?
Ce n'est pas parce qu'ils ont fait quelque-chose de bien sur un modèle qu'il n'y a pas de quoi s'indigner quand ils prétendent être compatible Linux, mais ne le sont pas sur un autre modèle: c'est de la publicité mensongère!

Sympa le gribbag, mais codé 'à la main' une interface graphique, quelque soit le toolkit c'est ch***, pas un défaut de Swing en soit dont j'aime plutot la conception ...
mais beaucoup moins l'implémentation: quand j'avais essayé de l'utiliser c'était buggé jusqu'a la moelle (i18n, impression, etc) et très lent: ça n'a pas du beaucoup changer pour cette partie: les outils d'admin Solaris9 donc fait par Sun (!!!) sont 'escargotesques'.

La FAQ parle de débutant ET de 'cleaning-up' (nettoyage) du kernel, donc ce projet a bien les deux buts: initier les débutants ET nettoyer le kernel.

Ce qui implique bien sûr que le kernel Linux a besoin de nettoyage, pas étonnant sur un projet de cette taille..

Il y a sous Linux des 'coins noir' du kernel comme la gestion des tty, que personne n'ose toucher (ce ne sont pas des projets pour les débutants: trop compliqué), j'ignore s'il y a des problèmes équivalents sur les kernel *BSD..

Et bien en tout cas pour les applications clients .NET c'est pas forcément mieux que Java: l'interface graphique d'ATI pour le controle de leur driver est pathétiquement lente et gourmande.. Une contre pub a l'utilisation de .NET pour faire des interfaces graphiques.

Remarque Java aussi pour les GUI c'est pas ça: même Sun n'arrive pas à faire des GUI en Java propre: l'interface graphique des outils d'administration sur Solaris ont été recodé en Java (pour gérer les disques par exemple), avant c'était une interface assez baroque mais utile et rapide qui a été transformer en un machin pas très pratique ou il faut beaucoup cliqué et d'une lenteur insupportable (au moins sur Solaris 9 pas essayé Solaris10) ..

[ tellement lente que j'ai appris les commandes équivalentes pour éviter d'utiliser l'interface graphique, c'est dire! ]

Et je trouve très ironique c'est que pour une fois les problèmes de license n'ennuient pas FreeBSD pour récupérer du code, mais ennuyent Linux..

La plupart du temps c'est l'inverse!

Ceci dit, c'est quand même dommage cette incompatibilité entre GPLv2 et CDDL: autrement il y aurait pu y avoir DTrace aussi dans Linux et cela aufait fait de DTrace un quasi-standard Unix..

Comme le kernel Linux ne peut pas changer de licences, à moins de réimplémenter DTrace (ou que Sun change sa license mais ce n'est pas près d'arriver non plus: ils le savaient bien qu'ils étaient incompatible GPLv2 dès le départ), cela ne va pas arriver.

Ou plus exactement, il manque les sources de cet élément, pas l'élément en lui-même, ce qui est quand même une grosse différence.

> Si ce que tu dis est vrai

C'est vrai en France je pense.

> un bon chef commande à plusieurs personnes

Un mauvais chef aussi, et ce n'est pas ce qui manque..

> ça va enfin décollé

Oui enfin peut-être: les cartes Intel ne sont que dans les portables et pour AMD-ATI ce n'est pas encore fait..

Mais c'est sur que si ca arrive, cela libérerait Xorg/XGL, mais pour les jeux, ils ne faut pas réver.
Par exemple la majorité des jeux actuels sont fait en Direct3D alors qu'utiliser OpenGL simplifierait beaucoup le portage vers d'autres OS, cela montre bien que les producteurs de jeux n'en ont rien à faire de porter les jeux vers d'autres OS , tout simplement parce que ce n'est pas rentable.

Il y en a qui sont tres sympa a lire: "why userspace suck" qui donne bien un debut d'explication pourquoi Linux boote deux fois plus lentement qu'un BeOS..

Je n'ai pas encore tout lu, mais j'ai bien aimé aussi "The Need for Asynchronous, Zero-Copy Network I/O".

Oui enfin pour le moment, FreeScale va *commencer* a vendre des MRAM de 4-Mbit (pas octet hein, bit) à 25 $ pièce:
http://eetimes.com/news/latest/showArticle.jhtml?articleID=1(...)

Donc si tu fait le calcul, les 128 Go de MRAM, ça fait 6.5 millions de dollar..

Mais oui, on peut espérer que le futur appartienne à la MRAM: avec un temps d'accès de 35ns, un nombre de réécriture quasi-illimité, ça fait saliver..

Note qu'avec google ça doit deja pas etre loin, et puis un ou des deux bookmark plus une recherche, ce n'est pas bien compliqué..

> Au risque d'écrire une énorme bétise ne pourrions nous pas rajouter facilement des sous-titres ?

Gneh? Vas-y commence, j'attends le résultat.

Dire que c'est facile d'ajouter des sous-titres, cela me parait une bétise oui, cela représente beaucoup de boulot AMHA..

Sous Windows (pas tapé), j'ai "optimisé" le volume sonore, en:
- changeant le 'modele' des hauts parleurs
- mettant l'utilisation des hauts-parleurs a 100%
- pareil dans le mode avancé, mettre tout à 100%

Et j'ai obtenu un résultat audible (mais pas très fort) pour la présentation de Keith Packard.
C'est ballot cette histoire de volume: quand j'écoute de l'anglais, pour comprendre j'ai remarqué qu'il faut que le volume soit plus fort que pour le français..

J'ai du tout mettre a fond sur mon PC pour entendre les présentations, bien sur le moindre beep ensuite résonne comme un avion supersonique..

Un gros bémol pour le desktop des particuliers, mais pas pour le desktop en entreprise ou la, on se fiche pas mal du support des jeux..
Et je pense que le desktop Linux commencera par l'entreprise.

Bien sûr en entreprise, il y a d'autre verrous: .doc, outlook, active directory ...