ZeroW Performance

[Holomino]

Test.zip

Hallöle,

mag mir vielleicht jemand spontan mit seinem großen Raspi unter die Arme greifen und die im Anhang aufgeführten Dateien in einen C-Compiler schmeißen und als Release durchlaufen lassen?

Ich bekomme mit meinem ZeroW so etwa 3,5s für einen Durchlauf raus. Kommt mir etwas viel vor.


Danke
Holomino

[Holomino]

Mit nem 3B+ bitte????

[NumberFive]

gcc main.c BresenhamTest.c Bresenham.c -o test.bin -mtune=native -O2

Dann komme ich auf eine 2er auf diese Zeiten

Bresenham time: 2.839819
Press e to exit, anything else to repeat

Bresenham time: 2.808073
Press e to exit, anything else to repeat
t

Bresenham time: 2.843296
Press e to exit, anything else to repeat
e
Bresenham time: 2.808091
Press e to exit, anything else to repeat

[Holomino]

Hmmm,
mit nem BPI M2 Zero liege ich jetzt bei 2,5s. Der taktet so bei 960MHz im Normalbetrieb.

Aber schon etwas seltsam: Auf'm Notebook(1,8GHz) habe ich ne Durchlaufzeit von 0,2s.
Da alle Operationen im Ganzzahlbereich liegen und auch nur ein Kern involviert ist, hätte ich jetzt eher gedacht, das lässt sich grob linear anhand der Prozessorfrequenz schätzen - aber hier liegt die Abweichung bei Faktor 5?!? Was treibt der ARM da?

[NumberFive]

Ich habe mir den Code nicht wirklich angesehen nur Compiliert. Was ist der Ziel des Codes ? Malen von Kreisen ?
Für mein Projekt habe ich da auch mal angefangen aber habe zur zeit aufgeben jetzt sind alle Steuerelementebilder das geht einfach viel schneller. Problem leider nicht wirklich skalierbar ohne das es blöd aussieht. Wenn alles mal Funktioniert will svg noch mal versuchen.

Muss es C sein ? oder darf es auch C++ sein ?

http://www.cplusplus.com/reference/cmath/abs/

Das ist für mich fliescomma damit geht er auf die FPU ergo da kann man vielleicht noch was raus holen.
https://stackoverflow.com/questions/...e-lines-faster

int err = (dx > dy ? dx : -dy) / 2, e2;
Hier verlassen mich meine C erkenntnisse was macht die Zeile ? , e2 verstehe ich nicht

[Holomino]

Doch, den kennst Du auch:

int err, e2;
int err= 0, e2;
int err= irgendwas, e2;

Aber ich muss lachen, den Code hab ich von irgendwo geklaut und ich habe auch ziemlich lange auf die Zeile gestarrt, bis endlich der Groschen fiel.

Der Bresenham ist in der Form nen Linienerzeuger, der steppt nur die Punkte von Start bis End durch. Ganz gut für nen Laserscanner im GridSlam zu gebrauchen (Wenn man denn im Callback auch mit den Gridzellen vergleicht oder sie setzt).

Allerdings war die Sache für mich auch nur ein Test, um mal zu sehen, was aus diesen kleinen PI-Dingern rauszuholen ist. Ich habe meine App mittlerweile mit C# unter Mono recht gut mit dem BPI M2 Zero am laufen (nachdem ich nun auch mal die Rechnerei auf die Kerne verteilt habe). Mit dem RPI ZeroW wird's rein rechnerisch unter Mono nix, wenn ich sehe, dass alle vier Kerne des BPI zur Zeit bei etwa 50% liegen. Den ganzen Sermon für das Raspi-Geklüngel auf C zu portieren würde sicher die Sache um den Faktor 3..4 beschleunigen, lohnt sich aber für mich irgendwie (noch) nicht. Ich hänge hier sowieso 90% der Zeit mit nem Notebook lokal in Simulationen oder über Bluetooth am Roboter.

Ich nehme das jetzt einfach mal zur Kenntnis mit dem (nicht repräsentativen) BresenhamTest:
Faktor Arm Mono : Arm C 4:1
Faktor Windows C : Arm C 1:5
Faktor Windows C : Windows C# 1:4

[NumberFive]

Ok jetzt habe ich das auch verstanden. Danke.
Dann lassen wir das Thema wie es ist. Ich mag es zwar nicht so Energie zu verschwenden aber das dein Projekt und ich sollte meines voran treiben.
Ich programmiere jeden Tag C# (Job) aber ich mag es nach wie vor nur bedingt das krass Beispiel die Farbe aus eine Bitmap rechnen (Graustufen A3 200 Dpi). C# 30 msec C++ 3 msec Windows 8 Kerne 16 GByte Hauptspeicher.

[Holomino]

Es gibt da tatsächlich nur eine Hand voll Dinge, die mich an C# festhalten lassen: PropertyGrid(zur Konfiguration auch während der laufenden Simulation), XMLSerializer(zum Laden/Speichern von Konfigurationen), Reflection (zum Durchforsten/Laden/Speichern von externen DLLs per Latebinding),....
Das mag ich nicht mehr missen. Ich bin mittlerweile einfach zu faul oder zu alt, Konfigurationsdialoge zu malen oder in Dateien per Hand rumzuhacken.

Aber man kann ja auch den rechenlastigen Teil in den unmanaged-Bereich auslagern, wenn es nötig wird.

[NumberFive]

für Config files nehme ich Json https://github.com/nlohmann/json/releases.
Zu dem rest sage ich mal nix.

[Holomino]

http://www.cplusplus.com/reference/cmath/abs/

Das ist für mich fliescomma damit geht er auf die FPU ergo da kann man vielleicht noch was raus holen.

BTW: In der Bresenham-Funktion wird das "abs" einmalig aufgerufen, wenn Du in BresenhamTest die Anzahl der Aufrufe kleiner machst (/100) und die Länge der Linien entsprechend vergrößerst (*100), macht das zumindest bei mir in der Durchlaufzeit null Unterschied.

An der FPU liegt das also hier nicht.