Parlons Arduino > Composants
Benchmark MCU
simontpellier:
Bonjour,
Je serais heureux de recevoir de l'aide pour devenir capable de bien choisir une carte, selon ses caractéristiques ET mes besoins propres ... aujourd'hui c'est au petit bonheur la chance !
Pour concrétiser rapidement ce qui a amené ce besoin : après être passé par différents matériels et configurations, mon MCU principal, gestionnaire, est aujourd'hui un Tennsy 3.5. Il est sollicité par beaucoup de tâches et s'en sort fort bien mais prend juste beaucoup de temps pour les communications I2C, au point qu'il serait vite coincé sur un réseau de bonne taille, d'où mon souci et ma question.
Sur le site PJRC, on trouve ce tableau de benchmark :
Je suis malheureusement incapable d'en tirer un enseignement... on y voit cependant qu'un ESP32 surclasse le Tennsy 3.5 (pour 10 fois moins cher !!)
Ayant des ESP32, j'ai donc tenté de retrouver dans des tests simplistes cette supériorité potentielle mais ça n'est pas sauf exception ce qui en ressort. (CPU speed sur : Teensy 120 / ESP 80)
Faudrait-il encore que ces tests aient un minimum de validité... un benchmark rigoureux est probablement une discipline, un art, à part entière...
Il doit néanmoins exister des critères élémentaires pour dégrossir la question ?
Donc grand merci par avance pour toute réponse.
Voici le code des tests perso avec les résultats :
--- Code: ---/* POUR TESTS DE PERF */
uint16_t count = 0;
uint32_t timerTests = 0;
void setup() {
Serial.begin(115200);
delay(100);
}
void loop() {
for (int f=0; f<1000; f++) {
/* test calculs*/
float sqr = sqrt(f); /* resultat TEENSY : 773 Hz / resultat ESP32 : 244 Hz */
/* test IO */
// digitalWrite(4, HIGH); /* resultat TEENSY : 1390 Hz / resultat ESP32 : 4074 Hz */
// digitalWrite(4, LOW);
/* IO rapide - TENNSY 3.5 */ /*resultat TEENSY : 19633 Hz */
// digitalWriteFast(4, HIGH);
// digitalWriteFast(4, LOW);
/* IO rapide - ESP32 */ /* resultat ESP32: 9384 Hz */
// GPIO.out_w1ts = ((uint32_t)1 << 4); // HIGH
// GPIO.out_w1tc = ((uint32_t)1 << 4); // LOW
}
count++;
if (millis()-timerTests >= 3000) {
Serial.printf("%u Hz \n", count/((millis()-timerTests)/1000));
timerTests = millis();
count = 0;
}
}
--- Fin du code ---
cordialement
msport:
Bonjour,
qui peut répondre valablement à cette question ?
les performances seront différentes suivant qu'il s'agit de gérer des interfaces, des timings, des chaines de caractères, faire des calculs en virgule flottante, etc. et tout cela à partir de compilateurs plus ou moins efficaces.
Pour optimiser il faut identifier les goulots d'étranglement de son application et donc évaluer les performances des MCU à partir de là.
simontpellier:
Bonsoir Msport,
et merci... bien que ça sonne hélas comme une réponse valable je m'en rends compte.
Maintenant le compilateur à considérer "en plus" !! Bon bon, mais oui au fait !
Mais là il doit bien y avoir un compilateur plus performant dans l'absolu (sensiblement ?) que les autres !? ( Ou disons... l'un plus que l'autre, mon choix se limitant à Arduino / PIO )
AmadeusHF:
De nos jours il y a très peu de compilateurs fondamentalement différents. GCC, le Gnu C Compiler communautaire est massivement utilisé comme base de fabrication des "déclinaisons" propres à chaque noyau de CPU.
Cela signifie que les fabricants de "CORE" versent à la communauté les éléments de très bas niveau permettant de générer un code (instructions machines) et que, à la fin, la compilation d'un programme donné sera toujours du ressort de GCC (tout comme son optimisation).
Par ailleurs, tout comme le choix d'un langage, le choix d'une architecture CPU dépendra de ce que l'on veut lui faire faire, et aussi de ce que l'on peut en attendre sur d'autres dimensions....comme par exemple le fait de s'intégrer dans une communauté dynamique Open Source ou pas.
Il faut aussi comprendre que les composants dont nous parlons ne sont pas de simples CPU : ce sont ce que l'on appelle des System On Chip (SOC), qui embarquent de nombreux périphériques dédiés à telle ou telle tâche...ce qui à la fin rend la comparaison de la partie CALCUL PUR du composant peu représentative de sa capacité à résoudre tel ou tel problème.
Exemple : un ATMEGA à 8 Mhz est parfaitement capable de décoder un flux DCC avec une précision chirurgicale. Un ESP32 devant traiter le même signal, pourtant de basse exigence (8 Khz environ) ne sera pas aussi fiable dans une telle tâche, ce malgré ses deux cores à 240 Mhz....
L'ATMEGA utilisera pour ça ses timers flexibles, capables de mesurer le signal en continu....ce que l'ESP ne sait tout simplement pas faire ! Aucun de ses composants périphériques n'est prévu pour mesurer EN CONTINU un signal....en revanche pour faire du BLUETOOTH, l'ATMEGA sera à la ramasse là ou l'ESP se la coulera douce.
simontpellier:
wouff ! c'est d'un clarté telle que je crois bien avoir tout compris.
le compilateur : plus de souci.
Mais le "SOC" (notion intégrée je crois)... ça soulève quelques questions car dans ces conditions, comment connaître A PRIORI les prédispositions de tel ou tel... même le datasheet (1000 pages parfois!) restera nébuleux, sauf certainement pour un expert.
Expérience perso : l'ESP32, alléchant et approvisionné pour voir, qui se révèle 2x plus lent qu'un Nano en lecture analogique. L'adaptation du code d'un matériel à l'autre ne se faisant pas d'un clic, pouvoir choisir sur papier ça serait quand même pas mal !
Il faudrait une sorte d' "auto-journal" des SOC... ça existe ?
Navigation
[#] Page suivante
Utiliser la version classique