dask.array.reshape sehr langsam

Question

Ich habe ein Array, das ich aufbauen iterativ wie folgt:

step1.shape = (200,200) 
step2.shape = (200,200,200) 
step3.shape = (200,200,200,200) 

und dann umformen zu:

step4.shape = (200,200**3) 

ich dies tun, weil dask.array.atop scheint dir nicht zu erlauben, von einer Form wie dieser zu gehen: (200,200) -> (200,200 ** 2). Ich denke, das ist so, dass es mit Chunking und fauler Bewertung zu tun hat.

Wenn ich Step4 mache und versuche, es umzuformen, scheint dasask die Matrix vor der Umformung zu berechnen, was zu einer erheblichen Rechenzeit und Speicherauslastung führt.

Gibt es eine Möglichkeit, dies zu vermeiden?

Wie gewünscht, hier einige Dummy-Code:

def prod_mat(matrix_a,matrix_b): 
    #mat_a.shape = (300,...,300,200) 
    #mat_b.shape = (300, 200) 
    mat_a = matrix_a.reshape(-1,matrix_a.shape[-1]) 
    #mat_a = (300**n,200) 
    mat_b = matrix_b.reshape(-1,matrix_b.shape[-1]) 
    #mat_b = (300,200) 
    mat_temp = np.repeat(mat_a,matrix_b.shape[0],axis=0)*np.tile(mat_b.T,mat_a.shape[0]).T 
    new_dim = int(math.log(mat_temp.shape[0])/math.log(matrix_a.shape[0])) 
    new_shape = [matrix_a.shape[0] for n in range(new_dim)] 
    new_shape.append(-1) 
    result = mat_temp.reshape(tuple(new_shape)) 
    #result.shape = (300,...,300,300,200) 
    return result 

b = np.random.rand(300,200) 
b = da.from_array(b,chunks=100) 
c=da.atop(prod_mat,'ijk',b,'ik',b,'jk') 
d=da.atop(prod_mat,'ijkl',c,'ijl',b,'kl') 
e=da.atop(prod_mat,'ijklm',d,'ijkm',b,'lm') 
f = e.sum(axis=-1) 
f.reshape(300,300**3) ----> This is slow, as if it is using compute() 

Answer 1

Diese Berechnung nicht compute ruft stattdessen stecken es eine sehr sehr große Grafik zu machen. Im Allgemeinen ist das Umformen von parallelen Arrays ziemlich intensiv. Viele deiner kleinen Brocken sprechen mit deinen anderen kleinen Brocken und verursachen Chaos. Dieses Beispiel ist besonders schlecht.

Vielleicht gibt es eine andere Möglichkeit, Ihre Ausgabe zunächst in der richtigen Form zu produzieren?

Blick durch die Entwicklung logs es scheint, dass dieser Fehler tatsächlich während der Entwicklung erwartet: https://github.com/dask/dask/pull/758