Un Raspberry Pi 3 peut être deux fois plus rapide qu’un Mac
Il n’y a pas que les PC assemblés avec soin qui sont plus rapides que les Mac, un simple RaspBerry Pi 3 vendu à peine 50 € peut terminer une tâche deux fois plus vite qu’un Mac portable ! Bon, autant le dire d’emblée, ce n’est pas systématiquement le cas. C’est même encore un euphémisme, puisque ce n’est le cas que dans un seul cas très précis, mais la comparaison mise en avant sur le blog des créateurs du mini-ordinateur reste impressionnante.
Le RaspBerry Pi 3 est un ordinateur destiné aux bricoleurs, mais aussi à l’éducation. Et l’un des objectifs de cette version est d’être parfaitement optimisée pour Scratch, un langage dynamique imaginé par le MIT pour apprendre le développement aux enfants. On peut l’utiliser pour créer des petits jeux et programmes dès l’âge de huit ans.
Et comme ces deux vidéos le prouvent, le RaspBerry Pi 3 fait deux fois mieux qu’un MacBook Pro doté d’un Core i5 et sorti en 2011. Certes, cela prouve surtout que Scratch est bien mieux optimisé sur le mini-ordinateur que sur l’appareil d’Apple, ce qui n’est pas rien. En théorie, le processeur du portable devrait écraser littéralement celui du Pi 3, mais avec suffisamment de travail, on peut inverser les rôles.
Et même si ce n’est pas utile à la majorité dans le cas de Scratch, un même effort d’optimisation avait été mené par le passé pour le media-center Kodi, et pour le navigateur web de Gnome, Epiphany. Dans les deux cas, ce travail a permis d’optimiser suffisamment ces logiciels assez lourds pour les faire tourner correctement sur les RaspBerry Pi.
Et puisque l’on évoque ces petits ordinateurs pas chers, la fondation Raspberry a conçu un nouvel accessoire pour accompagner les Pi : une caméra. Ou plutôt, un nouveau modèle qui vient remplacer l’ancienne sortie en 2013. Capteur Sony de 8 mégapixels et toujours 25 $, de quoi enrichir encore son installation avec de l’image.
[MàJ 27/04/2016 10h17] : comme certains lecteurs plus attentifs que l'auteur l'ont noté, il s'agit d'un MacBook Pro, puisque les bordures autour de l'écran sont noires.
C'est la fête des Mac aujourd'hui...
J'aimerais bien qu'il soit possible d'installer Mac OSX sur la framboise... Et que ça tourne tranquillement, pour des trucs d'iTunes...
L'usine à gaz d'iTunes sur Raspberry Pi, quelle vision d'horreur…!
Par contre, on peut très bien le bidouiller comme streamer. Il existe des tas de recettes.
Voici un compte-rendu tout frais d'un amateur averti. Il a utilisé un autre mainboard low-cost, Odroid-C2, mais le soft clé, le player Volumio, marche aussi sur Raspberry. Des images pour le flasher directement sont disponibles en ligne.
http://archimago.blogspot.ch/2016/04/set-up-low-power-linux-audio-player...
Comme quoi avec de l'optimisation on peut faire des miracles, y a qu'à voir Metal qui permet de multiplier par 10 les performances!
Mais le problème de l'optimisation c'est que ça demande du travail.
ça demande du travail, du temps, de la disponibilité et des competences
Un des gros probleme dans le monde du PC ce sont les mensonges d'Intel qui pour vendre ses processeurs a deployé un marketing intensif qui a fait croire que les mecanismes du processeur dispensaient le programmeur d'optimiser son code.
Dans les faits, optimiser un x86 est une vraie horreur car il est quasi impossible de savoir comment le code va etre executé: un x86 c'est plus une machine virtuelle qu'autre chose!
Et puis en commercial, il y a les contraintes de temps, le manque de personnel competent, les objectifs dictés par le marketing et plus par l'ingenierie,... de fait l'industrie informatique s'est calée derriere le modele de Microsoft: on produit de la beta a peine fonctionnel, avec un code le abstrait possible et on patche a tour de bras des que les utilisateurs se plaignent trop.
Dans le monde du RISC (ARM donc), les ingenieurs ont encore la culture de l'optisation et du soft qui ne peut pas etre patché facilement (parce que ARM c'est de l'embarqué a la base et du serveur).
Le Raspberry a cet avantage d'avoir des passionnés competents qui travaillent dessus et sa faible puissance initiale oblige a optimiser. Et puis c'est du RISC, et l'optimisation elle se fait de la conception a la compilation!
Il n'empeche que c'est une grosse claque et pour Apple et pour Intel.
Intel n'est pas responsable de la non optimisation des logiciels, faut pas tout mélanger...
Intel n'a jamais prétendu que optimiser son code ne servait à rien, leur proc le faisant tout seul.
D'ailleurs ils vendent tout une suite d'outils dédiés à la recherche des goulots d'étranglements, au cache miss, aux délais IO, etc.
Par contre Intel bosse depuis des années pour que leurs processeurs ajustent *dynamiquement* le pipeline d'exécution (et désormais l'horloge et l'alimentation) pour tenter de booster l'exécution du code.
Ce n'est pas pour autant qu'ils clament que l'optimisation en amont ne sert à rien.
Mais ce n'est pas pour autant que l'optimisation dynamique coté hardware n'a pas un intérêt et qu'Intel ne devrait pas en faire un argument marketing...
L'optimisation, c'est du temps, et le temps c'est ce qui coûte le plus cher de nos jours.
C'est pas la peine d'aller chercher beaucoup plus loin pourquoi l'optimisation n'est pas souvent sérieuse car, dans bon nombre de cas de tous les jours, il est très difficile de justifier le surcoût auprès de ceux qui payent, en particulier pour des développements souvent juger comme éphémères, jetables, ou les prérequis seront tout simplement augmentés, ou les lenteurs seront l'objet d'une correction future (voir une mise à jour) voir un argument marketing de la future version (70% plus rapide...).
On voit donc de l'optimisation que dans 3 grands domaines :
- là où de tout façon même avec optimisation c'est toujours trop lent alors sans optimisation c'est même pas envisageable : calcul scientifique, rendu 3D, etc...
- là où c'est rentable de le faire dès le départ, en gros là où y'a pas vraiment le choix, en gros là ou le matériel est plus limité que la moyenne et ou l'on tente de lui faire faire plus qu'a l'accoutumée. Le monde embarqué, le jeu vidéo innovant, les équipements mobiles...
- là où le temps ne coûte pas de l'argent mais du temps libre : dans les communautés de hobbyistes, de fanas, de puristes, des passionnés, etc. Dont Rasberry Pi.
@ byte_order : Très bonne présentation du problème de l’optimisation.
Par ailleurs, réduire les CPU x86 à du CISC c'est complètement mettre de côté leur architecture type superscalaire en laissant croire que la complexité plus grande du jeu d'instruction les rends fatalement plus lent à les exécuter.
@byte_order
Tu defends le x86 pour contester mon analyse, mais ce que tu avances c'est exactement ce que je dis, minoré de la responsabilité d'Intel.
Le fait est qu'un x86 est une marchine virtuelle, et qu'il est impossible de savoir comment sera executé le code, deja parce qu'il s'agit d'un secret industriel.
Ici on a un exemple très marquant qui casse ton argument: Scratch est optimisé sur processeur ARM, pas sur processeur x86, pourtant dans les deux cas l'interet, les contraintes de temps, d'argent, etc sont les memes. Sauf que d'un coté on a un materiel libre, opensource dont le programmeur a accés et peu maitriser tout de A a Z dans l'autres, il y a une boite noire insondable (le x86)...
@ C1rc3@0rc : « Ici on a un exemple très marquant qui casse ton argument: Scratch est optimisé sur processeur ARM, pas sur processeur x86, pourtant dans les deux cas l'interet, les contraintes de temps, d'argent, etc sont les memes. Sauf que d'un coté on a un materiel libre, opensource dont le programmeur a accés et peu maitriser tout de A a Z dans l'autres, il y a une boite noire insondable (le x86)... »
Ce serait joli si c’était ça. Sauf que ce n’est pas le cas (cf. une de mes réponses à byte_order un peu plus tôt). :-)
Le miracle c'est plutôt de faire moins bien avec un meilleur matos ;-)
Le travail fait sur Raspberry, c'est la normalité.
Toutafé.
Mais, contrairement à l'optimisation, faire un programme lent, c'est très facile ;-)
Là, ce qui semble clair, c'est que le portage de Scratch sur Mac OS X a un gros goulot d'étranglement quelque part...
@ byte_order : « Là, ce qui semble clair, c'est que le portage de Scratch sur Mac OS X a un gros goulot d'étranglement quelque part... »
En fait, il semble que ce n’est même pas ça (si j’ai bien compris ce que j’ai lu en diagonale en sautant de lien en lien) : il s’agit d’une évolution de la version 1.4 de Scratch, qui était implémentée en Squeak, tournant donc sur une machine virtuelle pour Squeak (ça a changé avec Scratch 2, qui repose sur Flash).
Le boulot qui a été fait a consisté à adapter le code pour le rendre compatible avec une machine virtuelle Squeak plus récente et bien plus rapide (Scratch 1.4, n’étant plus tout neuf, tournait sur une VM assez ancienne). Ça, plus du travail sur le code lui-même pour l’améliorer par endroits.
Le résultat est un Scratch bien plus rapide.
Mais en fait, il est plus rapide sur toutes les plateformes (tout comme la version précédente se traînait sur toutes les plateformes, et pas juste en version Mac). Il ne semble pas y avoir d’optimisation particulière pour le Pi. S’ils faisaient tourner le même programme avec NuScratch sur le Mac au lieu d’utiliser l’ancienne version de Scratch, le Pi serait très probablement largué.
Bref, c’est un joli travail de modernisation de Scratch 1.4 pour lui donner une vitesse d’exécution compatible avec un Raspberry Pi, mais le comparatif en vidéo n’est là que pour montrer que le but a été atteint, et non pour faire la démo d’une super optimisation spécifique au Pi.
Ah, merci, donc c'est surtout NuScratch qui a fait un bond en performance par rapport a Scratch 1.4.
J'avoue j'ai pas été voir dans le détail en quoi consistait NuScratch.
Merci de l'avoir fait.
@ byte_order : « Ah, merci, donc c'est surtout NuScratch qui a fait un bon en performance par rapport a Scratch 1.4. »
Ouais, c’est vrai qu’on peut résumer ça comme ça, plutôt que d’écrire une tartine comme j’ai fait. :-)
« Merci de l'avoir fait. »
Ma curiosité a vaincu ma flemme. ;-)
@ fousfous
Oui, ça demande du travail.
Donc ils n'ont optimisé que du côté Pi 3.
En plus ils sont juges et parti.
Pas étonnant dans ces conditions qu'ils arrivent à trouver un cas où leur machin est plus rapide qu'un MBP (ou n'importe quoi d'autre).
C'est un MacBook Pro avec les bords noir !
Je viens de déballer le miens :D
Oui, oui et la marmotte... Arrêtons de comparer ce qui n'est pas comparable. Faites une compilation d'une application avec un raspberry... et aller prendre un café :-) Même si le Pi 3 est beaucoup plus rapide, il me fallait une demi-heure à une heure pour compiler Centreon sur un Pi version B :-), il faut encore une dizaine de minutes voir plus avec le Pi 3.
Le Pi 3 a fait des progrès, c'est certain, mais il est limité par son système de stockage et son bus couplé à l'USB et la carte réseau. C'est une bonne machine pour l'éducation, certaine application embarquée mais arrêtons les comparaisons. Il ne sera jamais capable d'embarquer et faire fonctionner mes dizaines de VM stockés sur mon Macbook et je ne vous parle pas de mes montages vidéos pour mes formations !
Sur ce, je recommande le Pi 3 pour s'éclater en électronique :-)
Pas besoin de compiler quoique ce soit. Faire une mise à jour de raspbian est suffisante pour se rendre compte où se trouvent les lacunes.
https://xkcd.com/456/
:)
La première chose qu'on apprend aux développeurs, c'est que toute la puissance du monde ne vaut rien si les algorithmes des programmes utilisés sont médiocres... Une calculatrice peut s'avérer plus efficiente qu'un Mac Pro dernier cri (même si c'est caricatural dans ce cas de figure).
Hé papy, c'était vrai à ton époque comme à la mienne. Maintenant, les djeunz qui sortent de l'école avec un diplôme d'informatique n'ont jamais fait de TP d'assembleur. En d'autres termes, ils ne savent pas comment ça marche.
@ heurte : « Maintenant, les djeunz qui sortent de l'école avec un diplôme d'informatique n'ont jamais fait de TP d'assembleur. En d'autres termes, ils ne savent pas comment ça marche. »
Minipapy parlait de la qualité des algorithmes — ce qui n’a vraiment rien à voir avec le fait de savoir développer en assembleur. Dijkstra ne faisait pas d’assembleur.
On ne t’a pas appris ça, à ton époque (quelle qu’elle ait été), ou c’est l’âge qui fait que tu as déjà tout oublié ? ;-)
Bon, cela dit, si à défaut d’assembleur, les petits jeunes pouvaient au moins faire du C (et pas juste une heure ou deux en passant), ce serait bien. :-)
@BeePotato,
à propos, une version optimisée de l'algo de Dijkstra:
https://fr.wikipedia.org/wiki/Algorithme_A*
Pages