›

L'iPad est-il une bête de course ?

muqaddarmuqaddar Administrateur
23:06 modifié dans Actualités #1
Que conclure de ce genre de tests ?
http://www.macgeneration.com/news/voir/192532/imovie-l-ipad-bat-macbook-pro-et-mac-pro

On peut se poser la question, encore plus aujourd'hui, de l'optimisation logicielle ?

Réponses

  • cyranocyrano Membre
    23:06 modifié #2
    ca doit etre compilé avec LLVM 2  :D
  • SystemSystem
    23:06 modifié #3
    J'aimerai vraiment qu'on m'explique comment une appli compilée avec LLVM 2 ira plus vite qu'avec n'importe quel autre compilateur...
  • muqaddarmuqaddar Administrateur
    23:06 modifié #4
    dans 1300194032:

    J'aimerai vraiment qu'on m'explique comment une appli compilée avec LLVM 2 ira plus vite qu'avec n'importe quel autre compilateur...


    Moi aussi, mails il disait ça avec de l'humour. ;)
  • AliGatorAliGator Membre, Modérateur
    23:06 modifié #5
    Je dis ça au hasard car je connais pas le détail d'implémentation, mais si LLVM2 a des algos d'analyse de code et d'optimisation plus poussés, ou une architecture plugin plus structurée, permettant des modules dédiés à  chaque langage ainsi qu'à  chaque architecture matérielle, ça parait logique qu'elle puisse optimiser encore plus le code machine généré, non ?

    (Bon bien sûr pas au point que ça transcende les perfs comme sur le comparatif iPad/MBP ici, mais bon ça c'était pour la boutade)
  • DrakenDraken Membre
    mars 2011 modifié #6
    L'optimisation matérielle des puces doit pas mal aider ..
  • muqaddarmuqaddar Administrateur
    23:06 modifié #7
    dans 1300194679:

    L'optimisation matériel des puces doit pas mal aider ..


    Hum.
    Peut-on imaginer qu'Apple optimise l'A4 et l'A5 pour l'objective-C ou le C (parce que bon, tout ce qui est traitement video, ça doit être du C pur...) ?
  • DrakenDraken Membre
    23:06 modifié #8
    Pour l'Objective-C non. Mais pour le framework CocoaTouch, oui !

  • zoczoc Membre
    mars 2011 modifié #9
    dans 1300194032:

    J'aimerai vraiment qu'on m'explique comment une appli compilée avec LLVM 2 ira plus vite qu'avec n'importe quel autre compilateur...

    Parce que tous les compilateurs ne génèrent pas le même code, et qu'en l'occurrence, la maturité de gcc, qui est un avantage en terme de stabilité, est au contraire un inconvénient en terme d'implémentation des nouvelles techniques d'optimisation du code (l'architecture du GCC est ancienne, pas très modulaire et rend tout ajout acrobatique).

    Pour LLVM2, ils sont reparti d'une feuille blanche, avec comme but premier la performance (et au détriment de la stabilité, car oui il y a des bugs dans LLVM2).

    Bon, sinon, les processeurs A4 et A5 sont dessinés à  partir des implémentations "type" d'ARM, par conséquent il n'y a pas d'optimisation spécifique à  Apple dedans. Par contre il est évident que le runtime Objective-C est "tuné aux petits oignons" pour le processeur, comme c'est déjà  le cas de ce même runtime pour processeur intel (le routage des messages est écrit directement en assembleur, assez intéressant à  lire, la version x86_64 se trouvant ici).
  • muqaddarmuqaddar Administrateur
    23:06 modifié #10
    dans 1300207251:

    Bon, sinon, les processeurs A4 et A5 sont dessinés à  partir des implémentations "type" d'ARM, par conséquent il n'y a pas d'optimisation spécifique à  Apple dedans. Par contre il est évident que le runtime Objective-C est "tuné aux petits oignons" pour le processeur, comme c'est déjà  le cas de ce même runtime pour processeur intel (le routage des messages est écrit directement en assembleur, assez intéressant à  lire, la version x86_64 se trouvant ici).


    Merci pour ces précisions.
    Donc on optimise bien un runtime pour un processeur. Et pas l'inverse...

    Cela dit, que penses-tu de ces tests de performance ? Les doit-on du coup en partie à  LLVM2 par exemple ? A une optimisation du code de bas niveau de l'application ? Ou à  d'autres choses ? Ou à  tout ça cumulé ?
  • AliGatorAliGator Membre, Modérateur
    23:06 modifié #11
    Tiens, j'ai regardé, c'est intéressant de voir que par exemple d'après ce code, quand on envoie un message à  'nil', il va essayer de de l'envoyer à  un receiver de remplacement (ce qu'il appelle le "nil receiver") et seulement si ce "nil receiver" est nil lui aussi, alors il retourne zéro... 
    // message sent to nil: redirect to nil receiver, if any<br />LMsgSendNilSelf:<br />	movq	__objc_nilReceiver(%rip), %a1<br />	testq	%a1, %a1		// if (receiver != nil)<br />	jne	LMsgSendReceiverOk	//&nbsp;  send to new receiver

    .data<br />// Substitute receiver for messages sent to nil (usually also nil)<br />// id _objc_nilReceiver<br />.align 4<br />.globl __objc_nilReceiver<br />__objc_nilReceiver:<br />	.quad&nbsp;  0
    Bon là  vu l'implémentation, ce nilReceiver vaut justement 0 / NULL / nil, mais il y aurait donc une ouverture à  la possibilité de rediriger plutôt tous les messages envoyés nil à  un autre objet, en remplaçant ce nilReceiver par un objet global ? Ca peut être intéressant comme truc je trouve, par exemple pour catcher/logguer ces envois à  nil involontaires ?
  • chkdskschkdsks Membre
    23:06 modifié #12
    Comme c'est de l'encodage, je pense que c'est une optimisation sur la partie GPU de l'A5 qui est certainement mieux exploitée que les puces graphiques dans les Mac, mais pourquoi....  :o
  • muqaddarmuqaddar Administrateur
    23:06 modifié #13
    dans 1300225929:

    Comme c'est de l'encodage, je pense que c'est une optimisation sur la partie GPU de l'A5 qui est certainement mieux exploitée que les puces graphiques dans les Mac, mais pourquoi....  :o


    Sauf que c'est plus rapide sur l'A4 aussi...
  • chkdskschkdsks Membre
    mars 2011 modifié #14
    Effectivement ;) Apple a du faire des optimisations dans les frameworks CocoaTouch avec des parties clefs en assembleur et utiliser très fortement l'architecture PowerVR, ce qui expliquerait les très bons résultats sur l'iPad 1 et encore mieux sur le 2
Connectez-vous ou Inscrivez-vous pour répondre.