Crunchez vos adresses URL
|
Calculez la conso électrique de votre PC
|
Hébergez vos photos
Page 18 sur 21 PremièrePremière ... 8101112131415161718192021 DernièreDernière
Affichage des résultats 511 à 540 sur 613

Discussion: Intel Atom

  1. #511
    Citation Envoyé par Møgluglu Voir le message
    Je suppose que gcc doit commencer par désactiver SSE2 sur Atom. .
    ssemath est en revanche critique d'apres mes mesures. Je ne sais pas si ca utilise SSE2, mais c'etait sur du code FP.


    Wabon?...
    Bravo, j'ai plus qu'à me mettre à l'ARM (j'ai encore le temps d'ici à ce que ces trucs sortent).
    http://www.linuxfordevices.com/c/a/N...ed-initiative/

    D'un autre cote c'est facile maintenant : il suffit d'apprendre x86 et ARM, ca couvre suffisamment de marches

  2. #512
    Citation Envoyé par newbie06 Voir le message
    Par ailleurs, contrairement a ce que tu dis, un processeur in order profitera mieux d'un bon scheduling de code, qu'un OoOE. Il est donc relativement important de bien decrire les pipes et les diverses contraintes.
    Je dis pas le contraire, je dis que le -march=core2 préconisé jusqu'à présent me parait foireux à cause du fait qu'il n'y a pas d'OOO donc mécaniquement pas les mêmes optis. D'un autre coté, -march=pentium pour avoir de l'inorder, ça sert à rien non plus puisque 64bits, SSE, SSE2, SSE3, SSE4, HT, ... sont passé par là.

    C'est juste que ça m'a traversé l'esprit hier soir, quand je compilais postgresql en -O3 (option dans le make config en clair) sur mon serveur quad core
    Spoiler Alert!
    à base de D510 donc dual core atom avec HT
    Suite à une suggestion, je vais utiliser cette signature pour des canards en manque de ranking pro. Ou des quotes idiots.

  3. #513
    La plupart des optims de compilation sont pour le frontend, pas pour l'OOO. Le frontend du Core2 est 4-wide, celui de l'Atom 2-wide avec des restrictions differentes sur ce qui peut etre fetch en parallele. L'alignement optimal des instructions est different. Pour un core2 la seule raison de reordonnancer les instructions est d'ameliorer la bande passante du frontend, a moins de decaller tes instructions d'une 100aine d'instructions, ce que les compilos font assez rarement...
    Pour Atom a l'inverse il faut ordonnancer pour maximiser la vitesse du frontend, et aussi minimiser les dependances d'execution.
    fefe - Dillon Y'Bon

  4. #514

  5. #515
    60K LE, 312 multiplieurs, 4 PLL… Le FPGA est manifestement un Arria II GX 65 (EP2AGX65) :
    http://www.altera.com/products/devic...iigx-index.jsp
    [Edit: en fait y'a déjà un lien depuis la page d'Intel, c'est pas du jeu]

    C'est loin d'être un monstre, mais ça doit être suffisant pour le marché visé.
    Il est relié au SoC Atom par un PCIe X1.

    Si on trouve facilement des cartes de dev pas trop cher, ça peut être un jouet amusant.

  6. #516
    Question de noob total : c'est quoi l'avantage en terme de dév par rapport à un xilinx avec powerpc (en-dehors de x86 vs ppc ) ?

  7. #517
    L'avantage, c'est que tu peux booter ton Atom d'abord pour qu'il configure lui-même le FPGA ensuite (ça sera le cas avec les ARM-Xilinx aussi).

    Alors que pour utiliser les PowerPC des Virtex, il faut commencer par programmer le FPGA, ce qui les rend assez useless…
    Le PowerPC marche un peu comme un coprocesseur du FPGA. Bien sûr, c'est le contraire qu'on veut, et les constructeurs ont enfin compris ça.

  8. #518
    Ha mince je croyais que les xilinx ppc pouvaient faire ça ! Alors oui c'est en effet un gros avantage pour l'Atom.

  9. #519
    Vous avez des détails sur oak trail?
    Niveau perf/watt, fréquence max etc.

    Visiblement c'est vendu en bundle avec meego, ça va être fun ce qui va débarquer bientôt dans nos chaumières!

  10. #520
    Citation Envoyé par Møgluglu Voir le message
    Si on trouve facilement des cartes de dev pas trop cher, ça peut être un jouet amusant.
    Dispo en volume vers juin 2011. Prévoir entre 1 et 2 reins pour une carte de dev.
    Dernière modification par Møgluglu ; 19/12/2010 à 18h29.

  11. #521
    Breaking news (enfin pour moi) : Anand Chandrasekher quitte Intel. Fallait pas qu'il se moque de Warren East

  12. #522
    La news date d'aujourd'hui donc c'est breaking pour tout le monde
    fefe - Dillon Y'Bon

  13. #523
    Personne pour parler d'Oak Trail qui n'est toujours pas un SoC et qui a une génération de retard sur le GPU face à l'iPad 2 ?
    J'ai l'impression qu'il arrive un peu tard avec pas grand-chose de sexy. Cedar Trail ptet avec un vrai CPU ?

  14. #524
    Honnetement il n'y a pas grand chose a discuter sur les "SOC" a base d'atom, a part la liste de fonctionnalites manquante par rapport aux competiteurs .
    fefe - Dillon Y'Bon

  15. #525
    J'ai toujours espoir d'avoir raté un truc, je suis fan de la concurrence, mais là
    Bon, je retourne tailler mes TLB alors.

  16. #526
    Il faut encore attendre un peu, vu les cycles de developement et le fait que un bon SOC n'etait pas vraiment quelque chose de fondamental a avoir il n'y a ne serait-ce que 3-4 ans (on va dire avec les debuts de l'iphone), il reste encore un peu a attendre avant de voir arriver quoi que ce soit qui ne soit pas un gros hack pas terrible... Et puis si tu regardes le dernier "evenement" du cote d'Atom c'etait Anand qui partait a la recherche de nouvelles opportunites .
    fefe - Dillon Y'Bon

  17. #527

  18. #528
    Il ne reste plus qu'à espérer qu'Intel arrivera à sortir des drivers qui fonctionnent, et pas seulement pour Windows comme le dit l'article, mais aussi pour Linux, voire Android.

    En tout cas, intéressant de voir qu'Intel semble abandonner son IGP même sur le segment netbook/nettop.

  19. #529
    J'en doute, étant possesseur d'un Poulsbo Z500 dans le netbook... Y a jamais eu aucun pilotes ou presque.
    M'enfin on verra bien.
    crève boulon

  20. #530
    Si l'on en croit http://www.phoronix.com/scan.php?pag...item&px=OTQyNg

    Intel just hired a boatload of new Intel OSTC (Open-Source Technology Center) developers with lots of mobile experience.

    When Nokia announced they would be banding together with Microsoft for their smart-phone platform and effectively doing away with MeeGo, many viewed this as a great loss for Linux. While Nokia has abandoned Linux for their phones and tablets, it was to Intel's gain. The dozens (circa 80) of developers Intel has just recently hired for the OSTC are former Nokia developers out of Finland. There's a couple well-known names in the mix.

    These developers to be starting soon for Intel for their open-source group were working on MeeGo / Maemo at Intel. Several of these developers have graphics expertise and worked on the PowerVR Linux blobs; the Nokia N900 has a PowerVR SGX530 core, for example. What these developers will be doing for Intel OSTC though isn't publicly known at this point, but should emerge in the coming months. Regardless of whether it's for an open-source PowerVR driver or not, the work should be interesting.
    Donc, tout espoir n'est pas perdu

    We should treat all the trivial things of life seriously, and all the serious things of life with sincere and studied triviality.[Oscar wilde]

    There is no such thing as a moral or an immoral book. Books are well written, or badly written. That is all.[Oscar wilde]

    No artist is ever morbid. The artist can express everything.[Oscar wilde]

  21. #531
    Je ne pense pas qu'Intel va répéter les erreurs passées sur ces drivers. Oui, je suis du genre naïf, je crois toujours que les gens apprennent de leurs conneries.

    Puis comme le fait remarquer braoru, y'a MeeGo maintenant, ils n'ont plus vraiment d'autre choix que de faire marcher leur GPU avec un kernel Linux

  22. #532
    Ayé, la nouvelle micro architecture Atom est annoncée pour 2013. Silvermont est son petit nom et ça sera évidemment du 22nm.

  23. #533
    Oui, ca a mis du temps a venir, mais c'etait vraiment necessaire (tic,tic,toc enfin).
    fefe - Dillon Y'Bon

  24. #534
    Premiers tests independants de Medfield :
    http://semiaccurate.com/2012/04/26/h...rk-as-a-phone/
    http://www.anandtech.com/show/5770/l...medfield-phone

    A noter qu'une partie de l'analyse de Charlie est fausse : AnTuTu a une version native x86, donc l'emulateur ARM n'est pas implique.

    Je trouve les resultats pas mauvais, mais sans plus. Mais en tout cas Intel is in the place

  25. #535
    Oui rien d'epoustouflant, mais ca marche et c'est utilisable (c'est l'essentiel), et sur une version assez ancienne d'Android pour l'instant. Maintenant la competition peut commencer .
    Dernière modification par fefe ; 27/04/2012 à 23h07.
    fefe - Dillon Y'Bon

  26. #536
    Geekbench iPad 4 vs Z2760

    Je suis assez étonné du scaling de certains tests multi-threads sur Clovertrail.

    Par ailleurs, je me demande si le code FP n'a pas été compilé en x87

  27. #537
    Interressant oui. Comme toi je me demande ce qui se passe en FP.
    fefe - Dillon Y'Bon

  28. #538
    Citation Envoyé par fefe Voir le message
    Interressant oui. Comme toi je me demande ce qui se passe en FP.
    Sur un desassemblage de la version Linux 32-bit :
    Code:
    bash-3.2$ wc geekbench_x86_32.txt
      641867  4162868 39113211 geekbench_x86_32.txt
    bash-3.2$ grep '%st' geekbench_x86_32.txt  | wc
       1178    5890   56523
    bash-3.2$ grep xmm geekbench_x86_32.txt | wc
         51     398    2929
    Ca suffit pour dire que c'est du x87 non ? C'est pas comme si je connaissais le x86

  29. #539
    Et côté ARM, c'est de la simple ou double précision ?

  30. #540
    Citation Envoyé par Møgluglu Voir le message
    Et côté ARM, c'est de la simple ou double précision ?
    Aucune idée, j'ai pas de moyen de récupérer les packages.

Page 18 sur 21 PremièrePremière ... 8101112131415161718192021 DernièreDernière

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •