2016-11-15 5 views
1

Old Titel: * Kleine Matrixmultiplikation viel langsamer in R2016b als R2016a * (Update unten)Large Workspace-Variablen beeinflussen Multiplikation Laufzeit der unabhängigen Variablen

Ich finde, dass die Multiplikation der kleinen Matrizen scheint viel kleiner R2016b als R2016a. Hier ist ein minimales Beispiel:

r = rand(50,100); 
s = rand(100,100); 
tic; r * s; toc 

Dieser Vorgang dauert etwa 0.0012s in R2016a und 0.018s R2016b.

eine künstliche Schleife erstellen, um sicherzustellen, das ist nicht nur ein paar anfängliche Aufwand oder etwas auf den gleichen Verlustfaktor führt:

tic; for i = 1:1000, a = r*s; end, toc 

Dieser Vorgang dauert etwa 0.18s in R2016a und 2.1s R2016b.

Sobald ich die Matrizen viel größer machen, sagen r = rand(500,1000); und s = rand(1000,1000), verhält sich die Version ähnlich (R2016b scheint sogar ~ 15% schneller). Hat jemand einen Einblick, warum dies so ist, oder kann dieses Verhalten auf einem anderen System verifiziert werden?

Ich frage mich, ob es mit der neuen Rechen Erweiterungen Implementierung zu tun hat (wenn diese Funktion einige Kosten für kleine Matrixmultiplikation hat): http://blogs.mathworks.com/loren/2016/10/24/matlab-arithmetic-expands-in-r2016b/


Update

Nach vielen Tests, ich stellte fest, dass dieser Unterschied nicht zwischen MATLAB-Versionen lag (ich entschuldige mich). Stattdessen scheint es ein Unterschied zu sein, was sich in meinem Basisarbeitsbereich befindet ... und schlimmer noch, der Typ der Variablen im Basisarbeitsbereich.

Ich räumte einen riesigen Arbeitsbereich (der viele große Zellenarrays mit vielen kleinen, unterschiedlich großen Matrixeinträgen hatte). Wenn ich die Variablen lösche und das Timing von r * s mache, bekomme ich eine viel schnellere Laufzeit (x10-x100) als vor dem Laden des Workspace.

Die Frage ist also, warum wirkt sich das Vorhandensein von Variablen im Arbeitsbereich auf die Matrixmultiplikation zweier kleiner Variablen aus? Und noch wichtiger: Warum verlangsamen bestimmte Arten von Variablen den Arbeitsbereich dramatisch?

Hier ist ein Beispiel, in dem eine große Variable in Zellenform im Arbeitsbereich die Laufzeit der Matrixmultiplikation oder zwei nicht verwandte Matrizen beeinflusst. Wenn ich diese Zelle zu einer Matrix zusammenfasse, verschwindet der Effekt.

clear; 
ticReps = 10000; 
nCells = 100; 
aa = rand(50,100); 
bb = rand(100, 100); 

% test original timing 
tic; for i = 1:ticReps, aa * bb; end 
fprintf('original: %3.3f\n', toc); 

% make some matrices inside a large number of cells 
q = cell(nCells, nCells); 
for i = 1:nCells * nCells 
    q{i} = sprand(10000,10000, 0.0001); 
end 

% the timing again 
tic; for i = 1:ticReps, aa * bb; end 
fprintf('after large q cell: %3.3f\n', toc); 

% make q into a matrix 
q = cat(2, q{:}); 

% the timing again 
tic; for i = 1:ticReps, aa * bb; end 
fprintf('after large q matrix: %3.3f\n', toc); 

clear q 
% the timing again 
tic; for i = 1:ticReps, aa * bb; end 
fprintf('after clear q: %3.3f\n', toc); 

In beiden inszeniert, nimmt q etwa 2 GB. Ergebnis:

original: 0.183 
after large q cell: 0.320 
after large q matrix: 0.175 
after clear q: 0.184 
+3

Ich vermute, dass nur die MathWorks diese Frage vollständig beantworten konnte.Allerdings würde ich empfehlen, mit "Zeit" genau die Ausführungszeiten zu messen, vor allem für kleine Berechnungen. – horchler

+0

Ich stimme zu, dass MathWorks die wichtigsten Leute sind, die antworten können. Ich habe gerade nach Matlab Central gefragt. Danke für den "Zeit-Vorschlag" - die Ergebnisse scheinen mit dem obigen "tic"/"toc" übereinzustimmen. – adalca

+0

Ich habe das gerade auf MacOS X versucht und kann nicht bestätigen ... – zeeMonkeez

Antwort

0

Ich habe ein Update von Mathworks erhalten.

So weit ich es verstehe, sagen sie, dass dies der Fehler des Windows-Speicher-Managers ist, der Speicher zu großen Zell-Arrays in einer ziemlich fragmentierten Weise zuweist. Da die (nicht zusammenhängende) Multiplikation Speicher (für die Ausgabe) benötigt, dauert das Abrufen dieses Speicherstücks aufgrund der Speicherfragmentierung, die durch die Zelle verursacht wird, länger. Linux (wie getestet) hat dieses Problem nicht.

Verwandte Themen