Les design des laptop Mac sont principalement sans ventilo et Intel n'a pas fait beaucoup d'effort dans cette direction. Du coup, Apple a eu tendance a reduire la frequence des CPU qu'ils utilisent pour pouvoir tenir des temperatures correctes. Avec un passage a ARM, surtout les dernieres generations 64bits, il y a largement moyen d'avoir suffisament de performance pour faire tourner un usage laptop classique.
Apres, c'est pas mal la faute a Intel qui a beaucoup pousser sur des briques hardware quasiment pas utilise par le soft, car ecrire de l'assembleur pour faire de l'AVX512 partout ou une architecture specific pour utiliser les blocs de decompression hw, c'est pas franchement ideal pour grand monde. Du coup, on se retrouve avec du soft qui chauffe l'air ambiant alors qu'on pourrait etre nettement plus efficace si ils avaient un rien investit dans l'infrastructure logiciel de leur ecosysteme. Du coup, ca chauffe et on n'en tire meme pas avantage.
Je ne sais pas pendant combien de temps tu as été en hibernation, mais les gens n'ont pas attendu la crise sanitaire pour délocaliser ce qui peut l'être.
Et devine quoi? Ben en fait ce n'est pas si rentable que ça. Les entreprises indiennes (par exemple) ont un TJM 10x inférieur mais bon le taf est fait 7-8x moins vite, la rentabilité n'est pas si évidente et la "mode" est de réinternaliser.
Tout a fait! Et ca ne va probablement pas devenir plus simple pour les entreprises. La competition pour l'acces aux competences va devenir plus difficile. Les entreprises qui ont un bon processus de recrutement et sont capable de faire du teletravail efficacement ont un avantage par rapport a ceux qui ne peuvent pas. Les GAFA vont enfin comprendre qu'il n'est pas necessaire d'envoyer les gens a San Francisco et vont se rendre compte qu'ils ont plus de monde pres a travailler pour eux. Enfin ils n'ont pas le choix, ils n'ont plus le droit au visa d'immigration pour le reste de l'annee et etant donnee la latence de leur systeme, ca veut probablement dire pas d'immigration avant Septembre 2021. Ca va leur donner le temps de s'organiser et de faire en sorte que ca marche, ce n'est pas comme si on tentait d'aller sur la Lune. Du coup, je pense que au contraire, cela ouvre plus de potentielle pour notre profession.
Je n'ai pas vu grand monde pointer du doigts le fait que le télétravail va durer. Je n'habite pas en France et je remarque clairement une différence de niveau d'information. Le télétravail sur la côte ouest des états unis à ralentit l'arrivée de la première vague et limiter son amplitude. Les entreprises ne sont pas pressé de renvoyer leurs employés aux bureaux, car ils n'ont pas envie d'avoir tout leurs employés en arrêt.
Ainsi les bureaux c'est pour ceux qui ne peuvent pas travailler chez eux, avec un taux d'occupation des locaux de 25% du taux d'avant et avec des groupes d'employés qui ne se croisent pas. Les usines tournent avec des shifts qui sont regroupés par famille et aussi ne se croise pas. Et on évite que les gens qui n'ont pas besoin d'être la croise les gens qui doivent être la (Je bosse actuellement pour une boîte taïwanaise, ce sont leurs règles et ca marche chez eux). Ceux qui sont sur site doivent porter un masque quand il y a quelqu'un d'autre dans la même pièce. On se lave les mains à chaque entrée dans le bâtiment. Et c'est prévu pour durer jusqu'à l'été prochain. Du coup, certaines entreprises clarifie que cela va être du télétravail pour 24 mois. Comme ca tout le monde planifie en conséquence.
Et le risque est grand. Même en Corée du Sud avec une population qui fait nettement plus attention qu'en Europe, il y a une deuxième vague. Les entreprises qui s'organisent pour fonctionner en protégeant leurs équipes et en leur permettant d'être productive seront celle qui passeront cette crise au mieux. Et les pays qui arrivent à organiser leurs entreprises pour minimiser les risques seront ceux si s'en sortent le mieux.
Du coup, on en rediscute à l'été prochain de savoir si le télétravail ca peu marcher à l'échelle de la planète. Mais vaudrait mieux que pour ceux pour qui ca ne se passe pas bien, voir avec vos manager comment faire pour améliorer les choses, car ca va durer et pour résoudre le problème, c'est une question culturelle. Il faut s'adapter et les sociétés aussi doivent s'adapter.
Sauf qu'on parle ici d'interface graphique. Une fois que tu as chargé le thème et les font, tu n'as plus d'IO nécessaire pour le rendu graphique et même pour l'interactivité. Après il y a une balance avec ton cache et tu peux te retrouver à ne pas avoir toutes ces ressources en mémoire, mais globalement la partie interface ne devrait dépendre du disque que pour la première frame.
L'intérêt du coup d'avoir un scheduler rt, c'est probablement pour les thread en charge du rendu qui ont une deadline fixe de 14ms. Généralement le Shell tourne avec une priorité supérieur au reste des applications et ca suffit pour atteindre cette deadline. Je suis du coup pas super convaincu. De plus la majorité de la deadline va être dans la dépendance avec le gpu qui lui ne va probablement pas scheduler les requêtes en fonction du process qui lui envoie les commande. Après c'est probablement le changement le plus simple à coder pour gratter un peu de performance.
Etant donnee le contenu du journal introduisant ce debat et l'etat actuel de la reconnaissance de la connaissance scientifique face au marabouteux, ca promet d'etre triste. Je prend le paris qu'on va continuer de laisser une masse deconnecter de toute production agricole, science agronomique et qui ignore la famine decider en suivant le marketing de la peur d'une caste de bobo parisien qui se disent ecolo en paignant l'agriculture francaise comme un mixte de l'agriculture de nos grand parents et de l'agriculture americaine.
Si c'etait un debat sur l'avenir de l'informatique, on aurait en conclusion que seul des languages sures ou de haut niveau devrait etre utilise avec une interdiction formelle d'utiliser quoi que ce soit en C. Le lendemain de l'entree en effet de la loi, il n'y aurait plus d'informatique en France, car toutes les bases de notre informatique tourne sur du C et "personne" ne l'aurait vu venir.
La meme chose s'applique sur l'agriculture. On a une masse de gens qui fantasment l'agriculture comme etant realise par une bande de bouseux sans competence qui ont besoin d'etre eduque. Alors que les fermiers sont en premieres lignes pour eviter les revolutions ici et ailleurs (Et oui, l'exportation ca permet d'eviter a des famines lorsqu'il y a des pertes de recolte), se battent contre le changement climatique (C'est une des seules activites humaines qui peut avoir un bilan carbone negatif) le tout dans une economie de marche ou ils sont des entrepreneurs qui reussissent aussi economiquement en prenant en compte la science et en realisant des experimentations souvent en avance sur le monde academique.
Au lieu de dire comment s'y prendre, il vaudrait mieux reconnaitre le charactere strategique et hors marche de l'approvisionnement en produit agricole et donner des objectifs mesurables/quantifiables avec des moyens d'accompagnement marketing. En objectifs quantifiables on pourrait avoir:
- calories produites pour calories consomme pour un hectare (un score A-F comme pour l'electromenager et les batiments)
- quantite de matiere organique au metre carre sur les premiers 50cm du sol
- distance moyenne des cultures a une haie
Pas la peine d'ajouter des trucs sur les pesticides, ceux-ci sont deja tres controle et il est impossible de vendre des produits contamines. C'est assez n'importe quoi de raconter qu'il prolifere dans nos assiettes.
En mesure d'interdiction, je mettrais l'interdiction des derogations de pesticides toxiques connues. Cela aura un impact direct qui rendra la plus part des activites de production bio en France impossible (Le cuivre est un neuro toxique extremement toxique qui s'accumule dans les sols et est interdit en conventionnelle. Mais il a une derogation pour etre utilise en bio, car sinon le bio en France ne serait pas possible).
Avec de tel objectif, le resultat assez evident et il ne faut pas se voiler la face, c'est la fin du bio en France. En contre partie les bonnes pratiques lie a l'agriculture de conservation des sols, les activites de paturages seront mecaniquement promu ainsi que la recherche et l'amelioration des techniques agricoles. Pas la peine de rester bloquer sur l'Allemagne des annees 30.
Ce n'est qu'une question de temps. Linux aussi ne pouvait pas être utilisé dans un environnement critique il y a quelque années. Il faut bien démarrer quelque part et avancer.
Je vois un problème à l'idée, c'est le coup de changement de contexte qui va exploser, car il faudra reprogrammer le fpga pour le nouveau process. Ca peut marcher sur un contexte de microcontrôleurs, mais ca devient réducteur du coup (mais étant donné la montée des RISCV dans ce domaine, ca peut être un marché).
Juste pour completer, Terminology entre aussi dans la categorie terminaux pavant (ils supportent les tabs et le pavement). Il supportent aussi OpenGL et il est aussi tres leger, tout en proposant pas mal de fonctionnalite que d'autres terminaux n'ont pas (inline et popup d'une petite vingtaine de formats d'image et de tous les formats de video que supporte gstreamer/vlc, theme/background pour chaque pavement/tab, compression de 'historique, miniview, …).
Il fut un temps, peut etre il y a 3 ou 4 ans, j'avais fait des benchmarks. Le plus rapide, lege et efficace etait urxvt, mais terminology pouvait lui tenir la comparaison. Je ne sais pas trop ou cela en est aujourd'hui. Il faudrait que je reprenne le temps de faire des tests…
Les escapes sequences de terminology sont documentees (pour une fois qu'on a de la doc) dans la page de man. Il n'est pas necessaire d'utiliser les helpers comme tycat pour ce genre de commande. Apres ce n'est pas un standard, mais il n'y a pas trop de standard pour ce genre de fonctionnalite. Si tu as un pointeur vers une spec d'escape command standardise, ca serait assez facile de les ajouter a terminology, vue que les fonctionnalites sont deja la.
Pour ce qui est de la portabilite, Terminology fonctionne sur une large variete d'unix, inclu MacOS X. Sous Linux, tu peux l'utiliser en remplacement de ta console systeme grace au backend KMS/DRM ou frame buffer. Il y a aussi un backend Wayland en plus du backend X. Du coup, c'est pas si mal niveau portabilite. Le seul environnement manquant, c'est Windows et c'est principalement parce que jusqu'a recemment la maniere dont l'execution de process fonctionnait ete tres differente. Mais probablement qu'avec le support Ubuntu dans Windows cela devient plus jouable. Il faudrait regarder.
Si tu utilises une application X en pensant qu'elle peut se securiser, oublie ! Il y est possible pour toutes les applications ayant acces au meme serveur X, elles peuvent litterallement intercepter tous les appuies sur toutes les touches et capturer tous les pixels qui passent, cela fait partie du standard… Wayland resoud pas mal de ces problemes… Et en cree probablement d'autre !
Effectivement l'interet d'avoir le rendu fait cote GPU, c'est d'etre plus lege cote CPU. C'est un peu utile quand on a une machine poussive et que le CPU est trop charge, lors d'une compilation par exemple. Par contre, il y a un cout a utiliser le GPU, cela augmente l'utilisation de la batterie. De plus, du a la maniere dont OpenGL et X interragisse, il y a une forte latence lors du resize d'une fenetre OpenGL. Personnellement, c'est la principale raison pour laquelle je n'utilise pas l'acceleration OpenGL de mon terminal. Il faudrait que je regarde/test avec Wayland qui ne devrait pas avoir ce probleme.
Excellent progres ! Du coup, cela me fait poser quelques questions.
Est-ce qu'il y a une possibilite de gerer secureboot lorsque l'on remplace le bios ? En continuant dans cette direction, si oui, est-il possible d'acceder a un TPM ? Si oui, est-il possible d'utiliser cela pour initialiser des SED ? Ca serait assez utile pour les serveurs avec des disques et les protegers a minima quand on est dans un data center partage.
En fait, la question devient aussi quelle forme de distribution allez vous utiliser ? Une base de distribution classique facon debian ? Ou un firmware base sur buildroot ou yocto ? Comment va se passer la mise a jour d'un bios ?
Si je ne me trompe pas, lorsqu'on fait un kexec, on perd rapidement le "contact" et on ne peut pas debugger un kernel ou initrd qui ne demarre pas sans avoir acces physique a l'ecran. Sans une carte a cote, je ne vois pas trop de moyen acceptable de faire cela. Vous avez des idees sur le sujet ?
Ah, et sinon, c'est probablement une evidence, mais sshd et remote acces lors de la phase de boot pour pouvoir faire des diagnostic manuel, ca me parait tellement utile.
Bof, Intel ce n'est pas juste une bonne finesse de gravure, c'est aussi de bonnes idées. Mais depuis 5 ans quand AMD était
au fond du trou et ARM qui stagnait à augmenter la menace, Intel s'est relâché, ses dernières puces étaient de simple
rafraichissements des gammes plus vieilles. AMD avec Ryzen a tout remis à plat pour revenir dans la course.
Ce que tu racontes n'a aucun sens ! Pour commencer, je parle de performance par core. Si tu as plus de temps avant d'avoir un nouveau processus de fabrication, tu l'investit dans ce qui peut te donner plus de performance pour ton investissement. ARM, AMD et compagnie n'ont pas d'usine, donc ils n'investissent pas directement dans un processus de fabrication (autrement que en choisissant l'usine avec laquelle ils vont faire leur production). Du coup, pour eux 4 mois supplementaires pour optimiser les performances d'un core, c'est un avantage. Comme en terme de complexite, la loi de Amdhal limite les optimisations que l'on peut faire (En terme de hardware, c'est plutot un domaine bien balise, du coup, c'est plutot une question de compromis que de nouvelle technique d'optimisation). Au final tout le monde finira dans un mouchoir de poche pour le meme jeu d'instruction.
Sur le sujet, je te conseille de visionner la conference de David Patterson https://www.youtube.com/watch?v=1FtEGIp3a_M (Un saut a 39min pour ce qui l'en est de la fin de la loi de Moore).
Corollaire interressant de la fin de la loi de Moore, c'est que les performances intrinseques d'un jeu d'instruction vont progressivement etre de nouveau interressante a regarder… Si il y en a vraiment une ! Car finalement, un ARM, un x86, voir meme un RISC-V sont tous implementes a coup de micro code sur des pipelines de profondeur identique…
L'histoire française nous dit plutôt autre chose. De la fin du 17ème siècle au milieu du 19ème, la principale source d'énergie et de matériaux fut le bois. On n'avait pas encore trouvé nos mines de charbon, contrairement aux anglais. L'état à du déployé des gardes forestiers pour protégé sa ressource et en enlevé la gestion des mains des locaux. Cela au bénéfices premiers des militaires et des industrielles. Pendant les quasi 150 ans que cela à durée, il y a eu au moins un mort par an dans les gardes forestiers lié à un conflit sur la ressource. L'ajout d'un petit âge glacière a finit de déstabilisé le système et on a eu le droit au chaos en France pendant un moment. (La mauvaise gestion de nos forêts date de cette époque)
Pourtant, on avait découvert les états unis alors, et ils étaient couvert de bois. Mais il fut impossible de transporter cette ressource en France, car on manquait de l'infrastructure pour.
Du coup, il est assez facile de faire un parallèle avec la situation actuelle aussi bien pour le pétrole que pour les astéroïde. Et je doute fortement qu'on aura à temps l'infrastructure pour produire suffisamment dans l'espace et ramené le tout sur terre. D'ailleurs, on n'a toujours pas de source d'énergie sérieuse dans l'espace (je parle d'un truc avec un ordre de grandeur dans la dizaine de méga watt).
La loi de Moore est déjà entrain de ralentir. On est passé de 18 mois à 22 mois. Et le ralentissement est projeté avec une accélération durant la prochaine décennie. La principale raison, c'est l'explosion des coups. On atteint aujourd'hui de l'ordre de 10 milliards de dollars d'investissement par usine. Le tout à payer en moins de deux ans pour pouvoir construire la génération d'après (pas comme une centrale nucléaire qui elle s'amortie sur 40 ans).
De plus la performance par coeur, du fait de pas mal de problématique physique (dissipation thermique et perte électrique), stagne depuis 2015/2016. C'est probablement une des explications du rattrapage en cour de amd et arm sur Intel.
Tout ca, c'est le résultat de la loi de Amdahl et l'augmentation de la difficulté à optimiser un système. Pour faire simple, au début, c'est facile, mais à la fin, ca devient de plus en plus dure.
Je te conseille de lire «l'âge des low tech» pour te rendre compte que non, tu ne veux pas du 100% renouvelable ! Les besoins miniers et de surface seraient tel que notre planète ne le supporterait pas plus que notre consommation d'énergie fossile. Et cela, sans compter que l'énergie nette disponible serait probablement trop base pour permettre à notre civilisation d'exister.
Tu ne penses pas que la license GPL peut etre problematique pour faire un ASIC, car la plus part des usines viennent avec leurs propres blocs et bonne chance pour avoir ca sous GPL :-)
Je pense que tu fais une erreur. Tu confonds énergie net et énergie brut. L'énergie que reçois notre planète est l'énergie brute, la transformé en énergie net nécessite de consommer de l'énergie et de la matière (ceux sont les pertes du systèmes). Hors l'énergie net extractible de ce que l'on reçois du soleil est très faible.
De même, nous n'irons jamais miner jusqu'aux fin fonds des entrailles de la terre, car la quantité d'énergie nécessaire pour cela grandit exponentiellement (diminuant la disponibilités de celle ci pour le reste de la société). Et aller dans l'espace pour y installer une mine à probablement le même problème…
En fait, ce n'est pas techniquement le fait d'etre RISC qui pourrait rendre une architecture libre. C'est en fait son age. Une fois que les brevets qui la couvrent expirent. Ainsi, meme l'architecture x86, pre 1997 est aujourd'hui libre. Mais il faut dans ce cas, copie ce qu'on fesait dans les 90, sinon brevet ! Du coup, les architectures RISC sont plus interressante, car elles ont moins de goulot d'etranglement.
Donc dans la liste des processeurs libre, avec code source, tu as aujourd'hui le LEON (dont l'architecture date de la fin des annees 80) et le J-Core (Un SH2 pour l'instant) qui date du milieu des annees 90. A la fin de l'annee, ce sera le tour du SH4 qui ne sera plus couvert en fin d'annee par les brevets. Ce qui est interressant comme difference, c'est que le SH est ce qu'on peut appeler un RISC de seconde generation. Du coup, il y a une vrai difference sur le jeu d'instruction entre l'un et l'autre. Celui est plus compact et se rapproche de la densite des x86 et ARM Thumb est actuellement inspire de ce jeu d'instruction. L'interet d'avoir un jeu d'instruction compact, c'est que une moindre consommation de bande passante memoire pour le code (donc plus pour les data, ce qui est quand meme ideal). C'est un des avantages des x86, mais les SH a la difference des x86 n'ont pas besoin d'un etage microcode extrement complique pour pouvoir executer leurs codes. J'attend que la societe derriere le J-Core sorte leur board de developpement pour faire un journal plus consequent sur le sujet. Mais globalement, c'est un projet tres interressant a mon avis.
Mais ensuite, c'est aussi une question de tradeoff. Aujourd'hui pour designer un CPU completement libre, il faut pouvoir se payer un ASIC (Surun FPGA, on peut probablement atteindre les 100Mhz, grand maximum). Et clairement plus le process de gravure est fin et moderne, plus c'est couteux. Du coup, on peut difficilement imaginer acceder a plus que 250Mhz sans avoir des millions de dollars. De plus, il faut pouvoir ecouler des volumes important, de l'ordre de 20000 unites par batch. Donc on se retrouve dans un domaine plus IoT dans un premier temps. Du coup, cela veut dire que les processeurs sont optimises pour l'efficacite energetique et non les performances. Cela veut dire pas de branchement predictif, des petits caches et pas de multi instruction. Globalement, on ne va pas concurrencer un serveur x86 avec ca tout de suite.
En parlant de brevets qui expirent, il y a un certain nombre de techno que l'on utilise tous les jours qui vont expirer dans les 10 prochaines annees. Une partie du standard 3G, le Wifi, AMD 64 bits, … Je n'ai encore vu personne assembler une telle liste, mais ce serait extremement interressant pour le materiel libre !
Sérieusement qui a les moyens de payer aussi chère une solution libre ? C'est juste un plan sans queue ni tête des le départs. 100€ pour du hardware d'un constructeur inconnu qui me dit que c'est libre, je suis près à prendre le risque. Plusieurs milliers d'euros, Nop !
Je pense que tenter de reproduire le même business modèle du consumer électronique mais juste en prenant des composant plus libre fournit par les même société qui font les versions non libre, n'arrivera à rien. C'est pas leur priorité et les volumes sont trop petit.
Le projet Risc-V tente une approche différente, mais ils font aussi pas mal d'erreurs et pas forcément comme celle présenté dans l'article. Tout d'abord le design fondation orienté et pas logiciel libre avec des gros red flags sur les brevets d'une possible implémentation. Mais même si ca c'était clarifié, le vrai problème, c'est la fragmentation du logiciel. Pas de norme pour le boot, yeah, un noyaux et un bootloader par version de cpu ! Même l'user space va être compliqué à unifier… Sans compter aussi l'approche universitaire, Risc parfait et on ajoute à postériori les instructions compact parce qu'on a des problèmes de performances. Il faudra bien une décennie avant que le Risc-v soit utilisable comme plateforme (globalement, ils font les mêmes erreurs que arm…).
Du coup, quand on part de se point de vue, clairement on a le droit d'être défaitiste et de se dire qu'il n'y a rien qui va sortir.je pense que c'est faux.c'est juste que le point de départ est mal placé.
Il faut une architecture performante, supporté par linux et gcc, sans brevet ni aucune grosse société active dessus. C'est bien dans les années 90, il y a eu pas mal d'architecture qui ont subit un mauvais sort économique. Je pense en particulier aux alpha de dec et aux super Hitachi.
Je ne connais aucune société qui tente avec l'alpha, mais c'est probablement juste parce que le marché n'est pas la. Pour le super Hitachi, il y a la société SEI qui a libéré sous licence bsd un compatible SH2 nommé j2 et un son petit frère le j1. Le tout sans brevet et qui boot direct sur un linux upstream (ils ont rajouté le support du device tree et normalisé le boot pour avoir le même noyaux sur toute leur board).
Ils ont déjà des clients et travaille à une board a 100€ pour dev sur fpga dans l'objectif de faire des asic (ca prend plus de temps, car ils ne peuvent pas la prioritise face aux clients qui payent déjà). Cette board a trois puces: un fpga, un contrôleur pour le boot et un contrôleur USB pour des raison d'énergie. Pour l'instant, ces deux dernières ne sont pas libre. Mais avec le temps et des volumes connus, elles pourront toutes les deux être progressivement remplacé par des Soc a base de j-core.
De plus leur roadmap est plutôt clair et suis la disponibilité des brevets. Ainsi en fin d'années, le j3 sortira avec une mmu et sera compatible avec le sh4. Il aura probablement aussi une fpu, mais suivra le standard IEEE plutôt que ce que faisait le sh4. Le j4 est prévu comme une évolution multi issue du j3 et sera probablement pour la fin de l'année prochaine. Enfin, ils attendront 2020 pour faire le j64 qui sera une évolution 64 bits du jeu d'instruction sh comme x86_64 fut une évolution du x86_32. Il est a noté qu'ils se focalisent sur une architecture basse consommation d'énergie, du coup, ils n'ont aucun plan pour implémenter quoique ce soit de prédictif.
De mon point de vue, je pense que c'est une approche plus sûre.Rome ne s'est pas construit en un an et avoir des étapes utiles et vendeuses avant de faire un monstre comme celui proposé par talos , me semble nécessaire ! Et il y a plein de technos qui vont se libéré dans les dix ans: wifi,3g,…
Je pense que tu devrais refaire l'expérience. En achetant les wafer sur ebay, tu peux produire 35000 puces en 150nm pour 60000€. Le prix augmente de manière à peu près raisonnable et proche de linéaire jusqu'à 45nm, par contre le prix de la commande minimal augmente lui aussi de manière linéaire. Ca reste donc une question de volume.Mais la loi de Moore continue de diminuer ces prix…
Maintenant qu'est ce qu'on peut mettre dans un tel package. Un dual core Risc à 150MHz sans optimisation pour du 150nm et probablement jusqu'à 250MHz avec un petit effort (question de volume). En 45nm, et bien on titille le GHz…
De plus, on peut utilisé des fpga aujourd'hui pour facilement développer et tester ce genre de design. Par contre, les board bas prix de dev ne sont pas orienté pour le développement de Soc en général, du coup faut se méfier et regarder si on accès directement aux sorties (USB, HDMI, Ethernet…).
La raison du pourquoi du comment c'est possible…si tu pars sur un design prouvé sans brevet et avec linux qui fonctionne dessus, même si c'est à basse fréquences, tu peux le donner au fab et ca les intéresse, car elles peuvent en faire ce qu'elle veulent derrière. Sans compter qu'il y a pas mal de fab en Asie qui sont en sous production, donc le marché à évoluer et ca va plutôt dans le bon sens.
Je te trouve bien pessimiste dans ton journal. Il y a un point que personne n'a releve. La fin progressive des brevets sur le 802.11b d'ici a 2019. Et oui, le WiFi a 20 ans ! \o/
Cela implique que l'on va probablement voir apparaitre des soft-core pour FPGA ou de la SDR implementant le Wifi completement libre. C'est quelque chose que je trouve tres interressant, ainsi une grande partie de la technologie de la fin des annees 90 combine a la seule loi de Moore permet d'etre competitif avec le bon logiciel dessus. Du coup, il ne faut pas etre negatif, et la fin de cette decennie va surement voir une explosion de hardware libre et competitif ! Sans compter qu'avec le ralentissement de la loi de Moore, la competition se deplace du toujours plus, vers l'utilisation plus efficace du hardware par le software…
Elle a du plomb dans l'aile et c'est la même logique que pour les pics pétroliers et miniers. Il existe un point dans le temps où l'investissement en capitale nécessaire pour le prochain saut technologique dépasse les gains potentiels. Du coup, les investissements ralentissent au cours du temps.
Aujourd'hui il n'y a que deux constructeur à avoir la dernière techno de finesse de gravure. Intel et Samsung. Il y a 4 ans, ils étaient 4. Il y a dix ans, on avait du mal à les compter sur nos 10 doigts. Les usines de cette génération a coûté plus chère qu'un EPR et devra être remboursé en 2 ans…pour pouvoir construire la génération d'après… Qui coutera encore plus chère. En fait depuis 10 ans le coup de fabrication des usines à microprocesseur suit aussi une loi exponentielle, et ca, c'est pas bon.
Du coup, oui, ca ralentit. De la,à dire que ca s'arrête, on n'y est pas encore. Probablement une ou deux décennies avant que cela n'arrive (si on continue de fabriquer autant de Smart Phone, tablette et laptop pour justifier la prochaine génération).
Très bonne article, et ca vaudrait une dépêche ! Juste dans la liste des architectures sur lesquels il faut garder un oeil en temps que libriste, j-core, aka super Hitachi.
Aujourd'hui, seule le j2 est disponible. C'est un coeur super Hitachi 2 avec le support du smp. Il est disponible sous licence bsd en forme vhdl et fonctionne d'emblée sur un fpga. Il n'a aucun brevet qui s'applique dessus et à une densité d'instruction proche du x86. Il y a eu un premier batch d'asic. Bon, clairement, ca fonctionne à 60MHz et on ne fera pas une work station avec ca.mais avec la fin des brevets sur le sh4 en 2017, il y a de quoi espéré une base très intéressante.surtout que contrairement au risc-v, le code libérée est du code de production avec un véritable objectif de performance et de coup. Voilà, je te conseille de garder un oeil sur j-core.org.
Si on parle de CPU et de graphique, on parle forcement de rendu logiciel, sinon c'est un probleme de GPU et c'est une autre discussion. Du coup, pour avoir regarde un peu leur proposition de calcul vectoriel, je vois pas vraiment de raison pour que ca ne se passe pas bien. Manque juste un petit framebuffer avec plusieurs plans hardware pour couvrir pas mal de use case.
On fait facilement du 60fps en 512P sur un MIPS a 500Mhz sans extention vectoriel. Je pense qu'un RISC V avec une frequence plus eleve et une unite de calcul vectoriel devrait sans sortir en HD. Apres le 4K, ca reste encore un challenge pour meme le haut de gamme, donc disons que ca posera probablement des soucis au RISC V aussi.
[^] # Re: Mais pourquoi donc ?
Posté par cedric . En réponse au journal Transition ARM : Apple assistera certains projet open source . Évalué à 1.
Les design des laptop Mac sont principalement sans ventilo et Intel n'a pas fait beaucoup d'effort dans cette direction. Du coup, Apple a eu tendance a reduire la frequence des CPU qu'ils utilisent pour pouvoir tenir des temperatures correctes. Avec un passage a ARM, surtout les dernieres generations 64bits, il y a largement moyen d'avoir suffisament de performance pour faire tourner un usage laptop classique.
Apres, c'est pas mal la faute a Intel qui a beaucoup pousser sur des briques hardware quasiment pas utilise par le soft, car ecrire de l'assembleur pour faire de l'AVX512 partout ou une architecture specific pour utiliser les blocs de decompression hw, c'est pas franchement ideal pour grand monde. Du coup, on se retrouve avec du soft qui chauffe l'air ambiant alors qu'on pourrait etre nettement plus efficace si ils avaient un rien investit dans l'infrastructure logiciel de leur ecosysteme. Du coup, ca chauffe et on n'en tire meme pas avantage.
[^] # Re: Rien de nouveau
Posté par cedric . En réponse au journal Télétravail, premier pas vers une délocalisation générale ?. Évalué à 2.
Tout a fait! Et ca ne va probablement pas devenir plus simple pour les entreprises. La competition pour l'acces aux competences va devenir plus difficile. Les entreprises qui ont un bon processus de recrutement et sont capable de faire du teletravail efficacement ont un avantage par rapport a ceux qui ne peuvent pas. Les GAFA vont enfin comprendre qu'il n'est pas necessaire d'envoyer les gens a San Francisco et vont se rendre compte qu'ils ont plus de monde pres a travailler pour eux. Enfin ils n'ont pas le choix, ils n'ont plus le droit au visa d'immigration pour le reste de l'annee et etant donnee la latence de leur systeme, ca veut probablement dire pas d'immigration avant Septembre 2021. Ca va leur donner le temps de s'organiser et de faire en sorte que ca marche, ce n'est pas comme si on tentait d'aller sur la Lune. Du coup, je pense que au contraire, cela ouvre plus de potentielle pour notre profession.
# Ca va durer.
Posté par cedric . En réponse au journal Télétravail, premier pas vers une délocalisation générale ?. Évalué à 7.
Je n'ai pas vu grand monde pointer du doigts le fait que le télétravail va durer. Je n'habite pas en France et je remarque clairement une différence de niveau d'information. Le télétravail sur la côte ouest des états unis à ralentit l'arrivée de la première vague et limiter son amplitude. Les entreprises ne sont pas pressé de renvoyer leurs employés aux bureaux, car ils n'ont pas envie d'avoir tout leurs employés en arrêt.
Ainsi les bureaux c'est pour ceux qui ne peuvent pas travailler chez eux, avec un taux d'occupation des locaux de 25% du taux d'avant et avec des groupes d'employés qui ne se croisent pas. Les usines tournent avec des shifts qui sont regroupés par famille et aussi ne se croise pas. Et on évite que les gens qui n'ont pas besoin d'être la croise les gens qui doivent être la (Je bosse actuellement pour une boîte taïwanaise, ce sont leurs règles et ca marche chez eux). Ceux qui sont sur site doivent porter un masque quand il y a quelqu'un d'autre dans la même pièce. On se lave les mains à chaque entrée dans le bâtiment. Et c'est prévu pour durer jusqu'à l'été prochain. Du coup, certaines entreprises clarifie que cela va être du télétravail pour 24 mois. Comme ca tout le monde planifie en conséquence.
Et le risque est grand. Même en Corée du Sud avec une population qui fait nettement plus attention qu'en Europe, il y a une deuxième vague. Les entreprises qui s'organisent pour fonctionner en protégeant leurs équipes et en leur permettant d'être productive seront celle qui passeront cette crise au mieux. Et les pays qui arrivent à organiser leurs entreprises pour minimiser les risques seront ceux si s'en sortent le mieux.
Du coup, on en rediscute à l'été prochain de savoir si le télétravail ca peu marcher à l'échelle de la planète. Mais vaudrait mieux que pour ceux pour qui ca ne se passe pas bien, voir avec vos manager comment faire pour améliorer les choses, car ca va durer et pour résoudre le problème, c'est une question culturelle. Il faut s'adapter et les sociétés aussi doivent s'adapter.
[^] # Re: Aucun I/O dans le fil d'exécution principal est irréaliste
Posté par cedric . En réponse au journal GNOME avec un scheduler temps réel. Évalué à 4.
Sauf qu'on parle ici d'interface graphique. Une fois que tu as chargé le thème et les font, tu n'as plus d'IO nécessaire pour le rendu graphique et même pour l'interactivité. Après il y a une balance avec ton cache et tu peux te retrouver à ne pas avoir toutes ces ressources en mémoire, mais globalement la partie interface ne devrait dépendre du disque que pour la première frame.
L'intérêt du coup d'avoir un scheduler rt, c'est probablement pour les thread en charge du rendu qui ont une deadline fixe de 14ms. Généralement le Shell tourne avec une priorité supérieur au reste des applications et ca suffit pour atteindre cette deadline. Je suis du coup pas super convaincu. De plus la majorité de la deadline va être dans la dépendance avec le gpu qui lui ne va probablement pas scheduler les requêtes en fonction du process qui lui envoie les commande. Après c'est probablement le changement le plus simple à coder pour gratter un peu de performance.
# Un debat qui promet d'etre bien deprimant et inutile
Posté par cedric . En réponse au journal Débat public sur l'agriculture. Évalué à 6.
Etant donnee le contenu du journal introduisant ce debat et l'etat actuel de la reconnaissance de la connaissance scientifique face au marabouteux, ca promet d'etre triste. Je prend le paris qu'on va continuer de laisser une masse deconnecter de toute production agricole, science agronomique et qui ignore la famine decider en suivant le marketing de la peur d'une caste de bobo parisien qui se disent ecolo en paignant l'agriculture francaise comme un mixte de l'agriculture de nos grand parents et de l'agriculture americaine.
Si c'etait un debat sur l'avenir de l'informatique, on aurait en conclusion que seul des languages sures ou de haut niveau devrait etre utilise avec une interdiction formelle d'utiliser quoi que ce soit en C. Le lendemain de l'entree en effet de la loi, il n'y aurait plus d'informatique en France, car toutes les bases de notre informatique tourne sur du C et "personne" ne l'aurait vu venir.
La meme chose s'applique sur l'agriculture. On a une masse de gens qui fantasment l'agriculture comme etant realise par une bande de bouseux sans competence qui ont besoin d'etre eduque. Alors que les fermiers sont en premieres lignes pour eviter les revolutions ici et ailleurs (Et oui, l'exportation ca permet d'eviter a des famines lorsqu'il y a des pertes de recolte), se battent contre le changement climatique (C'est une des seules activites humaines qui peut avoir un bilan carbone negatif) le tout dans une economie de marche ou ils sont des entrepreneurs qui reussissent aussi economiquement en prenant en compte la science et en realisant des experimentations souvent en avance sur le monde academique.
Au lieu de dire comment s'y prendre, il vaudrait mieux reconnaitre le charactere strategique et hors marche de l'approvisionnement en produit agricole et donner des objectifs mesurables/quantifiables avec des moyens d'accompagnement marketing. En objectifs quantifiables on pourrait avoir:
- calories produites pour calories consomme pour un hectare (un score A-F comme pour l'electromenager et les batiments)
- quantite de matiere organique au metre carre sur les premiers 50cm du sol
- distance moyenne des cultures a une haie
Pas la peine d'ajouter des trucs sur les pesticides, ceux-ci sont deja tres controle et il est impossible de vendre des produits contamines. C'est assez n'importe quoi de raconter qu'il prolifere dans nos assiettes.
En mesure d'interdiction, je mettrais l'interdiction des derogations de pesticides toxiques connues. Cela aura un impact direct qui rendra la plus part des activites de production bio en France impossible (Le cuivre est un neuro toxique extremement toxique qui s'accumule dans les sols et est interdit en conventionnelle. Mais il a une derogation pour etre utilise en bio, car sinon le bio en France ne serait pas possible).
Avec de tel objectif, le resultat assez evident et il ne faut pas se voiler la face, c'est la fin du bio en France. En contre partie les bonnes pratiques lie a l'agriculture de conservation des sols, les activites de paturages seront mecaniquement promu ainsi que la recherche et l'amelioration des techniques agricoles. Pas la peine de rester bloquer sur l'Allemagne des annees 30.
On peut rever :-D
[^] # Re: Quid de la certification et de l'utilisation industrielle ?
Posté par cedric . En réponse à la dépêche La libération des FPGA et des ASIC bien engagée pour 2020. Évalué à 10.
Ce n'est qu'une question de temps. Linux aussi ne pouvait pas être utilisé dans un environnement critique il y a quelque années. Il faut bien démarrer quelque part et avancer.
[^] # Re: chip de test
Posté par cedric . En réponse au journal k1g1 : le premier FPGA Libre…. Évalué à 2.
Je vois un problème à l'idée, c'est le coup de changement de contexte qui va exploser, car il faudra reprogrammer le fpga pour le nouveau process. Ca peut marcher sur un contexte de microcontrôleurs, mais ca devient réducteur du coup (mais étant donné la montée des RISCV dans ce domaine, ca peut être un marché).
# Terminology
Posté par cedric . En réponse à la dépêche Quel terminal pour 2018 ?. Évalué à 7.
Juste pour completer, Terminology entre aussi dans la categorie terminaux pavant (ils supportent les tabs et le pavement). Il supportent aussi OpenGL et il est aussi tres leger, tout en proposant pas mal de fonctionnalite que d'autres terminaux n'ont pas (inline et popup d'une petite vingtaine de formats d'image et de tous les formats de video que supporte gstreamer/vlc, theme/background pour chaque pavement/tab, compression de 'historique, miniview, …).
Il fut un temps, peut etre il y a 3 ou 4 ans, j'avais fait des benchmarks. Le plus rapide, lege et efficace etait urxvt, mais terminology pouvait lui tenir la comparaison. Je ne sais pas trop ou cela en est aujourd'hui. Il faudrait que je reprenne le temps de faire des tests…
[^] # Re: iTerm2
Posté par cedric . En réponse à la dépêche Quel terminal pour 2018 ?. Évalué à 2.
Les escapes sequences de terminology sont documentees (pour une fois qu'on a de la doc) dans la page de man. Il n'est pas necessaire d'utiliser les helpers comme tycat pour ce genre de commande. Apres ce n'est pas un standard, mais il n'y a pas trop de standard pour ce genre de fonctionnalite. Si tu as un pointeur vers une spec d'escape command standardise, ca serait assez facile de les ajouter a terminology, vue que les fonctionnalites sont deja la.
Pour ce qui est de la portabilite, Terminology fonctionne sur une large variete d'unix, inclu MacOS X. Sous Linux, tu peux l'utiliser en remplacement de ta console systeme grace au backend KMS/DRM ou frame buffer. Il y a aussi un backend Wayland en plus du backend X. Du coup, c'est pas si mal niveau portabilite. Le seul environnement manquant, c'est Windows et c'est principalement parce que jusqu'a recemment la maniere dont l'execution de process fonctionnait ete tres differente. Mais probablement qu'avec le support Ubuntu dans Windows cela devient plus jouable. Il faudrait regarder.
[^] # Re: En 2018… comme en 1993, xterm
Posté par cedric . En réponse à la dépêche Quel terminal pour 2018 ?. Évalué à 3.
Si tu utilises une application X en pensant qu'elle peut se securiser, oublie ! Il y est possible pour toutes les applications ayant acces au meme serveur X, elles peuvent litterallement intercepter tous les appuies sur toutes les touches et capturer tous les pixels qui passent, cela fait partie du standard… Wayland resoud pas mal de ces problemes… Et en cree probablement d'autre !
[^] # Re: pardon mais...
Posté par cedric . En réponse à la dépêche Quel terminal pour 2018 ?. Évalué à 2.
Effectivement l'interet d'avoir le rendu fait cote GPU, c'est d'etre plus lege cote CPU. C'est un peu utile quand on a une machine poussive et que le CPU est trop charge, lors d'une compilation par exemple. Par contre, il y a un cout a utiliser le GPU, cela augmente l'utilisation de la batterie. De plus, du a la maniere dont OpenGL et X interragisse, il y a une forte latence lors du resize d'une fenetre OpenGL. Personnellement, c'est la principale raison pour laquelle je n'utilise pas l'acceleration OpenGL de mon terminal. Il faudrait que je regarde/test avec Wayland qui ne devrait pas avoir ce probleme.
# Petites questions
Posté par cedric . En réponse au journal Vers des serveurs libres, ouverts et sécurisés : NERF (2). Évalué à 3.
Excellent progres ! Du coup, cela me fait poser quelques questions.
Est-ce qu'il y a une possibilite de gerer secureboot lorsque l'on remplace le bios ? En continuant dans cette direction, si oui, est-il possible d'acceder a un TPM ? Si oui, est-il possible d'utiliser cela pour initialiser des SED ? Ca serait assez utile pour les serveurs avec des disques et les protegers a minima quand on est dans un data center partage.
En fait, la question devient aussi quelle forme de distribution allez vous utiliser ? Une base de distribution classique facon debian ? Ou un firmware base sur buildroot ou yocto ? Comment va se passer la mise a jour d'un bios ?
Si je ne me trompe pas, lorsqu'on fait un kexec, on perd rapidement le "contact" et on ne peut pas debugger un kernel ou initrd qui ne demarre pas sans avoir acces physique a l'ecran. Sans une carte a cote, je ne vois pas trop de moyen acceptable de faire cela. Vous avez des idees sur le sujet ?
Ah, et sinon, c'est probablement une evidence, mais sshd et remote acces lors de la phase de boot pour pouvoir faire des diagnostic manuel, ca me parait tellement utile.
Oh et sinon go, vous aimez ?
[^] # Re: Jouer au démineur en 2157
Posté par cedric . En réponse au journal Next, la web-série sur les risques d’effondrement de notre civilisation, et le monde d’après. Évalué à 2.
Tu peux lire le premier paragraphe de https://en.wikipedia.org/wiki/Moore%27s_law .
Du coup, bah, non.
Ce que tu racontes n'a aucun sens ! Pour commencer, je parle de performance par core. Si tu as plus de temps avant d'avoir un nouveau processus de fabrication, tu l'investit dans ce qui peut te donner plus de performance pour ton investissement. ARM, AMD et compagnie n'ont pas d'usine, donc ils n'investissent pas directement dans un processus de fabrication (autrement que en choisissant l'usine avec laquelle ils vont faire leur production). Du coup, pour eux 4 mois supplementaires pour optimiser les performances d'un core, c'est un avantage. Comme en terme de complexite, la loi de Amdhal limite les optimisations que l'on peut faire (En terme de hardware, c'est plutot un domaine bien balise, du coup, c'est plutot une question de compromis que de nouvelle technique d'optimisation). Au final tout le monde finira dans un mouchoir de poche pour le meme jeu d'instruction.
Sur le sujet, je te conseille de visionner la conference de David Patterson https://www.youtube.com/watch?v=1FtEGIp3a_M (Un saut a 39min pour ce qui l'en est de la fin de la loi de Moore).
Corollaire interressant de la fin de la loi de Moore, c'est que les performances intrinseques d'un jeu d'instruction vont progressivement etre de nouveau interressante a regarder… Si il y en a vraiment une ! Car finalement, un ARM, un x86, voir meme un RISC-V sont tous implementes a coup de micro code sur des pipelines de profondeur identique…
[^] # Re: Jouer au démineur en 2157
Posté par cedric . En réponse au journal Next, la web-série sur les risques d’effondrement de notre civilisation, et le monde d’après. Évalué à 3.
L'histoire française nous dit plutôt autre chose. De la fin du 17ème siècle au milieu du 19ème, la principale source d'énergie et de matériaux fut le bois. On n'avait pas encore trouvé nos mines de charbon, contrairement aux anglais. L'état à du déployé des gardes forestiers pour protégé sa ressource et en enlevé la gestion des mains des locaux. Cela au bénéfices premiers des militaires et des industrielles. Pendant les quasi 150 ans que cela à durée, il y a eu au moins un mort par an dans les gardes forestiers lié à un conflit sur la ressource. L'ajout d'un petit âge glacière a finit de déstabilisé le système et on a eu le droit au chaos en France pendant un moment. (La mauvaise gestion de nos forêts date de cette époque)
Pourtant, on avait découvert les états unis alors, et ils étaient couvert de bois. Mais il fut impossible de transporter cette ressource en France, car on manquait de l'infrastructure pour.
Du coup, il est assez facile de faire un parallèle avec la situation actuelle aussi bien pour le pétrole que pour les astéroïde. Et je doute fortement qu'on aura à temps l'infrastructure pour produire suffisamment dans l'espace et ramené le tout sur terre. D'ailleurs, on n'a toujours pas de source d'énergie sérieuse dans l'espace (je parle d'un truc avec un ordre de grandeur dans la dizaine de méga watt).
[^] # Re: Jouer au démineur en 2157
Posté par cedric . En réponse au journal Next, la web-série sur les risques d’effondrement de notre civilisation, et le monde d’après. Évalué à 5.
La loi de Moore est déjà entrain de ralentir. On est passé de 18 mois à 22 mois. Et le ralentissement est projeté avec une accélération durant la prochaine décennie. La principale raison, c'est l'explosion des coups. On atteint aujourd'hui de l'ordre de 10 milliards de dollars d'investissement par usine. Le tout à payer en moins de deux ans pour pouvoir construire la génération d'après (pas comme une centrale nucléaire qui elle s'amortie sur 40 ans).
De plus la performance par coeur, du fait de pas mal de problématique physique (dissipation thermique et perte électrique), stagne depuis 2015/2016. C'est probablement une des explications du rattrapage en cour de amd et arm sur Intel.
Tout ca, c'est le résultat de la loi de Amdahl et l'augmentation de la difficulté à optimiser un système. Pour faire simple, au début, c'est facile, mais à la fin, ca devient de plus en plus dure.
[^] # Re: J'ai jeté un oeil...
Posté par cedric . En réponse au journal Next, la web-série sur les risques d’effondrement de notre civilisation, et le monde d’après. Évalué à 3.
Je te conseille de lire «l'âge des low tech» pour te rendre compte que non, tu ne veux pas du 100% renouvelable ! Les besoins miniers et de surface seraient tel que notre planète ne le supporterait pas plus que notre consommation d'énergie fossile. Et cela, sans compter que l'énergie nette disponible serait probablement trop base pour permettre à notre civilisation d'exister.
[^] # Re: Pourquoi X86 (Intel)
Posté par cedric . En réponse à la dépêche Un pas en avant pour les serveurs libres : le projet NERF. Évalué à 6.
Tu ne penses pas que la license GPL peut etre problematique pour faire un ASIC, car la plus part des usines viennent avec leurs propres blocs et bonne chance pour avoir ca sous GPL :-)
[^] # Re: pertinence de l'article
Posté par cedric . En réponse au journal [Bookmark] Le coût écologique d’internet est trop lourd, il faut penser un internet low-tech.. Évalué à 2.
Je pense que tu fais une erreur. Tu confonds énergie net et énergie brut. L'énergie que reçois notre planète est l'énergie brute, la transformé en énergie net nécessite de consommer de l'énergie et de la matière (ceux sont les pertes du systèmes). Hors l'énergie net extractible de ce que l'on reçois du soleil est très faible.
De même, nous n'irons jamais miner jusqu'aux fin fonds des entrailles de la terre, car la quantité d'énergie nécessaire pour cela grandit exponentiellement (diminuant la disponibilités de celle ci pour le reste de la société). Et aller dans l'espace pour y installer une mine à probablement le même problème…
[^] # Re: Et Risc?
Posté par cedric . En réponse à la dépêche Open Compute Summit 2017, alors c’était bien ?. Évalué à 9.
En fait, ce n'est pas techniquement le fait d'etre RISC qui pourrait rendre une architecture libre. C'est en fait son age. Une fois que les brevets qui la couvrent expirent. Ainsi, meme l'architecture x86, pre 1997 est aujourd'hui libre. Mais il faut dans ce cas, copie ce qu'on fesait dans les 90, sinon brevet ! Du coup, les architectures RISC sont plus interressante, car elles ont moins de goulot d'etranglement.
Donc dans la liste des processeurs libre, avec code source, tu as aujourd'hui le LEON (dont l'architecture date de la fin des annees 80) et le J-Core (Un SH2 pour l'instant) qui date du milieu des annees 90. A la fin de l'annee, ce sera le tour du SH4 qui ne sera plus couvert en fin d'annee par les brevets. Ce qui est interressant comme difference, c'est que le SH est ce qu'on peut appeler un RISC de seconde generation. Du coup, il y a une vrai difference sur le jeu d'instruction entre l'un et l'autre. Celui est plus compact et se rapproche de la densite des x86 et ARM Thumb est actuellement inspire de ce jeu d'instruction. L'interet d'avoir un jeu d'instruction compact, c'est que une moindre consommation de bande passante memoire pour le code (donc plus pour les data, ce qui est quand meme ideal). C'est un des avantages des x86, mais les SH a la difference des x86 n'ont pas besoin d'un etage microcode extrement complique pour pouvoir executer leurs codes. J'attend que la societe derriere le J-Core sorte leur board de developpement pour faire un journal plus consequent sur le sujet. Mais globalement, c'est un projet tres interressant a mon avis.
Mais ensuite, c'est aussi une question de tradeoff. Aujourd'hui pour designer un CPU completement libre, il faut pouvoir se payer un ASIC (Surun FPGA, on peut probablement atteindre les 100Mhz, grand maximum). Et clairement plus le process de gravure est fin et moderne, plus c'est couteux. Du coup, on peut difficilement imaginer acceder a plus que 250Mhz sans avoir des millions de dollars. De plus, il faut pouvoir ecouler des volumes important, de l'ordre de 20000 unites par batch. Donc on se retrouve dans un domaine plus IoT dans un premier temps. Du coup, cela veut dire que les processeurs sont optimises pour l'efficacite energetique et non les performances. Cela veut dire pas de branchement predictif, des petits caches et pas de multi instruction. Globalement, on ne va pas concurrencer un serveur x86 avec ca tout de suite.
En parlant de brevets qui expirent, il y a un certain nombre de techno que l'on utilise tous les jours qui vont expirer dans les 10 prochaines annees. Une partie du standard 3G, le Wifi, AMD 64 bits, … Je n'ai encore vu personne assembler une telle liste, mais ce serait extremement interressant pour le materiel libre !
# Bullshit !
Posté par cedric . En réponse à la dépêche Matériel libre : état des lieux après l’échec de la campagne de financement Talos. Évalué à 4.
Sérieusement qui a les moyens de payer aussi chère une solution libre ? C'est juste un plan sans queue ni tête des le départs. 100€ pour du hardware d'un constructeur inconnu qui me dit que c'est libre, je suis près à prendre le risque. Plusieurs milliers d'euros, Nop !
Je pense que tenter de reproduire le même business modèle du consumer électronique mais juste en prenant des composant plus libre fournit par les même société qui font les versions non libre, n'arrivera à rien. C'est pas leur priorité et les volumes sont trop petit.
Le projet Risc-V tente une approche différente, mais ils font aussi pas mal d'erreurs et pas forcément comme celle présenté dans l'article. Tout d'abord le design fondation orienté et pas logiciel libre avec des gros red flags sur les brevets d'une possible implémentation. Mais même si ca c'était clarifié, le vrai problème, c'est la fragmentation du logiciel. Pas de norme pour le boot, yeah, un noyaux et un bootloader par version de cpu ! Même l'user space va être compliqué à unifier… Sans compter aussi l'approche universitaire, Risc parfait et on ajoute à postériori les instructions compact parce qu'on a des problèmes de performances. Il faudra bien une décennie avant que le Risc-v soit utilisable comme plateforme (globalement, ils font les mêmes erreurs que arm…).
Du coup, quand on part de se point de vue, clairement on a le droit d'être défaitiste et de se dire qu'il n'y a rien qui va sortir.je pense que c'est faux.c'est juste que le point de départ est mal placé.
Il faut une architecture performante, supporté par linux et gcc, sans brevet ni aucune grosse société active dessus. C'est bien dans les années 90, il y a eu pas mal d'architecture qui ont subit un mauvais sort économique. Je pense en particulier aux alpha de dec et aux super Hitachi.
Je ne connais aucune société qui tente avec l'alpha, mais c'est probablement juste parce que le marché n'est pas la. Pour le super Hitachi, il y a la société SEI qui a libéré sous licence bsd un compatible SH2 nommé j2 et un son petit frère le j1. Le tout sans brevet et qui boot direct sur un linux upstream (ils ont rajouté le support du device tree et normalisé le boot pour avoir le même noyaux sur toute leur board).
Ils ont déjà des clients et travaille à une board a 100€ pour dev sur fpga dans l'objectif de faire des asic (ca prend plus de temps, car ils ne peuvent pas la prioritise face aux clients qui payent déjà). Cette board a trois puces: un fpga, un contrôleur pour le boot et un contrôleur USB pour des raison d'énergie. Pour l'instant, ces deux dernières ne sont pas libre. Mais avec le temps et des volumes connus, elles pourront toutes les deux être progressivement remplacé par des Soc a base de j-core.
De plus leur roadmap est plutôt clair et suis la disponibilité des brevets. Ainsi en fin d'années, le j3 sortira avec une mmu et sera compatible avec le sh4. Il aura probablement aussi une fpu, mais suivra le standard IEEE plutôt que ce que faisait le sh4. Le j4 est prévu comme une évolution multi issue du j3 et sera probablement pour la fin de l'année prochaine. Enfin, ils attendront 2020 pour faire le j64 qui sera une évolution 64 bits du jeu d'instruction sh comme x86_64 fut une évolution du x86_32. Il est a noté qu'ils se focalisent sur une architecture basse consommation d'énergie, du coup, ils n'ont aucun plan pour implémenter quoique ce soit de prédictif.
De mon point de vue, je pense que c'est une approche plus sûre.Rome ne s'est pas construit en un an et avoir des étapes utiles et vendeuses avant de faire un monstre comme celui proposé par talos , me semble nécessaire ! Et il y a plein de technos qui vont se libéré dans les dix ans: wifi,3g,…
[^] # Re: Pistes de développement
Posté par cedric . En réponse à la dépêche Matériel libre : état des lieux après l’échec de la campagne de financement Talos. Évalué à 3.
Je pense que tu devrais refaire l'expérience. En achetant les wafer sur ebay, tu peux produire 35000 puces en 150nm pour 60000€. Le prix augmente de manière à peu près raisonnable et proche de linéaire jusqu'à 45nm, par contre le prix de la commande minimal augmente lui aussi de manière linéaire. Ca reste donc une question de volume.Mais la loi de Moore continue de diminuer ces prix…
Maintenant qu'est ce qu'on peut mettre dans un tel package. Un dual core Risc à 150MHz sans optimisation pour du 150nm et probablement jusqu'à 250MHz avec un petit effort (question de volume). En 45nm, et bien on titille le GHz…
De plus, on peut utilisé des fpga aujourd'hui pour facilement développer et tester ce genre de design. Par contre, les board bas prix de dev ne sont pas orienté pour le développement de Soc en général, du coup faut se méfier et regarder si on accès directement aux sorties (USB, HDMI, Ethernet…).
La raison du pourquoi du comment c'est possible…si tu pars sur un design prouvé sans brevet et avec linux qui fonctionne dessus, même si c'est à basse fréquences, tu peux le donner au fab et ca les intéresse, car elles peuvent en faire ce qu'elle veulent derrière. Sans compter qu'il y a pas mal de fab en Asie qui sont en sous production, donc le marché à évoluer et ca va plutôt dans le bon sens.
# Faut etre optimiste !
Posté par cedric . En réponse au journal Point d'étape sur le matériel et nos libertés partie 2. Évalué à 5.
Je te trouve bien pessimiste dans ton journal. Il y a un point que personne n'a releve. La fin progressive des brevets sur le 802.11b d'ici a 2019. Et oui, le WiFi a 20 ans ! \o/
Cela implique que l'on va probablement voir apparaitre des soft-core pour FPGA ou de la SDR implementant le Wifi completement libre. C'est quelque chose que je trouve tres interressant, ainsi une grande partie de la technologie de la fin des annees 90 combine a la seule loi de Moore permet d'etre competitif avec le bon logiciel dessus. Du coup, il ne faut pas etre negatif, et la fin de cette decennie va surement voir une explosion de hardware libre et competitif ! Sans compter qu'avec le ralentissement de la loi de Moore, la competition se deplace du toujours plus, vers l'utilisation plus efficace du hardware par le software…
[^] # Re: Comment bookmark de gens optimistes
Posté par cedric . En réponse à la dépêche Le logiciel libre au-delà de x86. Évalué à 6.
Elle a du plomb dans l'aile et c'est la même logique que pour les pics pétroliers et miniers. Il existe un point dans le temps où l'investissement en capitale nécessaire pour le prochain saut technologique dépasse les gains potentiels. Du coup, les investissements ralentissent au cours du temps.
Aujourd'hui il n'y a que deux constructeur à avoir la dernière techno de finesse de gravure. Intel et Samsung. Il y a 4 ans, ils étaient 4. Il y a dix ans, on avait du mal à les compter sur nos 10 doigts. Les usines de cette génération a coûté plus chère qu'un EPR et devra être remboursé en 2 ans…pour pouvoir construire la génération d'après… Qui coutera encore plus chère. En fait depuis 10 ans le coup de fabrication des usines à microprocesseur suit aussi une loi exponentielle, et ca, c'est pas bon.
Du coup, oui, ca ralentit. De la,à dire que ca s'arrête, on n'y est pas encore. Probablement une ou deux décennies avant que cela n'arrive (si on continue de fabriquer autant de Smart Phone, tablette et laptop pour justifier la prochaine génération).
# excellent point !
Posté par cedric . En réponse au journal Le logiciel libre au-delà de x86. Évalué à 6.
Très bonne article, et ca vaudrait une dépêche ! Juste dans la liste des architectures sur lesquels il faut garder un oeil en temps que libriste, j-core, aka super Hitachi.
Aujourd'hui, seule le j2 est disponible. C'est un coeur super Hitachi 2 avec le support du smp. Il est disponible sous licence bsd en forme vhdl et fonctionne d'emblée sur un fpga. Il n'a aucun brevet qui s'applique dessus et à une densité d'instruction proche du x86. Il y a eu un premier batch d'asic. Bon, clairement, ca fonctionne à 60MHz et on ne fera pas une work station avec ca.mais avec la fin des brevets sur le sh4 en 2017, il y a de quoi espéré une base très intéressante.surtout que contrairement au risc-v, le code libérée est du code de production avec un véritable objectif de performance et de coup. Voilà, je te conseille de garder un oeil sur j-core.org.
[^] # Re: Open Hardware
Posté par cedric . En réponse au journal Et si on achetait de l'Open Hardware (v2) ?. Évalué à 2.
Si on parle de CPU et de graphique, on parle forcement de rendu logiciel, sinon c'est un probleme de GPU et c'est une autre discussion. Du coup, pour avoir regarde un peu leur proposition de calcul vectoriel, je vois pas vraiment de raison pour que ca ne se passe pas bien. Manque juste un petit framebuffer avec plusieurs plans hardware pour couvrir pas mal de use case.
On fait facilement du 60fps en 512P sur un MIPS a 500Mhz sans extention vectoriel. Je pense qu'un RISC V avec une frequence plus eleve et une unite de calcul vectoriel devrait sans sortir en HD. Apres le 4K, ca reste encore un challenge pour meme le haut de gamme, donc disons que ca posera probablement des soucis au RISC V aussi.