Après l'abandon de la course à la fréquence par Intel on croyait que l'avenir des CPU passerait par le multi-core. Cela reste vrai mais s'y ajoute une autre tendance bien plus étrange et discutable : l'intégration dans le microprocesseur de fonctions auparavant prises en charge en externe.
Quand il s'agit, comme pour les AMD, d'intégrer le contrôleur mémoire dans le CPU on ne peut qu'applaudir à l'initiative. Après tout c'est du hardware mis dans du hardware : on avait déjà fait ceci lors de l'intégration des coprocesseurs arithmétiques dans les CPU sous forme d'unités FPU… conceptuellement banal et technologiquement sensé et profitable.
D'ailleurs pour illustrer ceci on apprend qu'AMD veut continuer sur sa lancée et va intégrer le contrôleur PCIexpress dans ses futures puces pour diminuer encore les temps de latence (http://www.theinquirer.net/?article=24756(...) ).
Par contre ce qui est moins banal et potentiellement plus gênant pour moi c'est l'intégration dans le CPU de choses qui devraient êtres effectuées en software.
Regardez cet article : http://www.theinquirer.net/?article=24781(...) on y découvre la nouvelle lubie d'Intel : Rockton Technology
Il s'agit d'intégrer en hardware dans ses puces futures des routines spéciales pour accélérer le code Java et .Net !
En gros c'est un nouveau jeu d'instruction (comparable au SSE ou au MMX) pour prendre en charge en hard les instructions spécifiques et courantes propres à ces langages managés. Il y aura aussi une partie software pour faire la jonction avec le kernel (un compilateur Just In Time).
Vous allez me dire que c'est cool et que ça va booster les programmes Java et .Net…et je vous réponds qu'à mon avis c'est une grosse connerie !
1) Les ajouts de nouveaux jeux d'instructions sur une archi ancienne c'est laid : ça bloque souvent la concurrence (lock-in au profit d'Intel) et ça pose le problème de l'adaptation des programmes pour en tirer partie (des IFDEF partout ?)
2) Cela favorise arbitrairement certains langages aux détriment d'autres déjà existants ou futurs…et en plus Java et .Net dans une perspective libriste c'est le pire choix possible !
3) L'interface software avec le kernel pose également problème : quelle sera la licence ? Est-ce qu'une alternative libre sera possible ou bien l'API d'interface hardware restera-elle non documentée ? Un compilo JIT en interface avec le kernel est-ce que c'est propre du point de vue technique ?
4) Sur un plan philosophique le CPU ne devrait prendre en charge que des opérations de base sur les entiers et les flottants et ne pas se transformer en bloat-CPU qui dit papa-maman et fait le café !
Avec la puissance marketing et financière d'Intel il est probable que cette solution s'impose dans le monde de l'entreprise (qui ne jure que par Java et .Net) et que donc le libre devra s'adapter qu'il le veuille ou non pour rester compétitif : Si une appli Java ou .Net tourne 35 fois plus vite sur le "Windows 2007 RocktonEdition" que sur le noyau 2.6.26 d'une Debian Etch y'aura pas photo pour le DSI de la boite !
Comme la course à la fréquence n'est plus trop possible, comme le multi-core l'ensemble des fondeurs le font ou le feront, comme l'informatique quantique est encore dans les limbes…et bien le seul vrai différenciateur technique c'est LA fonction spécifique que ne propose pas le concurrent ! Donc le bloat-CPU est une tendance lourde qui semble inévitable.
Via met des modules hardware de crypto dans ses puces (AES et RSA et SHA), IBM met ou va mettre des modules hardware qui câblent les instructions SQL courantes dans ses puces POWER…et maintenant Intel avec JAVA et .NET !
Prochaine étape Outlook et Internet Explorer directement gravés dans votre CPU ?
Journal Les bloat-CPU
22
juil.
2005
# on peut la voir
Posté par Dugland Bob . Évalué à 10.
de toutes façons,
1) les machines lisp ça a été inventé dans les années 50/60
2) personne n'a gueulé contre les instruction de tagged arithmetics chez Sun sparc
3) tous les langages modernes se ressemblent d'un point de vue exécution.
4) il est temps de passer à plus moderne.
[^] # Re: on peut la voir
Posté par patrick_g (site web personnel) . Évalué à 9.
Non. Je bosse pas chez Intel et je me base juste sur l'article cité. De toute façon ça change quoi ?
>> les machines lisp ça a été inventé dans les années 50/60
Et elle sont mortes de leur belle mort.
>> personne n'a gueulé contre les instruction de tagged arithmetics chez Sun sparc
Connait pas. C'est leur jeu d'instruction VIS comparable au SSE d'Intel ?
>> tous les langages modernes se ressemblent d'un point de vue exécution.
Hein ? java compilé avec GCJ c'est pareil que managé par un JIT ? De toute façon ça reste un lock-in au profit de deux langages non libres donc c'est mal.
>> il est temps de passer à plus moderne.
Il est temps que les CPU computent et arrêtent d'essayer de nous imposer des technos que personne ne demande. Je note que tu ne réponds pas à ma dernière interrogation : Ou placer la limite ? IE en dur ça te tente ?
[^] # Re: on peut la voir
Posté par Dugland Bob . Évalué à 10.
ça n'a donc rien à voir avec les SIMD
Java compilé avec GCJ possède un mode d'exécution très proche de celui d'une JVM sun, oui. Et non, c'est probablement pas lock-in, un truc comme python ou perl pourrait probablement en tirer parti (je spécule vu que j'ai pas la liste, mais je soupçonne un peu ce qu'il vont faire), ça devrait faire plaisir aux barbus. Simplement java et .net c'est plus vendeur dans un communiqué.
quand à la frontière, elle est claire :
- Cisc : y'en a pas
- RIsc : orthogonal + une petite série d'instructions pratiques.
sauf qu'on est aujourd'hui dans le System On Chip, donc y'a pas de frontière *du tout*.
[^] # Re: on peut la voir
Posté par patrick_g (site web personnel) . Évalué à 0.
Et allez donc ! pas de frontière ! Du Java dans mon CPU...et du SQL aussi...et puis un petit décodeur HTML pour "accélerer l'internet"...et une petite dose de Palladium pour la sécurité...sans oublier un lecteur .doc/.xls pour faciliter l'ouverture des documents d'Office 2003.
Idée géniale : pourquoi pas un cablage hardware pour le compte Passport/MSN ? Voila un truc qui l'est bien !
[^] # Re: on peut la voir
Posté par Sébastien Koechlin . Évalué à 3.
Un décodeur HTML, ça ne veut pas dire grand chose, mais par contre un parser XML, surtout qu'avec les nouveaux formats de documents, ça va devenir de plus en plus utile...
Je rigole...
Un grand absent à mon avis: le traitement des chaines de caractères. Quoi qu'on fasse, dans un programme moderne, que ce soit du java, du perl, du PHP ou du C, passe beaucoup de temps a tripoter des chaines de caractères, les charsets varient, les ordinateurs et les programmes dialogues, les formats sont multiples...
[^] # Re: on peut la voir
Posté par CrEv (site web personnel) . Évalué à 4.
Par exemple, il existe une instruction qui permet de chercher une suite de caractères dans une chaine (autrement dit dans un texte). Cette fonction étant cablée en hard est extrémement rapide.
Mais personne ne l'uitilise pour des simples problèmes de compatibilité (entre proc) et donc elle ne sert à rien.
Ce qu'il faudrait à mon avis, c'est d'avoir quelque chose de cohérent (car à faire chacun dans son coin, toutes les "nouvelles" instructions ne servent qu'à du marketing ou alors il faut tout recompiler pour son proc et encore, il faudrait que les compilos exploitent le tout avant même d'y songer...)
Mais bon, il existait déjà des proc java alors...
Sinon, le problème que je vois est plus qu'il n'y a pas d'alternatives purement libres à java / .net (alternatives aussi complètes et crédibles, et me sortez pas mono...)
[^] # Re: on peut la voir
Posté par vaxvms . Évalué à 3.
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR006(...)
[^] # Re: on peut la voir
Posté par patrick_g (site web personnel) . Évalué à 2.
Par contre pour un chip Intel grand public c'est déja beaucoup plus discutable non ?
[^] # Re: on peut la voir
Posté par ookama . Évalué à 1.
il offre quelque chose amenant un gain pour l'utilisateur
De plus il est libre de ses choix que cela te plaise ou non, sinon lance toi dans la fabrication de processeur ;-)
[^] # Re: on peut la voir
Posté par TazForEver . Évalué à 2.
[^] # Re: on peut la voir
Posté par Mildred (site web personnel) . Évalué à 1.
mais pourquoi pas ?
[^] # Re: on peut la voir
Posté par gc (site web personnel) . Évalué à 2.
Je rigole...
Tu rigoles ? Mais est-ce que tu sais que ça existe déjà depuis longtemps ?
http://www.internetnews.com/dev-news/article.php/3443541(...)
http://www.internetnews.com/infra/article.php/3482416(...)
# Pas étonnant
Posté par Guillaume Knispel . Évalué à 9.
[^] # Re: Pas étonnant
Posté par Guillaume Ceccarelli . Évalué à 5.
[^] # Re: Pas étonnant
Posté par Nicolas Bernard (site web personnel) . Évalué à 10.
Par contre, si Intel veut faire des "coprocesseurs Java" et des "coprocesseur .Niet", je n'ai rien contre (mais je n'en acheterai pas!).
Sinon, pourquoi ne pas intégrer un petit fpga dans les CPU? cela permettrait à un programme qui doit faire beaucoup d'une certaine opération lente avec les instructions standards de programmer sa propre instruction...
[^] # Re: Pas étonnant
Posté par Ontologia (site web personnel) . Évalué à 1.
- Transformer un algo en VHDL en live (SystemC ,... ?)
- Le temps que prend la reconfiguration du circuit
Après on pourrait imaginer un FPGA avec un coeur power64 dans un coin pour gérer l'OS et etc... et le reste en fpga pour s'adapter aux besoins en permanence.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Presque deja fais
Posté par TheBreton . Évalué à 2.
un ppc64 et une tripoté de petit processeur vectoriel dans les coins.
Moins rapide que le fpga sur des fonctions cablé, mais plus évolutif (c'est du soft) et leur temps de programmation permet lors du task-switch de recharger leur memoire programme.
voir
http://linuxfr.org/2005/06/29/19228.html(...)
et surtout
http://www.research.ibm.com/cell/(...)
# bopf, c'est dans l'ordre des choses
Posté par kra . Évalué à 6.
tu veux dire, comme l'integration d'open GL, directX, Cg (les shaders de nvidia) dans les gpu des cartes graphiques?
c'est plutot une bonne chose je trouve, ca decharge le cpu d'operations "inutiles" et si ca permet de booster les perf comme cela l'a fait pour la 3D, j'suis a donf pour.
faut voir apres si les "pilotes" suivent, mais conceptuellement, je vois pas ou se trouve le probleme.
[^] # Re: bopf, c'est dans l'ordre des choses
Posté par Guillaume Ceccarelli . Évalué à 5.
[^] # Re: bopf, c'est dans l'ordre des choses
Posté par kra . Évalué à 4.
un cpu c'est fait a la base pour executer des applis, ou est le mal a vouloir accelerer l'execution de code java/.net?
'fin chais pas moi, c'est comme un SSE ou un MMX, quel est le probleme au juste?
si tu l'as et que tu veux l'utiliser, bah tu l'utilise, tu sera content parce que ca ira plus vite (ou pas selon si c'est du marketing ou non)
si tu l'as et que tu veux pas l'utiliser, bah t'utilise la jvm qui va bien et tu seras content parce que tu sera plus "libre" (mouarf)
si tu l'as pas, cf cas 2.
surtout que l'article mentionne la creation d'une jvm avec les gus de la fondation apache, venez pas dire que c'est une mauvaise nouvelle ca.
[^] # Re: bopf, c'est dans l'ordre des choses
Posté par patrick_g (site web personnel) . Évalué à 5.
Le mal c'est que ce sont deux langages qui posent problème au libre et que si cette solution s'impose alors tous les autres langages sont morts.
Si Java et .Net deviennent 50x plus rapides que C++ et 10.000x plus rapides que Python/Perl/Ruby et bien t'aura plus que tes yeux pour pleurer (sauf si t'est le PDG de Sun ou de Microsoft).
Pourquoi privilégier ainsi 2 langages au lieu de faire un truc générique ?
[^] # Re: bopf, c'est dans l'ordre des choses
Posté par galactikboulay . Évalué à 2.
de définir son propre jeu d'instruction, comme une reprogrammation
du microcode en somme.
Ca ne profiterait pas qu'à Java et .Net, ça permettrait également
de pouvoir émuler (au moins dans une certaine mesure) les jeux
d'instructions d'autres processeurs, style MIPS, PowerPC ou autre.
[^] # Re: bopf, c'est dans l'ordre des choses
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 4.
[^] # Re: bopf, c'est dans l'ordre des choses
Posté par kra . Évalué à 2.
dommage.
[^] # Re: bopf, c'est dans l'ordre des choses
Posté par mdlh . Évalué à 10.
Evidement, un CPU specialise pour Java et .Net, c'est non seulement la mort pour les autres langages et pour les autres processeurs si ils ne font pas de meme, car qu'on le veuille ou non, JAVA et .Net est utilise largement en entreprise et comme apparement ici on a tendance a dire que l'utilisation d'un processeur ou un OS en entreprise entraine son utilisation chez le particulier, cela va non seulement etre un coup dur pour le libre aussi bien au niveau langage, mais aussi pour le choix de la plateforme.
Le raisonnement est correct, a condition qu'il soit sur des bases saines. Rien ne dit qu'Intel n'ai pas annonce l'ajout d'un certain nombres d'instructions qui seront benefiques a un certain type de calcul, dont Java et .Net sont notement friand. D'ailleur, rien ne dit que ceci est exclusif a Java et .Net. A ma lecture de l'article, Java et .Net sont utilises pour illustrer l'interet de la nouvelle instruction. Dans ce sens d'ailleurs, meme l'auteur le signale: Java et .Net sont tellement different qu'il lui paraissait vraiment etrange qu'une technologie puisse supporter les 2. En fait, il y a une sacree delegation au niveau logiciel pour obtenir une certaine flexibilite. Peut etre que cette flexibilite permettra de benificier de cette technologie pour d'autres languages. Meme si il est vrai qu'il y a plus de chance que Java ou .Net soit supporte largement avant.
Bref, sans avoir plus d'information necessaire, il est difficile de conclure sur le gain de cette instruction. On pourrait tout aussi bien conclure que le gain reelle sur l'execution d'une appli qui utilise cette instruction ressemble plus a un coup de pouce equivalent a l'introduction des instructions MMX. Ca aide, mais si tu veux des reels perfs pour ton jeux, tu te retourneras vers une bonne carte 3D. Si c'est le cas (et je n'en sais rien), parler d'appli 50 fois plus rapide que le C++ cela me paraitrait un peu exessif.
[^] # Re: bopf, c'est dans l'ordre des choses
Posté par Vivi (site web personnel) . Évalué à 6.
oui d'ailleurs quand on google "Rockton Technology", le premier lien c'est ça:
http://www.sterlingplumbing.com/onlinecatalog/detail.jsp?item=43073(...)
moi je dis c'est louche.
[^] # Re: bopf, c'est dans l'ordre des choses
Posté par imalip . Évalué à 4.
[^] # Re: bopf, c'est dans l'ordre des choses
Posté par Ontologia (site web personnel) . Évalué à 2.
On pourrait tout aussi bien conclure que le gain reelle sur l'execution d'une appli qui utilise cette instruction ressemble plus a un coup de pouce equivalent a l'introduction des instructions MMX.
Vu la granulité des instructions en asm, je pense franchement pas que des instructions accélérant java ou .net ne puisse pas servir à autre chose.
Quand on me parlait de meumeux, je pensais au début que c'étaient des instructions qui t'inversait des matrices 4x4 en 3 cycles. En fait, la plus "balaise" fait quatre addition en même temps ou une formule du type
a*b+c
Donc je vois franchement pas de quoi s'inquiéter...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: bopf, c'est dans l'ordre des choses
Posté par Gniarf . Évalué à 6.
scoops :
*Intel/Microsoft domine la micro-informatique depuis 20 ans et plus.
*Intel est d'accord pour tout ce que tu veux tant que ça tourne sur un CPU Intel, et de préférence avec des chipsets Intel aussi
*Microsoft est d'accord pour tout ce que tu veux tant que ça tourne sous Windows (qui tourne surtout sous Intel pour des raisons d'économies de développement, mais bref) et ne vient pas concurrencer les vaches à lait maison (Office, SQL Server...)
*Intel se garde un petit concurrent sur son propre domaine du x86 pour faire taire toute accusation de monopole sur le x86
*Intel s'amuse à pousser et reculer quelques pions comme Linux ou Java pour taquiner Microsoft et lui rappeller qu'ils ne sont pas non plus complètement soumis même si le mariage est quasi parfait
*Microsoft fait de même avec AMD, dans l'autre sens
et d'une manière générale dans le commerce :
*malheur aux vaincus
*malheur aux clients des vaincus
visiblement, c'est plutot Intel qui pose problème au libre, non ? (ou plutot qui te pose problème)
seule conclusion logique pour toi : aller voir ailleurs. et pourtant s'il n'y a d'alternative, comme pour des cartes graphiques 3D avec des drivers libres et performants, il va bien falloir faire des choix
[^] # Re: bopf, c'est dans l'ordre des choses
Posté par TheBreton . Évalué à 3.
Ou est le probleme ? il ne faux pas faire de mix (je ne te pas que tu le fais mais l'article de base le fait un peut) entre ABI et API, en l'occurence c'est l'ABI qui serait porté dans le proc pour qu'il embarque un pseudo processeur java (qui est basé sur un langage de processeur a accumulateur), bien sur le code java traitement de base sera executé de plus vite, mais toute interraction user restera dans la JVM.
N'oublions pas que les ARM et les x86 ont eté equipé d'un opcode destiné a faire tourné du C plus rapidement (heureusement d'ailleur tout les OS sont ecris en C / asm)..c'est la voie des CISC d'integrées de nouveau opcode,nouveau jeux d'instruction pour supporté de nouveau langage!
la voie des RISC aujourd'hui est plutot sombre, leur frequences ne progresse que peut...
[^] # Re: bopf, c'est dans l'ordre des choses
Posté par Glorbouille . Évalué à 2.
Mais il ne faut pas faire l'amalgame avec les les pross optimisé pour le c.
En fait on se retrouve dans la situation des années 70.
Les fréquences ne montant que très peu (1 à 4 MHz....) , la solution (marqueting?) pour différentier les pross était d'ajouter des instructions. On a donc due subir des machins comme le 6809 (sans suite) avant de pouvoir profitter des vrais améliorations.
Ajouté des instructions, ce n'est pas trop compliqué, cela peut parfois être seulement du µ-code.
En fait, j'aimerai des pross totalement micro-programmable, comme les transmettas. (et pourquoi pas aussi, c'est vrai, des unités opérationnelle à base de fpga).
[^] # Re: bopf, c'est dans l'ordre des choses
Posté par Zenitram (site web personnel) . Évalué à 4.
Tu ne melangerai pas tout???
- Les Models Shaders 3.0 sont des elements pmateriel de conception de puces graphiques
- OpenGL, DirectX, Cg sans des API pour acceder aux Shaders.
Il n'y a rien de choquant a mettre un modele dans un GPU/CPU (et meme logique), genre MMX/SSE etc... Tu es libre d'utiliser le language que tu veux pour DirectX ou OpenGL...
Par contre mettre un API dans un language precis (.net, Java), ca me choquerai! (liberté de choisir son language)
[^] # Re: bopf, c'est dans l'ordre des choses
Posté par kra . Évalué à 7.
ca revient au meme..
on integre des fonctionnalites haut niveau auparavant effectuees de facon logicielle dans du hard pour accelerer le tout, et on construit une api d'encore plus haut niveau en soft qui finira elle aussi par etre integree au hard etc.
C'est pas parce que ya marque java/.net/troll inside dans l'article que sapusailedaimon.
Yaurait marque python/perl/ruby/libre inside, on aurait eu une acclamation generalisee, intel aurait merite le qualificatif de bienfaiteur de l'humanite etc. alors que c'est exactement la meme chose.
pour les trolls relatifs a la liberte de java/.net, je vous renvois a la lecture de cet excellent article paru dans linuxmag qui expose (sans troller!! jolie performance.) les points legaux concernant java/.net.
Pour resumer en 3 lignes un articles de plusieurs pages :
- il est parfaitement legal et possible de distribuer une jvm/implementation de java 1.4 et 1.5 libre, le seul probleme etant dans la licence pas tres amicale avec les developpement ouverts (tout du moins tant que le produit n'est pas 100% conforme, apres on fait ce qu'on veut)
- pour .net, bah c'est franchement le bordel, entre les annonces de microsoft, les brevets pas valides etc. c'est un gros flou general et il faut attendre que la situation s'eclaircisse.
(et non, je ne melange pas tout, je sens tres bien faire la difference que tu explicites)
# Sur un plan philosophique
Posté par dinomasque . Évalué à 7.
Sur un plan philosophique, certaines personnes ne concoivent pas qu'on puisse mettre des choses aussi inutiles que les opérations sur les flottants dans un CPU alors que des routines logicielles le font très bien ...
Sur un plan philosophique, on peut très bien dire que les puces spécialisées dans la 3D, le son, ... ne servent non plus à rien.
Aujourd'hui le nombre de transostors n'est plus aussi limitant qu'il y a dix ans. Ajouter des transistors pour accélérer/améliorer les applications utilisées sur les ordinateurs ça ne peut être qu'une bonne idée.
BeOS le faisait il y a 20 ans !
[^] # Re: Sur un plan philosophique
Posté par patrick_g (site web personnel) . Évalué à 3.
alors, au nom du ciel, ajoutons des transistors pour accélerer des trucs génériques et pas des trucs proprios et bardés de brevets comme Java et .Net !
Je suis pas opposé par exemple a des instructions sur les vecteurs comme SSE ou Altivec mais c'est parce que c'est juste des registres en plus pour des vecteurs = c'est générique...alors que .Net c'est de bien plus haut niveau. Comme je l'ai déja dit si on s'engage la-dedans pourquoi ne pas remonter carrement jusqu'au niveau applicatif et avoir un mailer et un browser dans le CPU ?
Bloat, Bloat, Bloat !
[^] # Re: Sur un plan philosophique
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
"La première sécurité est la liberté"
[^] # Re: Sur un plan philosophique
Posté par patrick_g (site web personnel) . Évalué à 2.
tu implémente tout le protocole SMTP en hardware et tu obtiens un processeur qui est très rapide quand il est dans une machine qui sert comme serveur de mail
[^] # Re: Sur un plan philosophique
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Sur un plan philosophique
Posté par patrick_g (site web personnel) . Évalué à 1.
[^] # Re: Sur un plan philosophique
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
"La première sécurité est la liberté"
[^] # *** PUBLICATION IMMEDIATE : INTEL EN FAILLITE ***
Posté par Moule Atarte (site web personnel) . Évalué à 10.
Personne n'a été surpris de l'énorme succés du Bloatium, le processeur lancé au printemps 2006 par Intel pour remplacer ses Pentium 4 vieillissants.
Avec un niveau de performance largement au-delà de ses principaux concurrents, le Bloatium a permis à Intel de s'arroger une part encore plus importante du marché mondial des processeurs.
Malheureusement pour le fondeur américain, ces niveaux de performance ont été atteint en incluant dans le processeur, le coeur de nos PC, des fonctions qui étaient auparavant réalisées par des logiciels, telles que la connexion à internet (TCP/IP), l'envoi et la réception de Mails (SMTP) ou la lecture des documents Word. L'adoption par une majorité d'entreprise de machines basées sur ce nouveau processeur n'a rendu la chute que plus dure pour le géant des semi-conducteurs.
En effet la découvertes de multiples failles dans les différends protocoles mis en places en usine dans les processeurs et ne pouvant être mis à jour, contrairement à logiciel courant comme Windows, a entraîné une vague de piratages et de cyber-terrorisme sans précédent ciblant les (mal)heureux possesseurs de Bloatium. Evidemment chacune des entreprises victime s'est retourné contre son fournisseur de matériel; qui s'est à son tour adressé à Intel qui viens d'être reconnu coupable de négligence grave par la cour suprême des États-Unis d'Amérique.
L'action Intel est suspendue de cotation depuis 3 semaines.
L'action AMD à la bourse de New-York a été suspendue après une hausse de 42 000%.
[^] # Re: *** PUBLICATION IMMEDIATE : INTEL EN FAILLITE ***
Posté par Kouenny . Évalué à 3.
[^] # Re: *** PUBLICATION IMMEDIATE : INTEL EN FAILLITE ***
Posté par Moule Atarte (site web personnel) . Évalué à 5.
[^] # Re: *** PUBLICATION IMMEDIATE : INTEL EN FAILLITE ***
Posté par patrick_g (site web personnel) . Évalué à 2.
Au dela du coté bien marrant de ton premier post c'est vrai que le problème d'un protocole cassé alors qu'il est en dur dans la puce est vraiment inquiétant.
C'est VIA qui fait des chips avec MD5 dedans non ?
[^] # Re: *** PUBLICATION IMMEDIATE : INTEL EN FAILLITE ***
Posté par Brice Carpentier . Évalué à 5.
[^] # Re: *** PUBLICATION IMMEDIATE : INTEL EN FAILLITE ***
Posté par mdlh . Évalué à 2.
[^] # Re: *** PUBLICATION IMMEDIATE : INTEL EN FAILLITE ***
Posté par Nicolas Bernard (site web personnel) . Évalué à 4.
1) les générateurs aléatoires en matériels produisent des nombres qui sont normalement (sauf percée en mécanique quantique ou CPU dans un bain d'hydrogène liquide pour réduire le mouvement des atomes) réellement aléatoires, bien plus que ceux produits par les générateurs logiciels.
2) une faille étant toujours possible, rien ne t'empêche d'utiliser un PRNG logiciel. Ce ne serait pas le cas d'une implémentation matérielle de TCP/IP ou tu n'aurais disons accès à ta prise ethernet que par l'interface socket...
[^] # Re: *** PUBLICATION IMMEDIATE : INTEL EN FAILLITE ***
Posté par JoeBar . Évalué à 3.
Vrai, sauf que... de générateur matériel de nombre aléatoire dans un CPU, il n'y a point !! Sinon tu penses bien qu'on les utiliserait plutot que d'avoir des mauvais générateurs logiciels.
Une fois j'ai vu une photo d'un proto de générateur de nombre aléatoire, ben c'était une grosse carte (compte une grosse carte PCI epaisse de plusieurs centimètres). Je ne sais pas comment ca a évolué mais s'ils avaient réussi à en mettre dans les CPU ca aurait fait du bruit je pense.
[^] # Re: *** PUBLICATION IMMEDIATE : INTEL EN FAILLITE ***
Posté par Nicolas Bernard (site web personnel) . Évalué à 5.
D'autres méthodes mesurent par exemple le bruit thermique dans une résistance, et ca, ca prend beaucoup moins de place et on trouve des cartes qui embarquent ce genre de choses depuis un certain temps: cf. par exemple <http://www.soekris.com/vpn1401.htm(...) >.
Via mesure justement le bruit dans ses processeurs pour générer des nombre aléatoires, sur le processeur à coeur Nehemiah. Cf. <http://www.via.com.tw/en/initiatives/padlock/hardware.jsp#rng(...) >.
[^] # Re: *** PUBLICATION IMMEDIATE : INTEL EN FAILLITE ***
Posté par JoeBar . Évalué à 2.
[^] # Re: *** PUBLICATION IMMEDIATE : INTEL EN FAILLITE ***
Posté par Nicolas Bernard (site web personnel) . Évalué à 1.
[^] # Re: Sur un plan philosophique
Posté par dab . Évalué à 0.
[^] # Re: Sur un plan philosophique
Posté par Nelis (site web personnel) . Évalué à 4.
Bref, d'après ce que je lis, rien n'empêchera Python ou d'autres languages d'utiliser ces instructions ...
# Ca existe déjà non?
Posté par EzDaYo . Évalué à 3.
# truc en plus.
Posté par Nicolas Boulay (site web personnel) . Évalué à 10.
Par contre des fonctions accélératrices bouffeuses de perf et standard, j'y suis à 200 % pour !
Le cryptage AES, un hash sh1 ou md5, la compression LZW, un générateur random rapide, voir une pile IP, cela accèlère des opérations faites très courament et qui bouffe de la puissance pour pas grand chose.
"La première sécurité est la liberté"
[^] # Re: truc en plus.
Posté par patrick_g (site web personnel) . Évalué à 3.
On est parfaitement d'accord. OK pour des fonctions acceleratrices pour des trucs bas niveau, génériques, standardisés et patent-free.
Par contre .Net c'est niet !
[^] # Re: truc en plus.
Posté par totof2000 . Évalué à 0.
[^] # Re: truc en plus.
Posté par patrick_g (site web personnel) . Évalué à 5.
T'a essayé d'acheter un téléphone portable qui fasse que téléphone et pas appareil photo ?
Ben moi oui et je me suis vu répondre par mon opérateur que ça n'existe plus. J'aimerais bien que ce soit le client qui impose ses vues mais ce n'est pas le cas : si Rockton s'impose t'aura plus aucun CPU sans ce truc (à moins d'être un extraterrestre en PPC ou en SPARC).
Bien entendu on pourra toujours utiliser son processeur sans utiliser Rockton mais alors pourquoi je dépenserais des euros à l'achat et des watts à l'utilisation pour ce truc ?
[^] # Re: truc en plus.
Posté par M . Évalué à 1.
Si tu veux on echange (surtout que mes batteries ne tienne plus...).
Moi je serait bien content et puis si je veux pas de APN, je m'en sert pas...
[^] # Re: truc en plus.
Posté par imalip . Évalué à 6.
[^] # Re: truc en plus.
Posté par gc (site web personnel) . Évalué à 2.
[^] # Re: truc en plus.
Posté par imalip . Évalué à 2.
[^] # Re: truc en plus.
Posté par gc (site web personnel) . Évalué à 2.
[^] # Re: truc en plus.
Posté par imalip . Évalué à 4.
Le deuxieme est une joint-venture entre les 2 compagnie, qui vend des telephones bases sur les plateformes d'Ericsson.
La plateforme Ericsson, elle, est generique (ma carte de dev a 2 ports SD card et un Memory stick) et est vendue a un certain nombre de (gros) clients :
-LG
-NEC
-SHARP
-AMOI (chinois)
-INVENTEC (chinois aussi)
-SAGEM
et surement un certain nombre d'autres.
[^] # Re: truc en plus.
Posté par ookama . Évalué à -2.
Pour le prix, vu la baisse réguliere en peu de temps tu ne verras pas la différence
alors faut pas chercher des excuses...
[^] # Re: truc en plus.
Posté par Nicolas Bernard (site web personnel) . Évalué à 5.
Et qu'on ne me dise pas que le processeur est pas assez puissant pour faire un truc réactif quand il y a une JVM embarquée!
[^] # (HS)
Posté par Zenitram (site web personnel) . Évalué à 3.
Ben moi oui et je me suis vu répondre par mon opérateur que ça n'existe plus.
Bizarre, je viens juste d'en acheter un sans apareil photo (mais avec MMS quand meme) :
http://www.nokia.fr/index.php?content_id=6178&increment=0(...)
[^] # Re: truc en plus.
Posté par dab . Évalué à 4.
Heureusement qu'il y a des extraterrestres tels que ceux-ci, les monopoles c'est bof.
[^] # Re: truc en plus.
Posté par kra . Évalué à 5.
on parle d'instructions au niveau du cpu la, qu'est ce qui empeche les autres langages a machine virtuelle d'utiliser les memes instructions?
si ils ont pondu un truc qui accelere java ET .net ya forcement une genericite quelque part, vu que les bytecodes des deux sont assez differents.
s'il y a quelque chose que j'ai rate ou omis, explique le moi stp.
[^] # Re: truc en plus.
Posté par patrick_g (site web personnel) . Évalué à 2.
J'ai 2 craintes :
1) que le bidule soit pas assez générique et donc que Java et .Net aient un gros avantage de performances au détriment des autres langages...Je sais pas si cette crainte est justifiée mais il vaut mieux s'inquieter maintenant que trop tard.
2) que même si le bidule est assez générique il y ait d'autres problèmes de nature juridique (licence de l'interface logicielle, documentation de l'API non dispo...etc).
[^] # Re: truc en plus.
Posté par kra . Évalué à 4.
2) serieusement, tu vois intel ajouter des instructions a ses processeurs et ne pas les documenter/ne pas autoriser tout le monde a les utiliser (chui meme pas sur qu'ils puissent le faire ca d'ailleurs)? j'veux bien qu'il y ait des cons chez eux, mais la c'est un elevage de poulain en batterie s'ils font ca..
[^] # Re: truc en plus.
Posté par B16F4RV4RD1N . Évalué à 2.
En tout cas un proc pour accélérer python cela serait sympa :)
Au niveau de java, sachant que c'est un système qui permet d'avoir la plate forme de son choix pour diverses applications, je préfère cela à visual basic ou .net, donc je serais tenté de dire "pourquoi pas?"
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
# Vendredi
Posté par nigaiden . Évalué à 10.
[^] # Re: Vendredi
Posté par Sylvain (site web personnel) . Évalué à 2.
# CPU java
Posté par divad . Évalué à -3.
Et oui, il y a aussi quelques, l'OS etait même stockés dans un BIOS, il y avait des ordinateurs sans disques durs.
Bref, c'est l'evolution............on doit l'accpeter (sans forcement la supporter hein)
# .Net pas libre ?
Posté par _Franz_Telekom . Évalué à 2.
Depuis quand .Net est-il moins libre que le C ou que l'OCaml ?
Une grosse partie de .Net est ECMA, ou en passe de l'être, et contrairement à Java les restrictions sur les possibilités d'implementation ne sont pas !
D'ailleurs, si Stallman parle du Java-trap, je n'ai pas vu la même chose à propos de .Net... D'où probablement l'existence de DotGnu, non ?
[^] # Re: .Net pas libre ?
Posté par Nicolas Boulay (site web personnel) . Évalué à -2.
"La première sécurité est la liberté"
[^] # Re: .Net pas libre ?
Posté par tripa . Évalué à 5.
[^] # Re: .Net pas libre ?
Posté par patrick_g (site web personnel) . Évalué à 4.
[^] # Re: .Net pas libre ?
Posté par _Franz_Telekom . Évalué à 0.
On parle de Samba, du Sender-ID, de tout un tas de trucs, mais le seul élément concret, c'est l'ECMA.
Et je ne parle pas des erreurs et approximations...
En utilisant cette façon de penser, je pourrais écrire :
"Le C et Unix sont gênants pour les logiciels libres"
Pourtant, je ne sais pas pourquoi, ça sonne mal.
[^] # Re: .Net pas libre ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
"La première sécurité est la liberté"
[^] # Re: .Net pas libre ?
Posté par bobefrei . Évalué à 3.
# Ça devait arriver...
Posté par Ontologia (site web personnel) . Évalué à 6.
Le problème, c'est qu'une unité d'exécution RISC, disons - pour couper la poire en deux, à jeu d'instruction de taille flottante (oui je sais, c'est plus vraiment du RISC), ça ne prend pas 200 millions de transistors.
Au lieu de ça, on implémente des nouvelles instructions (bonne idée), et on tente des incantations vaudoo sur le code (genre exécution dans le désordres et autres bidouilles) comme si le compilateur n'était pas foutu de le faire lui même (du moment qu'on y travail).
Quand on a 200 millions de transistors, on à quoi comme solution, quand on en a déjà trop pour aligner de plus en plus de pipelines ?
- On fait du multi-coeur (Cell)
- On rajoute des instructions spécifiques et complexes (Intel/AMD).
Le problème des multi coeurs est que ça implique un gros goulot d'étranglement au niveau mémoire (ben oui puisque vous avez un débit mémoire qui ne double pas quand le nombre de coeur double, quadruple)
et des problèmes de parraléllisme
http://www.onversity.net/cgi-bin/progarti/art_aff.cgi?Eudo=bgteob&a(...)
Faudra repenser le développement et tout développer en multi-threading. Je souhaite longue vie aux langages intrinsèquement parallèles.
Ou alors, on se retrouvera avec des bloat CPU.
Je ne partage pas la peur de patrick quand aux conséquences pour le libre, car je vois mal d'une part intel/amd ne pas documenter ses instructions, et d'autre part, leur granulité sera trop fine pour qu'elles soient réservables à .net ou java. Je veux dire par là qu'un compilo bien foutu saura les utiliser à bon escient.
M'enfin quand on voit que gcc est pas foutu d'utiliser mmx, sse, etc... On peut avoir peur.
Après mes propos ne sont que d'humbles intuitions...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Ça devait arriver...
Posté par patrick_g (site web personnel) . Évalué à 4.
Il me semble que ça va changer très bientot non ? Avec la nouvelle architecture tree-ssa de GCC4 ils vont pouvoir faire de l'autovectorisation bien plus facilement...c'est d'ailleurs prévu dès la version GCC4.1.
Bien sur la vraie solution pour utiliser à plein les unités multimédias des CPU c'est de se taper à la mimine des routines en assembleur (surtout pour les codecs et autres trucs de ce genre).
Pour ce qui est de mes inquiétudes je pense surtout à l'interface logicielle qui est évoquée dans l'article. Je pense comme toi qu'Intel/AMD vont documenter leurs nouvelles instructions...mais quid de l'interface logicielle dans le kernel ? elle sera sous GPL ou seulement un gros binaire bien laid ?
[^] # Re: Ça devait arriver...
Posté par Troy McClure (site web personnel) . Évalué à 1.
le plus simple c'est d'utiliser les fonctions _mm_add_ps et cie , comme ça pas d'assembleur, pas de prise de tête sur l'allocation des registres et à l'arrivée t'as un truc "portable" même sous visualc
[^] # Re: Ça devait arriver...
Posté par patrick_g (site web personnel) . Évalué à 2.
c'est pas un truc spécifique MMX/SSE ça ?
ça marchera pas avec Altivec et compagnie....
[^] # Re: Ça devait arriver...
Posté par Troy McClure (site web personnel) . Évalué à 1.
[^] # Re: Ça devait arriver...
Posté par Ontologia (site web personnel) . Évalué à 2.
Je comprend pas très bien ton histoire d'interface logiciel dans le kernel.
Une instruction, c'est un opcode, tu lui donne des registres ou des adresses mémoire à manger et c'est tout.
Du moment qu'elle est documenté, je vois pas où est le problème.
Et puis accélérer du java ou du .net qui ne sont que des langages semi compilés sur des machines virtuelles, je vois pas quel genre d'instructions spécifiques à ces deux langages on pourrait faire ?
En conclusion, je vois pas où est le danger pour le libre...
Mais ya ptetre un truc que j'ai pas compris ?
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Ça devait arriver...
Posté par woopla . Évalué à 3.
Un contre-exemple de ca est l'IA64. C'est un processeur qui repose massivement sur le compilo pour avoir de bonnes performances. Et le problème c'est que pour l'instant, des compilos vraiment performants pour IA64, ben y'a pas. Même Intel a du mal, et je pense qu'ils ont plutôt intérêt à ce que ca marche.
Comme d'hab', hein, c'est une histoire de compromis. Si ca améliore les perfs et que ca coûte pas plus cher que de le faire en soft, ben autant en profiter. Exemple : les TCP/IP Offload Engine. Un truc bien pratique quand on a un serveur qui a besoin de débit, ca permet de décharger le processeur pour qu'il fasse autre chose. Dans le processeur de monsieur tout-le-monde, pas important. C'est pour ca que, si je me trompe pas, les TOE sont encore rares dans les chipsets réseau grand public.
Si les extensions Intel pour VM sont asssez génériques (on en sait rien pour l'instant), ca pourra profiter à tout le monde. Donc, oui pour ca dans les processeurs grand public.
[^] # Re: Ça devait arriver...
Posté par imalip . Évalué à 4.
Si si, y'en a un. C'est le compilo d'HP, malheureusement uniquement disponible sous HP-UX...
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.