Articles précédents : Articles
- [1] Moteur XForms libre pour Eclipse/SWT disponible
- [18] Mise en place d'un comité de sélection du lieu des RMLL'07
- [40] Wiktionary et Wikisource : les autres projets de la fondation Wikimedia
- [111] Big Brother Awards 2005
- [47] Débat ouvert autour de DADVSI
- [4] L'Éof présente "Linux pour les débutants"
- [46] Un e-mag pour Mandriva Linux
- [188] DADVSI : c'est reparti
- [25] Les bibliothèques anglaises se préoccupent de la prolifération des DRM
- [0] AperoWeb à Rennes
Liens connexes
- L'annonce : (631 clics)
- OpenSparc : (853 clics)
- DLFP: SUN libère ses processeurs SPARC (681 clics)
Dépêche modérée par
Dépêche éditée par
En perte de vitesse sur le marché des CPU après le début fracassant de l'architecture X86-64 et la très bonne résistance des Power d'IBM, Sun vient de prendre une décision radicale en décidant de publier la description de ses processeurs sous la licence libre la plus célèbre et la plus reconnue.
Après la bascule vers la GPL, n'importe quel fabricant pourra utiliser le design librement, le modifier et produire des microprocesseurs qui resteront eux-mêmes libres.
Richard stallman a salué cette initiative : "The free world welcomes Sun's decision to use the Free Software Foundation's GPL" et tous les libristes peuvent en faire autant.
NdM Il s'agit de la suite de l'article de décembre dernier donné en lien
![[en]](../../../images/en.png)
L'annonce : (631 clics)-
OpenSparc : (853 clics)
![[fr]](../../../images/fr.png)
DLFP: SUN libère ses processeurs SPARC (681 clics)
> Lire la suite (106 commentaires, moyenne: 4,2). [dépêche : 1966 caractères]
C'est évidemment un coup de poker dans l'espoir de regagner des parts de marché qui se sont évaporées au profit de ses concurrents, mais c'est aussi un gain net pour l'ensemble de la communauté du libre.
Celle-ci avait senti depuis longtemps que la prochaine bataille se jouerait sur le hardware et que si les utilisateurs voulaient préserver leurs libertés il serait nécessaire d'avoir des machines libres en plus des logiciels. Les menaces du Trusted computing se précisent, les pressions des majors pour imposer une "chaîne de confiance hardware" augmentent. C'est ce qui explique la naissance de projets comme F-CPU (une tentative de design d'un processeur moderne libre) et de nombreux autres essais. Le succès n'est pas vraiment au rendez-vous du fait de la puissance très réduite des puces ou de la focalisation sur un marché de niche (comme le LEON de l'agence spatiale européenne qui est un processeur compatible Sparc v8 sous LGPL).
Bien entendu, le fait que la conception d'un processeur moderne et puissant soit une tache épouvantablement complexe n'aide pas au décollage de telles tentatives et c'est pourquoi l'annonce de SUN est si importante.
La première spécification disponible est celle de l'UltraSPARC T1 , une puce ultra innovante puisqu'elle propose 8 coeurs simples (in-order) avec 4 threads dans chaque coeur. On obtient ainsi une puce à 1.2 GHz faisant tourner 32 threads simultanément en ne consommant que 72 watts !
C'est bien mais
Produire des cpu ça coûte une fortune! Où trouver l'argent pour les prototypes? Comment être compétitif en taille de gravure?
-
[^]Re: C'est bien mais
Posté par dilbert () le 15/02/2006 à 12:54. (lien). Évalué à 10.Dans les écoles d'ingénieurs bien sûr. Cette nouvelle est du pain béni pour les écoles et universités. Imagine la perle pour un enseignant, pour des projets de diplôme...C'est magnifique! Enfin du concret pour les étudiants!
-
[^]Re: C'est bien mais
-
-
[^]Re: C'est bien mais
Posté par Cédric Leullier (page perso, ) le 15/02/2006 à 13:02. (lien). Évalué à 3.J'y connais pas grand chose, mais cette décision devrait permettre de réduire les frais de recherche et développement, puisque ce sera alors une communauté qui fera évoluer les spécifications. Cela devrait quand même intéresser quelques fondeurs...
-
[^]Re: C'est bien mais
Posté par dark_star () le 15/02/2006 à 13:04. (lien). Évalué à 10.non pas des masses par rapport au devellopement en lui meme du proc. N'importe quelle fondeur chinois peut te couler des series de 100 voir 500. Par email et par carte bleue. ici pas besoin de prototypes.
alors qu'avant tu payais des ingenieur pendant 3 ans, tu achetais des logiciel a 100KE, tu serais les fesses pour ne pas avoir de bug. Tu pleurais a droite et a gauche pour avoir des financement, et tu essayer de trouver un fondeur pour faire une petite serie pour faire des proto.
Si l'europe et les industriel europeens ne sont pas trop nul, il y a quelque choses a faire. cf les universitées, les chercheurs qui pleurent 'yapasdemoyen' etc...-
[^]Re: C'est bien mais
Posté par Jakie Kasperwsky () le 15/02/2006 à 13:47. (lien). Évalué à 8.Je suis tout à faire d'accrods avec toi. Il y a ici un moyen d'avoir un cas d'école pour tous étudiants voulant étudier quelques-chose de pointu et aussi pour les chercheurs de mettre en application leurs théories. C'est une super nouvelle.
Qui peut construire de telle puce ? Tout le monde et c'est ça qui peut faire des progrès énormes en terme de coût et de recherche en R&D. Si SUN donnait aussi une archi de carte graphique sous licence libre, on peut envisager d'avoir des ordis standards fabriqués par milion et ne coûtant presque rien.-
[^]Re: C'est bien mais
Posté par patrick_g (page perso, ) le 15/02/2006 à 13:59. (lien). Évalué à 10.>> on peut envisager d'avoir des ordis standards fabriqués par milion et ne coûtant presque rien.
ahem....je me suis laissé dire qu'une usine de production de puces gravées en 90 nanomètres se chiffre en milliards de dollars.
Faudra bien les amortir et donc facturer les puces en monnaie sonnante et trébuchante. Faut pas croire que l'effet d'échelle va être gigantesque car la compétion sera avec les x86 qui sont déja produits par centaines de millions d'exemplaires et ou il existe une conccurence (Itel,AMD,Via) pour faire baisser les prix.
Sun fait juste ça pour sauver son architecture CPU propriétaire et il ne faut pas s'attendre à une invasion de PC UltraSparc sous Linux à Carrouf !
Les vrais bénéfices c'est :
1) la description libre d'un processeur puissant et moderne pour les étudiants.
2) la possibilité pour des fondeurs alternatifs d'entrer sur le marché.
3) la possibilité pour des pays souverains de se baser sur une informatique non dépendante de firmes étrangères.
4) Une issue de secours en cas de Trusted Computing généralisé.-
[^]Re: C'est bien mais
Posté par imbolcus (page perso, ) le 15/02/2006 à 14:53. (lien). Évalué à 6.Sun fait juste ça pour sauver son architecture CPU propriétaire et il ne faut pas s'attendre à une invasion de PC UltraSparc sous Linux à Carrouf !
peut etre pourrions nous assister a une invasion d'appareils mobiles UltraSparc sous Linux a Carrouf... car dans ce secteur il y a encore une assez grande variete de processeurs...-
[^]Re: C'est bien mais
Posté par djano () le 15/02/2006 à 15:25. (lien). Évalué à 2.Avant ca, il va falloir revoir un peu le design.
Je me suis laisse dire que sa consommation, meme si elle semble faible pour un CPU de serveur reste assez enorme pour un appareil mobile: 70 Watts
premiere sources avec Google + ultrasparc t1 consommation :
http://www.silicon.fr/getarticle.asp?ID=12400
http://www.presence-pc.com/actualite/ultrasparc-t1-12947/-
[^]Re: C'est bien mais
Posté par patrick_g (page perso, ) le 15/02/2006 à 15:57. (lien). Évalué à 9.UltraSparc IIi 650 Mhz
* 17.6 W (max) at 650 MHz, 1.7 V
* Energy star support: 1/2x, 1/6x, reduced clocking
* 2.5 W max in sleep mode-
[^]Re: C'est bien mais
Posté par Jimmy (page perso, ) le 16/02/2006 à 23:14. (lien). Évalué à 5.C'est effectivement pas mal par rapport aux puces x86 dernier cri (qui dépassent allègrement les 100W), mais ca reste bcp trop pour l'embarqué !
Par exemple, des DSP Texas Instruments C5xxx, utilisés dans des téléphones portables, consomment environ 0.33mA/MHz, soit 80mW à 200MHz sous une tension de coeur de 1.2V.
http://focus.ti.com/dsp/docs/dspplatformscontenttp.tsp?secti(...)
Un DSP C6416 à 1GHz consomme moins d'1W, et il a aussi 8 unités de calcul en parallèle (ca compte quand même pour un seul coeur)
http://focus.ti.com/docs/prod/folders/print/tms320c6416t.htm(...)
Un ARM926 consomme environ 0.45 mW/MHz, soit 120mW à 266 MHz. Sans compter les modes d'économie d'énergie.
http://arm.com/products/CPUs/ARM926EJ-S.html
Cela dit, la libération du Sparc (même si c'était déjà un design assez ouvert, cf. LEON) est une excellente nouvelle, car on pourrait voir apparaître des fondeurs-intégrateurs comme il y a des assembleurs de PC taiwanais, produisant à bas coût le design développé par la communauté des électroniciens-libres. Ca pourrait se concerner surtout des mini-PC, du style MacMini ou Mini-ITX, très prisés des geeks que nous sommes ! http://damnsmalllinux.org/store/
De son côté, IBM et Freescale ont également ouvert le design du PowerPC 405 pour les universités, mais apparemment n'importe qui peut devenir membre du consortium de spécification du standard PowerPC. La licence n'a quand même pas l'air libre ... http://www.power.org/home-
[^]Re: C'est bien mais
-
-
-
[^]Re: C'est bien mais
Posté par ZeAuReLiEn () le 15/02/2006 à 16:02. (lien). Évalué à 10.L'Ultrasparc T1 dispose de 8 cores (il existe en version 4 et 6 core je crois), et peut exécuter 4 thread par core (pour un total de 32 core).
Le rapport puissance/consommation apparait donc très bon-
[^]Re: C'est bien mais
Posté par ZeAuReLiEn () le 15/02/2006 à 16:03. (lien). Évalué à 5.Je voulais dire 32 thread, pas 32 core
-
[^]Re: C'est bien mais
Posté par cortex62 (page perso, ) le 15/02/2006 à 19:11. (lien). Évalué à 4.Il est vraiment multicore ? Parce que 8 par rapport à ce qui ce fait, ça fait vraiment beaucoup (pour un processeur libre en plus ).
Question : la gestion du cache mémoire ça ce passe comment ? Parce que la il y a du monde quand même.--
L'erreur est humaine, mais un véritable désastre nécessite un ordinateur.-
[^]Re: C'est bien mais
Posté par bertrand () le 16/02/2006 à 08:10. (lien). Évalué à 10.Le principe est le suivant :
Il execute 32 threads sur 8 cores, donc 4 thread par core.
Les 4 threads d'un core sont exécuté successivement.
Les instructions de chaque thread sont exécutés après les rapatriements de données dans le cache. Les accès mémoires ne pénalisent donc pas le core car, pendant ce temps il exécute une instruction des chacun des 3 autres threads.
C'est du moins le principe. Cela nécessite donc un cache moins grand qu'un processeur monothread.
Si une instruction a besoin d'accèder à 2 adresses mémoires, et qu'il y en a déja une en cache il n'y a pas d'attente par exemple.
Par ailleurs le fait que l'entrelacement des threads soit systématique pemet de l'implémenter très simplement dans le processeur. Il suffit (en très très gros) de basculer a un jeu de registre parmi quatre à chaque période d'horloge.
La contrepartie des 8 cores, c'est qu'ils sont très simple (comparé à un x86-64 ou équivalent).
La performance n'est donc pas identique à un monocore ultra rapide avec un cache monstrueux.
C'est très adapté à des serveurs gérant des processus simple (et si possible identique car besoin de moins de cache d'instruction) en grand nombre, genre serveur web ( Sun n'a pas fait ça par hasard), peut être moins à un desktop quoi que le nombre de processus activé sur un desktop linux classique est non négligeable. Sur des programmes effectuant du calcul intensif et non programmé en multithread la puissance disponible est de 1/32 de la puissance total du processeur.--
Bertrand
-
-
[^]Re: C'est bien mais
Posté par Matthieu Moy (page perso, ) le 16/02/2006 à 07:52. (lien). Évalué à 6.Les besoins en matière de consommation n'ont rien a voir entre les procs de serveurs et ceux d'appareils mobiles.
Dans l'embarqué, un truc qui compte, c'est déjà que le proc ne consomme pas quand il ne travaille pas. Genre ton téléphone portable alumé pendant que tu ne téléphone pas. Les designers ont des techniques assez évoluées pour activer et désactiver l'alimentation d'une partie de la puce selon si elle est en utilisation ou pas.
Ça ne fait pas de l'ultra-sparc un mauvais processeur, mais pour de l'embarqué, j'ai des doutes.
-
-
-
-
[^]Re: C'est bien mais
Posté par Cali_Mero () le 15/02/2006 à 17:10. (lien). Évalué à 3.5) La possibilité pour Intel et AMD d'aller puiser de bonnes idées à peu de frais pour faire évoluer leurs versions du x86. Enfin, s'il y en a à puiser...
--
#define MAGIC 0xdefaced /* I should've patented this number -cliph */-
[^]Re: C'est bien mais
Posté par imalip (page perso, ) le 15/02/2006 à 17:22. (lien). Évalué à 10.Perdu. C'est du GPL. S'ils veulent pouvoir vendre des CPU avec des bouts en provenance de Sun dedans, il faudra qu'ils les passent sous GPL aussi. Et j'ai comme un doute, la...
--
"While a monkey can be a manager, it takes a human to be an engineer" Erik Zapletal-
[^]Re: C'est bien mais
Posté par Cali_Mero () le 15/02/2006 à 17:36. (lien). Évalué à 5.Ce que je veux dire, c'est qui ira vérifier ? Et comment ?
Dans le monde du logiciel, il est facile pour un vendeur peu regardant de "s'inspirer" de code GPL pour améliorer son propre produit non-GPL. Or là on parle de spécifications matérielles, et je n'ai pas souvenir de précédent de la GPL appliquée à ce genre de choses, alors je me demande ce qui les empêcherait de le faire...--
#define MAGIC 0xdefaced /* I should've patented this number -cliph */
-
[^]Re: C'est bien mais
Posté par herodiade () le 15/02/2006 à 18:18. (lien). Évalué à 5.> Perdu. C'est du GPL. S'ils veulent pouvoir vendre des CPU avec des bouts en provenance de Sun dedans, il faudra qu'ils les passent sous GPL aussi. Et j'ai comme un doute, la ...
Le design est GPL.
Je crois qu'il set un peu abusif de parler de "Hardware Libre" en fait, parce que je doute que le fait que les schémas soient sous GPL change quoi que ce soit au droit de redistribution du hardware.
Bref, je ne suis pas sur que dans ce cas, Intel ou AMD soient contraints de reverser leurs propres designs.
Quelqu'un à les idées plus clair que nous sur cette question ?-
[^]Re: C'est bien mais
Posté par herodiade () le 15/02/2006 à 20:02. (lien). Évalué à 7.Après réflexion, je me demande même si, finallement, l'annonce «Sun livre ses designs sous GPL » a plus de portée effective (!= médiatique) que « Sun montre les specs détaillées de ses nouvelles CPU ».
En effet:
- Si dans ce contexte la GPL n'est pas contraingnante sur le matériel produit (distribuer un processeur basé sur un design libre ce n'est pas ditribuer un binaire, le fameux « in either source or binary form » de la GPL), les autres constructeurs ne seront pas contraints de livrer les « sources » de leurs processeurs basés sur le design de Sun. De fait Sun aurait aussi bien pu licencer ses docs sous BSD, CDDL, MIT ou Choucroute Folle, ça n'aurait pas changé grand chose en pratique (sinon l'effet médiatique).
- Si Sun dispose de brevets pour protéger ses innovations matérielles, ils peuvent cependant empécher totalement la fabrication/vente de processeurs inspirés de leurs designs.
Donc en l'attente de précisions sur ces points (type: « Sun ouvre son portefolio de brevets » et « Ils utilisent une version modifiée de la GPL imposant la redistribution des schémas si distributions de procs » ) on sait seulement que les specs du processeur Niagara T1 sont dispos. Point barre. Le reste est exrapolation (ou j'ai fait une erreur dans mon raisonement).
Vu comme ça, ce n'est peut-être finalement pas un évenement extraordinaire :/
-
-
[^]Re: C'est bien mais
Posté par Matthieu C () le 15/02/2006 à 18:24. (lien). Évalué à 5.Sauf que la GPL c'est pas un brevet : tu ne peux pas reprendre le desing tel quel mais rien ne t'empeche de recuperer les bonnes idees et de les implementer a ta sauce....
-
[^]Re: C'est bien mais
Posté par Yth (Jabber id, ) le 16/02/2006 à 09:45. (lien). Évalué à 2.Ce qui en soit ne diffère en rien des logiciels : tu peux sans problème reprendre les idées des autres, tant que tu ne reprends pas de bout de code.
Là tu pourrais reprendre des idées si tu ne reprends pas de bouts de circuit.
Après, dans le cas des Sparc, peut-être que Sun a des brevets sur certaines parties...
Yth.
-
-
-
-
[^]Re: C'est bien mais
Posté par Jakie Kasperwsky () le 15/02/2006 à 23:36. (lien). Évalué à 6."il existe une conccurence (Itel,AMD,Via) pour faire baisser les prix".
Je ne suis pas tout à fait d'accord. La baisse des prix due à la concurrence est assez relative. La concurrence joue surtout sur les performances des processeurs. Pour les processeurs, les coûts de productions sont négligeables par rapport aux coût de lancement (R & D puce et machine + contruction de la ligne de fabrication se compte en effet en milliard de dollars).
En fait Intel pourrait pouduire des processeurs du genre pentium III à 1 GHz assez peu cher puisque qu'il ont les machines pour ça et qu'ils ont déjà amorti les dépense de R & D. Mais ce serait se tirer une balle dans le pied pour eux puisque beaucoup d'utilisateurs s'en contenterai (C'est la puissance de mon partable qui est tout à fait utilisable). Les fondeurs ont les moyens de le faire mais ils savent tous que leurs concurrents sont dans la même situation. C'est d'ailleurs là un des pbm du projet one Laptop Per Child, AMD fourni des processeurs pas cher pour ce projet mais prends aussi le risque de detruire ce model économique. Intel ne voulait pas prendre ce risque.
Au cours de mes quelques cours d'électronique, j'ai retenu que la révolution du domaine pouvait venir d'une architecture très standard bon marché avec Linux dessus et un ensemble de briques logiciel compatibles servant à créer tout un ensemble de services. Les livebox, freebox, ... sont peut-être des précurceurs. UltraSparc ou autre on y viendra de toute façon. Il suffit que quelqu'un commence.
-
-
-
[^]Re: C'est bien mais
-
[^]Re: C'est bien mais
Posté par Matthieu Moy (page perso, ) le 15/02/2006 à 14:08. (lien). Évalué à 9.Pour des petits circuits, je veux bien, mais pour les circuits un peu gros et à la pointe de la technologie, une usine de microelectronique, c'est plusieurs milliards d'euros, le masque avant de produire la première puce, c'est de l'ordre du million d'euros, ...
Les couts fixes pour la production des puces sont énormes. C'est pas pour rien qu'il y a peu de fabriquants de processeurs, et que dans l'embarqué, les entreprises concurrentes s'allient pour construire des usines (cf crolles 2 avec ST, philips et freescale).
Donc, pour la partie design, les universités pourront s'amuser avec, les particuliers et/ou petites entreprises pourront sans doute participer, mais pour la production des puces, ça restera entre les mains d'une poignée de grosses boites.
-
[^]Re: C'est bien mais
Posté par spart () le 15/02/2006 à 14:19. (lien). Évalué à 10.> N'importe quelle fondeur chinois peut te couler des series de 100 voir 500.
mmh, a propos, ce n'est pas la Chine qui a péniblement développé son propre processeur pour ne pas dépendre des fondeurs américains ?
Revons deux minutes... ils reprennent le design du Sparc, l'améliorent, inondent le marché de CPU ultra puissants sous GPL, sur lesquels du reste n'ont été portés que des OS libres...
argh, vite ma pillule...-
[^]Re: C'est bien mais
Posté par GhZaaark3 () le 15/02/2006 à 14:37. (lien). Évalué à 8.Donne m'en deux de tes pillules!!! j'suis traumatisé :)
Et les GPU libres... raghh, j'vais tombé dans les pommes.
C'est du pain béni pour les pays en voie de dev'
Bref c'est du très très fort.
Au moins ce qui est bien avec Sun, c'est que même si ils devaient sentir leur fin arrivé - ce qui n'est pas du tout le cas quand même - ils ne couleront pas avec leur navire.
Si il y a bien une entreprise qui peut prétendre la porteuse d'innovation, c'est bien SUN MicroSystem.--
moué...
-
-
Sympa pour les developpeurs
l'UltraSPARC T1 , une puce ultra innovante puisqu'elle propose 8 coeurs simples (in-order) avec 4 threads dans chaque coeur. On obtient ainsi une puce à 1.2 GHz faisant tourner 32 threads simultanément en ne consommant que 72 watts !
Je veux la même dans ma machine pour mes compilations de moz !
mk_add_options MOZ_MAKE_FLAGS=-j32, ça le fait moi je dit :-) Parce que bon, du -j2, c'est bien beau, mais attendre 30 minutes pour avoir un binaire Gecko, c'est embétant à la longue :-)
Y a ceux aussi qui compilent à longueur de journée du KDE ou du gentoo qui pourraient être interressé :-)
Tanenbaum était un visionnaire ...
Qui l'eu cru .. hein que lors de sa fronde avec Linus Torlvads, Andy Tanenbaum prédisait l'avenir ... avec 15 ans d'avance :)
From: ast@cs.vu.nl (Andy Tanenbaum)
Subject: Re: LINUX is obsolete
Date: 30 Jan 92 13:44:34 GMT
In article <1992Jan29.231426.20469@klaava.Helsinki.FI> torvalds@klaava.Helsinki.
FI (Linus Benedict Torvalds) writes:
>You use this [being a professor] as an excuse for the limitations of minix?
The limitations of MINIX relate at least partly to my being a professor:
An explicit design goal was to make it run on cheap hardware so students ... Making software free, but only for folks with enough money
to buy first class hardware is an interesting concept.
Of course 5 years from now that will be different, but 5 years from now
everyone will be running free GNU on their 200 MIPS, 64M SPARCstation-5.
Fil complet : http://www.oreilly.com/catalog/opensources/book/appa.html
Enfin, bon faut encore faire les machines, faire des distrib compatibles (SparcDriva, Ultrabuntu, UltraOpenSuSe, ), ... on en a encore pour 15 ans ! :)
La chanson est une industrie parce qu’une poignée d’imbéciles a réussi à être moins con que le reste.
(Coluche)
-
[^]xSparcs
Posté par iOops () le 15/02/2006 à 13:11. (lien). Évalué à 1.Où peut on se procurrer se type de machine et à quel coût ?
-
[+] [^]Re: xSparcs
-
[^]Re: xSparcs
Posté par Arnaud (page perso, ) le 15/02/2006 à 22:02. (lien). Évalué à 3.« aucun lien, fils unique »
;-)
-
-
[^]Re: xSparcs
Posté par ∫ầřυårðīņ (page perso, ) le 16/02/2006 à 23:14. (lien). Évalué à 2.ben tu sais, les portables à 100 euros, avec la manivelle pour produire le courant, il y aura peut être un ultra sparc dedans. Et un noyau hurd qui sortira en même temps que la nouvelle Debian ;)
Je rigole, je rigole, cela dit, avec l'ouverture de l'architecture de certains systèmes (ppc, sparc etc.), on risque d'avoir la possibilité de pouvoir sortir des machines complètement libres, cela peut être un beau enjeu--
The elevation of 'faith' is, in fact, a sign that a religious tradition is losing its ability to induce theophany, or has already lost it.
-
-
[^]Re: Tanenbaum était un visionnaire ...
Posté par patrick_g (page perso, ) le 15/02/2006 à 13:32. (lien). Évalué à 8.>> Enfin, bon faut encore faire les machines, faire des distrib compatibles
le machines existent : c'est SUN qui les vend pour l'instant mais cette annonce laisse présager d'autres vendeurs à moyen terme.
Quand aux distribs elles existent aussi ! (Debian Sarge est compatible Sparc...gentoo aussi je crois). Pareil pour NetBSD et OpenBSD.
Si l'union européenne etait visionnaire elle se lancerait à fond dans la production d'UltraSparc. Maintenant qu'ils sont GPL elle assurerait son indépendance technologique et elle aurait une chance de gagner des parts de marché dans un domaine (les CPU généralistes) ou elle n'existe pas.-
[^]Re: Tanenbaum était un visionnaire ...
Posté par GhZaaark3 () le 15/02/2006 à 14:39. (lien). Évalué à 0.Patrick G: c'n'est pas Debian(tm) qui est compatible Sparc, c'est linux-2.X, ce qui revient à dire que toutes les distros peuvent être Sparc compatible.
--
moué...-
[^]Re: Tanenbaum était un visionnaire ...
Posté par gnumdk (page perso, ) le 15/02/2006 à 15:12. (lien). Évalué à 6.>c'est linux-2.X
C'est vrai qu'avec un noyau linux, tu vas aller super loin... Tu crois pas oublié une grosse partie du systeme?
Compiler une distrib GNU/Linux pour la faire fonctionner sur une autre archi, cela ne se fait pas en claquant des doigts... Je me souviens encore il y'a quelques années un membre du PLF qui faisait des builds de mandrake pour sparc, c'etait pas évident et je crois meme que le projet n'existe plus...
-
[^]Re: Tanenbaum était un visionnaire ...
Posté par Sytoka Modon (page perso, ) le 15/02/2006 à 15:12. (lien). Évalué à 4.Entre pouvoir et le faire, il y a une petite différence... Voir les problèmes de debian avec certaines architectures pour compiler à temps les paquets, avoir un parc de machine, tester les logiciels et faire des patch adéquat (X par exemple).
Bref, il y a un grand pas entre avoir un noyau qui tourne et une distribution qui tourne sous une nouvelle architecture. C'est pas pour rien que les 3/4 des distributions se limite au x86.-
[^]Re: Tanenbaum était un visionnaire ...
Posté par mosfet () le 15/02/2006 à 16:04. (lien). Évalué à 3.C'est la qu'intervient NetBSD. Enfin je dis ca je dis rien
-
[^]Re: Tanenbaum était un visionnaire ...
Posté par Sytoka Modon (page perso, ) le 15/02/2006 à 18:01. (lien). Évalué à 4.Le noyau NetBSD est porté sur beaucoup d'architecture. OK. Mais qu'en est'il de X-Windows ?
Les BSD ont leur système de port. Je parlais du système global : distribution. Pour une debian, c'est plus de 1000 paquetages.
Le portage d'une console texte sur une architecture exotique, c'est intéressant mais ce n'est pas tout à fait les mêmes objectifs.-
[^]Re: Tanenbaum était un visionnaire ...
Posté par agmk () le 15/02/2006 à 18:13. (lien). Évalué à 4.>Pour une debian, c'est plus de 1000 paquetages.
Je crois que tu voulais dire "plus de 10000 paquetages". Je me trompe ?--
Wr ar fbhunvgr cnf ha qrfgva sharfgr à yn cncnhgé. Nzra.-
[^]Re: Tanenbaum était un visionnaire ...
Posté par GCN (Jabber id, page perso, ) le 15/02/2006 à 18:25. (lien). Évalué à 3.Ben il avait raison donc !
-
-
[^]Re: Tanenbaum était un visionnaire ...
Posté par herodiade () le 15/02/2006 à 18:42. (lien). Évalué à 5.D'autre part -même à s'en tenir au kernel- le fait que le noyau (Linux, xBSD, yBSD ...) puisse tourner sur une architecture donnée ne signifie pas que cette archicteture soit pleinement supportée.
Par exemple un noyau ne supportant que IA32 peut tourner sur un x86_64 type AMD64 en mode 32 bits, mais dans ce cas c'est, en toute honneteté, un support partiel de l'architecture. À ce sujet, puisqu'on parlait de support SPARC et de Debian, il y a une seule archive Debian/sparc, pas une archive 32 bits et une archive 64 bits -genre Debian/sparc et Debian/sparc64, comme c'est le cas en testing pour i386 32 et 64-: peut-on en déduir que Debian n'utilise les processeurs UltraSPARC qu'en mode 32 bit ? (c'est une question hein, j'en sait rien).
Il en va de même des nombreuses extensions proposées par les processeurs modernes, type Intel/PAE, UltraSPARC/Stackghost, Intel/Silvervale, AMD/Pacifica etc. sans parler de la gestion (ou pas) du SMP et/ou du multihreading sur l'archi concernée ...
Donc dire qu'une distro ou un OS est "sparc-compatible", c'est trop peu dire.
Le Niagara (le proc dont il est question dans l'article) serait bien peu intéressant exploité par un OS tournant en 32 bits et ne sachant pas gérer le SMP SPARC, ni la virtualisation ...
Et puis comme le signalaient les posts parents, le kernel est une chose, le bootloader, la toolchain, les packages, ... en sont une autre: UltraSPARC est une archi délicate sur ce point, car grand boutiste, 64 bits, avec des contraintes d'alignement strictes, bref tout ce qu'il faut pour aimablement lever les bugs des applis développées sur pécé (petit boutiste, majoritairement 32 bits, faibles contraintes d'alignement). Du coup, le travail des packageurs/distributions n'est pas négligeable. Ce n'est pas du « tout cuit ».-
[^]Re: Tanenbaum était un visionnaire ...
Posté par Jimmy (page perso, ) le 16/02/2006 à 23:36. (lien). Évalué à 3.peut-on en déduir que Debian n'utilise les processeurs UltraSPARC qu'en mode 32 bit ? (c'est une question hein, j'en sait rien)
En tout cas, il n'est pas rare de voir un Solaris 32 bits tourner sur un UltraSparc ... cherchez l'erreur.
UltraSPARC est une archi délicate sur ce point, car grand boutiste, 64 bits, avec des contraintes d'alignement strictes, bref tout ce qu'il faut pour aimablement lever les bugs des applis développées sur pécé
C'est clair que le portage peut s'avérer pénible si le code n'est pas bien propre au départ. D'un autre côté, le Sparc a des caractéristiques assez sympa, comme la banque de registres "à glissière" qui permet des changements de contexte très rapides.
J'avais aussi entendu dire qu'un processeur grand-boutiste était un petit peu plus rapide, et que c'est pour ca que tous les CPU RISC utilisent cette orientation (ou sont configurables, comme le MIPS et le PowerPC). Quelqu'un en sait plus ?-
[^]Re: Tanenbaum était un visionnaire ...
Posté par lasher () le 18/02/2006 à 18:22. (lien). Évalué à 3.Bof, en fait les processeurs actuels sont capables de se câbler comme on le désire (oui oui, on peut spécifier à certains procs actuels de fonctionner en little-endian ou en big-endian). Quand on en arrive à ce niveau de généricité, je ne vois pas trop où se pose le problème.
D'autre part, dans mes souvenirs, un de mes profs nous expliquait que d'un point de vue d'électronicien, faire du Big-Endian était plus simple, mais que d'un point de vue d'informaticien, le "penser" était plus difficile (ce qui se conçoit aisément). Bref, le design des puces devient plus complexe en Little-Endian, mais ne pose apparemment pas de problème de perfs significatif.-
[^]Re: Tanenbaum était un visionnaire ...
Posté par Jimmy (page perso, ) le 19/02/2006 à 22:27. (lien). Évalué à 3.les processeurs actuels sont capables de se câbler comme on le désire
Oui, c'est bien ce que je disais : les Mips, les PowerPC, les DSP TI, et sans doute bien d'autres. N'empêche que ces modes ne sont pas compatibles entre eux, et qu'il faut bien choisir lequel on utilise sur une carte donnée. Par exemple, il y a deux branches Mips dans Debian, l'une pour les stations Digital et l'autre pour SGI. http://www.debian.org/ports/mips/
Le standard PC est toujours little-endian, et les standards réseaux sont presque tous big-endian.
d'un point de vue d'électronicien, faire du Big-Endian était plus simple, mais que d'un point de vue d'informaticien, le "penser" était plus difficile (ce qui se conçoit aisément)
Je code quotidiennement pour des cibles embarquées qui utilisent les deux modes. La difficulté, c'est justement qu'on a une chance sur deux, quand on définit un champ de bits pour un registre, de se tromper de sens ... et que pour faire un code portable il faut tout faire en double, avec le risque d'erreur qui en découle.
Est-ce que tu te souviens de ce qui rend plus simple l'un ou l'autre sens selon le point de vue de l'utilisateur ? Parce que comme je suis à mi-chemin entre l'informaticien et l'électronicien, je n'ai pas un avis aussi tranché ;-)-
[^]Re: Tanenbaum était un visionnaire ...
Posté par lasher () le 20/02/2006 à 09:20. (lien). Évalué à 3.les standards réseaux sont presque tous big-endian.
Mmmh.
Quels standards réseaux ? Pour moi, ils étaient TOUS en BIG-ENDIAN :-)
Est-ce que tu te souviens de ce qui rend plus simple l'un ou l'autre sens selon le point de vue de l'utilisateur ? Parce que comme je suis à mi-chemin entre l'informaticien et l'électronicien, je n'ai pas un avis aussi tranché ;-)
Honnêtement, ce n'est pas avec le peu d'électronique que j'ai fait que je pourrai te répondre pour le Big Endian. Pour le little endian, avoir les octets de poids fort dans le "bon sens", c'est quand même plus facile pour imaginer ce que va faire la machine.
Genre, si j'ai un mot de 4 octets (ABCD) à transmettre sur le réseau, et en supposant que ce dernier soit en Little Endian, ils vont partir "dans l'ordre". Alors qu'en Big Endian, j'aurais un mot ABCD, mais en pratique, si le réseau est en Big Endian lui aussi, ABCD deviendra CDAB (si je ne m'abuse - ou alors c'est carrément au niveau de l'octet, et à ce moment-là ce sera DCBA). Bref, ça ne respecte pas l'ordre des "humains".-
[^]Re: Tanenbaum était un visionnaire ...
Posté par darkleon (page perso, ) le 24/02/2006 à 16:45. (lien). Évalué à 3.lors qu'en Big Endian, j'aurais un mot ABCD, mais en pratique, si le réseau est en Big Endian lui aussi, ABCD deviendra CDAB (si je ne m'abuse - ou alors c'est carrément au niveau de l'octet, et à ce moment-là ce sera DCBA). Bref, ça ne respecte pas l'ordre des "humains".
Ce n'est pas l'inverse plus tôt ? Je me rappelle des dumps hexa mémoires sur x86 des résultats d'une carte d'acquisition 32bits, c'est imbitable à lire pour un humain.
(H)=humain, (M)=machine
Sur 8 bits
BE (Big-Endian bit de poid plus fort en premier)
132 -> 10000100 -> 0x84
LE (bit de poid le plus faible en premier)
132 -> 00100001 -> 0x84
Sur 16 bits (2 adresses consécutives en mémoire )
BE : 32770 -> 10000000 00000010 -> 0x8402 -> AB (M) = AB (H)
LE : 32770 -> 01000000 00000001 -> 0x0284 -> BA (M) != AB (H)
Et en 32 bits
Big-endian : ABCD (M) = ABCD (H)
Little-endian : DCBA (M) = ABCD (H)
A priori LE est plus facile pour la machine, car pour augmenter la taille des mots, il ne faut pas lire la mémoire à rebours
Par contre ça oblige pour l'être humain de lire les chiffres de droite à gauche et non pas de gauche à droite
Le LE était un avantage sur les ordinateurs 16bits à bus 8 bits, ou il n'y avait pas à gérer le chargement de l'octet de poids fort avant l'octet de poids faible dans un registre (simplification du décodeur, pas besoin d'un registre tampon)
Maintenant que les bus mémoires font au minimum 64 bits et qu'il y a de toute manière un cache L1 entre la mémoire et le proc, cette limitation n'existe plus (présence automatique d'un "registre tampon")
Au niveau de l'électronique, avec la mémoire cache, ça doit être la même chose d'être en LE ou BE au niveau du nombre de portes. (par contre les schémas doivent être en mirrori)
Cette différenciation d'architecture vient plutôt de raisons historiques (comme le bios de 82)
Par contre au niveau logique le BE est plus facile a appréhender pour nous humains. C'est plus facile de debugger une série de mots 32 bits en BE qu'en LE (c'est peut être pour cette raison qu'à la base les protocoles réseaux sont en BE).
Mais je ne suis pas un spécialiste en conception de circuits éléctroniques, alors j'ai peut être dit une grosse connerie. Je serais ravis si c'est le cas, que l'on m'explique pour ne pas mourrir idiot :-)-
[^]Re: Tanenbaum était un visionnaire ...
Posté par Olivier Jeannet () le 28/02/2006 à 11:33. (lien). Évalué à 3.Sur 8 bits
BE (Big-Endian bit de poid plus fort en premier)
132 -> 10000100 -> 0x84
LE (bit de poid le plus faible en premier)
132 -> 00100001 -> 0x84
Autant je suis bien d'accord avec toi sur le fait que le big-endian est plus lisible pour un humain, puisqu'il respecte l'ordre naturel d'écriture (cf mon autre commentaire pas loin), autant je ne pige pas pourquoi tu inverses les bits au sein d'un même octet, je n'ai jamais vu ça.
On récupère toujours chaque octet "normalement". Ce sont les octets entre eux qui peuvent être à l'envers, quand on les lit 1 par 1 à la suite en mémoire.-
[^]Re: Tanenbaum était un visionnaire ...
Posté par Jimmy (page perso, ) le 17/03/2006 à 20:05. (lien). Évalué à 1.je ne pige pas pourquoi tu inverses les bits au sein d'un même octet, je n'ai jamais vu ça.
Justement, c'est bien là la principale différence entre Big Endian et Little Endian. C'est l'ordre des bits du bus de données (physiquement, sur les broches de la puce) qui est inversé :
- en little endian, le bit 0 du bus est le bit de poids faible, le bit 31 est le bit le plus significatif (1),
- en big endian, c'est le bit 0 qui est le bit de poids fort.
Ainsi, on représente généralement les bus big-endian [0..31] et les bus little endian [31..0], en notant toujours le bit de poids fort à gauche, dans le sens naturel de lecture.
Mais du coup, l'ordre des octets dans la mémoire est également inversé, car on parcourt toujours les adresses dans le sens croissant : l'octet qui contient le bit 0 sera toujours placé à une adresse plus basse que celui qui contient le bit 31.
Voici une explication assez claire :
http://membres.lycos.fr/cgiguere/vdn/vdn71/vdn71.htm
notamment le passage sur UNIX, XINU et NUXI ...
(1) on utilise souvent les notations MSB (Most Significant Bit) et LSB (Least Significant Bit).-
[^]Re: Tanenbaum était un visionnaire ...
Posté par Olivier Jeannet () le 18/03/2006 à 15:25. (lien). Évalué à 2.C'est l'ordre des bits du bus de données (physiquement, sur les broches de la puce) qui est inversé
C'est possible, mais ça ne change pas le fait que tu n'as aucun moyen de le savoir au niveau de la programmation.
Quand tu te retrouves sur une machine Little Endian (PC x86 dans mon cas), tu peux voir que l'ordre des octets est inversé en mémoire, quand tu stockes une valeur sur plus d'un octet (un entier 32 bits en particulier), par exemple en faisant "od -x fichier.bin" tu peux voir que les octets sont inversés 2 par 2 car les données sont lues par défaut sur 2 octets; pour avoir un affichage normal, il faut faire "od -t x1 fichier.bin" (casse-pieds quand on vient du monde 680x0 Big Endian). Les bits d'un octets apparaissent dans l'ordre normal (heureusement, sinon la machine serait difficilement utilisable !).
D'où ma surprise avec ton explication où tu inverses les bits au sein d'un octet; ça embrouille pour rien.
-
-
-
-
[^]Re: Tanenbaum était un visionnaire ...
Posté par Olivier Jeannet () le 28/02/2006 à 11:30. (lien). Évalué à 3.Pour le little endian, avoir les octets de poids fort dans le "bon sens", c'est quand même plus facile pour imaginer ce que va faire la machine.
Heu, pas du tout. C'est en big-endian que l'ordre est naturel : la valeur sur 32 bits 0x11223344 est stockée dans l'ordre en mémoire, l'octet 0x11 avant 0x22 et ainsi de suite. Un dump mémoire est parlant. La famille des Motorola 680x0 était big-endian et c'est agréable (j'y ai pratiqué pas mal d'assembleur).
Alors que sur x86 (little-endian, berk), quand tu fais un "od -x" d'un fichier, les octets sont inversés 2 à 2, c'est illisible. Il faut faire un "od -t x1" pour avoir les octets dans l'ordre.
-
-
-
-
-
-
-
[^]Re: Tanenbaum était un visionnaire ...
Posté par encre (page perso, ) le 16/02/2006 à 11:12. (lien). Évalué à 1.Ce serait vrai si NetBSD tournait de façon plus ou moins identique sous toutes ces archis. Essaye de faire fonctionner DrapeauOrangeBSD sous macppc et tu vas vite comprendre qu'en fait il va te falloir réécrire le driver video (attention, je ne parle que d'un driver console basé sur OpenFirmware, pas d'un super-driver pour faire tourner X) pour arriver à avoir plus de 10 caractères/secondes de rafraîchissement. Alors ok, que du ssh. Mais bon c'est dommage.
Moi j'ai (à contrecoeur, je dois avouer) choisi Linux dans ce cas. Donc NetBSD c'est très bien, mais surtout sur quelques archis avec beaucoup de développeurs. Et c'est compréhensible.
-
-
-
-
[^]Re: Tanenbaum était un visionnaire ...
Posté par herodiade () le 15/02/2006 à 14:41. (lien). Évalué à 10.> le machines existent : c'est SUN qui les vend pour l'instant
Hmm, je ne suis pas sûr qu'ils vendent déjà des serveurs sous Niagara.
Es-tu certains de cette info ?
> Quand aux distribs elles existent aussi ! (Debian Sarge est compatible Sparc...gentoo aussi je crois). Pareil pour NetBSD et OpenBSD.
Attention, le fait que certains processeurs UltraSparc|Sparc soient supportés ne signifie pas qu'ils le soient tous (en fait certains ne sont pas du tout supportés, au moins par les *BSD, faute d'ouverture des docs de la part de Sun -- c'est d'ailleur pour ça, obtenir cette ouverture, que je gueule un peu).
D'autre part - et à contrario des allégations marketing de J. Schwartz - la mise à disposition des schémas du processeur n'aidera (quasiment) pas le portage sur les serveurs de la vraie vie: encore faut-il que Sun mette à disposition, si possible sans NDA, les spécifications complétes de leurs serveurs: cablage du proc et de la mémoire, cartes scsi/raid etc. Ce qu'ils ont parfois, mais pas toujours, accépté de faire. J'avais déjà parlé de ça dans la précédente dépêche sur le sujet.
En fait l'intéret pratique de cette nouvelle n'est pas tant la portabilité que l'extention du libre au monde du matériel. Effectivement, de nombreux projets existent mais aucun d'une telle ampleur. Quelles seront les conséquences ? aura-t-on un jour une communauté du HL (hardware libre ;) vivante, riche, active et innovante comme la communauté du LL actuelle ? D'autres gros constructeurs emboiteront-ils le pas à Sun ? Quelles conséquences sur les prix des futurs procs ? Sur la qualité ? Quels vont être les modus operandi de ces communautés (cvs/svn + mailing-lists + wiki ... ?) et quels rétro-conséquence sur la communauté du LL ? Verra-t-on cette démarche reprise par des constructeurs sur d'autre types de matériels ? Les projets type Open Graphics y trouveront-ils le crédit / gage de sérieux nécéssaire à la levée de subvention ? ...
Cette dépêche n'a pas oublié que Schwartz s'adresse généralement aux developpeurs (car ce sont eux qui décide au bout du compte, dit-il dans l'article lié à la dépêche), moyennant des efforts de communication ciblée (sur nous !) et au prix de petites contre-vérités (paradoxalement, au prix de ne peut-être pas mettre assez en avant ce qu'il y a de réellement révolutionnaire dans la démarche de son entreprise !).
Donc mention spéciale à patrick_g qui nous a fait une excellente dépêche, distinguant le bon grain (l'extraordinaire potentiel d'un tel matériel libre) de l'ivraie (le marketing de Sun concernant sa position sur les LL, la GPL, la portabilité etc.). Un vrai boulot de journaliste ;) comparé à la précédente dépêche sur ce sujet. J'adorerai que toutes les dépêches relatant les coups de campagnes ciblées vers la communauté des LL émanant des gros industriels (Sun, IBM et Apple en particulier) soient rédigées avec autant de prudence.
Il reste juste un détail mineur qui m'interroge (enfin, peut-être que j'ai mal compris l'annonce de Sun): la dépêche semble indiquer que Sun compte libérer les designs de tout ses processeurs UltraSPARC (en précisant que le T1 était juste "les première spécification disponible ". Mais pour le moment je n'ai trouvé que des indications contraires, par exemple dans la FAQ du projet OpenSPARC : "OpenSPARC project is making the hardware source code of the recently announced UltraSPARC T1 processor available under an Open Source license. ".
J'ai l'impression que les communiquants de Sun entretiennent la confusion en parlant à l'occasion d'UltraSPARC (la famille de processeurs) de façon générique là où ils devraient préciser "UtraSPARC T1". Ou je me trompe et l'ensemble des designs UltraSPARC seront effectivement libérés ? Ou est-ce une mauvaise transcription des journalistes ?
Une dernière question: on-t-ils annoncé qu'ils donnaient gracieusement une licence d'utilisation de leurs (éventuels, mais probables) brevets concernants ce matériel à tous, sans discrimination, et royalty free ? Parceque la "gplisation" du design d'un proc vérouillé par des brevets serait complétement inutile. Bref, qu'en est-il de la question des brevets _matériels_ sur l'US ?-
[^]Re: Tanenbaum était un visionnaire ...
Posté par patrick_g (page perso, ) le 15/02/2006 à 15:35. (lien). Évalué à 5.>> Hmm, je ne suis pas sûr qu'ils vendent déjà des serveurs sous Niagara.
Es-tu certains de cette info ?
http://www.sun.com/servers/coolthreads/t1000/
http://www.sun.com/servers/coolthreads/t2000/
>> Il reste juste un détail mineur qui m'interroge [snip] J'ai l'impression que les communiquants de Sun entretiennent la confusion en parlant à l'occasion d'UltraSPARC (la famille de processeurs) de façon générique là où ils devraient préciser "UtraSPARC T1". Ou je me trompe et l'ensemble des designs UltraSPARC seront effectivement libérés ?
Dans le second lien (OpenSparc) on peut lire ceci :
The UltraSPARC Architecture 2005 is a complete specification of the instruction set architecture (ISA) common to Sun Microsystem's 64-bit SPARC implementations (beginning with UltraSPARC T1 in 2005). UltraSPARC Architecture 2005 complies with SPARC V9 Level 1, with many more details, plus includes numerous Sun extensions common to all UltraSPARC processors.
Donc a priori l'architecture libre est celle du T1 mais les futurs processeurs seront également libres (c'est comme ça que je comprends le beginning with UltraSPARC T1. De plus cette archi est compatible SPARC V9 (elle lui ajoute seulement des extensions).
>> aura-t-on un jour une communauté du HL (hardware libre ;) vivante, riche, active et innovante comme la communauté du LL actuelle ?
J'y crois pas trop car le hard reste un domaine matériel et donc il faut obligatoirement passer par le cycle très long de la conception/fabrication...rien a voir avec une chtite compilation de 15 mn !
>> D'autres gros constructeurs emboiteront-ils le pas à Sun ?
Pas tant qu'il pourront l'éviter et d'autant moins qu'ils voudront implanter des fonctions Trusted computing/DRM...etc.
Si SGI était malin ils libéreraient leurs MIPS mais bon.....
>> Verra-t-on cette démarche reprise par des constructeurs sur d'autre types de matériels ? Les projets type Open Graphics y trouveront-ils le crédit / gage de sérieux nécéssaire à la levée de subvention ? ...
J'ai un peu d'espoir pour les CGU. Après tout il y a bien des gens intelligents dans ces boites et ils vont bien finir par comprendre qu'ils ont tout a gagner à au moins ouvrir les specs (la mise sous GPL du design est encore un rêve). Ces types vendent du hardware alors pourquoi se faire chier à pondre des drivers ! Pourquoi un business model basé sur la vente de hard restreindrait l'usage de celui-ci par un manque de soft ? C'est vraiment très con.
Ils se privent de pleins d'OS et de pleins d'archi CPU sur lesquelles leur driver ne marche pas. La raison finira par leur souffler qu'il vaut bien mieux libérer les specs et sortir un driver libre : on a des retours de bugs par les utilisateurs; on a parfois même des patchs; on peut vendre sa carte a plus de gens et en plus les libristes sont fous de joie et vous font de la pub sur le net.
Si un décideur pressé d'ATI ou NVidia lit ceci il sait maintenant ce qu'il doit mettre dans son prochain Powerpoint exposant "une nouvelle stratégie révolutionnaire" !-
[^]Re: Tanenbaum était un visionnaire ...
Posté par herodiade () le 15/02/2006 à 16:57. (lien). Évalué à 3.> http://www.sun.com/servers/coolthreads/t1000/
> http://www.sun.com/servers/coolthreads/t2000/
Wow, c'est plutôt bon marché en plus: à peut près le prix d'un serveur x86 1U !
>> aura-t-on un jour une communauté du HL (hardware libre ;) vivante, riche, active et innovante comme la communauté du LL actuelle ?
> J'y crois pas trop car le hard reste un domaine matériel et donc il faut obligatoirement passer par le cycle très long de la conception/fabrication...rien a voir avec une chtite compilation de 15 mn !
Oui, là le "release early, release often" serait dévastateur !
Mais je pensait "vivante, riche, active et innovante" au sens d'une communauté large et créative, plutot que sur le plan du nombre de projets/releases.
> Pas tant qu'il pourront l'éviter et d'autant moins qu'ils voudront implanter des fonctions Trusted computing/DRM...etc.
Je ne suis pas certain d'y voir très clair sur ce point.
Est-ce que le fait que le design soit sous GPLv2 empêche les fondeurs (et même, les concepteurs/designers) d'implémenter des fonctionalités de type DRM ?
Je connais super mal le sujet des DRM, mais il me semble (me détromper si je dit une connerie) que:
1- un système de protection robuste ne devant pas reposer sur le secret de l'algorithme (security by obscurity), l'éventuelle protection DRM ne devrait pas être remise en cause par la publication des schémas (~= de l'algo), mais plutot de la clefs privée (par ex intégrée dans le firmware) qui l'utilise.
2- que le design du processeur soit GPL n'impose probablement pas que le contenu du firmware, dont la clef, le soit (ps: Sun a-t-il libéré le OpenBoot ?).
3- la GPLv2, même sur le plan logiciel, n'interdit pas l'implem de DRMs
Et puis Sun n'a pas l'air si farouchement anti DRM que ça ... : http://blogs.sun.com/roller/page/jonathan/20050826
Pour les GPUs, sans être aussi optimiste que toi, je crois me souvenir que le dev principal du projet Open Graphics peinait à trouver un support financier (d'ailleur ce projet avait été laché par son entreprise) parceque "le matériel libre, ce n'est pas une idée sérieuse". Maintenant que Sun fait des specs libres, son projet pourrait parraitre plus crédible aux yeux des décideux préssés !-
[^]A propos d'OpenGraphics
Posté par karteum59 () le 15/02/2006 à 17:24. (lien). Évalué à 4.En ce qui me concerne je suis assez sceptique pour OpenGraphics...
Par contre, plutôt que de concevoir un ASIC en entier (ce qui pose de gros problèmes financiers), ne vaudrait-il pas mieux s'orienter vers une carte AGP avec des composants plus "génériques" et programmables, par exemple, un gros DSP / FPGA / processeur vectoriel ?
Par exemple, le processeur Cell d'IBM semble très prometteur. Je ne sais pas comment il pourrait se mesurer face aux processeurs dédiés comme ceux de NVidia mais si c'était comparable il me semble qu'on pourrait imaginer une carte (PCI/AGP) avec un processeur Cell qui fasse office de GPU (hébergeant un mini linux et une version de Mesa optimisée)... A mon avis, vu que les composants existent (sauf la carte PCI/AGP qui héberge le tout) ce serait bien plus réaliste que de concevoir un chip en entier et d'espérer que quelqu'un le produira... Comme c'est un processeur généraliste, il n'y aurait pas de problème pour les extensions OpenGL, les shaders, le décodage MPEG4 à la volée...
Sinon à part ça, qqun sait comment le Ultrasparc T1 se compare face aux Intel / PPC / Cell ?-
[^]Re: A propos d'OpenGraphics
Posté par Nicolas Boulay () le 15/02/2006 à 17:40. (lien). Évalué à 6.Un FPGA est prévus pour opengraphics pour faire le développement.
Mais un FPGA est 4x plus lent et consomateur d'énergie (et chère) qu'un asic.
Sinon, on ne peut pas comparrer les perfs d'un DSP ou d'un cpu seul avec la puissance d'un gpu même simple comme l'OGP. Il y a un ordre de grandeur de différence (x10 donc...)--
"Plus un État censure, moins il est démocratique. Mais parce qu’on vous ment sur internet, on va le censurer pour ceux qui télechargent."-
[^]Re: A propos d'OpenGraphics
Posté par karteum59 () le 15/02/2006 à 17:47. (lien). Évalué à 3.on ne peut pas comparrer les perfs d'un DSP ou d'un cpu seul avec la puissance d'un gpu même simple comme l'OGP. Il y a un ordre de grandeur de différence (x10 donc...)
Oui je sais, mais en fait de processeurs je ne parlais pas de x86 mais de processeurs vectoriels multicores comme le Cell (qui apparemment repend pas mal de techniques mises en oeuvre dans les GPUs).
-
-
[^]Re: A propos d'OpenGraphics
Posté par Nicolas Boulay () le 15/02/2006 à 17:45. (lien). Évalué à 3.Un core T1 doit correspondre au cpu ppc simple du cell ou de la XBOX 360. Par contre, il monte moins haut en fréquence.
Il est à prioris in order, donc pas comparrable au athlon/pentium. Je dirais au pif, qu'un seul core à 1.2 Ghz doit être comparrable à un athlon à 800 mhz.
Pas d'out of order veut dire plein de gachis d'utilisation des unités de calculs. Mais il y a les threads pour ça, ce qui doit compenser.
Donc à 4 threads/core, tu dois avoir un trés bon taux d'utilisation.
Donc en gros, ton cpu en appli mutlithread doit être comparrable à un bi -athlon.
Donc avec 32 threads, on a une super machine faite pour les serveurs.--
"Plus un État censure, moins il est démocratique. Mais parce qu’on vous ment sur internet, on va le censurer pour ceux qui télechargent."-
[^]Re: Rapport Puissance/Conso
Posté par Mars () le 15/02/2006 à 19:17. (lien). Évalué à 0.> Donc avec 32 threads, on a une super machine faite pour les serveurs.
>
pour 72 Watts ?
Ce proc est vraiment écolo ! Et donc à même de se positionner correctement face aux prochains Intel dans ce domaine ?!
Ca serait une TRES BONNE nouvelle à l'heure où les problèmes d'énergie se révèlent primordiaux.
Cependant j'ai un gros doute ....-
[^]Re: Rapport Puissance/Conso
Posté par patrick_g (page perso, ) le 16/02/2006 à 09:34. (lien). Évalué à 3.>> Ce proc est vraiment écolo ! Et donc à même de se positionner correctement face aux prochains Intel dans ce domaine ?!
Oui c'est d'ailleurs très marrant de voir que le marketing SUN lors du lancement de l'UltraSparc T1 se basait sur l'écologie et les économies d'énergie. Du style "si tous les CPU du monde étaient des T1 alors on pourrait économiser x milliards de tonnes de pétrole".
Pour la puissance il y a aussi une donnée à prendre en compte : le T1 est vraiment pensé comme un processeur pour serveurs web et donc ses performances en virgule flottante sont minables. il n'a qu'une seule unité FP en tout (par opposition aux 8 coeurs/32 threads).
La prochaine génération prévue en 2007 (l'an prochain quoi) aura les caractéristiques suivantes :
* gravure 65 nm
* 8 coeurs (ça change pas)
* une unité FP par coeur (soit 8 en tout)
* 8 threads par coeur (soit 64 en tout)
* fréquence 1.4 à 1.6 GHz
-
-
-
[^]Re: A propos d'OpenGraphics
Posté par briaeros007 () le 15/02/2006 à 17:47. (lien). Évalué à 4.Par contre, plutôt que de concevoir un ASIC en entier (ce qui pose de gros problèmes financiers), ne vaudrait-il pas mieux s'orienter vers une carte AGP avec des composants plus "génériques" et programmables, par exemple, un gros DSP / FPGA / processeur vectoriel ?
Tiens ca alors ca alors c'est tout d'abord ce vers quoi s'oriente ogp ...
Le problème avec un fpga c'est que
1°) c'est cher à l'unité.
2°) c'est moins performant qu'un asic (en perf pur , en rapport conso/perf etc...)
voila pourquoi ils vont normalement d'abord faire une carte avec fpga (qui sera aux alentours de 500 ¤ je crois), et une fois que la levée de fond sera suffisante (et le debug aussi) lancer la protection d'un asic.
Sur la ml il parlaient de 1 million de $ pour faire le masque.
Par exemple, le processeur Cell d'IBM semble très prometteur. Je ne sais pas comment il pourrait se mesurer face aux processeurs dédiés comme ceux de NVidia mais si c'était comparable il me semble qu'on pourrait imaginer une carte (PCI/AGP) avec un processeur Cell qui fasse office de GPU (hébergeant un mini linux et une version de Mesa optimisée)...
Cell et gpu n'ont pas vraiment le même but.
D'ailleur la ps3 aura un gpu en plus de son cell.
Sinon à part ça, qqun sait comment le Ultrasparc T1 se compare face aux Intel / PPC / Cell ?
Pour le cell ca va être dur vu qu'il n'y a rien qui est équipé avec pour l'instant.
Sinon regarde par la :
http://opensparc.sunsource.net/nonav/performance.html
et plus spécifiquement la :
http://www.sun.com/servers/coolthreads/t1000/benchmarks.jsp
Même si on peux faire dire ce qu'on veux avec des chiffres, ca devrait te donner une idée.
Oui, là le "release early, release often" serait dévastateur !
Avec un fpga et une image stable de base ca peut passer encore.--
Subete ga wakatta toki…watashi ga anta wo korosu.-
[^]Re: A propos d'OpenGraphics
Posté par karteum59 () le 15/02/2006 à 17:55. (lien). Évalué à 1.Cell et gpu n'ont pas vraiment le même but.
J'ai suggéré ça en supposant que l'architecture vectorielle du Cell pouvait peut-être combler le gap. Effectivement, rien n'est moins sûr...
D'ailleur la ps3 aura un gpu en plus de son cell.
Oui, mais est-ce que c'est pour des raisons techniques ou pour des raisons "pratiques" ? (une implémentation OpenGL optimisée pour le Cell pourrait prendre des mois à coder / débugger, alors que les processeurs NVidia et leur drivers sont disponibles tout de suite)
-
[^]Re: A propos d'OpenGraphics
Posté par patrick_g (page perso, ) le 16/02/2006 à 09:43. (lien). Évalué à 2.>> Pour le cell ca va être dur vu qu'il n'y a rien qui est équipé avec pour l'instant.
maintenant si : http://www.itjungle.com/tlb/tlb021406-story02.html-
[^]Re: A propos d'OpenGraphics
Posté par karteum59 () le 16/02/2006 à 09:51. (lien). Évalué à 1.Intéressant... Sur cette même page on peut lire
IBM demonstrated a real-time rendering (...). Why there are not Cell-based graphics cards on the market right now is a complete mystery.
-
[^]Re: A propos d'OpenGraphics
Posté par patrick_g (page perso, ) le 16/02/2006 à 12:42. (lien). Évalué à 5.Ben nous on voudrait bien des cell-based graphics cards car on pourrait ainsi échapper aux salopiots d'ATI et NVidia qui ne veulent pas libérer leurs drivers.....mais pour les constructeurs il est quand même plus rationnel de vendre des cartes graphiques traditionnelles car elles sont concues dès le début pour le graphisme alors que le cell est quand même un CPU vectoriel assez généraliste.
je pense que les cell-blades d'IBM c'est plus pour les films 3D (pixar doit être content) ou pour des applications scientifiques spécifiques que comme substitut aux GPU.
-
-
-
-
-
-
-
-
Améliorations ?
On pourra proposer des patchs sur la ml ? :)
\o/ Poulpatine \o/
Les UltraSparc sous quelle GPL?
Alors, GPLv2 ou GPLv3 ?
"si les utilisateurs voulaient préserver leurs libertés ..." alors il vaudrait mieux la v3, histoire de ne pas pouvoir mettre des DRM dedant.
en fait la réponse semble être GPLv2 ...
-
[^]Re: Les UltraSparc sous quelle GPL?
Posté par herodiade () le 15/02/2006 à 14:56. (lien). Évalué à 2.La question est intéressante: ce sera bien la GPLv2 (nécéssairement: la GPLv3 n'est pas encore "releasée"), mais peut-être envisageront-ils de passer en v3 lorsqu'elle sortira ?
Car enfin, il suffit qu'un contributeur au processeur (peut-etre meme Sun l'a déja fait ?) réussisse à faire accepter une modification couverte par un de ses brevets (hardwares, donc valable aussi en Europe) pour que le matériel soit vérouillé au point que plus personne ne puisse implémenter le design librement. C'est un danger très important pour ce genre de projets, et la GPLv3 devrait permettre de le désamorcer (si au final elle impose effectivement au contributeur de céder les droits d'exploitation de ses brevets, c'est dans le cahier des charges).
Sun semble être bien disposé envers la GPLv3, en tout cas suffisament pour (prétendre) envisager de re-licencer OpenSolaris sous double licence (CDDL + GPLv3). Mais il s'agit peut-être d'une promesse en l'air ... cf. le blog de Jonathan Schwartz: http://blogs.sun.com/roller/page/jonathan-
[^]Re: Les UltraSparc sous quelle GPL?
Posté par djano () le 15/02/2006 à 15:50. (lien). Évalué à 2.D'ailleurs ca m'etonne beaucoup ce soudain amour pour la GPL.
Meme si OpenOffice est GPL, il me semblait que Sun avait cree la CDDL expressement pour qu'OpenSolaris ne soit pas compatible avec Linux. Peut etre est ce parce que Linus Torvalds s'est declare contre la GPLv3 en l'etat, et que donc Sun ne craint plus que son code soit pris pour renforcer Linux.
En effet, si la licence choisie est CDDL+GPLv3, alors ce n'est pas compatible avec Linux qui est GPLv2.
Bref, moi plus comprendre la! :?-
[^]Re: Les UltraSparc sous quelle GPL?
Posté par patrick_g (page perso, ) le 15/02/2006 à 16:02. (lien). Évalué à 2.>> Bref, moi plus comprendre la! :?
La sauce OpenSolaris ne prenant pas il faut bien qu'ils imaginent des solutions. C'est vrai qu'ils peuvent pousser le machiavelisme jusqu'à choisir la GPLv3 pour éviter l'import de code dans Linux qui reste sous v2.
Ca n'empecherais sans doute pas d'importer des bouts interessants comme ZFS qui sont biens distincts du core kernel je pense.
-
[^]Re: Les UltraSparc sous quelle GPL?
Posté par herodiade () le 15/02/2006 à 16:32. (lien). Évalué à 4.> donc Sun ne craint plus que son code soit pris pour renforcer Linux.
Non il est très improbable que ça soit leur motivation, car la remarque de Linus était un pur choix politique (une "police" le noyau mainstream, de kernel.org). Mais il n'y a pas un d'obstacle légal.
Moyennant quoi, si OpenSolaris est relicencé en GPLv3, et que par exemple ZFS ou DTrace intéressent suffisament les developpeurs (+ sont suffisament portables etc.) on verra certainement des projets adaptants ceux-ci à Linux, au moins come modules externes (ce qui de toute façon est assez bien admis et communs dans le monde Linux: p-o-m iptables, (anciennement) fuse, ...: autant de projets respectables mais pas immédiatement acceptés dans le kernel vanilla de Linus).
Même un fork n'est pas exclus: il en existe déjà, comme uclinux par exemple.
D'autre part Linus a mis de l'eau dans son vin en précisant qu'il pourrait y avoir des contributions v3 au noyau (simplement, que le noyau lui-même, dans son ensemble, serait considéré v2).
> En effet, si la licence choisie est CDDL+GPLv3, alors ce n'est pas compatible avec Linux qui est GPLv2.
Apparement Stallman tient à faire en sorte que la v3 finale soit compatible avec la v2.
http://gplv3.fsf.org/rationale#SECTION00380000000000000000
> Bref, moi plus comprendre la! :?
La GPLv3 n'empecherai pas Solaris de "renforcer Linux".
Ce qui est certain c'est qu'il ne s'agit pour le moment que de annonce d'une reflexion, meme pas d'un engagement. La GPLv3 n'est pas encore releasée.
Sun a déjà annoncé maintes fois "réfléchir à la libération de java", et on n'a encore rien vu venir.
(en clair: il s'agit peut-être d'une autre trouvaille de Schwartz en matière de marketing ciblé, ne tombons dedans: attendont plus de concret !).
-
[^]Re: Les UltraSparc sous quelle GPL?
Posté par JPz (page perso, ) le 15/02/2006 à 16:38. (lien). Évalué à 1."il me semblait que Sun avait cree la CDDL expressement pour qu'OpenSolaris ne soit pas compatible avec Linux."
C'est du FUD de GPL-istes barbus ça. Ils ont créé la CDDL, dérivée de la MPL (pour être réutilisable) car la MPL était ce qui collait le plus à leur vision. D'ailleurs la CDDL est bien antérieure à OpenSolaris. La CDDL est une licence très respectable.
-
-
De L'autre côté SGI ...
... est mal barr'
Si on en croit cette article:
http://www.channelregister.co.uk/2006/02/08/sgi_warns/
Les risques d'une année 2006 fatale sont bien présent.
Si ils pouvaient libèrer leurs specs à leur tour, ça serait génial.
j'en ai presque des scrupules... :/
Enfin...
moué...
-
[^]Re: De L'autre côté SGI ...
Posté par gnumdk (page perso, ) le 15/02/2006 à 15:14. (lien). Évalué à 4.>Si ils pouvaient libèrer leurs specs à leur tour, ça serait génial.
Si il pouvaient libérer leur code aussi, le OpenGL que Nvidia a porté pour eux sous GNU/Linux, ca serait pas mal déjà. Ca ferait déjà un truc de pas libre en moins dans les drivers de chez Nvidia.
Sun et le libre
Chez Sun ils libèrent tout sauf Java...
Comme pour Solaris et Ultrasparc, ils attendent aussi que Java soit quasiment mort commercialement avant de libérer leur implémentation ?
-
[^]Re: Sun et le libre
Posté par ufoot (page perso, ) le 15/02/2006 à 15:02. (lien). Évalué à 4.> ils attendent aussi que Java soit quasiment mort commercialement avant de libérer leur implémentation ?
Score 5: insightfull 8-)
Effectivement, il y a certainement un peu de ça. Mais bon ça reste une bonne nouvelle cette publication sous GPL. Cool!
-
[^]Re: Sun et le libre
Posté par sylware () le 15/02/2006 à 15:11. (lien). Évalué à 6.Il paraît qu'il ne faut pas confondre la division software de Sun avec la division hardware de Sun...
-
[^]Re: Sun et le libre
Posté par GuieA_7 (page perso, ) le 16/02/2006 à 12:28. (lien). Évalué à 4.Tu sous-entends que Solaris est codé par la division hardware de Sun?? (c'est une vraie question)
-
[^]Re: Sun et le libre
Posté par Matthieu Moy (page perso, ) le 18/02/2006 à 18:03. (lien). Évalué à 5.Je crois surtout qu'il sous-entends que Java est développé par la division hardware, alors que l'ultra-sparc est développé par la division soft.
Ou l'inverse, peut-être ;-).
-
-
Un vrai portable ou un gros pda
Donc, je te prends un core ultrasparc T1, on va en prendre que 2 ou 4 cela suffit. Je te colle le core Open Graphique à coté, quelque IOs : usb2, PCMCIA, FLASH, GSM/GPRS, WIFI, bluetouth. Avec tout ça je te fais un bon gros SoC optimisé consomation pour viser ~30W.
Je te colle ça sur une carte mère avec 1 Go de RAM et 4 Go de FLASH. Je rajoute un écran 14" à éclairage LED et une grosse batterie Lithium-polymer de qq dizaines d'Ah.
Je mets le tout dans un package pour que cela face moins de 1 kg.
Et je te fais le portable/PDA tueur de blackberry et autre smartphone (avec clavier de m...) !
Un vrai ordinateur portable quoi...
"Plus un État censure, moins il est démocratique. Mais parce qu’on vous ment sur internet, on va le censurer pour ceux qui télechargent."
-
[^]Re: Un vrai portable ou un gros pda
Posté par GhZaaark3 () le 15/02/2006 à 15:33. (lien). Évalué à 0.Le core d'OpenGraphique?, y a déjà quelque chose du genre?
Sinon, y a Nvidia qui vient de sortir un GPU pour l'embarqué.
http://www.dailytech.com/article.aspx?newsid=766
Oké c po libre...--
moué...-
[^]Re: Un vrai portable ou un gros pda
Posté par Nicolas Boulay () le 15/02/2006 à 15:58. (lien). Évalué à 3.non pas encore.
Le projet continue mais le core ne sera pas libre dans un premier temps, le temps de se faire une santé financière.
Il ne communique plus dessus tant que rien ne sort. J'espère un truc utilisable à la fin de l'année.--
"Plus un État censure, moins il est démocratique. Mais parce qu’on vous ment sur internet, on va le censurer pour ceux qui télechargent."
-
-
[^]Re: Un vrai portable ou un gros pda
Posté par Mark Havel () le 15/02/2006 à 18:01. (lien). Évalué à 2.Tu n'oublieras pas de trouver l'usine de processeurs à quelques milliards pour les fabriquer.
C'est bien beau de mettre un CPU sous GPL, mais je vois très très très mal en quoi cela pourrait être utile pour faire du matériel en l'absence des usines qui vont avec... Au mieux, cela peut permettre à quelques génies de se faire remarquer en proposant des améliorations de design...-
[^]Re: Un vrai portable ou un gros pda
Posté par Nicolas Boulay () le 15/02/2006 à 21:24. (lien). Évalué à 2.euh... il existe très peu d'usine dans le monde. C'est comme tout tu passes commande.
Si tu as déjà le code, tu gagnes un fric monstres.
Une puce comme ça, c'est un projet de ~10 Millions d'euro. Cela parrait énorme mais pas tellement pour un tel projet.
Si tu te payes un core genre PPC d'IBM, tu doubles le prix minimum voire plus. En gros, 10 M¤ par core (cpu, gpu,...).--
"Plus un État censure, moins il est démocratique. Mais parce qu’on vous ment sur internet, on va le censurer pour ceux qui télechargent."
-
-
[^]Re: Un vrai portable ou un gros pda
Posté par Rémi Hérilier (page perso, ) le 17/02/2006 à 17:06. (lien). Évalué à 0.En utilisant une architecture à mémoire partagée (comme sur les bonnes vieilles SGI O2 et cie), des bus HyperTransport (un pour le CPU, un pour la GPU, un pour les E/S et un pour la RAMDAC) et un crossbar pour partager l'accès à la RAM, on a une bonne machine de tueur =)
/me qui retourne rêver sur un pdf décrivant l'O2.
[+] Libriste
"Libriste".... C'est la première fois que je vois ce terme.
Je le trouve particulièrement horrible. De plus la communauté du logiciel libre présente, à mon avis, le gros avantage de parler correctement français par rapport aux autres communautés informatiques, je trouve donc ça dommage.
vw
-
[^]Re: Libriste
Posté par zgnouf () le 15/02/2006 à 16:12. (lien). Évalué à 5.La langue évolue grâce à des néologismes et si la langue française n'en propose pas, alors tu auras un beau mot anglais à la place et tu trouveras cela dommage.
La formation de ce mot est tout à fait logique, répond à un besoin etc. il n'y a pas de raison de le rejeter ou sinon tu peux aussi rejeter les logiciels et autres qui ne te choquent déjà plus...
À ce propos je signale une ressource gratuite qui est parfois bien utile pour ceux qui traduisent :
http://www.olf.gouv.qc.ca/ressources/gdt.html
Tout n'est pas forcément bon mais c'est souvent très utile.
-
[+] [^]Re: Libriste
Posté par zgnouf () le 15/02/2006 à 16:28. (lien). Évalué à -1.La langue évolue grâce à des néologismes et si la langue française n'en propose pas, alors tu auras un beau mot anglais à la place et tu trouveras cela dommage.
La formation de ce mot est tout à fait logique, répond à un besoin etc. il n'y a pas de raison de le rejeter ou sinon tu peux aussi rejeter les logiciels et autres qui ne te choquent déjà plus...
À ce propos je signale une ressource gratuite qui est parfois bien utile pour ceux qui traduisent :
http://www.olf.gouv.qc.ca/ressources/gdt.html
Tout n'est pas forcément bon mais c'est souvent très utile.
-
[^]Re: Libriste
Posté par Philip Marlowe (Jabber id, ) le 15/02/2006 à 17:49. (lien). Évalué à 5.Oui, on pouvait déjà être libre, libéré, libérateur, libéral, libertin, libériste (pilote de delta ou de parapente) ou libertarien, on peut désormais aussi être libriste. Peut-on être tout ça en même temps ? Peut-on en plus être laborantin ?
~~~~~~> []-
[^]Re: Libriste
Posté par Frédéric Lopez () le 15/02/2006 à 19:49. (lien). Évalué à 3.Libéro aussi tant qu'on y est, si on aime jouer au foot...
-
[^]Re: Libriste
Posté par Pierre Jarillon (page perso, ) le 16/02/2006 à 23:32. (lien). Évalué à 3.Pourquoi pas équilibre et équilibriste ? Comment, ce n'est pas le même libriste ?
-
[^]Re: Libriste
Posté par FredCL (page perso, ) le 18/02/2006 à 12:54. (lien). Évalué à 2.équilibre ? Ce ne serais pas le libre équitable ça?
c'est bon n'en jettez plus, j'ai vu la sortie -> [ ]
-
-
-
[^]Re: Libriste
Posté par Séverin Tagliante-Saracino () le 15/02/2006 à 20:10. (lien). Évalué à 2.Tu oublie "libertaire" et "libéralisé"
-
[^]Re: Libriste
Posté par Jean-Philippe (page perso, ) le 15/02/2006 à 20:36. (lien). Évalué à 5.Serais-je lourd en ajoutant libraire?
-
[^]Re: Libriste
-
[^]Re: Libriste
-
[^]Re: Libriste
Posté par Mithfindel (page perso, ) le 16/02/2006 à 08:57. (lien). Évalué à 3.Et pendant ce temps au Libéria...
-
-
-
-
Aucun lien, mais pour info ....
... "Le Pegasos devient Open hardware" .
Cette machine uniquement connue des amigaistes, à base de PPC (G3 ou G4) est libre (depuis un petit moment maintenant). Elle contient (en vrai, je n'ai pas été voir si les plans concordaient) 2 ports Ethernet (100 et 1000 Mbps), un port IEEE1394, deux ports USB, une carte son integrée, un port AGP ... à voir donc.
http://www.amigaimpact.org/modules/news/article.php?storyid=(...)
Spec != RTL
Sun a publie la spec, c'est bien. Ils annoncent qu'ils vont publier le RTL, c'est mieux. Ca peut prendre en effet tres longtemps pour implementer une spec en un code RTL. LEON (sparcv8) est un bon exemple de reussite mais ca fait un moment qu'il bourlingue.
Meme avec le RTL, ce n'est pas a la portee du premier venu. Il faut un outil de synthese (tres cher), d'analyse statique de timing (cher aussi) et de simulation (il y en a des gratos) pour synthetiser et valider ton processeur. Ca prend aussi beaucoup de temps pour developper les contraintes (dependantes du process de fabrication, donc des bibliotheques du fondeur). Les bibliotheques ne sont pas gratuites non plus. Pour les technos avancees, les memoires sont AMHA un point critique. Un processeur a pas mal de caches differents. Un generateur de memoires coute bombon (~ M$ "que" pour du 130 nm). Et quand on a fini tout ca, on n'a fait que la partie front-end du boulot ! Les outils back-end (P&R, LVS, etc.) coutent encore plus cher que leurs copains du front-end (et bouffent encore plus de CPU/memoire).
Xavier.
-
[^]Re: Spec != RTL
Posté par Jimmy (page perso, ) le 17/02/2006 à 00:09. (lien). Évalué à 3.Il faut un outil de synthese (tres cher), d'analyse statique de timing (cher aussi) et de simulation (il y en a des gratos) pour synthetiser et valider ton processeur.
C'est à mon avis un domaine où les logiciels libres sont très peu présents, même si il y a des initiatives en cours, c'est encore un domaine où les softs propriétaires aux prix exorbitants sont incontournbles.
Par exemple, moins un simulateur VHDL est cher (version démo gratuite), plus il contient de boucles d'attente vides ... (les simulations durent des heures).
Sans aller jusqu'au développement d'ASIC, avec les coûts de production astronomiques des masques, déjà avoir des outils libres pour FPGA permettrait de faire plein de choses. On a beau dire que c'est moins performant et plus cher, ces puces reconfigurables évoluent très vite : les prix baissent et les perfos augmentent à un rythme soutenu. http://www.trenz-electronic.de/prod/proden21.htm
J'avais eu l'occasion, il y a 3 ou 4 ans, d'aborder le sujet avec RMS. Il avait tout de suite soulevé le pb des coûts de production, mais quand j'ai parlé de FPGA, il a dit "si ca se télécharge dans la puce, alors c'est du logiciel, et la FSF encourage le logiciel libre"
http://www.freehdl.seul.org/
http://www.opencores
http://www.geda.seul.org/index.html.org
http://qucs.sourceforge.net/index.html-
[^]Re: Spec != RTL
Posté par Xavier Caron () le 17/02/2006 à 08:40. (lien). Évalué à 3.Tout a fait. Il existe cependant des simulateurs open-source Verilog comme Icarus mais il faut sacrifier son VHDL europeen. Le bleme, c'est que la validation d'un circuit se fait de plus en plus par preuve formelle (i.e., RTL / portes) et analyse statique de timing. La encore, les outils sont chers et les boites de CAD se farcissent pas mal. L'autre point bloquant est l'outil de synthese, surtout si tu veux faire un ASIC. Et j'en passe encore au sujet des outils dits de testabilite (ATPG, BIST logique). Malgre gEDA, il manque bien tout une chaine d'outils mais la fabrication coute cher et meme les universites / ecoles d'inge ont du mal a financer.
Au sujet de ASIC / FPGA, il faut comprendre que l'on cherche a faire un micro-processeur. Les frequences max d'un ASIC sont entre 5 a 10 fois moindres que celles d'une puce Intel ou AMD. Quant aux FPGA ils se rapprochent seulement de la frequence de fonctionnement d'un ASIC. Un FPGA coute plus cher a l'unite mais si tu as besoin de grandes quantites les couts fixes lies a la fabrication d'un ASIC (dont les 1 a 2 annees de developpement) sont finalement ammortis. On s'en sert souvent pour prototyper un micro-controlleur genre ARM par exemple.
En bref, concevoir et fabriquer une puce reste un sport de riche...-
[^]Re: Spec != RTL
Posté par Jimmy (page perso, ) le 17/02/2006 à 19:53. (lien). Évalué à 3.Au sujet de ASIC / FPGA, il faut comprendre que l'on cherche a faire un micro-processeur.
J'avais bien compris. Mais tu sais sans doute qu'on peut mettre des microprocesseurs dans les FPGA ... soit en dur dans le silicium (comme les Virtex4FX de Xilinx équipés d'un ou deux PowerPC 405), soit sous la forme de netlist (Nios chez Altera, MicroBlaze chez Xilinx, et puis le LEON dont on parlait plus haut).
Tu sais aussi que Linux (ou µClinux) a été porté sur tous ces processeurs.
Evidemment, les fréquences de fonctionnement n'ont rien à voir avec les processeurs PC haut-de-gamme, on est aujourd'hui dans la gamme 100 à 200 MHz pour un soft-core, et le double pour un hard-core (le tout sans radiateur ni ventilo !). Mais le but est bien différent de celui d'un CPU généraliste, ca on est dans une puce programmable ! On peut donc implémenter plein de périphériques sur mesure, parallèliser des coprocesseurs hardware pour des applications particulières, profiter de la reconfigurabilité de la puce (même en cours de fonctionnement), explorer des topologies multiprocesseurs ... les performances (vitesse de calcul ET consommation) ne sont pas du tout ridicules pour une application embarquée spécifique.
Et la possibilité de modifier le design une fois le produit fini, pour corriger un bug ou ajouter une fonctionnalité, vaut de l'or !
Un FPGA coute plus cher a l'unite mais si tu as besoin de grandes quantites les couts fixes lies a la fabrication d'un ASIC (dont les 1 a 2 annees de developpement) sont finalement ammortis.
Effectivement, c'est valable sur une grande quantité. Plus performant, moins cher à l'unité, mais il faut être sûr de son marché.
Le point où il devient plus rentable d'engager des gros coûts fixes pour produire un ASIC pas cher, que de payer un FPGA tout fait, recule de plus en plus. Par exemple, il y a un FPGA (un Spartan2, je crois) dans la Freebox, et ce n'est plus un produit de petite série ...
On s'en sert souvent pour prototyper un micro-controlleur genre ARM par exemple.
Pour certaines applications de traitement d'image en temps réel, où les débits de données sont importants, il n'est pas question d'utiliser un processeur généraliste (soit il consomme trop, soit il n'est pas assez performant), les délais de mise sur le marché et les volumes ne sont pas compatibles avec un développement ASIC, alors le FPGA est la seule solution !
Il y a 4 ou 5 ans, les FPGA étaient sans doute principalement utilisés pour faire du prototypage, mais plus maintenant.
Pour revenir aux outils de CAO (électronique et autres), il y a des solutions propriétaires qui tournent sous Linux [*], certaines ont même des versions démo gratuites, mais malheureursement rien de libre. Dans le domaine mécanique, il y a des codes de calcul, comme CodeAster, mais pas d'outil de design comme Catia. Pour l'électronique analogique, il y a Spice. Pour l'électronique numérique, je crois qu'on les a presque tous cités. Et l'optique, l'acoustique, la thermique, l'aérodynamique, l'énergétique ?
Il est vraiment temps que les outils libres sortent du domaine quasi-exclusif de la programmation logicielle, et déferlent sur tous les domaines techniques !
[*] La migration station->PC a réduit les coûts, mais la migration UNIX->Windows associée n'a pas que des avantages quand on développe ... Alors le couple PC+Linux est un bon compromis pour la CAO, et de + en + d'entreprises vont dans cette direction. Les éditeurs commencent (timidement) à suivre.-
[^]Re: Spec != RTL
Posté par Xavier Caron () le 20/02/2006 à 09:21. (lien). Évalué à 2.Le debat ASIC/FPGA est pas mal d'actualite, surtout pour moi, bossant chez un fondeur... Plusieurs criteres font qu'un ASIC est choisi comme la securite (quoique le point faible reste le bulk), des fonctions analogiques complexes ou de l'EEPROM / Flash. Nos gros SoC ("System on Chip") sont bases sur de l'ARM aide d'un DSP ou d'IPs dediees au traitement du signal plus toute la filasse protocolaire (USB, PCI, etc.) Un truc egalement de plus en plus a la mode est un ASIC base sur un micro-controlleur plus un zone programmable de type FPGA.
Pour la CAD, nous n'avons quasiment plus que des Linux-box au boulot. Ca marche tres bien et tres vite. Les outils sont tous portes avec comme baseline la RHEL3. Les quelques autres stations vieilissantes sont des Sun Sparc, SunOS 9 (dont ma poubelle sans clavier "avé l'accent"). Mais les softs open-source ne sont pas legion et nous depensons des mega-brouzoufs par an pour tous les outils dont nous avons besoin (une license a l'annee peut faire de 50 K$ a 500 K$). Vu la complexite des softs je ne vois malheureusement pas trop venir d'equivalent libre. Par exemple, un coeur ARM necessite un outil de synthese physique. Ca coute un max mais ca nous permet de traquer les um^2 et les MHz (facteur de decision chez nos cients). C'est deja une gageure de trouver un outil de synthese classique en OSS.
-
-
-
Cette page a été générée par Templeet en 0.3106s (dont 0.0435 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.