[Discussion] La technique et les smartphones/tablettes (ex-topic Cortex A15)

[Alex98]

Il y a effectivement les Atom basé sur des cores Silvermont qui doivent arriver cette année en 22nm mais les Airmont en 14nm ce sera pour 2014.

D'ailleurs, si Samsung ne dispose pas d'une chaine de production en 14nm FinFET au même moment je ne donne pas cher d'ARM dans le haut de gamme.

[HoM3r17]

Surtout quand on voit le rapport perf/watt des SoC qui utilisent déja actuellement, ils ont fait un travail assez énorme ... ce qui me fait chier c'est pour la concurrence, ils ont déja mis AMD dans le fossé, et ils sont en train de revenir sur les fondeurs qui utilisent les architectures ARM ... et comme j'ai une dent contre Intel ca me plait pas trop ...

Tiens justement quand on parle du loup cet article viens de paraitre, ca sera reservé aux tablettes Windows 8, mais c'est un bon début : http://www.comptoir-hardware.com/actus/processeurs/20649-amd-devoile-quelques-chiffres-sur-ses-apu-temash-a4-1200-et-a6-1450-pour-tablettes.html

[Alex98]

Disons aussi que le véritable soucis c'est que les fondries mettent de plus en plis de temps à copier les avancées d'Intel en matière de process de gravure.

A termes, c'est TSMC qui est menacé si les volumes de commandes diminuent à cause de la concurrence d'Intel. Et je doute que l'un des acteurs du secteur accepte de financer la R&D de TSMC comme AMD l'a fait (le fait) avec Global Foundry.

Il reste toutefois un espoir pour TSMC et (surtout) Global Foundry (et donc AMD) avec le FD-SOI qui pourrait permettre à cours termes de conccurrencer Intel à moindre coût... si ST ne ment pas sur son process...

Tiens justement quand on parle du loup cet article viens de paraitre, ca sera reservé aux tablettes Windows 8, mais c'est un bon début : http://www.comptoir-hardware.com/actus/processeurs/20649-amd-devoile-quelques-chiffres-sur-ses-apu-temash-a4-1200-et-a6-1450-pour-tablettes.html

Tu m'étonne que ça soit réserver aux tablettes. L'enveloppe thermique en usage est terriblement haute :s

[HoM3r17]

Tu m'étonne que ça soit réserver aux tablettes. L'enveloppe thermique en usage est terriblement haute :s

Apres entre les chiffres sur une Devboard et la réalité il y a souvent une différence, sur la devboard tout est poussé au max pour donner confiance aux partenaires potentiels non ?

[Alex98]

Ça dépend des constructeurs. Qualcomm le fait effectivement. Nvidia aussi à une tendance à faire ça.

Samsung refourge des devboards avec des drivers d'il y a 6 mois et bourré de bug... TI ne produisait que des SoC de tests il me semble.

[lolobarjo]

C'est clair que Samsung niveau driver et source, c'est carrément pas leur fort

Envoyé avec mon SGS2 Citizy accro à CM10.1 -> Tapatalk

[Alex98]

Et encore t'es généreux parce que ne pas souhaiter donner à la communauté du code propriétaire qu'on juge être un avantage pour la marque (genre les algo de post traitement de l'APN, ou la gestion réseau), c'est une chose... mais fourger de la m**** au devs pro c'est quand même grave lol

[lolobarjo]

Carrément, sur ce coup Samsung ont fait leur grosse p*te c'est rageant. Je comprend leur comportement alors que Qualcomm et TI eux ont aucun souci a lâcher des codes fiable. C'est l'une des choses qui m'avais fait dire que j'allais boycotté Samsung mais c'est chose impossible vu que se sont les seul a mettre de l'amoled et qui sont supporter par cyano (qui n'était pas le cas de Motorola jusqu'à se matin)

Envoyé avec mon SGS2 Citizy accro à CM10.1 -> Tapatalk

[Infernus]

Samsung essaie de garder ses SoC pour lui, ou alors les livrer avec une génération de retard, enfin c'est mon impression.

Maintenant pour revenir sur le sujet de Intel, je pense qu'ils doivent quand même appréhender la suite des évènements.

Les A15 délivrent des performances assez folles et ce n'est que la première révision, au prix d'une consommation bien plus élevée que les A9 cependant.

Intel a du beau matos sous le pied, mais il faudra voir ce qu'ils vont en faire.

Par contre là où Intel est en retard ('fin dans les Atom actuels, type Razr i), c'est sur la partie graphique.

Ils ont peut être de quoi rivaliser avec PowerVR mais ça ne sera pas avec leur HD4000.

A côté de ça ils vont devoir mettre le paquet sur Tizen aussi, ça risque de leur coûter bonbon vu l'état actuel de l'interface (et je ne sais pas ce que ça vaut en dessous)

[Alex98]

Pour le moment, je ne pense pas qu'ils aient à craindre grand chose.Les Intel Z2580 affiche des performances CPU similaires aux S600 (de ce qu'on a pu voir avec le K900) tout en aillant moitié moins de core. Ce qui signifie qu'à priori les performances de l'architecture sont bien meilleures. Ils passent aussi à un PowerVR SGX544MP2 @ 533Mhz côté GPU ce qui devrait leur assurer des perfs GPU supérieures aux Adreno 320.

Question consommation, ils passent aussi du 40nm au 32nm HKMG alors qu'ils avaient déjà une consommation similaires aux S4 Play en 40nm. En fin d'année le passage au 22nm va leur permettre de monter en fréquence ou d'augmenter le nombre de cores.

Par contre, à mon avis Tizen n'a pas d'avenir. Il paraît clair que la bataille pour la 3eme place va se jouer entre MS et BB

[Infernus]

Si tu dis vrai et que Intel est bel et bien au même niveau que les constructeurs ARM pour le moment ça risque de faire mal.

Mais dans l'autre sens que celui que je pensais.

D'autant plus que comme tu l'as fait remarquer (il me semble), Intel a de l'avance sur les prochains process de gravure...

C'est marrant l'évolution de l'Atom, à l'origine c'était un simple coeur pour une archi multi-coeur. Et maintenant ça deviens ce qu'Intel voulait que ça soit depuis l'abandon du projet.

Perso j'espère que Tizen arrivera à quelque chose avec Samsung et Intel derrière, par contre ils ont intérêt à nous sortir une interface digne de ce nom, parce que pour le moment c'est naze...

Je commence à en avoir marre du java sur Android, et je trouve W8 totalement creux et inintéressant. Et puis BB10 limité aux smartphones BB...

[Alex98]

On a pas grand chose mais on sait que le K900 (Atom 2 core) tape du 10k en CPU sur Antutu contre 11k pour les One ou G Pro (4 Cores S600). Et les X86 gardent encore et toujours l'avantage d'une bien meilleure gestion de la RAM (8k contre 4-5k pour les S600).

Et le pire c'est qu'on est sur une architecture recyclé. En fin d'année, on devrait voir arriver de nouveaux cores pour les Atoms.

Et je partage ton dégoût pour le java et les idées étranges des ingénieurs de Google. Je ne comprends pas leur volonté de persister dans cette direction alors qu'ils sont les seuls à le faire.

Modifié 3 mars 2013 par Alex98

[Infernus]

C'est bien ce que j'avais remarqué en testant le Orange by Intel d'un pote (nom de m**** d'ailleurs), les performances en single-thread sont vraiment épique.

Mais va falloir que Google se sorte les doigts du c** pour sortir des roms x86.

Je cherche toujours quelle mouche a piqué les devs d'Android pour utiliser du java sur un appareil mobile.

Sachant que c'était pour tourner sur les vieux Qualcomm 528Mhz de nos débuts...

Et faut quand même avouer que vouloir balancer de l'interprété là dessus c'est quand même pas vraiment malin...

Modifié 3 mars 2013 par Infernus

[Alex98]

En fait c'est Intel qui s'occupe du portage.

D'ailleurs c'est la partie amusante de l'histoire. A l'origine, le choix du Java a été motivé par la volonté de pouvoir supporter un grand nombre d'architectures sans soucis puisque c'est l'interpréteur qui adapte le code à l'architecture.

Sauf que dans la pratique l'AOSP de Google ne supporte pas plus de jeux d'instructions qu'iOS et que c'est aux concepteurs de SoC de faire tout le boulot d'adaptation de la dalvik machine et du kernel à leur hardware.

Pire, la solution de Google ne rend pas pour autant l'offre software homogène. Google a même dû mettre en place un système de telechargement pour le market qui envoie la bonne apk en fonction du HW.

[Infernus]

Je comprends bien l'intérêt du java, mais avec la puissance limité de l'époque le choix me paraît très discutable.

C'est marrant ce que tu dis sur la fin, parce que lorsque l'on "compile" les apk, on n'a qu'une version de cet apk.

Google recompile derrière ?

[Alex98]

Je ne pense pas que Google recompile. Ce sont les devs qui fournissent eux mêmes plusieurs versions de l'app en fonction du GPU ou éventuellement d'autres caractéristiques (résolution? ).

Autre fois c'était fait au premier démarrage de l'app (comme souvent dans les jeux). Maintenant le market le fait aussi.

De fait, je pense que je me suis mal exprimé car j'imagine que l'Apk reste la même. Ce sont probablement les autres fichiers qui changent.

[Infernus]

Effectivement ça me rappelle quelque chose.

Il est possible d'uploader plusieurs apk, faudrait que je regarde selon quels filtres on peut faire ça.

[Alex98]

Notons tout de même qu'on peut faire du Natif sur Android. Il y a même un NDK il me semble.

En fait c'est surtout Google qui tient au Java.

[Infernus]

J'ai regardé pour faire du natif... d'après ce que j'ai compris c'est uniquement des bouts de code.

Il faut wrapper du C++ dans du java...

[Alex98]

Je ne sais pas du tout vu que je n'ai jamais vraiment regardé mais si c'est le cas c'est vraiment n'importe quoi.

Par ailleurs, je vérifierai tout à l'heure, mais il me semble qu'on perd environ 50% de perfs à cause du java

[Infernus]

Tout dépend les tests, c'est aussi le système de GC de java qui est atroce (si Android utilise le même)

2 zones mémoires indépendantes, lorsque l'on fait appel au GC, les instances vivantes sont recopiées dans la seconde mémoire, la première est flush et les 2 sont échangées (la seconde devient la principale et la principale la seconde).

[Alex98]

On en avait parlé donc tu connais mon point de vu sur le GC en Java. C'est la principale raison pour laquelle j'ai horreur du Java.

[lolobarjo]

C'est quoi le GC ?

Envoyé depuis ma Nexus 7 se gavant à coup de CM10.1 -> Tapatalk HD Bêta

[Alex98]

Le Garbage Collector. Ce qui s'occupe de libérer la mémoire inutilisé.

[Infernus]

J'espère qu'un jour on pourra balancer du vrai natif directement...

Donc d'après ce que je viens de lire, il faut wrapper le tout dans une NativeActivity.