mruniversum Geschrieben August 2, 2012 at 12:09 Share Geschrieben August 2, 2012 at 12:09 hi, gibt es erfahrungen welche programmiersprachen sich am besten eignen hinsichtlich der performance (z.b. für verwendung auf RasPi)? hab das gefühl dass z.b. eine abfrage der temperatur über java unnötig lange dauert (ca 2-3 sekunden), evtl wäre das über C besser? Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
borg Geschrieben August 2, 2012 at 12:29 Share Geschrieben August 2, 2012 at 12:29 Sind die 2-3 Sekunden von Programmstart bis Programmende? Im laufenden Programm sollte so eine Abfrage keine 2-3 Sekunden dauern, auch nicht mit Java. Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
Nic Geschrieben August 2, 2012 at 13:29 Share Geschrieben August 2, 2012 at 13:29 Hmmh, ich glaube er meint die Zeit für 1 Function-Call getTemperature oder so ähnlich Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
kuli Geschrieben August 2, 2012 at 13:32 Share Geschrieben August 2, 2012 at 13:32 bei mir dauert ein method call über java ca. 1.5ms .. was ich gelesen habe wirds nie unter 1ms gehen, da es usb nicht zulässt. was die programmiersprache am RPi angeht: C wird natürlich schneller sein als java.. aber es hängt davon ab was du machen willst.. kann leicht sein dass java reicht python wird soviel ich weiss nativ vom RPi unterstützt.. da hast du aber einen overhead, da python interpretiert wird Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
Nic Geschrieben August 2, 2012 at 13:47 Share Geschrieben August 2, 2012 at 13:47 bei mir dauert ein method call über java ca. 1.5ms Mit Java nahe am theoretischen Limit ?! Boah , mit welcher Hardware und Betriebssystem. Kann das kaum glauben, mit einer nativen Sprache wie C ja, aber mit einer JVM Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
kuli Geschrieben August 2, 2012 at 15:02 Share Geschrieben August 2, 2012 at 15:02 naja es ist nur ein einziger method call und 1.5ms ist find ich 'viel' zeit. weiß jemand wie hoch genau die latenzen bei usb sind? wenn das mit 1ms pro request stimmt, müssten es bei einem get-request ja mindestens 2ms (rtt) sein.. oder wird eine maximale latenz von 1ms garantiert und weniger kanns immer sein? Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
borg Geschrieben August 2, 2012 at 17:34 Share Geschrieben August 2, 2012 at 17:34 @kuli: USB wird 1x pro ms gepollt vom Linux Kernel (oder auch von Windows, ist so im Standard definiert). Die Antwort auf ein getter ist immer direkt beim nächsten polling vom PC fertig. D.h. so eine Anfrage dauert minimal 1ms und maximal 2ms, je nachdem wo du dich gerade in diesem Abfragefenster befindest. Deswegen schreiben wir überall das unbedingt wenn möglich die Callbacks benutzt werden soll, da ist dann die absolut maximale Latenz nach auftreten eines Events 1ms, im Schnitt 500us. Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
kuli Geschrieben August 2, 2012 at 17:43 Share Geschrieben August 2, 2012 at 17:43 ok, alles klar, danke! Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
Nic Geschrieben August 3, 2012 at 08:59 Share Geschrieben August 3, 2012 at 08:59 Die Zeiten gelten hier aber nur bei Kabelverbindung ! Ich messe über Chibi-Funknetz mit GetChipTemp-Call vom Stepper und Delphi-Bindings über Win7x64 eine Dauer zw. ca. 80 bis 160ms, im Mittel etwa 100ms. Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
AuronX Geschrieben August 3, 2012 at 09:14 Share Geschrieben August 3, 2012 at 09:14 Java kann btw. locker genauso schnell wie C sein. Prinzipiell liegt es am Ende nur daran, dass der JIT guten Code erzeugt ^^ Man kann mir gerne erzählen, dass Java ein anderen Speicherverhalten hat als C (klar, weil C nicht managed ist), aber irgendwann sollte man mal damit aufräumen, dass C "automagisch" schneller ist weil es eben C ist. Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
Nic Geschrieben August 3, 2012 at 09:19 Share Geschrieben August 3, 2012 at 09:19 ...JIT guten Code erzeugt Ich bin kein Java-Experte, was meinst Du damit ? Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
AuronX Geschrieben August 3, 2012 at 12:04 Share Geschrieben August 3, 2012 at 12:04 kurzer Ausflug: Wenn du deinen C Code kompilierst, dann wird daraus durch den Compiler Maschinencode erzeugt, also Code der unmittelbar durch den Prozessor ausgeführt werden kann. Wenn du deinen Java-Code kompilierst, dann wird daraus Byte-Code, dieser kann nicht von der CPU ausgeführt werden, bei Java gibt es den Just-In-Time-Compiler (JIT) der den Bytecode während der ausführung zu Maschinencode umwandelt, deswegen sind Java-Programme auch grundsätzlich Plattformunabhängig. Wenn du C-Code kompiliert hast wirst du soetwas wie Optimierungen kennen. Dabei verändert der Compiler den Maschinencode so, dass er schneller ausgeführt werden kann, aber äquivalent zur Eingabe ist. EInfaches Beispiel: for(int i=0;i<3;i++) rufeMethode(); daraus kann der Compiler dann auch das machen (dargestellt als C-Code): rufeMethode(); rufeMethode(); rufeMethode(); Der Prozessor muss gar keine Sprünge mehr ausführen (wie es bei der Schleife nötig wäre) und der Code ist schneller. Der JIT kann das auch machen, aber es dauert halt länger solche Stellen zu finden. Für den C-Compiler ist es egal, der hat Zeit. Der JIT soll halt "in-time" arbeiten, deswegen wird er hin und wieder den Code nur "einfach kompilieren", dann wird dieser langsamer ausgeführt als äquivalenter (und optimierter!) C-Code. Auf der anderen Seite kann der JIT bei Methoden die schnell sein müssen sich auch später nochmal "Mühe geben" und sie dann halt optimiert kompilieren. Der JIT hat sogar einen Vorteil gegenüber dem C-Compiler: Er kennt die Laufzeitcharakteristik deines Programms, er kann wissen welche Methoden wie oft gerufen werden und dadurch besser optimieren. Bei C# sieht das alles übrigens ähnlich aus, es gibt auch Zwischencode der live zu Maschinencode wird. Selbstverständlich war das alles jetzt ziemlich kurz dargestellt, aber das Fazit sollte ungefähr dieses sein: Java-Code ist nicht per se langsamer, er wird es an manchen Stellen aufgrund schlechter JIT-Entscheidungen sein, an anderen kann er aber auch schneller sein als der meiste C-Code. Letztendlich mact den größten Performance-Unterschied die Wahld er richtigen Algorithmen aus, nicht die Wahl der richtigen Programmiersprache. Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
kuli Geschrieben August 3, 2012 at 14:04 Share Geschrieben August 3, 2012 at 14:04 dynamische bindungen sowie der garbage collector bedeuten jedoch (viel) mehr arbeit für die cpu Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
AuronX Geschrieben August 3, 2012 at 14:33 Share Geschrieben August 3, 2012 at 14:33 Ich will hier nciht den Glaubenskrieg im FOrum anzetteln, der wird im restlichen Internet genug geführt... In C ist auch Speicherverwaltung nötig, die einen machen sie nicht und haben deswegen Mem-leaks, die anderen machen es und kommen bei großen Anwendungen auf die Idee "kluge Pointer" zu nutzen, das ist auch nur nen verkleideter GC. Das mit dem Late Binding ist ein Punkt der auch C/C++ trifft. In C# beispielsweise ist es genau wie dort: Nur virtual/abstract kann überschrieben werden (während in java alles überschrieben werden kann was nciht final ist, also nur umgekehrte Logik). Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
Nic Geschrieben August 4, 2012 at 08:50 Share Geschrieben August 4, 2012 at 08:50 kurzer Ausflug: Wenn du deinen C Code kompilierst, dann wird daraus durch den Compiler Maschinencode erzeugt, also Code der unmittelbar durch den Prozessor ausgeführt werden kann. Also ich fand die Erklärung recht gelungen. Sehr gut, der Hinweis über "saubere" Programmierung bzw. Verwendung von vernünftigen Design Patterns. Damit wird der Code nicht nur übersichtlicher, und wartbarer sondern auch u.U. performanter. Keine Sorge, daß hier zuviel Infos rüberkommen. Im Forum wird m.E. eher viel zu wenig gepostet, als zu viel Keine Ahnung wie das interne Verhalten beim Delphi oder FPC ist, aber die Compiler erzeugen ohne Umweg von Byte-Code direkt platform-abhängigen nativen Code. Ich schätze mal ähnlich des C-Compilers, aber mit dem Overhead der VCL, Kapselung der WinAPI etc. PS: Habe die Zeit von der Fkt. GetChipTemperature kabelgeb. in Delphi gemessen, ich komme im Durchschn. auf 2ms auf einem i5,Win7 x64,8GB. Also die 1.5ms mit Java (abgesehen von JIT Optim.) entspricht kaum der Regel zur Laufzeit, ob es mit C dauerhaft erreicht möchte ich auch stark bezweifeln. Das Betriebssystem und seine zahlreichen bekannten und unbekannten Hintergrund-Prozesse/Threads dürften da Einfluß nehmen. Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
mruniversum Geschrieben August 4, 2012 at 08:51 Autor Share Geschrieben August 4, 2012 at 08:51 Hi, ich wollte mich grade auch mal zurückmelden. root@raspi:/home/TF# time java -jar /home/TF/temp/dist/temp.jar 22.93 real 0m4.424s user 0m3.480s sys 0m0.450s also hatte ich sogar noch untertrieben. scheinbar bin ich der einzigste wo das so langsam ist? Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
Nic Geschrieben August 4, 2012 at 09:10 Share Geschrieben August 4, 2012 at 09:10 verstehe nicht, was soll das heißen: real, user , sys ? Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
Nic Geschrieben August 4, 2012 at 09:21 Share Geschrieben August 4, 2012 at 09:21 Aha, verstehe: http://stackoverflow.com/questions/556405/what-do-real-user-and-sys-mean-in-the-output-of-time1 Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
mruniversum Geschrieben August 5, 2012 at 08:57 Autor Share Geschrieben August 5, 2012 at 08:57 gibt es andere erfahrungswerte mit dem raspi und javaabfragen bez. der laufzeit? Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
kuli Geschrieben August 5, 2012 at 10:48 Share Geschrieben August 5, 2012 at 10:48 du misst hier die gesamte ausführungszeit des programms. d.h. es muss geladen werden, dann wird irgendwann die ipconnection initialisiert, ... und dann erst wird die methode aufgerufen. von daher finde ich die zeiten nicht so merkwürdig. wenn du die zeit für den methodenaufruf selbst wissen willst, musst du das über die programmiersprache lösen. in java geht das mit System.nanoTime() Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
mruniversum Geschrieben August 5, 2012 at 12:04 Autor Share Geschrieben August 5, 2012 at 12:04 also am pc ist es erheblich schneller: user@pc1:~/NetBeansProjects$ time java -jar temp/dist/temp.jar 24.75 real 0m0.441s user 0m0.120s sys 0m0.020s liegt das rein an der leistung vom system? also kann ich davon ausgehen dass am raspi keine schnellere abfrage möglich ist? geht mir darum zu erfahren, ob das so korrekt ist, oder ob mein system nicht korrekt arbeitet... Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
kuli Geschrieben August 5, 2012 at 12:50 Share Geschrieben August 5, 2012 at 12:50 ja das lieg wahrscheinlich an der leistung des systems. aber wie gesagt, die meiste zeit geht beim laden und initialisieren verloren. wenn das programm mal läuft, gehen die einzelnen abfragen bestimmt schneller. mach mal eine messung vom methodenaufruf selbst! ist es notwendig dass du bei jeder abfrage das programm erneut starten musst? Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
mruniversum Geschrieben August 6, 2012 at 19:16 Autor Share Geschrieben August 6, 2012 at 19:16 Hi, ist es notwendig dass du bei jeder abfrage das programm erneut starten musst? ich habe mir angewöhnt java nur als schnittstelle für die TF komponenten zu nutzen. die meiste logik packe ich dann in shellscripte, da diese doch erheblich einfacher sind und man "mal schnell" was ändern / ausprobieren kann. bin z.b. grade dran, das relais-bricklet online-fähig zu machen: root@raspi:/tmp# time java -jar /tmp/JARs/relais/relais.jar 3 [relay1 = true, relay2 = true] mit dem aufruf von "relais.jar 3" gebe ich mir den status der relais aus. "relais.jar 1 1" schaltet beide relais ein, "relais.jar 2 0" lässt das erste relais unverändert, und schaltet das zweite aus. also 0 = aus, 1 = ein, 2 = nichts ändern, 3 = status anzeigen. nun kann ich über "exec" per php ein kleines shellscript starten, und mit dem relais den taster vom garagentorantrieb schalten. aufruf der url dann natürlich per smarthone, da der normale handsender erst funktioniert wenn man schon davor steht ;-) Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
Nic Geschrieben August 6, 2012 at 19:26 Share Geschrieben August 6, 2012 at 19:26 Das ist zu umständlich, und dürfte die Ursache für die schwache Performance sein. Es gibt übrigens PHP-Bindings hier im Portal mit denen Du direkt auf die TF-Teile zugreifen kannst. Wieso über java extra gehen ?! http://www.tinkerforge.com/doc/Software/Bricklets/DualRelay_Bricklet_PHP.html#dual-relay-bricklet-php Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
AuronX Geschrieben August 6, 2012 at 19:44 Share Geschrieben August 6, 2012 at 19:44 Ich würde auch empfehlen entweder direkt PHP-Bindings zu nutzen. Ansonsten ist die unnötige Rechenarbeit riesig: - Prozess erzeugen - Programm vom Speicher (SD/HDD) laden - TCP-Verbindung aufbauen Die beiden letzten Punkte bedeuten jeweils unnötigen IO. IO ist immer langsam ^^ Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.