Nicolas Boulay a écrit 16010 commentaires

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é"

La consommation d'une puce est la somme entre la conso dynamique qui est en F*V² et la conso statique qui est proportionnel à la surface à la tension genre S*V.

Aujourd'hui, on doit être à 60% de conso statique. Donc, un gros cortex A8 même à 1V et 26Mhz consommera beaucoup plus qu'un arm9 à 1V et 26 Mhz car il est dix fois plus gros.

ARM était très bon sur les processeurs "purement RISC". Avec les cortex A8, il passe au dual issue (type pentium I), avec le cortex A9, il passe à l'out of order (type PII ou PPC 603). Il inclus aussi une fpu et une unité de calcul vectoriel. C'est assez nouveau pour eux.

Ensuite, il y a le multicore pour l'A9.

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

Les premiers netbook arm devrait être à base de Scorpio de chez Qualcomm. C'est un compatible CortexA8 tournant à 1Ghz avec une unité SIMD 2x plus rapide que celle de base. C'est très bon pour la vidéo.

Le problème reste cependant le même :
- quand on lit un mp3, un arm à 10 mhz suffit largement. Plus, c'est de l'overkill qui bouffe de la batterie. Cela entraine de gros soucis de durée de batterie pour des téléphones qui passent d'une autonomie en semaines, à une autonomie en jour.
- Firefox ou n'importe quel autre navigateur "moderne" a besoin de grosse patate sur un seul cpu. Dans certain cas, même un atom a du mal !

C'est un peu le grand écart entre les 2 mondes. Pas assez d'autonomie d'un coté et pas assez de patates de l'autre.

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

C'est beau de résister au plonkage de newbies. C'est vrai aussi que l'on est tous passé par là.

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

Pour faire Antibes->Valence, j'ai mis 4h30 de route en comptant les arrets.

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

L'arm cortex A9 est une version out of order de l'arm cortex A8. Cela augmente le taux d'execution moyen d'instruction en parallèle mais cela peut aussi augmenter la consommation à cause de la taille de l'étage de gestion de l'out of order.

La fréquence reste aussi un peu basse par rapport à l'atom actuel. Il s'agit aussi des premières puces SMP de arm. Il y a tout un tas de problème spécifique à ce genre d'architecture. Ce n'est pas gagné que cela marche du premier coup. Le sparc Leon devait pouvoir aussi être smp mais il y a un problème "conceptuel" sur la gestion du cache.

Si les arm veulent concurrencé les atom, il faudrait partir sur du quadricoeur. C'est un minimum. De plus, les puces à base d'Arm ont un gros problème de bande passante mémoire (1 bus de 1Go/s pour les cpu+gpu).

J'ai l'impression que les personnes ayant faite l'architecture de SOC qui ont culture de l'arm9 utilisé partout en téléphonie mobile, ont l'impression avec ces cpu rapides, d'avoir une puissance "délirante" qui fait pourtant pâle figure avec le plus petit cpu x86 du marché. Ils ont oublié d'optimisé l'accès à la mémoire, cela se voit dans les temps de latence d'accès à la DRAM.

Bref, c'est pas gagné :)

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