Auteur Sujet: Benchmark MCU  (Lu 2073 fois)

simontpellier

  • Full Member
  • ***
  • Messages: 110
    • Voir le profil
Benchmark MCU
« le: janvier 16, 2022, 03:03:51 pm »
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 :
/* 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;
  }
}

cordialement
« Modifié: janvier 17, 2022, 02:47:20 pm par simontpellier »

msport

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 1881
  • HO avec DCC++ en DIY Réseaux très éphémères
    • Voir le profil
Re : Benchmark MCU
« Réponse #1 le: janvier 16, 2022, 03:27:18 pm »
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à.

Cordialement

simontpellier

  • Full Member
  • ***
  • Messages: 110
    • Voir le profil
Re : Benchmark MCU
« Réponse #2 le: janvier 16, 2022, 06:10:13 pm »
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

  • Full Member
  • ***
  • Messages: 204
    • Voir le profil
Re : Benchmark MCU
« Réponse #3 le: janvier 17, 2022, 03:46:17 pm »
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.

« Modifié: janvier 17, 2022, 03:52:20 pm par AmadeusHF »
Sébastien.
La perfection est un chemin, non un but...

simontpellier

  • Full Member
  • ***
  • Messages: 110
    • Voir le profil
Re : Benchmark MCU
« Réponse #4 le: janvier 17, 2022, 09:42:21 pm »
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 ?

AmadeusHF

  • Full Member
  • ***
  • Messages: 204
    • Voir le profil
Re : Benchmark MCU
« Réponse #5 le: janvier 18, 2022, 08:47:08 am »
C'est un peu le piège de tout ce "business" : la simplicité apparente qui caractérise aujourd'hui le monde de l'Arduino n'en élimine pas intrinsèquement la complexité sous-jacente : nous parlons de systèmes qui sont fondamentalement très complexes !

Par exemple pour déterminer si un timer peut ou ne peut pas servir à générer ou faire l'acquisition d'un signal DCC, il ne suffit pas de savoir qu'il y a X timers dans le processeur: il faut encore regarder comment ils fonctionnent !

On peut dégager quelques généralités, mais vraiment pas des tonnes....

Le fait est que l'ESP32 est plutot un processeur "généraliste" destiné à faire tourner de gros programmes peu techniques mais faisant appel à de la communication WIFI ou BT par exemple. Pour des fonctions techniques de bas niveau il lui faudra des coprocesseurs connectés.

Les petits CPU type ATMEGA ont, à l'inverse, toujours été très doués pour le traitement ou la génération de signal. Il y a des centaines de montage en ce sens sur le Net. En revanche ils sont peu efficients pour faire une IHM riche : pas assez de RAM ni de vitesse CPU.
« Modifié: janvier 18, 2022, 08:49:23 am par AmadeusHF »
Sébastien.
La perfection est un chemin, non un but...

Dominique

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 2616
  • 100% Arduino et N
    • Voir le profil
Re : Benchmark MCU
« Réponse #6 le: janvier 18, 2022, 11:01:17 am »
Il me semble que la première chose à faire est de définir le projet à réaliser et ses contraintes.
A partir de là croiser les tableaux comparatifs à plus de sens.
Cordialement,
Dominique

Jean-Luc

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 1654
    • Voir le profil
Re : Benchmark MCU
« Réponse #7 le: janvier 18, 2022, 02:26:46 pm »
Il faut aussi déterminer ce qui coince.

De ce que j'ai lu plus haut, c'est l'I2C. On pourra mettre le CPU le plus véloce qu'on veut, si le programme consiste à faire de l'attente active sur l'envoi de trames I2C, il ira à la vitesse de l'I2C, c'est à dire pas bien vite. :)

Le problème ne serait-il pas le fait que les fonctions Arduino font de l'attente active pour attendre que l'I2C soit dispo ?
Cordialement

simontpellier

  • Full Member
  • ***
  • Messages: 110
    • Voir le profil
Re : Benchmark MCU
« Réponse #8 le: janvier 20, 2022, 04:13:51 pm »
Ça me paraît en effet très complexe au point que le processus de choix l'est tout autant ; c'est ce que je découvre avec surprise à mesure que j'entre dans cet univers.

Car je ne connais pas de tableau comparatif, c'est bien là la question.
Sauf si l'on parle de comparer les besoins en entrées/sorties avec les pinouts des cartes du marché. Mais pour ce qui est des performances... j'ai plusieurs fois constaté que les benchmark bâtons ne correspondaient pas à mes observations. Ils sont d'ailleurs tellement globaux qu'on ne sait plus ce qu'ils mesurent (ni comment !).
C'est sur ce point que je m'interrogeais et sur l'existence de sources fiables sur le sujet.

Pour ce qui est de mon cas perso, Jean-Luc à bien relevé que le goulot d'étrangement est (ou sera un jour) l'I2C. Car I2C mis à part, la question de la puissance brute ne se pose pas. Que j'exploite aujourd'hui +/- 10% de la capacité d'un Teensy3.5 ou +/-15% d'un ESP32, ça ne fait aucune différence. Mais c'est effectivement toujours l'I2C le traînard (avec lib SSD1306AsciiWire.h).
( Peut-être mon programme fait-il en effet de l'attente active ? J'avoue ne pas savoir ce que c'est mais je soupçonnais quelque chose de ce genre.
Avec deux parades en tête : remplacer les écrans I2C par leur équivalent SPI / ou envoyer les trames par CAN à une carte supplémentaire, dédiée aux écrans)

Ce qui reste un souci très secondaire comparé à la question... carrément existentielle ! (bof) de savoir choisir une carte. Qui devient d'ailleurs chaque jour un peu plus aiguë ! Je viens (seulement) de découvrir la nouvelle "portée" d' Arduino NANO, les officielles. Avec déjà des variantes à ne plus compter en Chine, la championne du bâtardage !



« Modifié: janvier 20, 2022, 04:22:19 pm par simontpellier »

msport

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 1881
  • HO avec DCC++ en DIY Réseaux très éphémères
    • Voir le profil
Re : Benchmark MCU
« Réponse #9 le: janvier 20, 2022, 06:50:58 pm »
Bonsoir,

la conclusion qu'on pourrait en tirer dans votre cas, c'est de ne plus passer une minute à choisir un processeur mais de bien choisir la bibliothèque.
Il y en a pas mal pour le SSD1306. Certaines indiquent fast (?)
Par ailleurs, il est connu que les performances en SPI sont meilleures qu'en I2C (références demandées)
Cordialement

Dominique

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 2616
  • 100% Arduino et N
    • Voir le profil
Re : Re : Benchmark MCU
« Réponse #10 le: janvier 20, 2022, 08:58:40 pm »
Je viens (seulement) de découvrir la nouvelle "portée" d' Arduino NANO, les officielles. Avec déjà des variantes à ne plus compter..

Avez-vous des exemples et des références concrètes sur les Nano Every, leur comparaison avec les Nano 328?
Cordialement,
Dominique

Jean-Luc

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 1654
    • Voir le profil
Re : Re : Benchmark MCU
« Réponse #11 le: janvier 20, 2022, 10:25:23 pm »
( Peut-être mon programme fait-il en effet de l'attente active ? J'avoue ne pas savoir ce que c'est mais je soupçonnais quelque chose de ce genre.

C'est simple. l'I2C fonctionne à 400kHz. Envoyer un octet à un périphérique nécessite ~16 bits, soit 40µs. Si le processeur doit envoyer plusieurs fois un octet, il doit attendre que le précédent soit parti du registre I2C. Pour cela il teste en boucle un bit d'état de l'I2C qui indique sa disponibilité. Pendant tout ce temps le CPU ne fait rien d'autre que d'attendre l'I2C. C'est ce qu'on appelle une attente active. Ça se passe à l'intérieur de la bibliothèque SSD1306.

Pour résoudre le problème, on peut
  • faire une bibliothèque qui permet au programme de tester si l'I2C est libre et s'il ne l'est pas de faire autre chose. Ça revient à faire du multitâches à la main, c'est à la charge du programmeur et c'est pas drôle.
  • faire une bibliothèque qui gère un tampon d'octets à envoyer à l'I2C et qui effectue le transfert sur interruption « I2C dispo »
  • Le top : dégotter une bibliothèque qui utilise le DMA du Teensy 3.5 pour gérer par matériel un transfert mémoire vers l'I2C de manière autonome et pendant ce temps là le CPU fait autre chose.
 
Cordialement

jeanmi67

  • Newbie
  • *
  • Messages: 30
    • Voir le profil
Re : Re : Re : Benchmark MCU
« Réponse #12 le: janvier 20, 2022, 11:11:37 pm »
 
Bonjour,

Avez-vous des exemples et des références concrètes sur les Nano Every, leur comparaison avec les Nano 328?

Un élément de réponse...
https://socialcompare.com/fr/live/arduino-nano-every,arduino-nano

Jean-Michel
jeaNmi

AmadeusHF

  • Full Member
  • ***
  • Messages: 204
    • Voir le profil
Re : Benchmark MCU
« Réponse #13 le: janvier 21, 2022, 10:05:44 am »
Le nano every utilise un ATMEGA 4809 ce qui fait qu'on a 6 Ko de RAM au lieu de 2 Ko un fonctionnement "MEGA"....il faut utiliser un kit de base différent de celui du 328 pour compiler. La conséquence pouvant être que certaines librairies ne compilent pas.

Nous utilisons son petit frère le 4808 (32 broches au lieu de 48) sur nos rampes d'éclairage et décodeurs de loco. Le surplus de RAM est une bénédiction : ça permet une bien meilleur efficacité notamment de la partie décodage de flux, en autorisant un buffering que le 328 a du mal à supporter : entre la pile, les variables des 16 à 19 canaux d'éclairage et leurs animations...le 328 sature.

A noter que, avec son boitier de 48 broches, le 4809 du NANO EVERY propose un timer "B" de plus que le 4808.
Les AVR64 DA et DB, leurs successeurs, vont encore un peu plus loin en augmentant la fréquence maximale de 20 Mhz à 24 (mais souvent on restera sur 16 Mhz pour avoir la compatibilité avec beaucoup de bibliothèques !) et peuvent pousser jusqu'à 7 timers de trois types (A, B et C)

Dans tous les cas, le développement "Arduino" avec ces CPU ne pose pas de soucis particulier, surtout pour un usage courant. Et dès qu'on veut faire un peu plus que le tout venant, le pack MegaCoreX de MCUDude permet de s'affranchir des limites de l'offre de base Arduino et d'aller un peu plus loin en finesse.

L'équivalent n'existe pas encore à ma connaissance pour les AVR64...ce qui m'amènera probablement à faire le portage puisque nous allons utiliser ces CPU très bientot.
Sébastien.
La perfection est un chemin, non un but...