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:
bei dir:Code: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
Code:Raspi2 0 1 int_Add 0 3 int_Mult 0 2 float_op 0 1 randomize 0 1 matrx_algb 0 46 arr_sort(sch*** code tags nur im "erweitert" EditorCode:Raspi3 0 1 int_Add 0 3 int_Mult 0 2 float_op 0 1 randomize 0 1 matrx_algb 0 42 arr_sort
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!
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
mit Optimierunghw 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
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
@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
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)
Was du nur immer hast: http://logicals.com/de/forum/raspber...raspberry-pi-s
Gerade _das_ ist einer der Hauptvorteile von Linux: bei Bedarf kann man sich alles so zurechtoptimieren, wie man es eben braucht.
Der Nachteil: oft muss man es _selber_ machen.
Grüssle, Sly
..dem Inschenör ist nix zu schwör..
nein, es muss _richtig_ heißen:
"man _muss_ alles selber machen", und das betrifft nicht nur Variationen des Standard-Raspbian-Setups, sondern alles und jedes, was man auf dem Raspi an Hard- und Software braucht, angefangen mit GPIO, UART, I2C, C-IDE, graphic libs,... einfach _alles_ , und man _muss_ es nicht nur, man _muss_ es dann auch noch dafür _selber_ _machen_ _können_ .
Aber ich will hier keine Linux-Diskussion starten, das wäre off-topic, es ging nur um die Standard-RPi3-Performance in einem Standard-Raspbian-Jessie-Environment... und die ist eben nicht so super-doll.
Hinzu kommt, dass, wenn man was ändert, was das (Realtime) Verhalten angeht, dann laufen u.U. - bzw. sehr wahrscheinlich - viele libs nicht mehr, die auf die Standard-Setups angepasst sind, z.B. pigpio, evtl. auch WiringPi, openVG etc.
und ich muss endlich mal den source code vom Benchmark Test anpassen, damit auch Bruchteile von 1ms korrekt gemessen und angezeigt werden.
Diskussionen über Vor- und Nachteile von Betriebssystemen ist immer in etwa so wie wenn man über Geschmack debattieren will. Am Ende kommt doch nichts bei raus was nicht vorher auch schon da gewesen wäre.
Du hast schon recht. Benutzt man Linux so wie es gedacht war, dann hat man einen Kernel und dann gehts Stück für Stück weiter. Was Ubuntu, Fedora usw. dann draus gemacht haben ist ja im Endeffekt auch wie Windows. Man bekommt etwas vor gesetzt, was ein Team von Leuten für sinnvoll für den User halten. Deshalb finde ich auch die User so lustig, die sich Ubuntu auf den Rechner drauf machen und dann erzählen sie nutzen Linux. Prinzipiell richtig, aber von Linux haben die keine Ahnung.
So war es bei mir zumindest. Ich komme eigentlich vom AmigaOS. Zu Zeiten wo ich noch gut Kleingeld hatte war das auch ne echt dufte Sache und ich denke, ich würde es auch heute noch nutzen. Aber da das Geld knapp wurde und jetzt mit Kindern und Enkelkind kann ich eben nicht mehr die dicke Kohle für Hardware raus werden. Mir hat aber Windows auch noch nie gefallen. So habe ich, wenn überhaupt, gerade mal ein Jahr XP Professional benutzt. Dann ging die Suche nach einer Alternative los. Bei Linux hatte ich das Problem, welches nehmen? Denn GB Weise Zeugs runter laden, das war ja schlimmer wie Windows. So führte mich mein Weg von Suse über Fedora zu Ubuntu. Aber wie oben geschrieben, von Linux hatte ich bis dahin null Ahnung und für jeden Scheiss der nicht funktioniert hat musste ich in irgendwelchen Foren nachfragen. Die haben dann mit irgendwelchen Fachbegriffen um sich geschmissen und gelernt habe ich dabei nichts. Dazu fand ich auch die Geschwindigkeit nicht berauschend und diese gefühlten Millionen Programme, die man einfach so da installiert bekommen hat fand ich scheisse. In einem Chat hat mir dann jemand von Gentoo erzählt. 130 MB Installationscd und los gehs. Wenn das OS vollstaändig lauffähig installiert ist kommt man bis zum Prompt. Egal was man danach haben will muss man installieren, sogar über Pakete compilieren. Da lernt man dann die verschiedenen Configs, wie man einen X-Server konfiguriert usw. Wenn man die erste Installation dann zerschossen hat und Alles neu machen muss merkt man wie man schon deutlich mehr versteht von dem was da vor sich geht.
Und genau das mag ich an Linux im Hinblick auf den Raspi. Wenn ich den Raspi in einen Bot einbaue, dann braucht der kein X-Server laufen zu haben. Also bleibt der aus usw.
Yeah. Wenn das mal nicht Off-Topic ist. Meine Geschichte wie ich zu Linux kam ^^
ist doch auch mal ganz nett...
mich würde mal eine Statistik interessieren, wieviele Raspi-Nutzer NOOBS-Images verwenden und wieviele davon und auch insgesamt das "normale" Raspbian (z.Zt. Jessie). Und dann, wie sich der Rest der User aufteilt.
Anfänger im Roboterbau werden vermutlich auch ein Anfänger-Linux-Setup benutzen, nur sehr versierte User auch speziell konfigurierte. Real-Time-kernels nutzen sicher die wenigsten, vermute ich, aber echte Zahlen habe ich noch nicht gelesen (Findet man aber sicher, wenn man gezielt sucht).
Anwender, die den Pi als Media-Center nutzen, sind aber sicher nicht die richtige Zielgruppe für Roboterprogramm-Benchmarks.
Ich selber kam zum Linux über den Lego EV3, dort habe ich es gehasst, da man überhaupt nicht on-board arbeiten kann mit vernünftigem Screen (ssh und putty kommt mir nicht ins Haus),
und auch beim Raspi B+ machte es keinen Sinn, da unerträglich langsam für den Geany-Editor und Internet.
Der 2B ist jetzt ok, ich habe rausgekriegt, wie man pthread so konfiguriert, dass man schon sehr nahe an Echtzeittasks herankommt, und das reicht mir.
WLAN brauche ich ständig (allein schon wegen apt-get install und update und upgrade und git clone, auch mal schnell zur Inet-Suche von libs),
ohne wirless-Keyboard/Maus läuft auch nichts,
Grafik-Screens brauche ich für Programme (openVG) mit hoher Auflösung (möglichst mindestens HD 600p (mobil) oder möglichst 1080p (stationär) )
einen GUI-Desktop mit hoher Auflösung für Geany ebenfalls...:
Also ist das Standard-Jessie genau das, was ich brauche zum Roboter-programmieren.
Beim Rpi 3 scheint Linux mit seinen daemons und user-space-tasks aber soviel abzugraben dass eben keine 100% Leistungssteigerung für rechenintensive Programme übrig bleiben, wohl auch keine 50%...
mein Tipp ganz zu Anfang war ja mit dem 32bit-OS sogar nur ca. 15%, die Wahrheit wird irgendwo in der Mitte liegen...
Da ich denke, dass Hobby-Programmierer (keine Profis) am ehesten Standard-Jessie nutzen, habe ich daher auch auf Basis von Standard-Jessie verglichen (bei Arduino teste ich ja auch die Standard-IDE und nicht mbed-Kompilate).
Hallo,
genau deswegen nutze ich oft einen AVR UND einen RASPI in einem Projekt. Der AVR macht die Echtzeitsachen und ist 'sofort' nach dem Einschalten mit meinem Programm beschäftigt und der Raspi übernimmt 'komplizierte' Dinge. Während man mit der Hochfahrzeit des Raspis noch leben kann, ist ein AVR einfach zuverlässiger. Wobei sich das seit den jüngeren Raspi-Versionen auch schon gebessert hat, aber wieder schlimmer wird! Ich habe einen Raspi der ersten Generation ohne AVR im Bad als WLAN-Radio und Wettervorhersage. Dieser läuft monatelang problemlos durch. Hält auch die Verbindung per WLAN und steuert einen AX206 Bilderrahmen per lcd4linux an. Sobald ich das Raspbian update, gibt es nach wenigen Stunden bis Tagen Probleme und der Raspi verliert die WLAN-Verbindung. Da half dann nur ein Neustart. Also bleibt das alte Raspbian darauf erhalten.
Da in neueren Projekten nun auch aktuellere Raspis laufen, musste ein aktuelleres Raspbian her, da die neuen Raspis nicht mit dem alten Kernel starten. Nun ist es so, dass der AVR z.B. im Wecker, den Raspi überwacht und im Falle eines Falles das Wecken ganz klassisch per Piezo-Pieper übernimmt. Diesen Fall hatte ich zuletzt, als die Steckverbindung der UARTS ein Kontaktproblem hatte - funktioniert also. Ansonsten wird das Raspbian nicht mehr aktualisiert, wenn alles läuft. Darüber hinaus übernimmt der AVR Grafik-LCD und Matrixtastatur. In anderen Anwendungen sind die vielen Ein- Ausgänge eines AVRs von Vorteil.
Sicherheitsprobleme gibt es da in meinen Anwendungsfällen nicht, da die Raspis nicht aus dem Internet erreichbar sind. Diese betrachte ich wie einen AVR. Viele Probleme sind schon weg, wenn alles (außer Webserver) als root läuft.
Was der AVR nicht so ohne Weiteres schafft, ist Netzwerk. Da kann man beim Seitenaufbau zusehen und umfangreiche Kommunikation mit anderen Geräten im Netzwerk war bei meinen Versuchen Glücksache. Ein WizNet Modul war damals mindestens so teuer wie ein Raspi. Daher einfach mal mit dem Raspi probiert und ZACK - Netzwerk rennt und ist auch noch wesentlich einfacher zu programmieren. PHP ist schon eine feine Sache. Ein weiterer Vorteil ist, dass der Raspi 'seinen' AVR bequem per Netzwerk programmieren kann. Dann kommt natürlich noch das Radio ins Spiel. Das schafft der AVR auch nicht so einfach. MP3 würde einfacher gehen, aber auch diese Platinchen kosten etwa soviel wie ein Raspi.
Eine defekte SD-Karte hatte ich ganz am Anfang meiner Raspi-Zeit. Daraufhin hatte ich eine Zeit lang die SD-Karten schreibgeschützt im Raspi in Betrieb. Davon bin ich wieder weg. Erkennt das Raspbian beim Hochfahren von einer SD-Karte einen Fehler, will es die SD-Karte prüfen, scheitert aber am ReadOnly und bleibt einfach stehen. Was beim Raspbian bald gar nicht geht, ist dieses ständige 'Rumloggen' auf die SD-Karte. Das ist das erste, was ich abschalte. Dafür muss da an diversen Stellen was angepasst werden. Als programmiersprache nutze ich für den Raspi entweder BASH oder C. (Netzwerk PHP) Python habe ich noch nicht probiert, somit brauch ich es wohl nicht
Als die Nachricht mit dem Raspi 3 kam, dachte ich auch erst, den hole ich mir. Dann jedoch - wofür? WLAN, wo die Antenne auf der Platine ist, macht nicht viel Sinn / traue ich zumindest nix zu. Bluetooth? Hm, wofür, wenn ich auch WLAN am Smartphone habe? Netzwerk ist geblieben, USB Anbindung ist geblieben. 64 Bit brauch ich nicht bei dem bissel RAM. SD-Karte ist geblieben. - Soll jetzt wohl auch von USB booten - brauch ich nicht. Einzig die höhere Rechenleistung könnte beim kompilieren Zeit sparen. Aber soviel kompiliere ich nun auch wieder nicht.
Wenn das Herz involviert ist, steht die Logik außen vor! \/
AVRs oder Dues nebenher nutze ich auch am Raspi als IO-Muxer (UART, USB und I2C) -
aber das kriegst du nicht hin, dass du 16 Encoder im 100µs-Takt in Echtzeit auf dem AVR ausliest und berechnest UND die neu berechneten Encoder-Werte auch noch in unter 500µs zum Pi schickst, und dann am Pi moduliertes pwm in Echtzeit wieder zum AVR zurück zur Motorsteuerung.
Das schaffst du mit UART und I2C nicht, und man muss schon ein sehr versierter Programmierer sein, um Encoderwerte und pwm per SPI hin und her zu schaufeln.
Du kannst das teilweise outsourcen, aber trotzdem braucht man (zumindest ich) auch Echtzeit-Tasks auf dem Pi.
Aber IOs sind nicht das Thema, sondern allein die Rechenperformance im Vergleich Pi2 vs. Pi3, und die ist laut Benchmark eben ziemlich mies.
Berechtigungen
Zitieren
Lesezeichen