Nicolas Boulay a écrit 16190 commentaires

les API stables ça marche.

Va dire cela à ceux qui ont du matos qui n'est plus fonctionnelle sous Vista...

Et non, doubler ou tripler l'effort de maintenance pour des bouts externes ne vaut pas le cout. Et je suis persuadé que 80% de la différence de qualité (plantage) entre windows et Linux, c'est justement cette gestion des drivers par le noyau. (sous linux, une bonne source de plantage, c'était le serveur X comme par magie en espace utilisateur, alors que c'est normalement une garantie de stabilité...)

"La première sécurité est la liberté"

Tu veux des "mémoires transactionnelles" en HW? j'ai des doutes sur ce qui est attendu exactement, mais j'ai l'impression que c'est encore un truc complexe que les softeux refilent au hardeux en croyant au Père noël.

"La première sécurité est la liberté"

Disons que la FSF a décidé que le linker doit être stupide pour conserver des performances corrects.

De plus, vu le peu d'info disponnibles, peu d'optimisation sont possible.

"La première sécurité est la liberté"

Tu devrais lire le howto "stable api non sense" de la doc linux.

"La première sécurité est la liberté"

Tu parles de téchno qui font ça au niveau du linker, cela n'existe pas au niveau GNU, justement pour des raisons de perfs.

"La première sécurité est la liberté"

Lisaac est "bydesign" conçu pour mettre en contradiction les gains de perf avec la modularité du code.

Pas du tout, c'est même complètement idiot comme argument. Lisaac favorise la découpe en horizontal et optimise en vertical.

En gros, toute lib est compilé en global mais si tu veux faire des modules pour Linux, tu pourra à terme. Le coté "composant" de Lisaac n'existe pas encore, mais il pourra exister plus tard en ayant toujours la compilation global sur les libs. Le grain est bien plus gros que le fichier C.

"La première sécurité est la liberté"

c'est pas suffisant le git ?

"La première sécurité est la liberté"

sauf que tu doubles la base de code.

Linux passe directement de la case je casse l'API à la case je corrige tous les drivers.

Si l'API introduit une faille de sécurité tu la gardes ?

"La première sécurité est la liberté"

Tu as un exemple ?

"La première sécurité est la liberté"

La modularité dans le design du code est indépendant de la technologie que tu emplois derrière pour faire tourner le tout.

Linux n'est pas un microkernel pourtant tout les sous systèmes sont clairement identifié en interne. Les drivers ont un système objet pour se déclarer et être utilisé par l'OS.

Concernant le coté compile global de Lisaac, c'est une faiblesse qui est à relativiser. La compilation par fichier .c a été faite à cause de la faiblesse des machines de l'époque. Depuis la définition du C, les cpus ont gagné en vitesse, et la raison du saucissonnage du code n'a plus lieu d'être.

On sait que Lisaac doit être capable de gérer des millions de lignes de code. Aujourd'hui, on sait que 50000 lignes se compilent en une dizaine de seconde sur un atom, mais derrière gcc rament franchement (qq minutes ?). Cela laisse de la marge.

"La première sécurité est la liberté"

Un peu comme ceux qui mettent la gui dans le noyau ?

"La première sécurité est la liberté"

Certe mais je ne suis pas sûr que les applications utilisant le pilote soit dans un bon état.

"La première sécurité est la liberté"

C'était l'argument de BFS qui a besoin d'un ARM ou d'un Atom pour que cela soit vrai, vu que c'est déjà faux pour un core duo.

"La première sécurité est la liberté"

Et être hyper fort en HTML n'a pas trop d'intérêt pour faire un OS ou un compilo, bien au contraire.

"La première sécurité est la liberté"

La cote d'azur est étiré le long du littoral. C'est peu dense dés que tu t'éloigne de la côte, un peu le contraire d'un centre ville. Comme beaucoup d'endroit tu te retrouves sur des routes à 90Km/h. Donc, un trajet de 15 minutes en voiture te prendrai plus d'une heure à vélo.

"La première sécurité est la liberté"

?

"La première sécurité est la liberté"

Quand il faut 24 cycles pour atteindre le controlleur DRAM, ce n'est pas seulement un problème de bande passante mais aussi de latence parce que le contrôleur est à l'autre bout du chip.

Les busmatrix ne sont souvent qu'un moyen pour cacher les interconnections sous le tapis. De toute façon tous les flux de données important se font vers ou depuis la RAM.

A la limite, il faudrait juste une connexion en étoile vers le contrôleur mémoire et un APB pour gérer la configuration.

Ou bien encore un gros anneau comme sur certain FPGA ou le cell.

"La première sécurité est la liberté"

J'ai choisi de vivre dans la région, et j'en profite. Et tu sais quoi ? C'est beaucoup moins cher que Paris, et au total pas vraiment plus cher que Nice. Pour le même budget, entre habiter à Nice, et être au calme avec cette vue, j'ai fait mon choix: http://www.360cities.net/image/mougins http://www.360cities.net/image/mougins-le-haut

\o/ copain !

Alors tu es coté mer de verdure ou montagne + autoroute ?n

"La première sécurité est la liberté"

Je pense qu'une version propre, serait un gros NAT + une adresse ipv6 pour un FAI. Les boites se comportant comme des dhcp, il est facile de leur faire faire le choix.

"La première sécurité est la liberté"

Il me semble que c'est toujours l'unique moyen pour prouver son innocence.

"La première sécurité est la liberté"

Il faudrait que fasse la différence entre l'annonce de ARM sur une macro cell et le marché.

Concernant l'arm11 SMP, est-ce que tu connais du vrai silicium ?

Pareil pour le cortex A9, le 4430 n'aura que 2 cores max. Si il sort un jour à 4 cores, cela sera pour dans 1 an minimum.


Heu, sur un cpu arm tu es libre d'avoir le controlleur memoire que tu veux. Et la bande passante du bus AHB (entre le cpu et le controlleur memoire) est assez enorme.

Sauf qu'ils ne le font pas parce qu'ils n'ont pas le même genre de culture que intel/amd. Un chip de téléphone c'était avant tout la basse consommation, une myriade de périphérique, une taille petite, une intégration poussé, un prix bas. Les perfs ne rentraient en compte qu'au niveau du type de cpu ARM embarqué.

La bande passante d'un bus AHB classique est totalement ridicule par rapport au moindre petit x86. Il s'agit avant tout d'un bus 32 bits a vitesse plus faible que celle du cpu ! Dans un athlon64, le contrôleur mémoire est intégré dans le pipeline du cpu.

Pour avoir de la vrai puissance, il faudrait passer aux 64 bits en gardant la même fréquence avec une connexion direct au contrôleur mémoire, voir une connexion par port AHB du Cortex (de mémoire, il en a 2 ou 3, data et code séparé) et ne pas passer par un bus.

"La première sécurité est la liberté"

Tu penses auquel ?

3000 pages, c'est, en gros, pour une ligne par champs de bits. Pour comprendre mieux, il faut la doc de la sous partie.

"La première sécurité est la liberté"

C'est le "race to idle" vs "spread to deadline".

Un cpu intel passe de 35 à 25W en divisant sa fréquence par 2. donc, l'energie par cycle est plus élevé. Donc, cela ne sert que pour contrôler la temperature du chip. Il préfère tomber en idle à 5W.

Sur un ARM, c'est différent. On fait tomber la tension et la fréquence, et on y gagne un peu aussi en énergie par cycle.

"La première sécurité est la liberté"

Je suis le 1er à attendre de vrai pc portable. Les eee s'en approche mais coté poids c'est encore limite (1.5Kg pour avoir >5h d'autonomie)

"La première sécurité est la liberté"

Je n'avais pas vu les 2Ghz. Pour le chip que j'ai connu le 4430, TI parlait toujours de 1Ghz. Donc, 2Ghz, ce n'est pas pour tout de suite.

Concernant la consommation, c'est en comparaison avec l'A8, pas dans l'absolu.

En voyant les premières mesures de perf du 3430 à base de cortex A8, je maintiens mon énorme doute sur les perfs. Les "FSB" sont plus faibles (400Mhz ? en mobile DDR), on parle d'un seul bus de 32 voir 16 bits, des caches de 32Ko.

Sur une autre puce à base de powervr(), j'ai lu que les EFL était plus rapide en soft sur l'ARM qu'en utilisant le GPU à cause de la bande passante mémoire trop faible.

Je maintient que l'on parle de première puce ARM ayant à gérer de la cohérence de cache entre cpu (3430 n'en fait pas entre l'arm et le dsp), ce qui est une nouveauté qu'il est facile de rendre peu performant.

Je ne parle pas non plus du coté usine à gaz du produit. Pour le 3430 qui dispose de 2 cpu (arm+dsp), il y a 3000 pages pour définir les registres. Le 4430 passe à 7 cpus...

"La première sécurité est la liberté"