Haswell : trois modèles pour la gamme R (BGA), dès 288 $

Je vais surement me faire lapider mais …



Il y a t’il une chance qu’on voit ces procos sur des cartes-mères desktop ?



Perso, sur une carte Mini ITX à destination d’un HTPC je trouverais ça pas mal : ça permet de jouer aux jeux récents en 720p, de réduire l’encombrement en se passant de CG, d’intégrer l’alim à la carte, …





[SEMI HS]

Alors, bien sur, on ne peut pas changer de proco… Pour ma part rien à faire je me suis toujours retrouvé dans la situation ou l’upgrade passait par un changement de socket… Après je comprends ceux qui sont contre le BGA partout.

David_L a écrit :



Le BGA partout n’a jamais été à l’ordre du jour. Alors être contre, c’est un peu comme être contre l’obligation de porter une casquette rose fushia un peu.







Certains prophétisent la fin du socket à long terme chez Intel. Qu’ils aient tort ou non, au vu des réactions de certains sur PCI je prends mes précautions.



Sinon ok, du NUC mais rien sur le Mini ITX à l’heure actuelle. (Un port PCI Express, même en low profile, c’est utile de temps en temps ! " /> )

flodousse a écrit :



Ca sert pas uniquement pour la mise a niveau hein ? T’as jamais eu de carte mere qui lache ? T’aimes bien repayer toute ta config quand c’est juste la CM qui a rendu l’âme ? Moi je n’aime pas… surtout quand tu rachète une nouvelle cm et que la ram n’est plus compatible non plus t’as changé tout le pc.





Si t’aimes faire ca, achète un pc portable des qu’il lache tu jette tout. (même si il y a des gens qui essaie quand même de réparer les pc portables :) )





Ce truc ne devrait être utilise que sur du bas de gamme et encore. C’est clair que la ils testent les clients, j’espère que les gens ne vont pas acheter ca " />







Cool j’ai eu les réactions attendues alors que j’ai été plutôt compatissant. Aller je vais charger un peu la mule alors :



Moi ce qui me fait marrer ce sont les gens qui découvrent “la dictature de la majorité” quand ça leur plait. “Ouin les gens n’ont pas la même façon d’utiliser leur matériel que moi !” Moi aussi j’aimerais bien une carte mère multi socket sur laquelle je fous les I/O que je veux, le chipset que je veux, le NIC que je veux, la puce audio que je veux, … Bah oui parce que si le chipset ou le southbridge tombe en panne, c’est toute la CM qu’il faut balancer ! Oui et bah les bons geeks de PCI ils en ont rien à foutre et eux veulent juste pouvoir changer leur cpu et leur ram sur leur CM et du coup le marché est comme ça.



Si ça convient aux gens le bga je ne vois pas pourquoi ils n’iraient pas en acheter. Demain X ou Y me sort une carte mère pas dégueu base d’un de ces 3 procos j’achète parce que ça correspond à mes besoins.



Et oui nous sommes dans une duopole (et encore amd ne fait plus grand chose et fait aussi du bga sur ses brazos) et il n’y aura pas de concurrent pour venir remettre des sockets (ARM qui ferait des version sockets ?). Après s’il y a vraiment un marché du socket, que les gens qui se sentent concernés montent une projet/ boite, ce n’est pas non plus interdit : ils pourraient même se faire de la thune.

HarmattanBlow a écrit :



Je ne dis pas qu’ils ont tort. C’est simplement qu’en ce moment je suis particulièrement sensible au problème puisque je vais avoir dans quelques semaines une décision à prendre concernant une archi logicielle qui va en partie dépendre du nombre de coeurs dont disposeront typiquement les clients. Si le futur est à quatre coeurs plutôt qu’à trente-deux et bien mon archi ne sera pas la même.







Sans trop rentrer dans les détails non plus. (je ne suis pas programmeur) Il n’y a pas moyen de faire ça simplement et de pouvoir adapter ton logiciel au nombre de coeur dispo ? (notamment sur les boucles)

HarmattanBlow a écrit :



Malheureusement non, ce n’est pas aussi simple : d’abord tout ne peut pas se découper, certaines opérations doivent être faîtes séquentiellement si l’étape N dépend de l’étape N-1.



Ensuite, le découpage introduit lui-même une taxe significative sur les performances qui fait que toute boucle n’est pas efficacement parallélisable. Grosso modo tu ne peux paralléliser que les boucles hautes, celles qui vont contenir beaucoup de traitement à chaque itération, et non pas les boucles terminales qui ne contiennent que trois lignes de code.



Enfin tout ça a un coût financier puisque la parallélisation complexifie significativement le code, accroît le risque de bogues, le coût du développement et de la maintenance, etcétéra.





Dans le cas qui m’occupe moi, notre problème est essentiellement constituée d’opérations séquentielles et toute la ruse est de parvenir à dénicher des opérations qui peuvent être extraites de la séquence. Par exemple la première étape peut en fait être découpée en deux chaînes séquentielles, l’une étiquetant des paquets de données (le début d’un paquet commence à la fin du précédent), l’autre ne regardant que les étiquettes (l’analyse dépendant des étiquettes précédentes). Un thread produit, l’autre consomme.



La seconde étape commence quant à elle avec une analyse superficielle de l’arbre généré par la première étape. Cette analyse va extraire certains blocs qui pourront être analysés indépendamment une fois tout l’arbre analysé (ces blocs ont besoin d’infos qui peuvent être n’importe où dans le graphe et sont collectées lors de l’analyse superficielle). On a donc un premier point possible de parallélisation lors de l’analyse superficielle (chaque branche de l’arbre peut être inspectée séparément) mais qui ne vaut sans doute pas la peine d’être explloité, et un second point avec l’analyse ultérieure des blocs (disons cinq blocs en moyenne par exécution mais entre 0 et 20 selon les données reçues) assez facile à mettre en oeuvre et efficace.



Comme tu le vois, tout ça convient bien pour du quatre coeurs. Mais pour davantage de parallélisation il faudrait continuer à rechercher, par exemple commencer l’analyse de l’arbre de la seconde étape en même temps que la première (sans attendre la fin de la construction), isoler certaines étapes parallélisables au sein des blocs, etcétéra. Ce qu’on ne fera pas sans doute pas si on table sur du quatre coeurs parce que le gain serait assez faiblard et dans certains cas uniquement.









Merci pour les précisions et l’exemple ! " />



En effet je ne suis pas connaisseur et pour moi la parallélisation ça se résumait à une boucle for (itérations indépendantes) que l’on subdivise en X.

HarmattanBlow a écrit :



C’est le cas idéal. ;)

On le rencontre parfois cela dit, notamment dans les applis scientifiques (d’où des solutions comme OpenMP si tu viens d’un de ces domaines). Le reste du temps on peut parfois créer artificiellement ces boucles for, comme ici avec l’analyse des blocs à la fin, ou d’autres motifs de conception comme le producteur/consommateur de la première étape. Et le reste du temps… Le reste du temps c’est chiant. Très chiant. ^^







Ouais voilà. J’avais déjà programmé quelques calculs en C++ avec du Open MP, je pouvais découper tranquille mes boucles et les perfs du programme augmentaient linéairement avec le nombre de coeurs. ^^