05

Beagleboard & linux

déc

Salut.

Bon ma beagleboard-xM est à présent montée et linux Ubuntu configuré.
Alors un grand merci a mon pote Jean Michel, car moi j’y connais pas grand chose en installation linux.
Vu qu’il y a passé toute sa journée, tout seul je n’y serais sans doute jamais arrivé !!!

Un fois installée, un petit bench s’impose afin de comparer la beagleboard-xM aux serveurs de mon entreprise qui utilisent des Xeon à 3 Ghz !!!
Caractéristiques Linux de la beagleboard

Processor : ARMv7 Processor rev 2 (v7l)
BogoMIPS : 669.06
Features : swp half thumb fastmult vfp edsp thumbee neon vfpv3

Caractéristiques Linux du Xeon (au total il y a 8 processeurs)

vendor_id : GenuineIntel
cpu family : 6
model name : Intel(R) Xeon(R) CPU E5450 @ 3.00GHz
cpu MHz : 3000.002
cache size : 6144 KB
fpu : yes
bogomips : 6000.00

J’installe nbench-byte (je précise que ce bench n’utilise qu’un seul processeur, ou que tout du moins il est sensé permettre de comparer des architectures multi-processeurs a des architecture mono-processeur) et je lance le test.
Bon le résultat fait peur! Le Xeon serait d’après ce bench 25 fois plus puissant !!!

Comme cela ne me semble un peu inquiétant, j’essaye divers programmes (convert, tar, gzip,…)
Verdict… En moyenne le beagleboard-xM est entre 8 et 10 fois plus lente que le XEON, ce qui est nettement plus probable vu que le résultat est plus proche du ratio des bogomips.

Je fais un dernier test! celui de la conversion d’une image JPEG de 1024*1024 en une image TGA.
Pour ce faire j’utilise tinyJpeg
Ce choix est intéressant car le JPEG fait appel a une grosse masse de calcul. De plus a un moment ou un autre je vais devoir moi aussi décoder des images JPEG.

Le temps de conversion sur le XEON est de 0.144s contre 1.531s sur le Cortex-A8. (Je précise que ces temps sont ceux obtenus sans aucun paramètre d’optimisation fourni à gcc.)

Alors le processeur Cortex-A8 n’est pas trop en cause.
Il faut plutôt chercher cette grosse différence de performance du coté de la RAM LPDDR Ram (Low Power Double Data Rate mémory) ainsi que de l’absence de coprocesseur arithmétique du Cortex (Je ne suis pas bien sur que vpf3 soit utilisé par la distrib linux.)

Mon objectif pour le JPEG est de décoder l’image en moins d’un centième de seconde. Ca parait compliqué de rendre un programme 150 fois plus rapide, et pourtant, grâce à l’assembleur et surtout grâce à NEON, cela semble possible…
Je serai de toute façon vite fixé.

 | Tags:

Répondre

Human control : 2 + 6 =