Se connecter avec
S'enregistrer | Connectez-vous

Abandon de Larrabee : Intel s’explique

Par - Source: PC Perspective | B 27 commentaires

Intel a donné des précisions sur les raisons qui l’ont poussé à abandonner le projet Larrabee durant le dernier IDF.

Intel change de modèle

« Je pense juste qu’il n’est pas pratique d’essayer d’exécuter toutes ces fonctions de façon logicielle au regard de la complexité logicielle. Et nous avons rencontré des problèmes de performance par watt en essayant de faire toutes ces choses ». Ce sont les mots de Tom Piazza, un des directeurs en charge du projet, qui soulève le problème de la complexité logicielle inhérente à l’utilisation d’une multitude de cores x86.

Le GPU vivra encore longtemps

C’est un aveu très intéressant pour Intel qui a longtemps prêché la programmabilité des cores, mais qui semble aujourd’hui se tourner vers des composants à fonction fixe, après les déboires de Larrabee. C’est un changement de modèle qui arrive à une étape charnière de l’évolution des processeurs. En effet, la multiplication des cores et l’importance toujours plus grande des modèles logiciels tirant parti du parallélisme demandent que les acteurs soient plus pragmatiques, sous peine de noyer leurs efforts et les rendre vains. Ce discours montre aussi que malgré son intégration dans le CPU, le GPU a encore de beaux jours devant lui.

Intel semble avoir retenu sa leçon et M. Piazza a clairement annoncé qu’il ne pensait pas qu’une solution graphique utilisant l’architecture Larrabee verrait le jour.

Commentaires
Afficher les 27 commentaires.
Cette page n'accepte plus de commentaires
  • Anonyme , 21 septembre 2010 08:38
    « Je pense juste qu’il n’est pas pratique d’essayer d’exécuter toutes ces fonctions dans le logiciel au regard de la complexité logiciel. Et nous avons rencontré des problèmes de performance par watt en essayant de faire toutes ces choses »

    Le premier logiciel doit pas être remplacé par matériel ?
  • -3 Masquer
    Vikk , 21 septembre 2010 09:15
    La loose...
    En meme temps, il yavait qu'eux pour y croire :) 
  • seb-de , 21 septembre 2010 09:28
    Leur architecture est surement très complexe, mais si même Intel galère pour paralléliser un programmes alors cela ne m'étonne pas que les jeux peine tant à exploiter les cores de nos CPU.
    Est ce que quelque part, on n'entrevoit pas là les limites de la multiplications de cores comme à une certaine époque la montée en fréquences???
  • magellan , 21 septembre 2010 09:52
    Citation :
    Leur architecture est surement très complexe, mais si même Intel galère pour paralléliser un programmes alors cela ne m'étonne pas que les jeux peine tant à exploiter les cores de nos CPU.
    Est ce que quelque part, on n'entrevoit pas là les limites de la multiplications de cores comme à une certaine époque la montée en fréquences???

    Hum je dirais non. Le problème tient plus des méthodes que de l'environnement. On a depuis longtemps compris que multiplier les coeurs de calcul, et on a adapté OS et logiciels à cette problématique.
    Intel ne "galère" que pour une seule raison: c'est que le projet avait pour but de paralléliser des choses non codées comme tel à l'origine, ce qui est un défi énorme en soi. De là, bien entendu, les résultats doivent être bien inférieurs à leurs attentes, donc pas étonnant en soi.

    Enfin: les jeux ne sont pas le bon exemple des bonnes pratiques en développement. Souvent finis à l'arrache (délais de mise sur le marché), patchés par la suite, avec parfois des équipes réduites pour un même boulot, le code n'est que très très rarement optimisé. Pour preuve, il sort énormément de jeux qui "rament" sur des grosses configurations, alors que d'autres, mieux finis, présentent de meilleures performances brutes (plus de polygones et meilleur framerate) à configuration égale.
  • seb-de , 21 septembre 2010 09:59
    @magellam: J'ai Arma2, je comprends bien le terme "non optimisé"..
  • 1815 , 21 septembre 2010 10:18
    Citation :
    Leur architecture est surement très complexe, mais si même Intel galère pour paralléliser un programmes alors cela ne m'étonne pas que les jeux peine tant à exploiter les cores de nos CPU.
    Est ce que quelque part, on n'entrevoit pas là les limites de la multiplications de cores comme à une certaine époque la montée en fréquences???



    c'est pas justement parce qu'on avait du mal a continuer a gagner en frequence qu'on est passes aux cores par paquet de douze?
  • guillaumelbv , 21 septembre 2010 10:19
    alors la, de l'encre va couler O.O
  • seb-de , 21 septembre 2010 10:28
    Citation :
    c'est pas justement parce qu'on avait du mal a continuer a gagner en frequence qu'on est passes aux cores par paquet de douze?


    C'est plutôt parce que le rendement de l'architecture Netburst (Pentium 4, élu meilleur dispositif de chauffage pour chambre étudiante ;)  ) se dégradait lors de la montée en fréquence. Mais oui, tu as raison.
  • -3 Masquer
    magellan , 21 septembre 2010 10:52
    Citation :
    C'est plutôt parce que le rendement de l'architecture Netburst (Pentium 4, élu meilleur dispositif de chauffage pour chambre étudiante ;)  ) se dégradait lors de la montée en fréquence. Mais oui, tu as raison.

    Tu oublies les AMD qui permettaient la cuisson des oeufs sans avoir un four dans la piaule :rofl: 

    Sinon, question optimisation, étant dans le développement, ce que je constate, c'est que trop souvent le chantier initial n'est pas conçu pour absorber des problématiques du genre multi coeurs, d'autant plus qu'un jeu se développe sur plusieurs années (à l'exception notable des FPS qui sortent en pagaille, et qui s'appuient souvent sur un ou deux moteurs déjà programmés et refourgués à la pelle).

    Bien sûr, on peut tirer sur les développeurs, mais je pondère en précisant qu'il n'est vraiment pas évident de prendre en compte ce genre d'optimisation. Avant d'optimiser, il faut déjà corriger les anomalies majeures, en l'espèce les bugs de scripts, les collisions, les comportements anormaux de la physique et j'en passe. Une fois cette étape revue, il faut encore identifier le code réseau qui est devenu inévitable. Rien que cette étape est un cauchemar absolu, tant pour les tests de validation, que pour le codage lui-même. Exemple chronique: un FPS (excellent exemple) nécessite le ping le plus bas possible, le moins d'engorgement et ainsi de suite. Tant que c'est testé en réseau local, cela fonctionne (vive le 100Mbps). Par contre, quand tes clients sont à des milliers de kms... tout le monde se plaindra alors de ralentissement intolérables, de freezes et j'en passe. Pas évident de pratiquer une validation dans ces conditions! C'est d'ailleurs le pourquoi des betas fermées où, à travers le monde, des joueurs offrent leurs services gratuits aux équipes, ceci ouvrant enfin la possibilité de vérifier "in vivo" le comportement global du code.

    Enfin, Larrabee aurait pu être une solution intéressante, si ce n'est le fait que les GPU sont aujourd'hui des monstres de puissance de calcul (l'architecture Nvidia pour les calculateurs le prouve), ce qui rend quasiment inutile et surtout infaisable toute idée de "rendre la main" au processeur.
  • vince_jazzy , 21 septembre 2010 10:54
    La fin de Larrabee montre plusieurs chose :
    1) les limites de l'architecture x86 pour ce qui est de la conso,
    2) la difficultés de trouvés des modèle de programmation adapté aux architectures NUMA
    3) l’impossibilité d'avoir un compilateur qui parallélise l'application.
    4) La puissance des architectures GPU à mémoire pseudo unifié qui simplifie les modèles de programmation.
  • grad8 , 21 septembre 2010 12:29
    ses sure que le GPU a encore de beau jours devant lui voyons xd
  • zorro3364 , 21 septembre 2010 14:22
    @magellan: je trouve au contraire que les jeux sont un bon exemple. tout dépends de quoi on parle (car les jeux sont les applications les plus complexes qui existent): ia, physique, graphique? parce que, niveau calcul graphiques, les moteurs actuels sont plutôt efficaces avec les architectures actuelles.
    ça montre que la clé de la performance est la spécialisation. mais c'est valable dans tous les domaines: le spécialiste est toujours plus efficace dans son domaine que n'importe quel touche-a-tout, mais il est aussi plus limité en champ d'action.

    la où je suis d'accord avec toi, c'est que larrabee a effectivement été conçu pour paralléliser des calculs qui ne le sont pas au départ. hors, si comme tu le dis tu es dans le développement, tu sais mieux que personne que l'optimisation doit être présente dès les première phase de la conception...
  • -2 Masquer
    Wiiip , 21 septembre 2010 15:51
    "prrrrt" (bruit du ballon qui se dégonfle)
    -> j'espère que l'abruti payé à coup de millions qui a voulu faire ca s'est fait viré avec un magistral coup de pied au cul ... Mais bien entendu, je rêve ...

    Je ne comprends pas trop vos débats là ...
    Intel a voulu faire croire qu'il était tellement fort pour faire des cpu qu'il pouvait même en faire de suffisamment gros pour enfoncer des clous avec.
    C'est un peu comme si, sous prétexte qu'un cpu fait passer de l'électricité, ils avaient voulu concurrencer les fabricants de câbles.
    Ca ne remet pas forcément en cause le multi-cpu ... En tout cas, pas directement, le graphique est, avec le tissage de tapis, ce qui peut se faire le plus directement de façon parallèle. Mais justement, pour le coup, faut plutôt partir de petits objets qu'on rends de plus en plus intelligents (façon NVidia) plutôt que de partir de cpu complet qu'on essaye de dépouiller.
    (sinon, oui, le massive-multi-cpu va dans le mur pour le soft, mais c'est une autre histoire)

    Et accessoirement, oui, le ray-tracing est de la poudre aux yeux de quelques graphistes payés par leurs bourses de recherche, n'a pas d'avenir au vu du cout par transistor actuels (brillamment exposés par les GPU justement), même multiplié par 10, et n'a de toute façon aucun intérêt. (que de se masturber devant une boule qui brille)
    -> la plupart des effets réalistes ne sont pas pris en comptes par le ray-tracing... A commencer par les traces sur la boule brillante, justement.

    Et J'AIMERAIS, au minimum, quand on est payé en million de dollars, qu'avant de présenter un projet de développement coutant plusieurs centaines de millions (voir milliard), on vérifie avant "est-ce que ca marche", et "est-ce que ca pourra se vendre à hauteur de son coût ?"
    Le jour où l'on fera cela, les intels, IBM et autres microsoft arrêteront leurs conneries absurdes sans le moindre avenir pour se retourner vers les progrès réellement à leur portée.
    (un windows user-compliant déjà, ce serait bien ... Voir un windows capable de viser d'autres utilisateurs ?)
    ... Ou alors qu'Intel cherche à rattraper encore son retard techno en GPU, ne serait-ce que pour ses chipsets ... A travers un petit partage avec NVidia par exemple ?

    Mais bon, j'ai pas fait Harvard moi, donc j'ai du mal à comprendre qu'avec une grande gueule, on peut justifier même un ascenseur lunaire.
  • _pollux_ , 21 septembre 2010 16:38
    Wiiipblablabla

    tu savais à l'avance que ça allait foirer toi ?
  • vince_jazzy , 21 septembre 2010 16:53
    Calme Wiip...

    La R&(D) ça n'aboutie pas toujours à un produit mais permet aussi de développer tout un tas de choses à côté :
    Process de développement, modèle de programmation, test chip pour tester le nouvelle techno, nouvelles IPs, compilo ...
    Et je pense que vu où en est Intel (loin, très loin devant les autres fabricants) aujourd'hui il savent faire du reuse même sur les projets R&D avortés.
  • isneok , 21 septembre 2010 17:26
    Les jeux sont très loins d'être les applications les plus complexes Zorro...
  • -2 Masquer
    Wiiip , 21 septembre 2010 17:52
    _pollux_tu savais à l'avance que ça allait foirer toi ?

    "Foirer" dans le sens qu'ils abandonnerait, non. Il suffit toujours d'une présentation enthousiaste pour réussir à faire quelque chose d'un produit et le refourguer. (il n'y a qu'à voir le nombre d'objets & softs discutables qui évoluent tous les jours dans le joyeux monde de l'informatique pro.)
    Le bilan financier qui conduit à l'arrêt, lui, n'est du qu'au nombre de zéro qu'on réussi à aligner au culot, et aux moyens de l'acheteur (qui paye en fonction de ses moyens, puisqu'il est incapable de comprendre ce qu'il achète)
    Par contre, qu'ils n'iraient pas très loin dans le graphisme grand public avec une démarche pareil, ca, tout le monde le sait depuis qu'on connait la démarche.
    Et que l'argument "ray-tracing" ressemble bien plus à la tentative réussi d'un labo du domaine pour obtenir ses crédits pour une année de plus qu'à une quelconque réalité terrestre, ca, je l'ai toujours dit.

    ... Oui, ils peuvent réutiliser. Mais indirectement : ils ont créés les compétences, et ces compétences (les hommes), continuent à bosser pour eux dans un domaine proche. Pour le reste, plus c'est gros, plus c'est con. (et plus ca gaspille).
    S'ils étaient aussi intelligents que ca, ils commenceraient par ne pas faire n'importe quoi (idem IBM, idem microsoft)

    Mais bon, je comprends la démarche aussi : ils ont du fric à ne plus savoir qu'en foutre (enfin, de la part d'intel, je ne le pensais pas), et ils cherchent à trouver le domaine qui les rendra plus riche que des producteurs de pétrole (comme s'ils n'étaient pas suffisamment riches comme ca), donc ils cherchent n'importe où. Sauf que s'ils sont incapable de voir les murs venir, ca relève quand même de l'incompétence caractérisée, qui est très loin de leur valoir leurs salaires.
  • vince_jazzy , 21 septembre 2010 18:04
    Citation :
    S'ils étaient aussi intelligents que ca, ils commenceraient par ne pas faire n'importe quoi (idem IBM, idem microsoft)


    Premier point : ne pas confondre Microsoft (édition logiciel), IBM (microélec mais pas seulement) et Intel (Pure microélec)
    Car ces trois entreprises ont des modèles économiques très différents qui influe sur leur manières d'envisager leur R&D.

    Deuxième point :
    Intel ne fait pas forcément n'importe quoi car ils ont poussé l'x86 vraiment loin alors qu'a la base c'est pas top du tout comme architecture.
    Ensuite je ne vois pas pourquoi IBM fait n'importe quoi car dans le domaine des processeurs le Cell était pas ma du tout.
    Enfin Microsoft fait peut être n'importe quoi mais ça marche la preuve en est où ils en sont même si les moyens employés ne sont pas toujours légaux ou équitables...
  • magellan , 21 septembre 2010 19:57
    Citation :
    @magellan: je trouve au contraire que les jeux sont un bon exemple. tout dépends de quoi on parle (car les jeux sont les applications les plus complexes qui existent): ia, physique, graphique? parce que, niveau calcul graphiques, les moteurs actuels sont plutôt efficaces avec les architectures actuelles.
    ça montre que la clé de la performance est la spécialisation. mais c'est valable dans tous les domaines: le spécialiste est toujours plus efficace dans son domaine que n'importe quel touche-a-tout, mais il est aussi plus limité en champ d'action.

    la où je suis d'accord avec toi, c'est que larrabee a effectivement été conçu pour paralléliser des calculs qui ne le sont pas au départ. hors, si comme tu le dis tu es dans le développement, tu sais mieux que personne que l'optimisation doit être présente dès les première phase de la conception...

    Et c'est bien là où ça ne marche pas du tout: techniquement, tout bien penser dès le départ est un rêve, au titre qu'il y a toujours quelque chose qui va ralentir l'étude et le développement...

    Concernant le plus complexe: ce ne sont pas les jeux à mon sens, au titre que nombre d'entres eux s'appuient "bêtement" sur des SDK. C'est un boulot de scripting, de design, d'artiste, mais de là à dire que c'est le plus complexe... J'ajoute en plus que la majorité des jeux sont en mode "couloir", c'est à dire qu'il n'y a pas réellement possibilité de sortir des sentiers balisés. Un OS, un outil bureautique puissants, eux, permettent tellement de combinaisons, d'associations imprévues qu'il en devient fatalement très délicat d'en définir les limites. Et LA, il y a obligation de performance, car c'est sur des plateformes très hétérogènes qu'on retrouvera les dits produits (un OS s'installe, généralement, sur à peu près n'importe quoi), tandis que les jeux, eux, profitent de l'augmentation énorme de puissance. On peut prendre énormément d'exemples signifiants d'ailleurs: l'explosion des jeux 3D profitent de la couche D3D, et plus rarement open GL. Pratique, puisque c'est cette couche qui est supposée dialoguer avec le hardware. Dans ces conditions, le jeu profite donc d'instructions prédéfinies. C'est très différent quand il s'agit de concevoir la dite couche...

    Autre points que je trouve amusants à préciser:
    - IA? Quelle IA? Ce sont de purs scripts, des réactions prédéfinies. Les rares pseudo IA qui existent s'appliquent aux RTS, et encore... les très bons joueurs en connaissent finalement les failles et en jouent à loisir. Le seul à avoir eu une IA à peu près évolutive fut un produit MASA nommé Conflict Zone. Ce fut le premier (et à ma connaissance le dernier) à offrir une IA capable de "raisonnement", donc de s'adapter.
    - Physique? Même combat, il y a des moteurs qui se vendent des millions, et qui sont développés par des sociétés qui en utilisent les applications partout en dehors du jeu: mécanique, simulations pour les bâtiments... Ce que font les devs? Paramétrer les dits moteurs.
    - Graphique? Il n'y a pas de "codage" à proprement parler: un outil de construction 3D, de bonnes compétences en design... et c'est parti. C'est fini les objets 3D développés à la main!
    Ne perd surtout pas de vue que nombre de gros jeux s'appuient sur des moteurs développés par une ou deux sociétés (Valve et Id software en tête). EUX, ils font du moteur, les autres les utilisent et les adaptent un peu à leurs besoins. Les autres ne réinventent pas la roue.
  • zgooz , 21 septembre 2010 20:51
    Et dire que je demandais des news des bleus et de leur raytracing dans une précédente news sur les rouges, je suis servi.
    Dommage qu'Intel abandonne cette piste. Mais bon c'est sûr qu'en partant d'un processeur CISC, ils étaient mal barrés.
    Ceci dit les calculs massivement parallèle, ça existe et ça fonctionne nickel.
    Il suffit de savoir les programmer (cf. les simulations nucléaire, météorologique, géologique...).
    Et je ne vois pas pourquoi on n'arriverait pas à faire tourner un jour sur un même proc les 1600 coeurs qui battent dans ces serveurs.
    Non, les jeux ne sont pas les programmes les plus complexes. Faites voler une fusée en tenant compte de tous les paramètres, ça c'est du programme complexe.
Afficher plus de commentaires