Raspi Kaufberatung?

[Mxt]

wie läuft dann der Brickbench?

Bei mir nicht, alle Linuxboards laufen "headless" im Netzwerk und haben keinen grafischen Desktop geladen. Dadurch haben sie auch viel mehr Speicher frei, was Tests auch noch verzerren würde.


Noch ne Erkenntnis zum 3er: Die Reichweite des WLAN ist recht bescheiden, verglichen mit Laptop oder Tablett. Habs wieder ausgeschaltet.

[HaWe]

den Grafik-Display Teil kann man ntl auskommentieren, aber die Display-Benchmarks sind schon elementar wichtig für die Ermittlung der Gesamt-Leistung (zugegebenermaßen weniger auf dem Raspi allein betrachtet, insb. bei Verwendung von Multitasking), denn gerade im Vergleich zu den Arduinos einerseits und den Lego-ARMs sieht man, wie einem da hier und dort dadurch die Gesamt-Performance verhagelt wird.

[Mxt]

Also mir erscheint schon die Kommandozeile für den Compiler da auf der Seite sehr suspekt. Warum verwendet man bei einem Benchmark keine Optimierungen ?

Mit GCC -O2 -lm -o bench bench.c übersetzt kriege ich

Raspi2

hw brickbench
initializing...
0 1 int_Add
0 3 int_Mult
0 1 float_op
0 1 randomize
0 0 matrx_algb
0 13 arr_sort

Raspi3

hw brickbench
initializing...
0 1 int_Add
0 2 int_Mult
0 2 float_op
0 0 randomize
0 0 matrx_algb
0 13 arr_sort

Lässt man die Optimierungen, also das -O2 weg, kommt

Raspi2

hw brickbench
initializing...
0 1 int_Add
0 3 int_Mult
0 2 float_op
0 1 randomize
0 1 matrx_algb
0 46 arr_sort

Raspi3

hw brickbench
initializing...
0 1 int_Add
0 3 int_Mult
0 2 float_op
0 1 randomize
0 1 matrx_algb
0 42 arr_sort

Insgesamt wohl kein wirklich aussagekräftiger Test.

[HaWe]

keine Optimierungen deswegen, weil stur der nackte Code abgearbeitet werden soll.
Optimierungen können z.B. die Zählschleifen mit den Konstanten-Operationen wegoptimieren, deren Werte ja nie benutzt werden, oder auch sonst irgendwie Prozeduren "abkürzen".
Das wäre dann wie Nürburgring-Nordschleife querfeldein abgekürzt per Highspeed-Feldweg oder Hubschrauber.

Es sollen aber alle Oprationen haarklein gemacht werden, damit man sieht, wie lang da wirklich gebraucht wird fürs Laden in und aus Registern, Integer- und fp- Units (soweit vorhanden) und RAM.

hier nochmal zum direkten Vergleich meine B+ und 2B Werte:

bench test   ms B+    2B
cpu clock   800MHz 900MHz
Grafik:        openvg
Screen:     HDMI 1060x600
int_add         1      1
int_mult        3      4
float_op       13      2
mersenne        2      1   
matrix          1      2
arr_sort       88     46
text         2630   2626
graph       13333  13333

gesamt ms:  16072  16015
Benchmark:   3111   3122

bei dir:

Raspi2
0 1 int_Add
0 3 int_Mult
0 2 float_op
0 1 randomize
0 1 matrx_algb
0 46 arr_sort

Raspi3
0 1 int_Add
0 3 int_Mult
0 2 float_op
0 1 randomize
0 1 matrx_algb
0 42 arr_sort

(sch*** code tags nur im "erweitert" Editor

und doch, ich finde ihn SEHR aussagekräftig, weil er nämlich Funktionen wie in echten Programmen benutzt, sowohl low-level shift/XOR als auch high-level shellsort etc.

Da weiß man nämlich wirklich, was man an Mehr oder Weniger später zu erwarten hat.

(Multitasking wird hier nicht getestet, bei float und array_sort sieht man trotzdem stärkere Unterschiede als sonst zwischen B+ und 2B / 3B.)

wäre die Pi 3 cpu aber wirklich 2x schneller, würde man das auch in jedem Einzeltest im Vergleich zum 2B oder B+ sehen, wie auch sonst? Im Vergleich zu den verschiedenen Arduinos sieht man es ja auch!

[Mxt]

Man kann damit aber auf dem selben Rechner sehr unterschiedliche Ergebnisse produzieren. Hier nochmal der selbe Raspi2 nur mit einem anderen Linux und einem anderen Compiler

Ohne Optimierung

hw brickbench
initializing...
0 1 int_Add
0 4 int_Mult
0 1 float_op
0 2 randomize
0 1 matrx_algb
0 49 arr_sort

mit Optimierung

hw brickbench
initializing...
0 0 int_Add
0 0 int_Mult
0 1 float_op
0 0 randomize
0 0 matrx_algb
0 11 arr_sort

[i_make_it]

@HaWe: Tipp doch die eckigen Klammern den Backslash und das Wort CODE einfach von Hand ein.

Habe ich grade eben in einem anden Post auch gemacht, da ich mitten im Post nicht wechseln wollte

[HaWe]

das ist doch nichts neues, dass Linux nicht echtzeitfähig ist und im user space alles mögliche parallel nebenher läuft (ob man will oder nicht), was die Programmperformance insgesamt mehr oder weniger extrem stört - angefangen mit den ganzen Daemons, die Linux schon mitbringt, und all die, die man dann noch von Hand startet (gpio, i2c, UART, SPI, HDMI, Grafik, WiFi stick mit Internet und wirelss mouse/keyboard ...) und jeder Sche*** hat noch seinen eigenen Task und seinen eigenen Ast im device tree, was meinst du warum ich Linux hasse wie die Pest...
Wenn du das alles rauslöschst, läuft es dann schneller, klar, aber sonst auch nichts anderes mehr.

und wenn der Compiler falsch eingestellt ist und falsch "optimiert", ist klar, dass auch da was anderes rauskommt:
Bare metal wär der Raspi wschl 10-20xx so schnell wie ein Due, was er aber normalerweise nicht ist.
Aber deswegen habe ich ja das OS und die compile / make parameter immer mit angegeben (Raspbian Jessie, was der normale Standard ist)