ARM, architecture, news, etc.

[Møgluglu]

C'est sur que le code ARM généré par icc ne doit pas être super optimisé.

[newbie06]

C'est sur que le code ARM généré par icc ne doit pas être super optimisé.

Ouai c'est clair. Mais le gcc qu'ils ont pris pour ARM n'est pas tip top non plus

[newbie06]

Un peu de reve dans ce monde de brutes : AMD annonce un chip ARM 64-bit. Ca serait pour le deuxieme semestre 2014.

[Alexko]

Un peu de reve dans ce monde de brutes : AMD annonce un chip ARM 64-bit. Ca serait pour le deuxieme semestre 2014.

Dommage qu'il n'y ait qu'une "comparaison" avec le S1200 parce que Seattle se retrouvera plutot confronte a S1200-v2 a base de Silvermont qui ne devrait pas jouer dans la meme categorie que son avo(r)ton de frere.

?

La comparaison avec le S-1200 est pour l'Opteron-X, à base de Jaguar, et déjà disponible.

[newbie06]

?

La comparaison avec le S-1200 est pour l'Opteron-X, à base de Jaguar, et déjà disponible.

De quoi tu parles ?

[Foudge]

Test d'AnandTech : Snapdragon 800 (MSM8974) Performance Preview
http://www.anandtech.com/show/7082/s...lopment-tablet

[Alexko]

Petite comparaison avec Tegra 4 ici : http://arstechnica.com/gadgets/2013/...mely-fast-gpu/

J'attends de voir les mesures de consommation, mais ça s'annonce plutôt très bien pour Qualcomm.

[newbie06]

Petite comparaison avec Tegra 4 ici : http://arstechnica.com/gadgets/2013/...mely-fast-gpu/

Dommage qu'ils n'aient pas mis le K900 dans les benchmarks

Je suis un peu decu niveau CPU, mais niveau GPU rien a dire !

J'attends de voir les mesures de consommation, mais ça s'annonce plutôt très bien pour Qualcomm.

Y'a un slide marketing a ce sujet sur Anandtech : http://images.anandtech.com/doci/708...ormance400.png. Mais oui va falloir attendre des mesures independantes sur de vrais devices.

[newbie06]

nvidia est tout enerve :
- CUDA for ARM is available
- les drivers 319 ARM Linux ont les memes possibilites que pour les autres archis (je sais pas pourquoi ils mettent le pluriel, y'a qu'une autre archi nan ? ).

[Møgluglu]

Ça plus la (nouvelle) annonce de vendre l'IP Kepler sous licence... : http://blogs.nvidia.com/blog/2013/06...usiness-model/

On a un ou deux Carma qui trainent chez nous, il faudrait que je trouve le temps de jouer avec un jour...

[newbie06]

Monde de merde :

TARGET_arm_release_CFLAGS :=  -O2 \
                              -g \
                              -DNDEBUG \
                              -fomit-frame-pointer \
                              -fstrict-aliasing    \
                              -funswitch-loops     \
                              -finline-limit=300

TARGET_thumb_release_CFLAGS := -mthumb \
                               -Os \
                               -g \
                               -DNDEBUG \
                               -fomit-frame-pointer \
                               -fno-strict-aliasing \
                               -finline-limit=64

Le jeu du jour : trouver d'ou ca sort et pourquoi ca me gave

[Møgluglu]

Le code ARM doit respecter les règles d'aliasing strict, mais pas le code en mode Thumb sous Android ?

[newbie06]

Le code ARM doit respecter les règles d'aliasing strict, mais pas le code en mode Thumb sous Android ?

Tu y es presque : c'est le NDK et y'a pas que l'aliasing strict qui change. Ca optimise... pour la taille Quand on pense que c'est le defaut...

[Møgluglu]

C'est choquant ? À partir du moment où on compile en mode Thumb, c'est qu'on veut optimiser pour la taille et que les perfs sont secondaires, non ?

[newbie06]

C'est choquant ? À partir du moment où on compile en mode Thumb, c'est qu'on veut optimiser pour la taille et que les perfs sont secondaires, non ?

Ca pourrait se defendre si ce n'etait pas le mode de compilation release par defaut.

[Møgluglu]

Ah d'accord, Thumb est le mode par défaut.

Il va falloir t'y faire, tu développes une belle microarchi optimisée pour courir un marathon, mais les gens qui l'achètent la font marcher avec les deux jambes dans le plâtre.

En fait, Thumb, c'est le mode i386 legacy pour ARM...

[newbie06]

Explication du business model ARM : http://www.anandtech.com/show/7112/t...ss-model-works

Dans les jours qui viennent on devrait voir plus d'informations sur Cortex-A12 sortir.

[newbie06]

Allez hop une petite analyse sur AnTuTu. On ne va pas dire que la conclusion me surprend ; ce benchmark est une daube à éviter. Maintenant reste à savoir pourquoi soudainement ce benchmark s'est mis à favoriser outrageusement Intel : incompétence ou volonté délibérée ?

Enfin bref, j'espère que ça va permettre de lancer une opération nettoyage dans le monde des benchmarks. Même si François Piednoel me hérisse le poil au plus haut point, il a raison : les benchmarks devraient avoir leurs sources accessibles.

[newbie06]

Allez hop une petite analyse sur AnTuTu. On ne va pas dire que la conclusion me surprend ; ce benchmark est une daube à éviter. Maintenant reste à savoir pourquoi soudainement ce benchmark s'est mis à favoriser outrageusement Intel : incompétence ou volonté délibérée ?

Plus d'explications techniques : http://forums.anandtech.com/showthread.php?t=2330027

Il est trop fort cet icc

[Møgluglu]

Et en face, il y a l'histoire de Geekbench qui est compilé en mode IEEE-754 chez Intel mais qui tournerait sur l'ersatz de virgule flottante qu'est Neon chez ARM. C'est vrai ? (je lis pas couramment le VFP/Neon)

[newbie06]

Et en face, il y a l'histoire de Geekbench qui est compilé en mode IEEE-754 chez Intel mais qui tournerait sur l'ersatz de virgule flottante qu'est Neon chez ARM. C'est vrai ? (je lis pas couramment le VFP/Neon)

Non du tout, le mec de Geekbench n'a pas utilisé NEON. Si ça tombe il a même laissé les flags que je montre ci-dessus, ce qui expliquerait l'absence totale d'unrolling.

De toute façon, cette histoire de dénormaux ne changerait rien au fait que même un Cortex-A9 à 1.4 GHz est aussi rapide qu'un Z2580 à 2.0 GHz sur les benchmarks entier en mono thread

[Møgluglu]

Non du tout, le mec de Geekbench n'a pas utilisé NEON. Si ça tombe il a même laissé les flags que je montre ci-dessus, ce qui expliquerait l'absence totale d'unrolling.

OK, donc là le mec d'Intel se plaint que Geekbench mette en évidence leur gestion pourrie des sous-normaux et que le benchmark ne soit pas réécrit pour les avantager (en sous-entendant que violer IEEE-754 est le "normal setup").

(Qu'il dise que le développeur soit d'accord avec lui est plus inquiétant. Ils doivent vraiment avoir des bons moyens de persuasion. )

[newbie06]

OK, donc là le mec d'Intel se plaint que Geekbench mette en évidence leur gestion pourrie des sous-normaux et que le benchmark ne soit pas réécrit pour les avantager (en sous-entendant que violer IEEE-754 est le "normal setup").

(Qu'il dise que le développeur soit d'accord avec lui est plus inquiétant. Ils doivent vraiment avoir des bons moyens de persuasion. )

Je pense plutôt que les deux s'entendent pour dire que le but n'étant pas de mesurer la perf des dénormaux, il faudrait corriger le data set et/ou les boucles en cause ; il ne s'agirait pas de passer en FTZ.

Enfin ça c'est mon côté bisounours qui me fait penser que ce n'est pas une tentative de truander encore hein

[Møgluglu]

L'argument que le dataset n'est pas représentatif des calculs faits dans les SPEC la vraie vie est certainement valable. Mais je comprends qu'il propose aussi explicitement de changer le mode FPU :

Geekbench is interesting: you look at the results, and the main “unflattering” results are in a few sub-benchmarks, where the IA version is set up to handle denorms precisely, and the input dataset is configured to be 100% denorms. This is not normal FP code, not a normal setup, and possibly not even a apples-to-apples comparison to how ARM is handling these numbers.

Mais bon, il a peut-être juste voulu dire que les dénormaux ne sont pas normaux.
(désolé)

[newbie06]

Ben la FP ARM est aussi mise en handling précis (enfin pas en FTZ), je viens de vérifier sur un run complet: par défaut Android ne passe pas en FTZ, et Geekbench ne le fait pas non plus. Donc égalité, sauf qu'après ptet un des deux lit plus de dénormaux par manque de bol vu la suite:

http://forums.anandtech.com/showpost...0&postcount=46

Two of the Geekbench 2 floating point workloads (Sharpen Image and Blur Image) have a fencepost error. This error causes the workloads to read uninitialized memory, which can contain denorms (depending on the platform). This causes a massive drop in performance, and isn't representative of real-world performance.

Ca sera fixé dans la version 3 prévue pour août.

A noter aussi que l'auteur m'a confirmé qu'il avait laissé les flags par défaut, donc il a optimisé pour la taille pour ARM. Il va changer ça aussi pour la v3

[Alexko]

A noter aussi que l'auteur m'a confirmé qu'il avait laissé les flags par défaut, donc il a optimisé pour la taille pour ARM. Il va changer ça aussi pour la v3

Le fait que cette situation soit si générale d'une part, et que les développeurs soient d'autre part (apparemment) enclins à la corriger suggère un petit problème de communication chez ARM.

[Møgluglu]

A noter aussi que l'auteur m'a confirmé qu'il avait laissé les flags par défaut, donc il a optimisé pour la taille pour ARM. Il va changer ça aussi pour la v3

Nouveau scandale dans l'affaire des benchmarks truqués ! Les développeurs de geekbench auraient subi des pressions pour avantager les processeurs ARM.

[newbie06]

Le fait que cette situation soit si générale d'une part, et que les développeurs soient d'autre part (apparemment) enclins à la corriger suggère un petit problème de communication chez ARM.

C'est plutot que les dev tout habitues qu'ils sont a Visual Studio ne savent pas coller les options qu'il faut a un compilo. J'ai meme vu un type raconter qu'en FP ARM etait mauvais parce que son app Android ramait ; j'ai regarde son code et il avait force le mode sim soft de FP de gcc

Il y a aussi eu historiquement des bugs dans gcc qui ont depuis longtemps disparu.

Franchement je ne vois pas ce qu'ARM peut faire, hormis faire passer le message (j'ai essaye avec le type ci-dessus, mais j'ai jamais eu de nouvelle).

[fefe]

L'essentiel du code qui tourne sur les x86 actuels est compile avec -g et sans -O . En 30 ans ca n'a jamais change, j'ai jamais reussi a gagner cette bataille .

[newbie06]

L'essentiel du code qui tourne sur les x86 actuels est compile avec -g et sans -O . En 30 ans ca n'a jamais change, j'ai jamais reussi a gagner cette bataille .

Moi j'espere bien changer ca et gagner quelques batailes est surement possible ! Pour la guerre, aucun espoir

En tout cas, la bataille AnTuTu est partiellement gagnee :
http://thetechjournal.com/electronic...-revised.xhtml
Meme si c'est toujours en -Os sur ARM, c'est deja ca...