Matrisberäkningar med för STM32?

[Al_Bundy]

För annars kan jag inte ha min 2D array där.

[ahlsten]

Du behöver inte dela upp minnet manuellt för att uppnå målen i många av de där standarderna, det räcker att du bara använder exempelvis malloc under initiering och sen återanvänder. Innebär att funktioner får även temporära matriser och eventuell returmatris inskickade som argument, så kan du hålla koll på vad som används var. Men risken för svårdebuggade fel pga minnesläckor bör bli mindre.

Det skulle till exempel kunna betyda att du aldrig använder malloc i ditt bibliotek, men applikationen som använder sig av det initierar matriser med det innan reglerloopen snurrar.

[Al_Bundy]

Jag tror att det blir svårt och väldigt svår att få det enkelt. Man vill ju endast skriva av MATLAB kod som C-kod och sedan bara köra programmet.

Jag testade ta bort alla freeMatrix-funktioner här, Det blev ingen skillnad i hastighet. Det är svd.c som drar mest minne. Tar jag bort SVD och kör utan svd så kommer jag ned till 0.000002 sekunder.
Orsaken ligger i qr.c filen. Denna slukar mycket tid.

Kod: Markera allt

void svd(matrix* a, matrix* u, matrix* s, matrix* v){
	// Find data of matrix 'a'
	int n = a->row;
	int m = a->column;
	matrix* t; // Temporary matrix

	/*
	 * Initial declaration of values
	 */
	// Copy eye matrix to u
	t = eye(n, n);
	copyval(t, u);
	freeMatrix(t);

	// Copy transpose of 'a' to s
	t = tran(a);
	copyval(t, s);
	freeMatrix(t);

	// Copy eye matrix to v
	t = eye(m, m);
	copyval(t, v);
	freeMatrix(t);

	// Init q and r matrix for QR-facorization
	matrix* q = initMatrix(n,m);
	matrix* r = initMatrix(n,m);

	// Do while loop where we compute u,s,v
	for(int i = 0; i < 50; i++){
		// Solve QR from transpose of s
		t = tran(s);
		qr(t, q, r);
		freeMatrix(t);

		// Copy values from r to s
		copyval(r, s); // We do not need to delete r matrix yet

		// Copy u = u*q
		t = mul(u, q, false); // Not element wise
		copyval(t, u);
		freeMatrix(t);

		// Solve QR from transpose of s
		t = tran(s);
		qr(t, q, r);
		freeMatrix(t);

		// Copy values from r to s
		copyval(r, s); // We do not need to delete r matrix yet

		// Copy v = v*q
		t = mul(v, q, false);
		copyval(t, v);
		freeMatrix(t);

	}

	// Now we can delete r and q
	freeMatrix(q);
	freeMatrix(r);

	// Fix the s and v matrix, turn all the non-diagonal to zeros
	float* ptr_s = s->data;
	float* ptr_v = v->data;
	int n_s = s->row;
	int m_s = s->column;
	for(int i = 0; i < n_s; i++){
		for(int j = 0; j < m_s; j++){
			if(j != i){
				*((ptr_s + i*n) + j) = 0; // Non-diagonal need to be zeros
			}else{
				*((ptr_s + i*n) + j) = -*((ptr_s + i*n) + j); // They are negative, turn them positive
			}
			*((ptr_v + i*n) + j) = - *((ptr_v + i*n) + j); // Important to shift the v-values
		}
	}
}

[mankan]

Jag skyller på bekvämligheter. Det är svårt att skapa ett bibliotek som använder sig av statiska matriser.

Jag tror vi alla skjuter över målet då herr Bundy inte förstått skillnaden mellan stackminne och dynamiskt allokerat minne. Som trådens historia visat så får vi låta insikterna sjunka in i hans egen takt. Eller studsa ut i intet till den dagen han förstår att Matlab-syntaxen kostar för mycket i prestanda. Själv är jag övertygad om att med välskriven C++ kan fixa det mesta av detta biblioteks problem då faktiskt templates och klasser kan underlätta en hel del. Och för att mota Olle i grind, ja man kan använda C++ på STM32, det handlar bara om att veta hur.

[Shimonu]

Jag oroar mig för att han kommer slänga ur sig hur ineffektivt C är för han försökte minsann optimera och göra det bra men det blev aldrig snabbt... Men det är som att prata med en vägg ibland

.

[Al_Bundy]

Nej nej. Jag är nöjd med C. Som jag skrev innan, då många varken läser mina inlägg, så anser jag att om jag vill snabba på mina beräkningar så får jag använda rekursiv linjär algebra.

Då behöver man bara anropa vissa funktioner en gång och aldrig mer.

[Al_Bundy]

Jag skyller på bekvämligheter. Det är svårt att skapa ett bibliotek som använder sig av statiska matriser.

Jag tror vi alla skjuter över målet då herr Bundy inte förstått skillnaden mellan stackminne och dynamiskt allokerat minne. Som trådens historia visat så får vi låta insikterna sjunka in i hans egen takt. Eller studsa ut i intet till den dagen han förstår att Matlab-syntaxen kostar för mycket i prestanda. Själv är jag övertygad om att med välskriven C++ kan fixa det mesta av detta biblioteks problem då faktiskt templates och klasser kan underlätta en hel del. Och för att mota Olle i grind, ja man kan använda C++ på STM32, det handlar bara om att veta hur.

Högerklicka Convert -> To C++ Project via System Workbench. Då har man C++. Men fortfarande så kommer det bli samma sak med C och C++ med 2D matriser.

[hummel]

Men frågan är hur mycket tid jag vinner. Jag kanske förlorar tid. Jag vet varför malloc inte ska användas inom inbyggda system och det har med att det kan vara lättare att göra fel med minnet om man inte hanterar det.

Det stämmer inte riktigt. Anledningen är att du ofta är relativt begränsad med vad gäller minne och resurser samt att inbyggda system ofta är realtidssystem vilket då kan ställa till det eftersom dynamisk minnesallokering inte är deterministisk.

[Al_Bundy]

Det stämmer inte riktigt. Anledningen är att du ofta är relativt begränsad med vad gäller minne och resurser samt att inbyggda system ofta är realtidssystem vilket då kan ställa till det eftersom dynamisk minnesallokering inte är deterministisk.

Jag känner till ordet deterministisk inom reglerteori, men inte inom datavärlden. Kan du utveckla?

[hawkan]

Deterministisk i meningen vilken tid det tar att få den minnesstumpen som efterfrågas.
Men jag tycker du gör rätt. Identifiera vilken funktion som tar tid och ge dej på.den.

[Al_Bundy]

Okej. Så du menar att om jag vill ha 10 byte minne, så tar det en viss tid, så jag kanske får 9 byte minne i praktiken?

I detta fall så är det svd.c och qr.c som super mest tid. Egentligen så är det bara qr.c som suger mest tid då svd.c använder sig av qr.c 50 gånger.

Problemet är att jag använder modiferade Gram-Schmidt QR-faktorisering, vilket är typ den näst enklaste och näst noggrannaste QR-faktoriseringsmetoden. Det finns mer noggrannare, men skillnaden är e-16 jämfört med e-17. Dvs ingen skillnad alls i praktiken.

Sedan är det allmänt känt enligt vanliga linjär algebraböcker att QR-faktorisering är energikäravande och det är inget man kommer undan med, om man inte använder rekursiva metoder.

[Mr Andersson]

> Okej. Så du menar att om jag vill ha 10 byte minne, så tar det en viss tid, så jag kanske får 9 byte minne i praktiken?
Nej begär du 10 byte så får du antingen 10 eller 0 byte, ingenting mitt emellan. Däremot så kan det skilja väsentligt i hur lång tid allokeringen tar beroende på hur mycket av minnet som redan är använt och minnesfragmentering.

[mankan]

Det vore intressant att få veta prestandasiffror på STM32 så posta gärna här Al när du har testat.

[mankan]

Om du gör en ny version av cut som du använder internt i t.ex. qr funktionen så kan du slippa malloc.

Kod: Markera allt

matrix* cutNoMalloc(matrix* a, int start_n, int stop_n, int start_m, int stop_m, matrix* out)

Implementationen jämfört med vanliga cut: ta bort första raden och behåll resten.

Sedan anropar du den så här:

Kod: Markera allt

float c2Data[n + 1];
matrix c2Stack = { n + 1, 1, c2Data};
matrix* c2 = &c2Stack;
c2 = cutNoMalloc(q, 0, n, k,k, c2);

Glöm inte att ta bort anropet till freeMatrix(c2) också.

Det går säkert skriva kortare och även göra ett makro för att snygga till det hela.

[Al_Bundy]

Det vore intressant att få veta prestandasiffror på STM32 så posta gärna här Al när du har testat.

Nu hinner jag inte det imorgon då jag ska köra skoter hela dagen.

Men om någon har tid och lust att testa så vore detta uppskattat.

Det jag ska göra senare med detta bibliotek är att kunna anpassa det för deep learning via XOR metoden.