HaWe Brickbench Benchmark Test 2.0

[shedepe]

Also nur mal vom theoretischen Standpunkt ausgesehen: Wenn du z.B. in einer for Schleife in Python etwas rechnest, dann sollte das kaum langsamer sein als wenn du das in C++ ausführst. Am Schluss ist es eben doch binär Code der auf der CPU ausgeführt wird. Vorraussetzung du führst den Code mehr als einmal aus -> Python wird auf vielen Systemen Standardmäßig erst mal in Bytecode beim ersten Mal ausführen kompiliert und dann erst vom Interpreter
Wäre auch mein Tipp noch -> Wenn du wirklich gut benchmarken willst und nicht z.B. auf x86 Pech haben willst, dass grade Speicher kopiert wurde o.ä. führe jede Funktion am besten mehrere 100 Mal aus und berechne Maximale Zeit, Minimale Zeit und die Durchschnittszeit. Für einen Atmega sollte das natürlich keine Rolle spielen, weil da sonst nicht so viel passiert, bzw. die Architektur einfach genug ist.

[HaWe]

Also nur mal vom theoretischen Standpunkt ausgesehen: Wenn du z.B. in einer for Schleife in Python etwas rechnest, dann sollte das kaum langsamer sein als wenn du das in C++ ausführst. Am Schluss ist es eben doch binär Code der auf der CPU ausgeführt wird. Vorraussetzung du führst den Code mehr als einmal aus -> Python wird auf vielen Systemen Standardmäßig erst mal in Bytecode beim ersten Mal ausführen kompiliert und dann erst vom Interpreter
Wäre auch mein Tipp noch -> Wenn du wirklich gut benchmarken willst und nicht z.B. auf x86 Pech haben willst, dass grade Speicher kopiert wurde o.ä. führe jede Funktion am besten mehrere 100 Mal aus und berechne Maximale Zeit, Minimale Zeit und die Durchschnittszeit. Für einen Atmega sollte das natürlich keine Rolle spielen, weil da sonst nicht so viel passiert, bzw. die Architektur einfach genug ist.

hallo,
danke für die Tipps!
tatsächlich wird ja jede Schleife in jedem Sub-Test teilw. mehrere zig-tausend mal ausgeführt. Portieren nach Python kann ich es allerdings selber nicht, da ich absolut überhaupt keinen Schatten eines Schimmers von Python habe
- und dann soll der Code ja auch nicht nur irgendwie ähnlich sein, sondern bis ins Detail identische Routinen haben, soweit das die Python-Syntax auch nur möglich macht.
Das gilt unter besonderer Beachtung auch der Zeilen, in denen Variablen im C-Code als "volatile" deklariert wurden, um zu vermeiden, dass der Präprozessor oder der Compiler sie weg-optimiert (was ja ruckzuck passiert, da mit den mathematischen Ergebnissen nicht weitergerechnet wird)...

PS,
Für Java (JIT-Compiler) habe ich solche Tests auch schon mal gemacht, hier hat sich nach 3 Durchläufen nacheinander auch schon eine erhebliche Geschwindigkeitssteigerung gezeigt. Das bliebe jetzt auch für Python zu zeigen.
Die C(++) Compilate sind allerdings schon sehr, sehr stabil mit ihren runtimes.

[shedepe]

long test_Int_Mult() {
  int x,y;
  volatile long s;

  for(y=0;y<500000;++y) { // *500: 20,000,000 int mult/div
    s=1;
    for(x=1;x<=10;++x) { s*=x;} //1 3->10
    for(x=10;x>0;--x) { s/=x;}

  }
  return s;
}

Würde vorschlagen, das Ergbnis der Funktion in eine Variable einzulesen und erst diese Variable als volatile zu deklarieren. Sonst verhinderst du eventuell Optimierung in der Funktion die sich auf die Laufzeit auswirken könnten. Das selbe gilt auch für alle anderen Funktionen mit volatile Variablen in der Funktion.

[HaWe]

long test_Int_Mult() {
  int x,y;
  volatile long s;

  for(y=0;y<500000;++y) { //    10,000,000 int mult/div
    s=1;
    for(x=1;x<=10;++x) { s*=x;}  
    for(x=10;x>0;--x) { s/=x;}

  }
  return s;
}

Würde vorschlagen, das Ergbnis der Funktion in eine Variable einzulesen und erst diese Variable als volatile zu deklarieren. Sonst verhinderst du eventuell Optimierung in der Funktion die sich auf die Laufzeit auswirken könnten. Das selbe gilt auch für alle anderen Funktionen mit volatile Variablen in der Funktion.

ja, das stimmt, allerdings hatte ich das genau so eigentlich beabsichtigt, dass es keinesfalls optimiert werden sollte, weil ich unbedingt wollte, dass während der Laufzeit alle Schritte genau so, unverändert und unoptimiert vollständig berechnet werden:
Man sollte ein Maß haben, wieviel Zeit tatsächlich für eine definitiv durchzuführende Anzahl arithmetischer Operationen (hier eben vollständige explizite Integer Mult./Divis.) benötigt wird.

Hintergrund ist auch, dass bei "echten" Anwendungsprogrammen kaum immer so extrem viele kurze Operationen mit denselben Variablen in langen Schleifen durchgeführt werden, sondern diese eher durch if-statements, Jumps/Funktionsaufrufe und GPIO r/w sowie völlig andere Berechnungen mit ganz anderen Variablen unterbrochen sind. Dadurch ist es dann auch nicht unbedingt möglich, diese Operationen immer direkt auf den schnelleren Registern auszuführen, sondern stattdessen sind eher häufige RAM-Zugriffe erforderlich.
Genau diese sonst mögliche, schnellere Register-Arithmetik soll auch hier per volatile verhindert werden, abgesehen von kompletten weg-Optimierungen, weil die Rechenergebnisse weiterhin ungenutzt bleiben.