Verfasst am: 24.06.2009, 16:07
Titel: Kann man aus einer m-file eine mex32-Komplilat erzeugen?
Hallo,
ich hab das Problem, dass mein Programm durch die Nutzung von while-Schleifen recht stark verlangsamt wird (lt. profile viewer), ich hab mir gedacht, dass durch Kompilieren evtl. ein Geschwindigkeitsvorteil entsteht.
Zuerst hab ich eine Funktion zur exe gemacht. Komplilieren klappt, nur leider habe ich es nicht geschafft, diese exe-Funktion Werte zu übergeben...
Jetzt dachte ich mir, da mcc c-Files hinterlassen hat, wird das wohl mex-mässiger Code sein (also, ich hab davon keinen Plan), welche sich aber mit "mex -g hitsorted_main.c" nicht zu einer mex32-Funktion komplilieren lassen.
Geht sowas gar nicht ? muss ich meine Funktion nach C/mex portieren ?
Bringt das überhaupt was ?
Ob als EXE oder Library (mit dem MATLAB Compiler erstellt) - der M-code nutzt die MATLAB Component Runtime Umgebung und ist damit normalerweise genauso schnell oder langsam wie mit MATLAB der gleichen Hardware.
Aber es gibt natücliich jede Menge Möglichkeiten MATLAB Code zu beschleunigen. Wo ist den das Hauptproblem? Speicherverbrauch und damit verbunden swapping, oder "normale" Laufzeitprobleme. Was sagt den der MATLAB Profiler wo der Flaschenhals ist?
Danke für die schnelle Antwort !
Okay, dann quäl ich mich erst mit dem Kompilieren rum, wenn's fertig ist !
Also, zeitkritisch ist mein Problem an folgender Stelle:
Ich habe zwei Listen mit Koordinaten, gleiche Koordinaten sollen ausgegeben werden.
um nicht jedes Element mit jedem zu verglichen, hab ich die Listen sortiert, hole mir die erste x-Koordinate und gehe dann die zweite Liste durch, bis zur Übereinstimmung der x-Koordiante, dann überprüfe ich alle anderen Koordinaten. Andererseits überspringe ich in der ersten Liste Vergleiche, sollte dort die (neue) x-Koordinate der zweiten nicht vorhanden sein.
Das ganze löse ich über while-Schleifen, kombiniert mit ein paar if's, um die Endbedingungen zu finden (also Listenende).
Ich hoffe das war jetzt halbwegs verständlich...
Oder gibt es dafür schon eine fertige Implementation ?
Wie gesagt, der Profiler findet den Zeitverbrauch halt in den Schleifenköpfen. Obiges Problem entstand nur durch den Kampf gegen den Speicherverbrauch
swapping tritt nicht auf.
Ich würde mal behaupten der UNIQUE Befehl macht das ganze schneller. Vielleicht kann SORT auch irgendwo nützlich sein. Bei Performance-Erfolg bitte unbedingt berichten!
unique geht ja nur bei einer Matrix, ich hab mir mal die querverweise dazu durchgelesen, und bin fündig geworden:
intersect(A,B,'rows') ist das, was ich brauche.
Grad noch gefreut, schon wieder - die Prozedur braucht etwa 50% länger wie mein Suchalgorithmus...
Ja, die Daten waren nur ein gaanz Beispiel um die Datenstruktur zu zeigen...
Diese Berrechnung wird dann, wenn's fertig ist, ein paar Millionen Mal durchgeführt... Also, dass es lange dauert ist schon klar, es soll sich halt irgendwie in Grenzen halten...
Ich verstehe noch nicht, ob "treffer" in beiden Beispielen wirklich leer sein soll, schliesslich gibt es ja Koorinaten die doppelt auftreten. D.h der Code nach der IF Abfrage
Code:
if matter(idxm,1)==object(idxo,1) && matter(idxm,2)==object(idxo,2) && matter(idxm,3)==object(idxo,3)
muss verstanden werden um eine Aussage über den Gesamtcode zu erzielen. Ich kann mit vorstellen, dass bei sehr grossen Datenmengen folgender Trick eine bessere Performance erzielt als die riesige WHILE IF Schleife: Falls es einen technisch eindeutigen Höchstwert für alle Koordinaten gibt, könnten diese in eine eineindeutige Zahl umgewandelt werden. Beispiel, der Höchstewert ist 100, dann kann die eineindeutige Repräsentation durch x*100*100+y*100+z berechenet werden. Dann könnten wiederum MATLAB performance optimierte Routinen eingesetzt werden. Aber das kann dann schön viel Speicher fressen. Daher bitte 64 Bit MATLAB einsetzen.
Wie meinst du Treffer muss leer sein ?
Ich hab den nur mit zeros initialisiert, um Zeit durch dynamische Vergrösserung zu sparen.
Am Ende werden dann alle Zeichen nach der i-ten gelöscht.
Ich will ja quasi die Koordinaten finden, die in beiden doppelt auftreten. (oder gibt's in den Beispieldaten auch doppelte? )
Die Sache mit x*100*100 ist ne gute Idee, aber die zeitraubenden while-Schleifen nach o.g. if bleiben ja noch.
Vielleicht gehts schneller, wenn ich's dir in Echtzeit erklären kann ? - Wenn du magst, schick mir einfach deinen skype-Namen !
Do, nachdem bei grösseren Matrizen auch mein Code versagt, hab ich mir "intersect" und das darin genutzte sortrows genauer angesehen, das ist das Ergebnis:
Code:
c = [a;b];
c = c ( sort_back_to_front(c) , : );
% Find matching entries in sorted rows. [rowsC,colsC] = size(c);
if rowsC > 1 && colsC ~= 0 % d indicates the location of matching entries
d = c(1:rowsC-1,1:3) == c(2:rowsC,1:3);
else
d = zeros(rowsC-1,0);
end
c = c(d,:); % Intersect is list of matching entries
function ndx = sort_back_to_front(x) % NDX = SORT_BACK_TO_FRONT(X) sorts the rows of X by sorting each column % from back to front. This is the sortrows algorithm used in MATLAB 6.0 % and earlier.
[m,n] = size(x);
ndx = (1:m)';
for k = n-1:-1:1 [ignore,ind] = sort(x(ndx,k));
ndx = ndx(ind);
end
Du kannst Beiträge in dieses Forum schreiben. Du kannst auf Beiträge in diesem Forum antworten. Du kannst deine Beiträge in diesem Forum nicht bearbeiten. Du kannst deine Beiträge in diesem Forum nicht löschen. Du kannst an Umfragen in diesem Forum nicht mitmachen. Du kannst Dateien in diesem Forum posten Du kannst Dateien in diesem Forum herunterladen
MATLAB, Simulink, Stateflow, Handle Graphics, Real-Time Workshop, SimBiology, SimHydraulics, SimEvents, and xPC TargetBox are registered trademarks and The MathWorks, the L-shaped membrane logo, and Embedded MATLAB are trademarks of The MathWorks, Inc.
- die Prozedur braucht etwa 50% länger wie mein Suchalgorithmus...
)
RSS