Verfasst am: 25.01.2016, 18:13
Titel: Nutzung von parfor oder smpd für ARIMA
Ich möchte gerne parfor für parallelle Berechnungen nutzen.
Der Matlab Code läuft ja sequetiell ab.
Nur in Schleifen würde dann parfor zum Einsatz kommen, um die 2 Rechenkerne der CPU auszunutzen. In meinem Fall vielleicht gerade-s: 1. Kern, ungerade-s: 2. Kern. (s = max. 3 im Code)
Ich habe keinerlei Erfahrungen mit parfor.
Die einfachste und schnellste Lösung erscheint mir jedoch damit.
Leider verweigert er parfor bei diesem Code mit der Fehlerausgabe:
Code:
Error: The variable f in a parfor cannot be classified.
%% dient zur Erzeugung von Randwerten um den Code lauffähig zu gestalten for s = 1:n
for i = 1:1000
randwerte(i,1) = rand(1) * 100;
end
data{s}.werte = randwerte;
end
% Matrix definieren
matrix = 5;
L = zeros(matrix, matrix);
P = zeros(matrix, matrix);
%% der eigentliche rechenaufwentige Code (hier möchte ich gerne Rechenzeit einsparen durch Einsatz von parfor oder smpd)
%% Prolbem: die einfachste Lösung mit parfor geht nicht, und ich weiß nicht warum? tic for s = 1:n
for p = 1:matrix
for q = 1:matrix %% hier wurde mit parfor alles mögliche versucht !
model = arima(p, 0, q);
[f{s}, ~, l{s}] = estimate(model, data{s}.werte, 'print', false);
L(p, q) = l{s};
P(p, q) = p + q;
end
L1{s} = L;
P1{s} = P;
end end toc
Verfasst am: 26.01.2016, 19:28
Titel: Re: Nutzung von parfor oder smpd für ARIMA
Hallo tommylabamba,
Einerseits würde ich f und l noch als CELL initialisieren. Andererseits bleibt dann das Problem, dass f{s} in jeder Iteration der inneren Schleifen überschrieben wird. Wenn Du das dann parallelisierst, ist es zufällig, welchen Wert f{s} am Schluss hat.
Welchen Wert möchtest Du denn in f{s} stehen haben?
Ich habe das hier als Lösungsvorschlag gefunden, kann damit aber nichts anfangen:
"All variables written to within the body of a parfor loop must be analysed and
put into one of the categories. Usually, when you're writing to a variable, you
want it to be "sliced" - that means that each iteration of the loop supplies one
value (or a set of values). For the analysis to deduce that's what's happening,
the variable that you write to must be indexed with one of the indices being the
loop variable, and the other indices being the same for each iteration. E.g:
You've got two rule violations here - firstly, you've got two varying indices,
and secondly, the indices are not simply the loop variable "i"."
Zurück zu Deiner Frage:
s hat die Werte 1 bis 3, also im Prinzip durchlaufe ich momentan 3 mal die gleiche Schleife mit anderen Werten in struct mit 1 Kern. Und das dauert ganz schön lange, wenn ich matrix = 10 erhöhe.
Den oberen Vorschlag (in Englisch) verstehe ich so, das ich jede Spalte und Zeile einzeln indexieren muss. Das habe ich versucht, geht trotzdem nicht, weil ich denke, das Matlab s in der inneren Schleife nicht mehr kennt.
Das habe ich versucht, geht trotzdem nicht, weil ich denke, das Matlab s in der inneren Schleife nicht mehr kennt.
Ohne Kristall-Kugel kann ich nicht sehen, was Du versucht hast und woran es gescheitert ist. Die Idee, dass "Matlab in der inneren Schleife s nicht mehr kennt" ist nicht plausibel. Matlab vergisst keine Variablen.
Ich wiederhole nochmal meinen Lösungsvorschlag, denn er ist offenbar nicht bei Dir angekommen:
Code:
for q = 1:matrix %% hier wurde mit parfor alles mögliche versucht !
model = arima(p, 0, q);
[f{s}, ~, l{s}] = estimate(model, data{s}.werte, 'print', false);
end
Hier wird f{s} immer wieder überschrieben. In einer FOR-Schleife wird zum Schluss der Wert von "q=matrix" in f{s} stehen. In einer PARFOR-Schleife wird aber der Body der Schleife eben nicht sequentiell bearbeitet, sondern parallel. Deshalb ist nicht definiert, welcher Wert zum Schluss in f{s} stehen wird. Matlab muss aber annehmen, dass der Wert dieser Variablen von Interesse ist, sonst würdet Du ihn ja nicht in einem Cell-Array speichern.
Deshalb nochmal: Brauchst Du den Wert von f{s} später und ist es sinnvoll, dass er immer wieder überschrieben wird? Wenn Du die innere Schleife per PARFOR parallelisieren möchtest, muss das an f{s} und l{s} scheitern, da Matlab nicht dafür sorgen kann, dass die gleichen Werte wie beim sequentiellen FOR drin stehen. Ersetze also f{s} und l{s} durch etwas, was Du eigentlich brauchst. Vielleicht: f{s, p, q}. Dann wäre wieder alles eindeutig. (Pre-allocation nicht vergessen)
Wenn dies eine FOR-Schleife ist, wird v den Wert 5 haben. In einer PARFOR-Schleife ist der Endwert aber zufällig eine der Zahlen 1 bis 5. Das hängt nur davon ab, welcher Thread zufällig am längsten braucht. Und hier sollte Matlab die Arbeit verweigern, denn solche zufälligen Endwerte sind sinnlos.
f{s} oder irgendeine andere Variable in jeder PARFOR-Iteration zu überschreiben, ist also ein grundsätzliches Problem. "data{s}.f" würde genau das selbe Problem erzeugen.
Wird es jetzt klarer? Ausprobieren kann ich es nicht, da ich die benötigten Toolboxen nicht habe.
Gruß, Jan
Einstellungen und Berechtigungen
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.
RSS