S'identifier / Créer un compte
  • Actualités
  • Dossiers
  • Tests
  • Commentaires
  • INpactiens
Publicité
Avatar de Neo_13 INpactien
Neo_13 Inscrit le mercredi 20 novembre 02 - 17 commentaires -
Les derniers commentaires de Neo_13 :

Architecture qui nécessitait de procéder à des réécritures significatives de dizaines voire centaines de compilateurs pour y porter l'OS et tous ses outils, puis de recompiler des dizaines de milliers de binaires.

C'est cette inertie qui a, pour une bonne partie, disparue. Évidemment ce n'est pas fini, on ne change pas une industrie toute entière du jour au lendemain mais la situation n'est plus du tout la même aujourd'hui et cette tendance à l'agnosticisme ne va faire que s'accentuer.

Non, elle fonctionnait nativement en x86.
Et moyennant une compilation sur des outils distribués par Intel à prix d'or, elle fonctionnait en natif pas trop mal.

Et les DSP, c'est le futur, ça vient de sortir (selon ce qu'on retient comme techno, entre 1975 et 1980, hier soir quoi) et demain ça dominera le marché tellement c'est balaise. Finis les CPU, on fera tout par GPU tellement c'est plus mieux et ça se programme tout seul. On passe de 4 cores à 1000 cores avec la même surface, la même conso et les perfs sont multipliées par 250. C'est dire à quel point tous les fondeurs du monde sont des lowz0r et ils gâchent du silicium et des perfs.


Oui. Sauf que jusqu'à présent aucun n'a offert deux jeux d'instructions : un x86 et un autre.
Si, l'EPIC. On voit où en est cette architecture.
Et tous restent optimisés pour le jeu x86.
Et tous ont des décodeurs optimisés pour comprendre certaines sous partie du x86, voire la totalité pour certains.

Surtout le passé est une chose mais aujourd'hui tous les programmes écrits en java, javascript et dotnet peuvent supporter n'importe quel CPU, il suffit que l'OS le supporte pour que tous ces programmes deviennent immédiatement compatibles. Par ailleurs on a désormais un compilateur, LLVM, faisant office de standard de facto et facilement extensible à une nouvelle architecture. Enfin les plus gros clients des fondeurs ne sont (ne seront) plus des intégrateurs mais des consommateurs directs (Google, FB, MS, Amazon) ayant un très fort intérêt et la capacité à optimiser les performances au maximum, et en collaborant ensemble.

Dans ces conditions il n'est plus impensable d'imaginer que bientôt un pilote ou le bios fournira un back-end LLVM et une petite API, et que l'OS et les programmes n'auront qu'à balancer ce jeu d'instructions de niveau intermédiaire au bios, si bien que le CPU n'aurait même plus à exposer de jeu d'instructions (le bytecode LLVM étant compilé par le bios et non pas exécuté directement).

Je ne serais pas surpris que d'ici quelques années Google ou Facebook spécifie une telle architecture de façon à pouvoir passer d'une architecture matérielle à l'autre avec des coûts de migration nuls et ainsi choisir les architectures les mieux adaptées à chaque tâche. Du coup n'importe quel fondeur pourrait débarquer avec une meilleure archi et décrocher d'emblée un contrat de dizaines de millions de serveurs, suivi rapidement par d'autres du même acabit.
Ouais, je me souviens, ce genre de délire était aussi annoncé pour demain avec, non pas des LLVM hardware, mais des JVM hardware. Avec le succès que l'on sait (et pourtant dans certains domaines ils continuent d'être utilisés). Quant au LLVM compilé par le BIOS, le LLVM est surtout compilé par le CPU. Et il faut donc que le JIT LLVM soit compilé dans un assembleur natif pour qu'il puisse faire la suite. Et c'est vrai que les compilateurs ARM/whatever sont BEAUCOUP mieux optimisé que ceux sur x86. Ou alors on assemble à la main, ce qui est courant aussi.

[quote]
Ni l'un ni l'autre, ce sont les lois de la physique et des mathématiques qui sont à blâmer. Les développeurs et microélectroniciens ne font que peiner au mieux pour circonvenir ces limites jour après jour avec leur intelligence cinq fois inférieure à celle requise pour gérer ces problèmes.
[/Quote]M'kay

Parce qu'il est bien connu que les problèmes ronds sont efficacement solubles par des carrés. Si le carré est sous-utilisé, c'est forcément la faute de quelqu'un.

Sauf que le GPU, c'est un super carré. Et que les problèmes restent ronds, ces cons. Et qu'accessoirement, avec un travail manuel soigneux, certains font passer les ronds qui ne le sont pas tant que ça dans les carrés... On appelle ça optimiser. GPU ou SSE, même combat, même si c'est pas forcément le même détail, ca reste du calcul vectoriel.

Edité par Neo_13 le mardi 13 mai 2014 à 11:28

Au contraire, la concurrence n'a jamais été aussi vive pour Intel, sauf que c'est sur le serveur (Google & co sont en train de s'éloigner du x86 et d'Intel), les mobiles et tablettes (domination d'ARM tandis que le x86 est le challenger) et les objets (raspberry pi). Le x86 est sur son déclin et d'ici dix ans on n'achètera sans doute qu'un compatible x86 (via un transcodeur, le temps que tout le monde migre) dont les performances optimales seront obtenues en lui balançant un autre jeu d'instructions.
Ouais, comme le 68000, le Power, le PowerPC, l'Alpha, le ARM, l'EPIC, ... Ils ont tous tué le x86. Quant à l'histoire du transcodeur, si ça arrive, il suffirait à Intel et AMD de ne plus exécuter du code x86. Tous les CPU x86 depuis près de 20 ans sont tels que tu décris "le compatible x86" en fait. Par contre personne n'a migré, et pas seulement parce que le micro code n'est pas accessible : sur EPIC, il l'était, ça n'a pas migré quand même.


C'est une blague ? Regarde ce que fait AMD en ce moment avec l'intégration du GPU dans le processeur et tout ce qui l'accompagne pour améliorer la synergie entre les deux parties. Ce mouvement est une innovation comparable à l'introduction du x87 (unités de calcul flottant) ou du MMX (premières instructions vectorielles), c'est une transformation radicale de la pratique du calcul informatique et ça se produit maintenant, sous tes yeux.

Non, ce que tu veux toi c'est une amélioration des performances par coeur. Mais on a atteint un plafond technologique il y a dix ans et il n'y a toujours pas de nouvelle techno mûre pour ça. Et ce n'est pas la faute d'Intel qui investit beaucoup dans la recherche sur ce problème.
Donc ce ne sont pas les fondeurs qu'il faut regarder pour la stagnation, mais les dev ? Ca aussi, c'est pas hyper nouveau. Et Intel en a fait les frais sur le P4 (même si ce n'est pas ça qui l'a mis à mort, le P4), du coup, je crois qu'ils essayent de faire des innovations qui s'intègrent le plus possible dans leur pseudo JIT hardware, plutôt que de faire de la perfo inutilisable genre Cell. Quand on voit la quantité de SSE vectoriel exécuté par nos CPU par rapport au x87 ou au SSE scalaire... on peut se dire que la révolution arrivera un peu plus tard.
If you are wearing the UP24 but not able to be near your device, the activity will record and be held on the band until you open the app to connect. Up to 9 months of information can be held on the band, so as long as you are near the open app at some point, your information should be safe!
J'ai ma réponse.

Si c'est comme le UP, le bracelet à 10 jours de mémoire.

C'est ce que j'essaye de savoir, si c'est comme le UP, mais je ne trouve pas l'information.
Notez au passage que le Jawbone UP a baissé de prix il y a peu, passant chez plusieurs boutiques à moins de 90 euros, ce qui pourrait être intéressant pour ceux qui n'ont que faire du temps réel et la connectivité en Bluetooth 4.0 LE.
Et si je suis temporairement loin de mon téléphone, ou que je l'éteins la nuit, le bracelet enregistre pour synchronisation ultérieure (comme le up pas 24, mais en BT) ou on perds les infos ?

L'OS devra prendre cela en compte pour y acceder, mais je ne vois absolument aucun soucis, c'est comme quand on est passé de l'IDE au SATA
Oui, passer de ATA à ATA (parce que ça reste de l'ATA, seul le transport entre le controleur et le disque, la logique ne change pas tellement) c'est exactement pareil que passer d'un contrôleur connecté sur une ligne PCI-e à un canal de RAM.
ou même du SATA au PCIe dernièrement.

On supprime un contrôleur quoi. PCI-e pour PCI-e

C'est juste le canal de communication avec le matériel qui change. De manière interne l'OS voit toujours un espace de stockage qu'il peut utiliser. En gros il se moque de ce qui se trouve au bout du connecteur, du moment qu'il obéit et enregistre ou renvoit les données voulues, ca peut être un HDD, un SSD ou un lecteur de carte perforé, c'est kif kif.
L'utilisateur voit un espace de stockage, éventuellement, l'OS lui, voit de la RAM et l'adresse comme de la RAM.

C'est exactement pareil que ce qu'on connait déjà, oui...

ça se reset avec deux électro-aimants ! /poésie&finesse

Oui, mais une grosse alime en plus derrière, donc réservé aux gros serveurs et aux PC Gamers.


Bah comme pour une disque dur actuel...

Je vois ps trop le soucis, a part que ce sera vachement plus rapide pour formater ^^"

Tu connais la différence d'utilisation entre le disque dur et la RAM ? SI on peut effacer/formater un disque, c'est précisément en ayant un OS propre et fonctionnel en RAM. La le truc que tu veux formater, c'est l'OS en RAM. Problème.


il y aura forcement une broche pour reseter la mémoire


Flash, c'est flash, ça ne se reset pas "avec une broche"