ARM, architecture, news, etc.

[Childerik]

Attends, l'article cite est du grand n'importe quoi, ca serait moi y'a un mec qui serait vire pour incompetence

Ben ça j'ai vu . Mais bon, puisqu'on est parti sur les affirmations du monsieur truc qui parle d'introduire des ARM dans des petits serveurs, autant aller jusqu'au bout .

Maintenant, dans le grand n'importe quoi de cet article, on peut aussi se poser la question "pourquoi la très grande majorité des serveurs, même petits, sont sous archi x86 ?" : c'est la première question qui m'est venu à l'esprit et que le monsieur ne s'est même pas posée, ou qu'il n'a pas voulu se poser pour se la péter un max .

[Dandu]

le prix, non ?

Une bonne partie des serveurs servent à du stockage et/ou à héberger des trucs qui ont pas besoin de puissance : Dell propose pas mal de serveurs en Celeron, par exemple.

[Foudge]

Ceci dit, même dans le Top500, il y a 80% de CPU x86.

[Childerik]

le prix, non ?

Une bonne partie des serveurs servent à du stockage et/ou à héberger des trucs qui ont pas besoin de puissance : Dell propose pas mal de serveurs en Celeron, par exemple.

Surtout qu'un vulgaire Celeron commence à 25 €, ce qui ne pèse pas grand chose.

Puis l'archi en elle-même : le x86 dure depuis bientôt 30 ans. Le développement d'applications est quand même plus que rodée dessus.

Apple a eu un mal fou lors de la transition 68k vers PPC, il me semble ? J'imagine mal des développeurs qui ont toujours été habitués au x86 faire des appli serveur en arm comme ça, en claquant des doigts . Sachant qu'ils mettent déjà 10 plombes pour s'adapter aux différentes versions d'OS dans une même archi .

Ceci dit, l'ARM a encore de très beaux jours pour les produits embarqués, sachant qu'il faudra beaucoup de patience chez Intel pour réussir à investir ce marché.

[newbie06]

Puis l'archi en elle-même : le x86 dure depuis bientôt 30 ans. Le développement d'applications est quand même plus que rodée dessus.

Rode certainement, efficace certainement pas. Je parie que meme des applications massivement utilisees sur des serveurs continuent a faire des acces memoire non alignes, ou sont compiles pour du i686 voire du i386, donc avec un rendement reduit.

Apple a eu un mal fou lors de la transition 68k vers PPC, il me semble ? J'imagine mal des développeurs qui ont toujours été habitués au x86 faire des appli serveur en arm comme ça, en claquant des doigts . Sachant qu'ils mettent déjà 10 plombes pour s'adapter aux différentes versions d'OS dans une même archi .

Et voila, tu demontres clairement le probleme d'avoir une architecture hyper dominante : les gens ont leurs habitudes et font comme si rien ne changeait. Pourtant lorsque l'Alpha est sorti, les gens ont commence a nettoyer leurs problemes de 64 bits. Si on avait plus d'architectures differentes, les dev seraient habitues au portage. Je n'ai jamais de probleme de portage, que ce soit du 32 ou 64 bits, du little ou big endian, avec ou sans contrainte d'alignements. C'est surement parce que je suis vieux et que j'ai vu passer une bonne dizaines d'archis

Quant a Apple, leur problematique etait differente : il s'agissait de pouvoir faire tourner les applis 68k sur powerpc sans recompilation, avec en plus des applis qui ne respectaient pas les consignes ; ce souci de non respect des consignes fait que des applis ne tournent pas sous Vista.

Ceci dit, même dans le Top500, il y a 80% de CPU x86.

Ben ouai, un truc qui bourrine en calcul marche pas mal sur un cluster, et dans un cluster le prix du processeur a un impact plus important que dans un supercalculateur traditionnel (enfin je crois).

[Childerik]

Rode certainement, efficace certainement pas. Je parie que meme des applications massivement utilisees sur des serveurs continuent a faire des acces memoire non alignes, ou sont compiles pour du i686 voire du i386, donc avec un rendement reduit.

Je ne dis pas le contraire hein . Et c'est bien dommage de ne pas exploiter davantage les merveilleuses instructions simd quand on continue dans bien des applications à se restreindre au x87, voire au meilleur des cas le MMX.

Et voila, tu demontres clairement le probleme d'avoir une architecture hyper dominante : les gens ont leurs habitudes et font comme si rien ne changeait. Pourtant lorsque l'Alpha est sorti, les gens ont commence a nettoyer leurs problemes de 64 bits. Si on avait plus d'architectures differentes, les dev seraient habitues au portage. Je n'ai jamais de probleme de portage, que ce soit du 32 ou 64 bits, du little ou big endian, avec ou sans contrainte d'alignements. C'est surement parce que je suis vieux et que j'ai vu passer une bonne dizaines d'archis

Là, je ne suis pas d'accord avec toi sur le principe des bonnes vieilles habitudes : ce n'est pas aux utilisateurs finaux de payer les pots cassés, merde ! .

Puis dans ma philosophie, je préfère de beaucoup une architecture unifiante que 17 architectures différentes qui foutent un bordel monstre sur le portage d'une application (et le portage grâce à java, merci, je n'appelle pas ça quelque chose de franchement optimisé sur la plate-forme où l'application est exploitée : c'est pratique à court-terme, mais c'est très con à long-terme).

Quant a Apple, leur problematique etait differente : il s'agissait de pouvoir faire tourner les applis 68k sur powerpc sans recompilation, avec en plus des applis qui ne respectaient pas les consignes ; ce souci de non respect des consignes fait que des applis ne tournent pas sous Vista.

Le non-respect des consignes sous Vista, c'est un problème beaucoup plus mineur : ça touche essentiellement l'accès au kernel.

Puis on remarquera que la communauté open source a été beaucoup plus réactive pour s'adapter à Vista : étrange, non ? .

[Foudge]

Rode certainement, efficace certainement pas. Je parie que meme des applications massivement utilisees sur des serveurs continuent a faire des acces memoire non alignes, ou sont compiles pour du i686 voire du i386, donc avec un rendement reduit.

Donc finalement, ce n'est pas l'archi des CPU x86 qui est inefficace, mais les logiciels qui ne sont pas assez optimisés pour ?

[fefe]

Les CPUs x86 sont aujourd'hui les CPUs les plus efficaces sur du code mal ecrit et ce tres loin devant la concurence. La seule chose qui peut donner un avantage aux autres CPUs est que l'on n'a pas besoin de la performance que les x86 proposent et les avancees technologiques (process+etat de l'art/experience dans le domaine) rendent accessibles des performances suffisantes a des CPUs plus simples.

[Foudge]

A voir si l'Atom ne va pas changer la donne...

[newbie06]

Les CPUs x86 sont aujourd'hui les CPUs les plus efficaces sur du code mal ecrit et ce tres loin devant la concurence.

Oui surtout les programmes x87 Et ça va aller en s'arrangeant avec l'AVX.

La seule chose qui peut donner un avantage aux autres CPUs est que l'on n'a pas besoin de la performance que les x86 proposent et les avancees technologiques (process+etat de l'art/experience dans le domaine) rendent accessibles des performances suffisantes a des CPUs plus simples.

Là je suis partiellement d'accord : les autres archis n'ont pas un aussi lourd passif à se traîner, et il y a donc moins d'effort à fournir. Je suis assez admiratif de ce qu'AMD et Intel ont réussi à tirer du x86.

D'un autre côté tu présentes les choses comme si Intel & Co avait tout inventé, les autres n'étant que des suiveurs. Je pense qu'il y a eu toute une époque où d'un point de vue micro-architectural Intel n'était qu'un suiveur sur le x86. Je me souviens avoir beaucoup ri lorsqu'ils ont présenté leur concept révolutionnaire de moteur RISC interne. Ha ouai ils devaient parler de micro-op

Maintenant les choses ont changé car Intel a le meilleur process du monde (et l'a peut-être toujours eu, c'est un domaine que je ne connais pas) et l'architecture la plus utilisée.

N'empêche que leurs avancées ne me font toujours pas rêver, empiler des nouvelles instructions et élargir les chemins de data, mouai ça sert, est-ce nouveau ? Chais pas, faut que je ressorte mes bouquins sur les archis vectorielles d'il y a 30 ans. J'imagine assez que beaucoup de choses ne sont pas expliquées qui seraient amusantes, mais comme je ne les connais pas...

De là à croire que les autres ne peuvent innover et baffer Intel temporairement, que seul Intel a besoin d'un tel niveau de performances, non. Toutes les archis se tapent des JIT JVM, du dispatch dynamique, du pointer chasing, des programmes d'incompétents qui ne savent pas ce qu'un cache est obligeant à faire du prefetch, des optimisations sur les TLB de niveau 1, de la compatibilité avec des aberrations d'une autre époque, etc.

Donc finalement, ce n'est pas l'archi des CPU x86 qui est inefficace, mais les logiciels qui ne sont pas assez optimisés pour ?

En quelque sorte. Comme le dit Fefe, Intel déploie des moyens monstre pour que les programmes existants continuent de bien tourner. J'aimerais beaucoup voir les x86 générer des fautes sur les accès non alignés

Mais si leurs efforts étaient suffisants, ils n'ajouteraient pas des dizaines d'instructions tous les deux ans (argument à moitié fallacieux, mais pas 100% faux). Leurs nouvelles instructions vectorielles n'amélioreront pas les perfs de l'existant, mais je suis sûr qu'on verra plein de reviewers se caresser devant les vitesses d'encodage des programmes les utilisant.

Je continue de penser qu'un programme recompilé spécifiquement pour le processeur sur lequel il tourne va gagner 5 à 15% de perf (s'il est limité par le CPU) et ce sans compter sur les nouvelles instructions.

Tout ce que je dis c'est du gut feeling, pas une vérité absolue

[Childerik]

newbie06, on t'a reconnu ! Tu es un rescapé du naufrage Sylvania survenu en 1993 près des plages d'OSRAM h34r:. Et depuis, tu cherches à te venger de ce méchant Intel qui a torpillé le navire:zomb:

[fefe]

Oui surtout les programmes x87 Et ça va aller en s'arrangeant avec l'AVX.

Ben oui sur du code ecrit pour une machine a pile trouve une archi aussi efficace

D'un autre côté tu présentes les choses comme si Intel & Co avait tout inventé, les autres n'étant que des suiveurs. Je pense qu'il y a eu toute une époque où d'un point de vue micro-architectural Intel n'était qu'un suiveur sur le x86. Je me souviens avoir beaucoup ri lorsqu'ils ont présenté leur concept révolutionnaire de moteur RISC interne. Ha ouai ils devaient parler de micro-op

Je ne crois pas avoir dit qu'il n'y avait jamais rien eu d'autre que du x86. L'alpha 21264 a ete pendant un long moment la meilleure machine a executer du code mal compile ou mal ecrit, precede par ... mmm le P6 ... Avant le P6 n'importe quelle archi RISC s'en sortait mieux sur du code pourri que les x86 (et en face du P6 le PPC604, meme s'il s'en sortait pas mal, restait assez sensible tres dependant des optims).

Maintenant les choses ont changé car Intel a le meilleur process du monde (et l'a peut-être toujours eu, c'est un domaine que je ne connais pas) et l'architecture la plus utilisée.

L'avantage de process s'est accentue avec le temps, vu que les investissements necessaires pour progresser sont exponentiels et ne laissent plus la place a des petits acteurs avec de bonnes idees.

N'empêche que leurs avancées ne me font toujours pas rêver, empiler des nouvelles instructions et élargir les chemins de data, mouai ça sert, est-ce nouveau ? Chais pas, faut que je ressorte mes bouquins sur les archis vectorielles d'il y a 30 ans. J'imagine assez que beaucoup de choses ne sont pas expliquées qui seraient amusantes, mais comme je ne les connais pas...

Je suis d'accord avec toi que depuis P4 il n'y a pas eu grand chose de vraiment excitant dans le monde du x86. Beaucoup de bonnes idees realistes et pas tres sexy en font de bons produits mais c'est tout. Pour le reve et les innovations majeures, regarder cote GPU ou Niagara...
Il y a beaucoup a faire dans le SIMD: la plupart des problemes de SIMD modernes peuvent trouver des reponses dans les machines vectorielles, mais en pratique c'est nettement plus complique que ca, les contraintes sont finalement assez differentes, et les codes aussi.

De là à croire que les autres ne peuvent innover et baffer Intel temporairement, que seul Intel a besoin d'un tel niveau de performances, non. Toutes les archis se tapent des JIT JVM, du dispatch dynamique, du pointer chasing, des programmes d'incompétents qui ne savent pas ce qu'un cache est obligeant à faire du prefetch, des optimisations sur les TLB de niveau 1, de la compatibilité avec des aberrations d'une autre époque, etc.

Ce n'est pas ce que je disais. Je voulais juste dire que pour browser le web regarder des videos de poneyz et ecrire des mails il y a probablement 50 boites dans le monde qui peuvent faire des cpus suffisants.
Apres il y aura toujours des codes pourris, des languages de trop haut niveau etc... Et pour ca AMD et Intel dominent et effectivement les autres peuvent aller se coucher, les dernieres startups qui ont essaye se sont oriente vers du low cost (en fin de projet parce qu'ils n'arrivaient pas a de bonnes perfs) et ont fait faillite, cf au hasard Transmeta, Montalvo et ce malgre des investissements assez enormes (>100aines millions de $ au mini par projet en R&D). Meme VIA/Centaur qui a pourtant une experience tres importante sort son Isaiah qui du point de vue features ressemble a un Phenom/C2D (single core) mais en a la moitie des performances. Comme processeur hautes performances il reste quoi d'autre ? IBM avec la serie Power qui ne me donne pas l'impression de vouloir re-investir dans des CPUs client.

Mais le monde du software a pris de trop mauvaises habitudes avec les augmentations de performances regulieres et garanties sans n'avoir rien a faire.

Mais si leurs efforts étaient suffisants, ils n'ajouteraient pas des dizaines d'instructions tous les deux ans (argument à moitié fallacieux, mais pas 100% faux). Leurs nouvelles instructions vectorielles n'amélioreront pas les perfs de l'existant, mais je suis sûr qu'on verra plein de reviewers se caresser devant les vitesses d'encodage des programmes les utilisant.

Bof, il y a des gens de marketing qui se sont rendus compte que ca faisait plein de pub d ajouter des instructions regulierement plutot que de tout ajouter d'un coup. Donc l'argument tombe un peu a l'eau. La methode est de faire un jeu d'instruction a trous, avec des torus connus et d'ajouter petit a petit le reste (j'exagere un peu, les instructions ajoutees sur le tard sont essentiellement des instructions ayant un rendement cout/perf faible cf SSE3 et SSE4.2 par ex). En plus a chaque nouvelle release d'un jeu d'instruction ca fait une feature de plus a mettre sur la boite que le concurrent ne supporte pas (c'est mesquin mais ca marche).

[Gabriel]

N'empêche que leurs avancées ne me font toujours pas rêver, empiler des nouvelles instructions et élargir les chemins de data, mouai ça sert, est-ce nouveau ? Chais pas, faut que je ressorte mes bouquins sur les archis vectorielles d'il y a 30 ans. J'imagine assez que beaucoup de choses ne sont pas expliquées qui seraient amusantes, mais comme je ne les connais pas...

Ben Netburst ça faisait réver. Certes, il y a des problèmes, mais c'était assez ambitieux et courageux. En tous cas je trouve que c'était beaucoup plus beau que Core qui produit certes des CPU très efficaces sur le code existant, mais qui est aussi un gigantesque constat d'échec par rapport aux programmeurs.

De là à croire que les autres ne peuvent innover et baffer Intel temporairement, que seul Intel a besoin d'un tel niveau de performances, non. Toutes les archis se tapent des JIT JVM, du dispatch dynamique, du pointer chasing, des programmes d'incompétents qui ne savent pas ce qu'un cache est obligeant à faire du prefetch, des optimisations sur les TLB de niveau 1, de la compatibilité avec des aberrations d'une autre époque, etc.

Le gros problème, c'est bien que l'on doive faire tourner les applis existantes. De fait, qui risquerait de sortir un CPU "propre" mais qui ralentirait donc l'exécution des programmes existants? Pour ce permettre ce genre de choses, il faut une sacré réserve financière et une très grande force commerciale.

[newbie06]

Ben Netburst ça faisait réver. Certes, il y a des problèmes, mais c'était assez ambitieux et courageux. En tous cas je trouve que c'était beaucoup plus beau que Core qui produit certes des CPU très efficaces sur le code existant, mais qui est aussi un gigantesque constat d'échec par rapport aux programmeurs.

Netburst n'avait rien de revolutionnaire d'un point de vue architecture sauf peut-etre le trace cache.

Le gros problème, c'est bien que l'on doive faire tourner les applis existantes. De fait, qui risquerait de sortir un CPU "propre" mais qui ralentirait donc l'exécution des programmes existants? Pour ce permettre ce genre de choses, il faut une sacré réserve financière et une très grande force commerciale.

Tout a fait d'accord ! Et c'est bien pour ca que je dis qu'Intel n'est pas le seul a faire face a ce probleme et a tenter de le regler

[Gabriel]

Netburst n'avait rien de revolutionnaire d'un point de vue architecture sauf peut-etre le trace cache.

Tu as pleinement raison. Malheureusement, vu l'état actuel de l'écosystème x86 (incluant donc les programmes et programmeurs existants), le seul fait d'avoir quelque chose d'un peu plus propre et moins orienté "accélération du mauvais code" me fait réver.

newbie06, on t'a reconnu ! Tu es un rescapé du naufrage Sylvania survenu en 1993 près des plages d'OSRAM h34r:. Et depuis, tu cherches à te venger de ce méchant Intel qui a torpillé le navire:zomb:

Tu pourrais éclairer mon ampoule stp? J'ai du mal à voir le rapport entre le passage de Sylvania de GTE/Siemens vers Osram et Intel.

[Childerik]

Tu pourrais éclairer mon ampoule stp? J'ai du mal à voir le rapport entre le passage de Sylvania de GTE/Siemens vers Osram et Intel.

Aucun : tu cherchais un rapport ? Tu t'es fatigué pour rien .

[fefe]

Netburst n'avait rien de revolutionnaire d'un point de vue architecture sauf peut-etre le trace cache.

C'est un aveu d'ignorance... Entre les caches a acces speculatifs avec prediction de voie, la circuiterie employee pour fireball, l'implementation de SSE2 (full width/depipelined), le predicteur de branchement qui mettait une claque a tout ce qui n avait jamais existe, le mecanisme generique pour recuperer de tous ypes de speculation (replay), SMT, Netburst etait blinde d'innovations technologiques qui n'avaient jamais ete implementees en hard et pour lesquelles les publis scientifiques avaient generalement de 5 a 10 ans (et il faut considerer les 5 ans de dev du CPU)...

Je ne pretends pas que toutes ces innovations etaient bonnes (au contraire un bon paquet s'est avere etre un mauvais choix a long terme), mais de dire que netburst ne presentait aucune innovation technologique a part peut etre le trace cache c'est faux. Au cas ou vous ne l'auriez pas lu il y a un excellent article d'xbit qui doit faire 40 pages sur le P4 ca rafraichira vos memoires.

[Gabriel]

Effectivement, ca va me faire une bonne lecture

17 pages de Replay:
http://www.xbitlabs.com/articles/cpu...ay/replay.html

et surtout, 49 pages de Netburst:
http://www.xbitlabs.com/articles/cpu...etburst-1.html
http://www.xbitlabs.com/articles/cpu...etburst-2.html

edit: quand j'aurais fait mes devoirs, je reviendrais pour demander ce qui, avec le recul, c'est avéré ne pas être des choix judicieux.

[newbie06]

C'est un aveu d'ignorance...

Ca j'avoue

Entre les caches a acces speculatifs avec prediction de voie,

Way prediction -> 21264 en 1998 (pour rappel P4 c'est 2000). OK c'est cote instruction.

la circuiterie employee pour fireball

Cekoidonc ?

l'implementation de SSE2 (full width/depipelined),

J'ai deja dit ce que je pensais des ajouts de jeu d'instruction Le 21264 avait aussi des instructions multimedia (et je parle meme pas de SPARC qui a, il me semble, ete le tout premier), mais je ne sais pas s'il allait aussi loin.

le predicteur de branchement qui mettait une claque a tout ce qui n avait jamais existe, le mecanisme generique pour recuperer de tous ypes de speculation (replay), SMT, Netburst etait blinde d'innovations technologiques qui n'avaient jamais ete implementees en hard et pour lesquelles les publis scientifiques avaient generalement de 5 a 10 ans (et il faut considerer les 5 ans de dev du CPU)...

La je vais speculer un peu (pas le temps de verifier), mais il me semble que le predicteur du 264 n'etait pas pique des vers non plus, et que l'Alpha faisait aussi du replay dans tous les coins.

Je ne pretends pas que toutes ces innovations etaient bonnes (au contraire un bon paquet s'est avere etre un mauvais choix a long terme), mais de dire que netburst ne presentait aucune innovation technologique a part peut etre le trace cache c'est faux. Au cas ou vous ne l'auriez pas lu il y a un excellent article d'xbit qui doit faire 40 pages sur le P4 ca rafraichira vos memoires.

Ouai bon j'avoue ma memoire me trahit. Tout ce dont je me souviens lorsqu'il est sorti c'est que je me suis dit que le 21264 n'avait rien a lui envier.

Si j'ai le temps ce WE, je relirai des trucs sur le P4 et le 21264, histoire d'arreter de dire des conneries...

[fefe]

Ca j'avoue

Way prediction -> 21264 en 1998 (pour rappel P4 c'est 2000). OK c'est cote instruction.

Rien a voir entre les 2. D'un cote tu as de la speculation sur des donnees de l'autre sur des instructions donc ca ne change rien par rapport a predire les branchements.

J'ai deja dit ce que je pensais des ajouts de jeu d'instruction Le 21264 avait aussi des instructions multimedia (et je parle meme pas de SPARC qui a, il me semble, ete le tout premier), mais je ne sais pas s'il allait aussi loin.

Je n'ai pas dit que les instructions etaient innovantes juste que l'implementation l'etait. AltiVec par exemple implementait deja bien plus que SSE2 en terme d'instructions.

La je vais speculer un peu (pas le temps de verifier), mais il me semble que le predicteur du 264 n'etait pas pique des vers non plus, et que l'Alpha faisait aussi du replay dans tous les coins.

Oui mais rien a voir non plus en terme de complexite ni d'efficacite (bien sur je parle d'un domaine ou chaque pourcent de bonne prediction ajoute est limite une revolution).

Ouai bon j'avoue ma memoire me trahit. Tout ce dont je me souviens lorsqu'il est sorti c'est que je me suis dit que le 21264 n'avait rien a lui envier.

Non plus, le 21464 n'avait clairement rien a envier au contraire, mais le projet n'a pas publie beaucoup d'infos. Le 21264 etait tres innovatif quand il est sorti: le clustering en particulier, les predicteurs aussi, les acces speculatif au L2 (mais pas de replay non, une annulation a la P6).

Si j'ai le temps ce WE, je relirai des trucs sur le P4 et le 21264, histoire d'arreter de dire des conneries...

Le 21264 est au cote des archis qui ont le plus innove de ces 20 dernieres annees, au cotes du power 1, du P6 et du P4 du K8 (certains puristes prefereront dire que les innovations venaient du 21364, mais pour moi ca reste le K8) et de mon point de vue Niagara aussi. Il y en a tres certainement d'autres mais ces archis la m'ont marque pour leur cote innovant (du cote ISA c'est AltiVec qui remporte la palme pour moi et de tres loin).

[fefe]

http://www.digitimes.com/news/a20081125PD210.html

[newbie06]

Petite ambiguite dans l'article : l'ExpressGate est purement soft, il utilise donc le proc Intel ou AMD.

Je trouve aussi amusant que l'on dise que c'est ARM qui vise Intel, c'est un peu le contraire qui s'est passe. Enfin disons qu'Intel a cherche a grossir par le bas et a trouve une seule compagnie sur qui taper

[newbie06]

Une news qui pourrait etre interessante : http://www.presence-pc.com/actualite...2683/#comments

Si ce n'est le commentaire x86 vs ARM non argumente. Dandu, une fessee ?

[fefe]

C'est quoi le TDP de ce SOC ? Ca permettrait de le comparer avec qq chose de comparable et pas un systeme a 300W.

[newbie06]

C'est quoi le TDP de ce SOC ? Ca permettrait de le comparer avec qq chose de comparable et pas un systeme a 300W.

Aucune idee, ce n'est pas comme si Qualcomm etait du genre a communiquer
Enfin comme il sert pour des produits portables, parler de Phenom II, core i7 me parait d'un parti pris lamentable (desole Dandu, mais c'est exactement ce que je pense ).

[fefe]

Je le disais plus gentiment que toi . Mais d'un certain point de vue, si un tel systeme qui ne coute rien et ne consomme quasiment rien pouvait concurrencer les "gros" cpus ca serait une sacree news et quelque chose a fouiller .

[newbie06]

Je le disais plus gentiment que toi .

Moui, desole, j'y ai sans doute ete un peu fort... C'est juste que j'ai trouve ca etonnant et decevant. Mais j'en veux pas a Dandu, je suis sur qu'il fera attention la prochaine fois, comme moi qui ne dis plus de mal du P4

Mais d'un certain point de vue, si un tel systeme qui ne coute rien et ne consomme quasiment rien pouvait concurrencer les "gros" cpus ca serait une sacree news et quelque chose a fouiller .

Ha oui ca serait une sacree news. C'est marrant j'y crois pas, comme toi tu n'y crois pas non plus

[fefe]

J'ai pas fait gaffe, mais en plus 140mm^2 c'est loin d'etre petit. Bien sur tout depend du packaging, mais je suppose que vu les form factor vises il doit etre compact, donc on parle d'une puce assez imposante.

Quelqu'un connait les ratios package/silicon dans le monde des telephones portables ?

[edit] et par la meme occasion aurait des liens vers des white papers sur les "Snapdragon" parce que je n'ai trouve que du blabla marketing et de l'origami pour l'instant...

[Dandu]

Une news qui pourrait etre interessante : http://www.presence-pc.com/actualite...2683/#comments

Si ce n'est le commentaire x86 vs ARM non argumente. Dandu, une fessee ?

Je m'adapte à mes lecteurs

Plus sérieusement, c'est pour éviter les commentaires genre "c'est mieux que cette merde d'Atom"

C'est quoi le TDP de ce SOC ? Ca permettrait de le comparer avec qq chose de comparable et pas un systeme a 300W.

200 mW à 500 MHz, mais pas trop d'infos de la source.

Aucune idee, ce n'est pas comme si Qualcomm etait du genre a communiquer
Enfin comme il sert pour des produits portables, parler de Phenom II, core i7 me parait d'un parti pris lamentable (desole Dandu, mais c'est exactement ce que je pense ).

Comme je le dis, c'est pas du parti pris, c'est ce que mes lecteurs veulent, des comparaisons, même si pas pertinentes.

J'ai pas fait gaffe, mais en plus 140mm^2 c'est loin d'etre petit. Bien sur tout depend du packaging, mais je suppose que vu les form factor vises il doit etre compact, donc on parle d'une puce assez imposante.

Quelqu'un connait les ratios package/silicon dans le monde des telephones portables ?

[edit] et par la meme occasion aurait des liens vers des white papers sur les "Snapdragon" parce que je n'ai trouve que du blabla marketing et de l'origami pour l'instant...

c'est gros mais ça remplace pas mal de puces.

Et non, y a pas de docs ou très peu en dehors des CP.

[newbie06]

Plus sérieusement, c'est pour éviter les commentaires genre "c'est mieux que cette merde d'Atom"

Comme je le dis, c'est pas du parti pris, c'est ce que mes lecteurs veulent, des comparaisons, même si pas pertinentes.

Oui mais du coup tu n'as pas pris le risque de le comparer à un Atom. Parce que je ne parierais pas forcément sur l'Atom, mais je suis clairement de parti pris et en plus de mauvaise foi

200 mW à 500 MHz, mais pas trop d'infos de la source.

Ca me paraît plutôt bas comme valeur. Ca ne serait pas plutôt pour un des deux coeurs pris tout seul ?

Quant à avoir plus d'informations sur Snapdragon, hormis signer des NDA, c'est difficile.

Quelques liens:
- http://www.qualcomm.com/common/docum...onOverview.pdf
le coeur, nommé Scorpion, superscalaire 2100 DMIPS pour 1 GHz (plus que Cortex A9 superscalair OoO donné pour >2.0 DMIPS / MHz)

- http://www.insidedsp.com/Articles/ta...pion-Core.aspx
Ca semble confirmer ce que je disais plus haut puisqu'ils parlent de 200 mW à 600 MHz pour Scorpion tout seul.
Instructions SIMD (NEON) traitées sur 128 bits.
Superscalaire dual issue.