Vous n'avez pas encore de notification

Page d'accueil

Options d'affichage

Abonné

Actualités

Abonné

Des thèmes sont disponibles :

Thème de baseThème de baseThème sombreThème sombreThème yinyang clairThème yinyang clairThème yinyang sombreThème yinyang sombreThème orange mécanique clairThème orange mécanique clairThème orange mécanique sombreThème orange mécanique sombreThème rose clairThème rose clairThème rose sombreThème rose sombre

Vous n'êtes pas encore INpactien ?

Inscrivez-vous !

Intel en dit enfin un peu plus sur son fameux Larrabee

LarrabeeL'un des projets les plus ambitieux d'Intel ces derniers temps est sans aucun doute celui qui se cache derrière le nom de code Larrabee.

Dévoilé il y a de cela de nombreux mois, celui-ci constitue, selon Intel, le juste milieu entre l'évolution des CPU, qui vont vers plus de cœurs, et les GPU qui se veulent de plus en plus programmables, et capables de gérer des tâches autres que la 3D. Une vision que NVIDIA tente d'ailleurs d'imposer via CUDA.

Larrabee, la bête à tout faire d'Intel montre enfin le bout de son nez

Longtemps resté mystérieux, ce projet devrait être dévoilé dans les grandes lignes durant le SIGGRAPH qui se tiendra la semaine prochaine à Los Angeles, puis à l'IDF de San Francisco la semaine suivante.

Mais Intel, afin de préparer le terrain au niveau de la communication, a décidé d'en dire un peu plus à la presse en fin de semaine dernière.

On a ainsi pu apprendre que la bête serait bien composée de plusieurs cœurs, 32 selon les dernières rumeurs, issus de l'architecture P54C, soit un simple Pentium, revu et corrigé.

Un simple Pentium amélioré au cœur du système

En effet, celui-ci disposera de registres 64 bits, de prefetchers améliorés et d'un cache sur deux niveaux, dont 256 ko pour le L2. Chaque cœur pourra gérer quatre threads simultanément, chacun disposant de ses propres registres.

Larrabee Larrabee Larrabee

On restera ainsi sur une gestion des instructions de type « in-order », comprendre que le processeur ne pourra pas les traiter dans l'ordre qui lui semble le plus efficace, mais seulement dans celui dans lequel elles arrivent.

Il embarquera aussi une unité vectorielle et une unité scalaire, chacune disposant  aussi de ses propres registres. Quelques unités fixes seront aussi présentes afin de permettre l'exécution de certaines tâches précises, afin de maximiser la performance de la puce dans certaines conditions, en gardant une consommation raisonnable, selon le fondeur.

Une puce entièrement programmable, avec le x86 comme atout majeur ?

LarrabeeLe tout communiquera ensemble grâce à un ring bus de 512 bits dans chaque sens (soit 1024 bits au total), et les unités ainsi que le cache seront répartis au sein de la puce afin de maximiser la rapidité du traitement de l'information.

Côté programmation, Intel met bien entendu en avant le fait que sa puce est de type x86, et qu'il sera donc aisé aux différents développeurs d'en tirer parti, d'autant plus que les premières versions du SDK circulent déjà chez certains d'entre eux, selon nos informations.

Un plus qui pourrait faire du tort à NVIDIA qui tente actuellement d'imposer CUDA comme API de programmation généraliste pour GPU, mais qui nécessite des efforts de la part des développeurs.

La puce est bien entendu compatible avec la norme IEEE et capable de traiter des calculs en simple précision ainsi qu'en double précision.

La 3D ne serait pas en reste : DirectX et OpenGL supportés. Quid des performances ?

Larrabee Larrabee

Pour ce qui est de la 3D, Intel n'est pas en reste puisqu'il confirme que les versions actuelles de DirectX et OpenGL sont entièrement supportées, et que la porte n'est pas fermée concernant les futures versions de ces API, Larrabee étant entièrement programmable, alors que les GPU ne le sont encore que partiellement.

Intel précise d'ailleurs que l'un des avantages de sa puce est que la répartition des tâches au niveau des différentes unités se fait via un algorithme du côté logiciel et non pas via une unité fixe, permettant ainsi une meilleure adaptation aux différentes situations, et à l'amélioration des performances... si celui-ci est efficace.

Car il reste encore à voir ce qu'il en sera au niveau des performances, le fondeur restant plutôt flou concernant ce point pour le moment.

Des points qui restent à éclaircir, et un délai de sortie qui pourrait aider NVIDIA et CUDA

LarrabeeIntel se borne d'ailleurs à préciser que le fait de multiplier le nombre de cœurs permet de faire augmenter les performances dans les jeux de manière linéaire selon ses projections, sans plus de détails.

Espérons donc que l'on pourra bientôt en apprendre un peu plus sur la bête, qui ne semble avoir voulu montrer que ses atouts pour l'instant. Intel évite en effet le sujet des fréquences, mais surtout du TDP et de la consommation, qui nous a été annoncée comme relativement importante, notamment au repos.

Un détail qui pourrait aussi faire la différence, mais qui peut être amélioré d'ici le lancement des premiers produits grand public, d'ici 2009 ou 2010.
78 commentaires
Avatar de brice.wernet Abonné
Avatar de brice.wernetbrice.wernet- 25/08/20 à 06:32:25

Entre 95 et XP, il a fallu passer en gros de 4Mo (8Mo pour être à l'aise) à 128Mo (256Mo pour être à l'aise) en 5 ans. Et changer la carte vidéo ISA par une VLB pour que le dégradé (grille superposée) qui s'affichait quand on quittait soit instantanée. A l'époque, on benchait les CG en 2D pour savoir si l'interface graphique serait accélérée.

Les Windows 9x ont été empoisonnés de problème de fiabilité liés parfois aux pilotes (certains développés comme des pilotes pour Win 3.1). Un mauvais pilote pouvais empêcher Windows de démarrer.

De plus, on était dans le DLL hell: Windows allait chercher les DLL des applis dans le répertoire Windows par défaut, avant celui de l'appli, et plein d'appli remplaçaient des DLL dans le répertoire Windows par les leurs (les DLL MFC, VB, ...)

J'ai réinstallé dernièrement un Windows 95 (pour le jeu des screenshots), ben ça ne ravive pas que des bon souvenirs: chercher le bon pilote, planter l'install, modifier dans les fichiers ini pour désactiver le truc pourri, redémarrer toutes les 5 minutes à chaque changement...

Windows 2000 a corrigé cela - c'est le Windows que j'ai gardé le plus longtemps à part 10, j'ai eu XP mais pas sur mon poste principal - trop gourmand. Et un virus a eu raison de mon Windows 2000 ce qui a entamé ma période freebsd.

Avatar de Nerg34 Abonné
Avatar de Nerg34Nerg34- 25/08/20 à 06:47:21

La vache dire que je les ai tous connus...

Windows ME et son légendaire écran bleu... Le pire Windows et de loin.

Dire que l'arrivée d'xp me semblait être hier. Le temps passe vite.

Avatar de ecatomb Abonné
Avatar de ecatombecatomb- 25/08/20 à 06:59:53

Zut, c'était dans le magazine. J'avais oublié 😅

Je crois que j'ai tout connus aussi de la branche grand publique : du Windows 3.11 au 10
Pour le 95, j'ai eu du bol de ne pas trop voir de bug.

Avatar de JoePike INpactien
Avatar de JoePikeJoePike- 25/08/20 à 07:06:14

Me souviens de l'impossibilité d'utiliser une clé USB sur les NT4 au bureau
J'ai encore la clé USB de 32meg DiskOnkey offerte par mon fils qui pouvait être utilisé sur ce NT4
Un très beau cadeau d'anniversaire
:yes:

Avatar de meyrand018 Abonné
Avatar de meyrand018meyrand018- 25/08/20 à 07:07:56

d'aussi loin que je me rappelle... le premier c'était windows 3.11 Workgroup !

Avatar de JoePike INpactien
Avatar de JoePikeJoePike- 25/08/20 à 07:13:35
meyrand018

Il y a plus vieux :D
De mémoire c'était un 3.0 qui tournait sous OS2
:phiphi:

Avatar de trash54 Abonné
Avatar de trash54trash54- 25/08/20 à 07:18:08

J'ai encore un pack de disquettes de 3.11 WorkGroup :phiphi:

Moi je dis : celui qui a pas eu ME ne connait pas l'écran bleu :censored:

Avatar de Tandhruil INpactien
Avatar de TandhruilTandhruil- 25/08/20 à 07:29:33

Ah ! les CD Select ! Je dois encore avoir un jeu complet qui traine quelque part :D

Sinon dans mon entreprise à l'époque les serveurs étaient en Novell Netware.

A noter que les serveurs NT4 devaient être rebootés régulièrement, on m'avait dit que c'était un compteur qui passait en overflow au delà d'un certain temps (2 mois environ).

Édité par Tandhruil le 25/08/2020 à 07:29
Avatar de brice.wernet Abonné
Avatar de brice.wernetbrice.wernet- 25/08/20 à 07:34:52

Tandhruil a écrit :

A noter que les serveurs NT4 devaient être rebootés régulièrement, on m'avait dit que c'était un compteur qui passait en overflow au delà d'un certain temps (2 mois environ).

Non, pas sous NT4 normalement (sauf pilote pourri?). J'ai connu des NT4 démarré depuis des mois sans problème. Sous Windows 95, il y avait un compteur 32bits des millisecondes. S'il bouclait (donc après 4,3Gms soit 49,7j), ça plantait.

Avatar de wolruf Abonné
Avatar de wolrufwolruf- 25/08/20 à 07:38:07

fût > fut

Il n'est plus possible de commenter cette actualité.
Page 1 / 8