Hallo, Ich habe Messwerte die in Matlab akquiriert werden, und da gleich vorverarbeitet, bevor sie gespeichert werden. Das komische ist, dass als ich meinen Code auf uint16 umgestellt habe um Speicher und Zeit zu sparen, ging nix mehr, da plötzlich 30% mehr Rechenzeit für einfache Additionen benötigt werden (32 bit Matlab unter 64 bit Windows). Auch zwischen Single und Double ergibt sich sogut wie kein Performance-Unterschied. Weiß jemand was dafür der Grund ist? (Der Code bekommt uint8 Daten vom Messgerät, wandelt die in uint16/single/double um, addiert 10 folgende Werte, und speichert sie dann als 1 Wert in einem uint16/single/double array). Weiß jemand was da der Hintergrund ist?
Was spricht gegen einen richtigen Compiler ? Sofern die Berechnungen nicht zu kompliziert sind bietet Matlab keinerlei Vorteil. Von den rabbiaten Lizenzkosten mal abgesehen. Die Kommunikation mit der Umwelt ist auch besser mit einem richtigen compiler.
Naja, Danke für Deinen guten Willen, aber das hilft mir nicht die Bohne. Gegen den Compiler spricht, dass die Hardware in Matlab sehr gut vernetzt werden kann, und es schnell möglich ist, auf plötzliche Probleme während des Experiments zu reagieren. Zudem kenne ich mich mit Matlab mit Abstand am besten aus, ein Wechsel hätte diverse Probleme. Nicht zuletzt, dass die Analyse mit keiner vergleichbaren Software später so gut möglich ist.
Aha. ok. Was bietet Matlab denn fuer Debug Funktionalitaeten ? Zur Mittelwertbildung wuerde ich uebrigens einen exponentiellen Mittelwert vorziehen. Auf einer 32bit Maschine ist Byte, Word und Longword eh dasselbe an Geschwindigkeit.
Koennte mir vorstellen, das vielleicht ohne dass Du es willst, irgendwo (zB durch eine Division durch eine Double-Konstante) der Datentyp implizit in Double und wieder zurueck gewandelt wird. Das wuerde dann mehr statt weniger Aufwand bedeuten.
Matlab rechnet doch intern nahezu immer mit double. Wahrscheinlich findet in Deinem Code irgendwo eine implizite Konvertierung statt, so dass Du mit integer input Daten kein Geschwindigkeitsvorteil hast. Ansonsten könnte man sicher auch an Deinem Code noch was optimieren - stell doch mal die relevanten Stellen hier ein.
Hmm, es scheint wirklich das Problem zu sein, dass Matlab mit integer langsamer ist. Ich habe den Code jetzt so geändert, dass mit Single gerechnet wird, das spart gerade genug Speicher und ist halbwegs schnell. 10 Sekunden Rechenzeit für 180 s Aufnahmedauer, das reicht gerade so. Immerhin besser als die ursprünglichen 80 s... Da kam er nicht mehr hinterher.
Tine Schwerzel schrieb: > Hmm, es scheint wirklich das Problem zu sein, dass Matlab mit integer > langsamer ist. Ich habe den Code jetzt so geändert, dass mit Single > gerechnet wird, das spart gerade genug Speicher und ist halbwegs > schnell. 10 Sekunden Rechenzeit für 180 s Aufnahmedauer, das reicht > gerade so. Immerhin besser als die ursprünglichen 80 s... Da kam er > nicht mehr hinterher. Dann hast du effektiv ein Problem. Dein PC ist mit (geratenen) 3Ghz rund 187 mal so schnell wie ein mit 16Mhz getakteter AVR. Von der Limitierung durch die Datenübertragung reden wir erst mal gar nicht. Wenn du es schaffst einen PC mit einer simplen Mittelwertberechnung von einem AVR aus lahm zu legen, dann machst du etwas grundsätzlich entsetzlich falsch.
Hab ich irgendwo gesagt dass ich einen Mittelwert berechne? Es handelt sich um 248832000 Mittelwerte in 180 s plus die ActiveX-Datenaufnahme und Variablenzuweisungen.
Naja, und Matlab ist halt auch um einiges langsamer, als wenn man Compilierten Code ausführen würde.
Klaus schrieb: > Naja, und Matlab ist halt auch um einiges langsamer, als wenn man > Compilierten Code ausführen würde. Das halte ich mitlerweile für ein Gerücht. Das hängt -wie so vieles- vom Einzelfall ab. Für mittelgroße Gleichungssysteme (ca. 500000 Freiheitsgrade) muß der Fortran- oder C++-Programmierer schon sehr gut sein, um einen ordentlichen Matlab-Code abzuhängen - und wird wahrscheinlich auch deutlich länger dazu brauchen. Viele Grüße Nicolas
Matlab wird mit 'for'-Schleifen etc. langsam. Nahezu alles ist in Matlab in Matrixarithmetik ohne Schleifen programmierbar, das bringt mehr als die Typefummelei. Cheers Detlef
Tine Schwerzel schrieb: > Hab ich irgendwo gesagt dass ich einen Mittelwert berechne? Solange du nicht endlich mal irgendwas Codemässiges herzeigst, kann man im Grunde gar nichts sagen, sondern nur raten. Wenn du nicht willst, das hier wieder mal die Raterunden eingeläutet werden und dir jemand brauchbare, verwertbare Tips geben soll, dann zeig endlich deinen Code. Das ist doch nicht so schwer zu kapieren. Aber nicht wieder Winzigausschnitte, sondern nach Möglichkeit alles. Wenn man Zeit sucht, muss man oft das ganze Programm betrachten. Wenn man Zeit sucht, fängt man auf der algorithmischen Ebene an. Deine 180s kannst du dir in die Haare schmieren, weil kein Mensch weiß, welche Datenmenge da rein kommt. Schickt dein AVR jede Sekunde einen Datenwert, dann sind da ein paar MIttelwerte wohl etwas lächerlich. Schickt er in der Sekunde 1 Million Datenwerte, dann wirds schon spannender. Von daher sind die 180 Sekunden ein Zahlenwert, ja was denn eigentlich, ein Zahlenwert wie ihn Politiker benutzen: Sieht gut aus, ist aber nichtssagend.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.