Forum: Compiler & IDEs Lib Eigen (C++) auf STM32F429, Geschwindigkeit okay?


Lib Eigen (C++) auf STM32F429, Geschwindigkeit okay?
von Kaj G. (Firma: RUB) (bloody)

Lesenswert?
• ▲
▼ 
Hallo Forum,

ich verwende die Lib Eigen
http://eigen.tuxfamily.org/index.php?title=Main_Page

auf einem STM32F429 Discovery (CPU: STM32F429ZI)
https://www.st.com/en/evaluation-tools/32f429idiscovery.html

Genauer gesagt geht es um SVD (Singular value decomposition).
https://en.wikipedia.org/wiki/Singular_value_decomposition

Die Lib bietet 2 Funktion dafuer:
JacobiSVD und BDCSVD.
https://eigen.tuxfamily.org/dox/group__SVD__Module.html

JacobiSVD ist besser fuer kleine, BDCSVD besser fuer grosse Matrizen. 
Ich habe das ganze auch zum laufen bekommen, und mal die Unterschiede 
gemssen (Pin wackeln (PG2) und Logic Analyser).
1
Matrix  |BDCSVD  | JacobiSVD

2
        |t in ms | t in ms

3
---------------------------

4
5x5     |0.3     | 0.266

5
10x10   |1.9     | 1.8

6
15x15   |5.9     | 5.9

7
20x20   |13.8    | 13.8

8
25x25   |22.3    | 25.5

9
30x30   |33.9    | 43

10
35x35   |48      | 68.9

11
40x40   |63.7    | 102

12
45x45   |81.7    | 142

13
50x50   |114.2   | 200

14
55x55   |        | 257

15
60x60   |        | 347

16
65x65   |        | 420

17
70x70   |        | 530

18
75x75   |        | 676

19
80x80   |        | 774

20
85x85   |        | 961

21
90x90   |        | 1121

22
95x95   |        | 1333


Mit BDCSVD komme ich nur bis zu einer Matrizengroesse von ca. 55x50. 
Dann scheint der RAM knapp zu werden. Zumindestens wackelt der Pin nicht 
mehr. Mit JacobiSVD komme ich immerhin bis 95x95, dauert dann aber auch 
1,3 Sekunden. Hier ist dann auch Schluss mit der Groesse.

Die CPU ist auf 168MHz eingestellt.

Jetzt meine Fragen:
Sind die Zeiten "okay", also realistisch, oder sagt Ihr, das sollte 
eigentlich schneller gehen?
Und sind die Matrizengroessen okay, oder sollte da auch mehr gehen?

Der Code sieht im wesentlichen so aus:
1
#include "Eigen/Dense"

2
3
using namespace Eigen;

4
5
#define M_SIZE 50

6
7
int main(void)

8
{

9
    HAL_Init();

10
    SystemClock_Config();

11
12
    MX_GPIO_Init();

13
    MX_FMC_Init();

14
    MX_TIM1_Init();

15
16
    HAL_GPIO_WritePin(pin_out_GPIO_Port, pin_out_Pin, GPIO_PIN_SET);

17
18
    while (1)

19
    {

20
        MatrixXf A = MatrixXf::Random(M_SIZE, M_SIZE);

21
        VectorXf b = VectorXf::Random(M_SIZE);

22
23
        HAL_GPIO_WritePin(pin_out_GPIO_Port, pin_out_Pin, GPIO_PIN_RESET);

24
25
        A.bdcSvd(ComputeFullU | ComputeFullV).solve(b);

26
        //A.jacobiSvd(ComputeFullU | ComputeFullV).solve(b);

27
28
        HAL_GPIO_WritePin(pin_out_GPIO_Port, pin_out_Pin, GPIO_PIN_SET);

29
    }

30
}


Compileroptimierung steht auf -O3. Compiler ist arm-none-eabi-g++ (Arch 
Repository) 9.2.0

Wer es testen moechte, das Repo dazu findet sich hier:
https://gitlab.com/Bloody_Wulf/lda_svd

In dem Repo ist die Lib Eigen schon mit drin. Das Projekt wurde mit 
CubeMX erstellt. Compilieren mit 'make', flashen mit 'make flash'.

Freue mich auf Eure Antworten, Tipps und Hinweise.

Gruesse

  


  




  

    Beitrag melden Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Markierten Text zitieren Antwort Antwort mit Zitat
  







      

      



  

    Re: Lib Eigen (C++) auf STM32F429, Geschwindigkeit okay?
  


  

    

      von
      
        mh (Gast)
      
      


      
    


    

      
    

    

    

  
  


  

  Lesenswert?
  

  •
  
  ▲  
  

  ▼  
  		
  

  


  

      
Kaj G. schrieb:
> Sind die Zeiten "okay", also realistisch, oder sagt Ihr, das sollte
> eigentlich schneller gehen?
> Und sind die Matrizengroessen okay, oder sollte da auch mehr gehen?

Hast du dir da schon selbst ein paar Gedanken gemacht? Das ist kein 
Hexenwerk ...

  


  




  

    Beitrag melden Bearbeiten Löschen Markierten Text zitieren Antwort Antwort mit Zitat
  







      

      



  

    Re: Lib Eigen (C++) auf STM32F429, Geschwindigkeit okay?
  


  

    

      von
      
        abc (Gast)
      
      


      
    


    

      
    

    

    

  
  


  

  Lesenswert?
  

  •
  
  ▲  
  

  ▼  
  		
  

  


  

      
Kaj G. schrieb:
> Und sind die Matrizengroessen okay, oder sollte da auch mehr gehen?

Bei solchen Operationen solltest du dir mal C- und Assemblercode 
gleichzeitig ausgeben lassen und schauen, was er wirklich macht.

Gerade für den STM32 gibt es optimierte Bibliotheken, speziell im 
Kontext von Matritzenberechnungen (Stichwort: DSP-Befehle).

  


  




  

    Beitrag melden Bearbeiten Löschen Markierten Text zitieren Antwort Antwort mit Zitat
  







      

      



  

    Re: Lib Eigen (C++) auf STM32F429, Geschwindigkeit okay?
  


  

    

      von
      
        Johannes S. (Gast)
      
      


      
    


    

      
    

    

    

  
  


  

  Lesenswert?
  

  •
  
  ▲  
  

  ▼  
  		
  

  


  

      
Warum soll das überhaupt auf dem µC laufen? Die sind ja eigentlich nicht 
als Numbercruncher geboren.
Zum Profiling kann man auch einen Timer mit 1 µs laufen lassen und dann 
im Programm Zeitstempel in ein Array schreiben. Die Routinen, die länger 
laufen, dann im Debugger analysieren. Den Mathematikern ist vielleicht 
egal ob da grosse Arrays hin- und her kopiert werden.
Die Hardwarekeule kann man auch noch rausholen, µC werden ja immer 
schneller, es gibt ja noch die H7 mit >400 MHz oder Teensy 4.0 mit NXP 
iMXRT1062 mit 600 MHz:
https://www.pjrc.com/store/teensy40.html
Und aufpassen das nicht mit double gerechnet wird, die M4 FPU kann nur 
float in HW, das macht sehr viel aus in Speed und Codegröße.

  


  




  

    Beitrag melden Bearbeiten Löschen Markierten Text zitieren Antwort Antwort mit Zitat
  







      

      



  

    Re: Lib Eigen (C++) auf STM32F429, Geschwindigkeit okay?
  


  

    

      von
      
        Johannes S. (Gast)
      
      


      
    


    

      
    

    

    

      

      

      Angehängte Dateien:


      

    

  
  


  

  Lesenswert?
  

  •
  
  ▲  
  

  ▼  
  		
  

  


  

      
habe das mal in Mbed reingepackt, man muss nur die Lib in ein 
Verzeichnis im Projekt kopieren und in core/misc/kernel.h umbenennen 
weil das mit einer Datei gleichen Namens kolidiert.
Das gleiche Programm kann dann für verschiedene Targets kompiliert 
werden, ich habe auch das alte Disco F429ZI und zum Vergleich ein Nucleo 
H743 mit 400 MHz. Das Ganze im bare_metal Mode ohne RTOS.
Es ist einfach die Werte in eine Tabelle auszugeben. Beim alten Disco 
F429ZI ist eine serielle Schnittstelle nötig.
Die Rechenzeit ist allerdings mit unterschiedlichen Werten auch 
unterschiedlich lang, für genauere Ergebnisse müsste man bei gleicher 
Matrizengröße über mehrere Berechnungen mitteln. Aber für den Trend 
dürfte das reichen.
Wenn die Matrizen zu groß werden gibts Bekanntschaft mit dem Hardfault 
Handler.

1
Hello from DISCO_F429ZI

2
Mbed OS version: 5.14.2

3
4
mSize      init      bdcSvd   jacobiSvd

5
---------------------------------------

6
  3    0.010 ms    0.136 ms    0.114 ms

7
  4    0.013 ms    0.242 ms    0.220 ms

8
  5    0.016 ms    0.376 ms    0.349 ms

9
  6    0.018 ms    0.719 ms    0.690 ms

10
  7    0.022 ms    0.995 ms    0.965 ms

11
  8    0.026 ms    1.385 ms    1.352 ms

12
  9    0.031 ms    2.002 ms    1.966 ms

13
 10    0.035 ms    2.463 ms    2.424 ms

14
 11    0.041 ms    3.487 ms    3.443 ms

15
 12    0.048 ms    4.407 ms    4.358 ms

16
 13    0.055 ms    5.222 ms    5.170 ms

17
 14    0.061 ms    6.734 ms    6.676 ms

18
 15    0.069 ms    7.397 ms    7.335 ms

19
 16    0.077 ms   10.118 ms    8.983 ms

20
 17    0.086 ms   11.792 ms   11.844 ms

21
 18    0.096 ms   12.791 ms   12.675 ms

22
 19    0.105 ms   15.192 ms   15.038 ms

23
 20    0.116 ms   16.968 ms   17.911 ms

24
 21    0.126 ms   17.886 ms   20.408 ms

25
 22    0.138 ms   21.057 ms   23.333 ms

26
 23    0.149 ms   23.246 ms   25.638 ms

27
 24    0.161 ms   26.239 ms   31.462 ms

28
 25    0.175 ms   28.459 ms   32.017 ms

29
 26    0.188 ms   31.814 ms   34.661 ms

30
 27    0.202 ms   34.920 ms   38.958 ms

31
 28    0.215 ms   38.295 ms   44.780 ms

32
 29    0.230 ms   41.039 ms   47.973 ms

33
 30    0.245 ms   44.506 ms   52.626 ms

34
 31    0.261 ms   48.930 ms   57.163 ms

35
 32    0.279 ms   51.144 ms   63.501 ms

36
 33    0.295 ms   56.137 ms   71.446 ms

37
 34    0.313 ms   59.824 ms   77.364 ms

38
 35    0.330 ms   64.021 ms   79.684 ms

39
 36    0.348 ms   69.526 ms   84.994 ms

40
 37    0.368 ms   71.627 ms   90.017 ms

41
 38    0.387 ms   77.980 ms  106.611 ms

42
 39    0.407 ms   82.666 ms  117.184 ms

43
 40    0.428 ms   89.102 ms  121.475 ms

44
 41    0.449 ms   95.082 ms  130.688 ms

45
 42    0.470 ms   98.353 ms  138.925 ms

46
 43    0.491 ms  107.733 ms  147.745 ms

47
 44    0.514 ms  114.439 ms  162.254 ms

48
 45    0.537 ms  121.967 ms  167.670 ms

49
 46    0.562 ms  126.507 ms  180.827 ms

50
 47    0.585 ms  134.981 ms  183.637 ms

51
 48    0.611 ms  181.772 ms  197.213 ms

52
 49    0.634 ms  218.934 ms  212.051 ms

53
 50    0.660 ms  228.997 ms  231.479 ms

54
 51    0.686 ms  241.682 ms  234.837 ms

55
 52    0.713 ms  264.418 ms  262.289 ms

56
 53    0.739 ms  271.519 ms  269.971 ms

57
 54    0.768 ms  281.938 ms  289.610 ms

58
 

59
 

60
Hello from NUCLEO_H743ZI

61
Mbed OS version: 5.14.2

62
63
mSize      init      bdcSvd   jacobiSvd

64
---------------------------------------

65
  3    0.005 ms    0.048 ms    0.039 ms

66
  4    0.005 ms    0.081 ms    0.073 ms

67
  5    0.006 ms    0.124 ms    0.114 ms

68
  6    0.007 ms    0.233 ms    0.222 ms

69
  7    0.008 ms    0.318 ms    0.308 ms

70
  8    0.009 ms    0.436 ms    0.424 ms

71
  9    0.012 ms    0.624 ms    0.613 ms

72
 10    0.013 ms    0.760 ms    0.747 ms

73
 11    0.016 ms    1.066 ms    1.054 ms

74
 12    0.018 ms    1.338 ms    1.323 ms

75
 13    0.021 ms    1.583 ms    1.562 ms

76
 14    0.024 ms    2.014 ms    1.995 ms

77
 15    0.027 ms    2.198 ms    2.182 ms

78
 16    0.030 ms    3.117 ms    2.649 ms

79
 17    0.034 ms    3.652 ms    3.477 ms

80
 18    0.037 ms    3.882 ms    3.690 ms

81
 19    0.040 ms    4.632 ms    4.364 ms

82
 20    0.045 ms    5.129 ms    5.167 ms

83
 21    0.049 ms    5.272 ms    5.864 ms

84
 22    0.053 ms    6.321 ms    6.670 ms

85
 23    0.058 ms    6.970 ms    7.306 ms

86
 24    0.063 ms    7.850 ms    8.884 ms

87
 25    0.068 ms    8.492 ms    9.031 ms

88
 26    0.074 ms    9.498 ms    9.736 ms

89
 27    0.079 ms   10.358 ms   10.911 ms

90
 28    0.084 ms   11.283 ms   12.472 ms

91
 29    0.090 ms   11.961 ms   13.326 ms

92
 30    0.096 ms   12.974 ms   14.560 ms

93
 31    0.102 ms   14.294 ms   15.759 ms

94
 32    0.109 ms   14.936 ms   17.461 ms

95
 33    0.116 ms   16.637 ms   19.623 ms

96
 34    0.122 ms   17.701 ms   21.172 ms

97
 35    0.129 ms   18.796 ms   21.752 ms

98
 36    0.136 ms   20.337 ms   23.159 ms

99
 37    0.143 ms   20.657 ms   24.480 ms

100
 38    0.151 ms   22.550 ms   29.024 ms

101
 39    0.160 ms   23.783 ms   31.959 ms

102
 40    0.167 ms   25.711 ms   33.068 ms

103
 41    0.176 ms   27.451 ms   35.641 ms

104
 42    0.184 ms   28.136 ms   37.923 ms

105
 43    0.192 ms   30.970 ms   40.407 ms

106
 44    0.202 ms   32.706 ms   44.375 ms

107
 45    0.210 ms   35.043 ms   46.023 ms

108
 46    0.219 ms   35.960 ms   49.642 ms

109
 47    0.229 ms   38.108 ms   50.524 ms

110
 48    0.239 ms   48.215 ms   54.245 ms

111
 49    0.248 ms   55.326 ms   58.728 ms

112
 50    0.258 ms   57.998 ms   64.025 ms

113
 51    0.268 ms   61.431 ms   65.458 ms

114
 52    0.279 ms   67.094 ms   72.578 ms

115
 53    0.289 ms   68.222 ms   74.979 ms

116
 54    0.300 ms   70.554 ms   81.274 ms

117
 55    0.312 ms   75.299 ms   82.743 ms

118
 56    0.322 ms   78.851 ms   84.632 ms

119
 57    0.334 ms   82.780 ms   98.408 ms

120
 58    0.345 ms   84.396 ms   98.985 ms

121
 59    0.357 ms   89.510 ms  101.535 ms

122
 60    0.369 ms   95.451 ms  108.328 ms

123
 61    0.428 ms   97.379 ms  113.102 ms

124
 62    0.394 ms  102.776 ms  122.268 ms

125
 63    0.406 ms  106.267 ms  129.738 ms

126
 64    0.419 ms  113.470 ms  142.612 ms

127
 65    0.432 ms  117.002 ms  138.342 ms

128
 66    0.445 ms  120.279 ms  144.480 ms

129
 67    0.459 ms  126.243 ms  149.958 ms

130
 68    0.472 ms  135.481 ms  165.676 ms

131
 69    0.487 ms  137.607 ms  164.228 ms

132
 70    0.501 ms  142.316 ms  175.621 ms

133
 71    0.515 ms  148.183 ms  179.560 ms

134
 72    0.530 ms  154.451 ms  190.410 ms

135
 73    0.544 ms  160.569 ms  210.034 ms

136
 74    0.558 ms  163.870 ms  199.332 ms

137
 75    0.574 ms  168.268 ms  205.315 ms

138
 76    0.589 ms  175.763 ms  222.522 ms

139
 77    0.604 ms  182.049 ms  228.821 ms

140
 78    0.620 ms  191.724 ms  234.706 ms

141
 79    0.636 ms  196.732 ms  264.469 ms

142
 80    0.651 ms  207.548 ms  254.842 ms

143
 81    0.668 ms  210.594 ms  269.348 ms

144
 82    0.684 ms  217.470 ms  284.311 ms

145
 83    0.700 ms  228.048 ms  292.520 ms

146
 84    0.718 ms  233.186 ms  299.705 ms

147
 85    0.734 ms  242.007 ms  309.080 ms

148
 86    0.751 ms  244.601 ms  318.726 ms

149
 87    0.769 ms  253.876 ms  323.563 ms

150
 88    0.787 ms  265.796 ms  343.603 ms

151
 89    0.804 ms  274.344 ms  359.299 ms

152
 90    0.822 ms  280.532 ms  362.168 ms

153
154
++ MbedOS Fault Handler ++


  


  




  

    Beitrag melden Bearbeiten Löschen Markierten Text zitieren Antwort Antwort mit Zitat
  







      

      



  

    Re: Lib Eigen (C++) auf STM32F429, Geschwindigkeit okay?
  


  

    

      von
      
        Ruediger A.
            (Firma: keine)
        (rac)
        
      
      


      
    


    

      
    

    

    

  
  


  

  Lesenswert?
  

  •
  
  ▲  
  

  ▼  
  		
  

  


  

      
Hallo,

im Cortex M ist Alles, was auf den internen Bussen läuft, um Dimensionen 
schneller als wenn Du auf externe Peripherie zugreifen musst; was 
darüber hinaus den Kernel nicht verlässt ist nochmal um einiges 
schneller (Vorsicht Eigenwerbung: In meinem Buch diskutiere ich das sehr 
ausführlich). Du solltest also mit Optimierungsstufen experimentieren 
(mit auseinandergefaltetem Code bei Optimierung auf Geschwindigkeit z.B. 
hast Du zwar teilweise um mehrere Grössenordnungen aufgeblähten Code, 
der aber pfeilschnell abläuft, wenn Schleifen aus dem Cache heraus ohne 
Lesen des Programmes vom Bus abgearbeitet werden können) und dein 
Memorylayout so finetunen, dass möglichst nicht auf externe Busse 
zugegriffen werden muss. Also sämtlichen Code aus dem internen Flash 
auslesen, arithmetische Operationen wenn immer es geht in-Kernel (also 
Register-Register) ausführen und idealerweise kein externes RAM 
benutzen.

Der M7 hat zusätzlich noch durch die 6 stage Pipeline weitere 
Optimierungen, die den Code nochmals signifikant schneller ablaufen 
lassen können; dafür brauchst Du aber einen Compiler, der auf den M7 
Kern optimierten Code generieren kann.

Man muss dazu nicht notwendigerweise Assemblercode schreiben können, 
sollte sich aber mit linker command files und dem Compiler seiner Wahl 
gut auskennen.

Wenn man "nur" einzelne Optimierunge manuell nachführen muss, ist es 
auch ein ganz guter Anfang, seine C Datei mit "generate assembly Output" 
zu compilieren, die erzeugte Datei statt der C Datei als Quelle ins 
Projekt einzubinden und vom Assembler statt vom Compiler übersetzen zu 
lassen. Dann kannst Du einzelne Handoptimierungen in einer Kopie der 
Zwischendatei vornehmen.

  


  



  

  
:
    Bearbeitet durch User
  

  


  

    Beitrag melden Bearbeiten Löschen Markierten Text zitieren Antwort Antwort mit Zitat
  







      

      



  

    Re: Lib Eigen (C++) auf STM32F429, Geschwindigkeit okay?
  


  

    

      von
      
        Kaj G.
            (Firma: RUB)
        (bloody)
        
      
      


      
    


    

      
    

    

    

      

      

      Angehängte Dateien:



        
    

  
  


  

  Lesenswert?
  

  •
  
  ▲  
  

  ▼  
  		
  

  


  

      
Danke fuer Eure Antworten.

Ich habe neben der Laufzeit jetzt noch den Speicherverbrauch "gemessen". 
Dazu wurde ein Testprojekt mit den verschiedenen Matrizengroessen fuer 
x86 compiliert und mit Valgrind analysiert. Das Speicherverhalten ist 
womoeglich nicht exakt identisch zu ARM, reicht aber fuer eine 
Abschaetzung. Den Speicherverbrauch hab ich so tatsaechlich nicht 
erwartet.

Das nicht nutzen der FPU bewirkt eine Laufzeitverlaengerung um Faktor 
10.

Johannes S. schrieb:
> habe das mal in Mbed reingepackt,
Danke. Interessante Ergebnisse. :)
Auch interessant zu sehen, wie viel langsamer es durch das OS wird, und 
wie sich dann da doch das Mehr an Rechenleistung deutlich bemerkbar 
macht.

Ruediger A. schrieb:
> Du solltest also mit Optimierungsstufen experimentieren
> (mit auseinandergefaltetem Code bei Optimierung auf Geschwindigkeit z.B.
> hast Du zwar teilweise um mehrere Grössenordnungen aufgeblähten Code,
> der aber pfeilschnell abläuft, wenn Schleifen aus dem Cache heraus ohne
> Lesen des Programmes vom Bus abgearbeitet werden können)
Ich werde es probieren.

Ruediger A. schrieb:
> Wenn man "nur" einzelne Optimierunge manuell nachführen muss, ist es
> auch ein ganz guter Anfang, seine C Datei mit "generate assembly Output"
> zu compilieren, die erzeugte Datei statt der C Datei als Quelle ins
> Projekt einzubinden und vom Assembler statt vom Compiler übersetzen zu
> lassen. Dann kannst Du einzelne Handoptimierungen in einer Kopie der
> Zwischendatei vornehmen.
Auch das werede ich mir mal anschauen.

Ruediger A. schrieb:
> (Vorsicht Eigenwerbung: In meinem Buch diskutiere ich das sehr
> ausführlich)
Danke fuer die Erinnerung. Vielleicht hab ich gerade noch ein 
Weihnachtsgeschenk fuer mich gefunden. :D
Dieses hier?
https://www.amazon.de/Embedded-Controller-Grundlagen-industrielle-Anwendungen/dp/3658148497


Euch noch einen schoenen 3. Advent.

Gruesse

  


  



  

  
:
    Bearbeitet durch User
  

  


  

    Beitrag melden Bearbeiten Löschen Markierten Text zitieren Antwort Antwort mit Zitat
  







      

      



  

    Re: Lib Eigen (C++) auf STM32F429, Geschwindigkeit okay?
  


  

    

      von
      
        Ruediger A.
            (Firma: keine)
        (rac)
        
      
      


      
    


    

      
    

    

    

  
  


  

  Lesenswert?
  

  •
  
  ▲  
  

  ▼  
  		
  

  


  

      
Kaj G. schrieb:
>
> Ruediger A. schrieb:
>> (Vorsicht Eigenwerbung: In meinem Buch diskutiere ich das sehr
>> ausführlich)
> Danke fuer die Erinnerung. Vielleicht hab ich gerade noch ein
> Weihnachtsgeschenk fuer mich gefunden. :D
> Dieses hier?
> 
https://www.amazon.de/Embedded-Controller-Grundlagen-industrielle-Anwendungen/dp/3658148497
>

jo. Für deine Zwecke ist i.W. Kapitel 2 interessant, das ist auch 
separat erwerblich... :->

>
> Euch noch einen schoenen 3. Advent.
>

Ebenso!

  


  



  

  
:
    Bearbeitet durch User
  

  


  

    Beitrag melden Bearbeiten Löschen Markierten Text zitieren Antwort Antwort mit Zitat
  







      

      



  

    Re: Lib Eigen (C++) auf STM32F429, Geschwindigkeit okay?
  


  

    

      von
      
        Kaj G.
            (Firma: RUB)
        (bloody)
        
      
      


      
    


    

      
    

    

    

  
  


  

  Lesenswert?
  

  •
  
  ▲  
  

  ▼  
  		
  

  


  

      
Ich habe den Speicherverbrauch weiter mit Valgrind analysiert.
Interessant was Valgrind so alles kann :D
https://valgrind.org/docs/manual/ms-manual.html

Leider hat sich ergeben, das die Lib fuer den angedachten Zweck voellig 
unbrauchbar ist, da sie viel zu viel Speicher braucht.

Fuer eine 95x95 Matrize ergibt sich folgender Speicherverbrauch:
1
--------------------------------------------------------------------------------

2
Command:            build/bdc

3
Massif arguments:   --massif-out-file=build/bdc.out

4
ms_print arguments: build/bdc.out

5
--------------------------------------------------------------------------------

6
7
8
    KB

9
520.0^                                                       #                

10
     |                                                       #                

11
     |         ::@::::::@@                                   # ::  ::  ::   @ 

12
     |         ::@::::::@@:::::::::::::::::::::::::::::::::::#::::::::::::@:@:

13
     |         ::@::::::@@::: :   ::::::   :                 #::::::::::::@ @:

14
     |         ::@::::::@@::: :   ::::::   :                 #::::::::::::@ @:

15
     |         ::@::::::@@::: :   ::::::   :                 #::::::::::::@ @:

16
     |         ::@::::::@@::: :   ::::::   :                 #::::::::::::@ @:

17
     |         ::@::::::@@::: :   ::::::   :                 #::::::::::::@ @:

18
     |         ::@::::::@@::: :   ::::::   :                 #::::::::::::@ @:

19
     |         ::@::::::@@::: :   ::::::   :                 #::::::::::::@ @:

20
     |         ::@::::::@@::: :   ::::::   :                 #::::::::::::@ @:

21
     |         ::@::::::@@::: :   ::::::   :                 #::::::::::::@ @:

22
     |         ::@::::::@@::: :   ::::::   :                 #::::::::::::@ @:

23
     |         ::@::::::@@::: :   ::::::   :                 #::::::::::::@ @:

24
     |         ::@::::::@@::: :   ::::::   :                 #::::::::::::@ @:

25
     |         ::@::::::@@::: :   ::::::   :                 #::::::::::::@ @:

26
     |         ::@::::::@@::: :   ::::::   :                 #::::::::::::@ @:

27
     |       ::::@::::::@@::: :   ::::::   :                 #::::::::::::@ @:

28
     |       ::::@::::::@@::: :   ::::::   :                 #::::::::::::@ @:

29
   0 +----------------------------------------------------------------------->Mi

30
     0                                                                   33.34

31
32
--------------------------------------------------------------------------------

33
Command:            build/bdc

34
Massif arguments:   --stacks=yes --massif-out-file=build/bdc.out

35
ms_print arguments: build/bdc.out

36
--------------------------------------------------------------------------------

37
38
39
    KB

40
594.9^                                                  ##                    

41
     |                                                  # ::::                

42
     |                                                  # : ::                

43
     |                                     @::::::::::::# : ::  :: :::  @  :::

44
     |              @                      @: :::: : :::# : :: ::  ::: :@: :::

45
     |         :::::@::::@@:::::::::@::::::@: :::: : :::# : ::::: ::::::@:::::

46
     |         : :::@::: @ ::::::: :@: :: :@: :::: : :::# : ::::: ::::::@:::::

47
     |         : :::@::: @ ::::::: :@: :: :@: :::: : :::# : ::::: ::::::@:::::

48
     |         : :::@::: @ ::::::: :@: :: :@: :::: : :::# : ::::: ::::::@:::::

49
     |         : :::@::: @ ::::::: :@: :: :@: :::: : :::# : ::::: ::::::@:::::

50
     |         : :::@::: @ ::::::: :@: :: :@: :::: : :::# : ::::: ::::::@:::::

51
     |         : :::@::: @ ::::::: :@: :: :@: :::: : :::# : ::::: ::::::@:::::

52
     |         : :::@::: @ ::::::: :@: :: :@: :::: : :::# : ::::: ::::::@:::::

53
     |         : :::@::: @ ::::::: :@: :: :@: :::: : :::# : ::::: ::::::@:::::

54
     |         : :::@::: @ ::::::: :@: :: :@: :::: : :::# : ::::: ::::::@:::::

55
     |         : :::@::: @ ::::::: :@: :: :@: :::: : :::# : ::::: ::::::@:::::

56
     |         : :::@::: @ ::::::: :@: :: :@: :::: : :::# : ::::: ::::::@:::::

57
     |         : :::@::: @ ::::::: :@: :: :@: :::: : :::# : ::::: ::::::@:::::

58
     |         : :::@::: @ ::::::: :@: :: :@: :::: : :::# : ::::: ::::::@:::::

59
     |        :: :::@::: @ ::::::: :@: :: :@: :::: : :::# : ::::: ::::::@:::::

60
   0 +----------------------------------------------------------------------->Mi

61
     0                                                                   33.33

62
63
--------------------------------------------------------------------------------

64
Command:            build/jacobi

65
Massif arguments:   --massif-out-file=build/jacobi.out

66
ms_print arguments: build/jacobi.out

67
--------------------------------------------------------------------------------

68
69
70
    KB

71
195.7^  :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::#

72
     |  :                                                                    #

73
     |  :                                                                    #

74
     |  :                                                                    #

75
     |  :                                                                    #

76
     |  :                                                                    #

77
     |  :                                                                    #

78
     |  :                                                                    #

79
     |  :                                                                    #

80
     |  :                                                                    #

81
     |  :                                                                    #

82
     |  :                                                                    #

83
     |  :                                                                    #

84
     |  :                                                                    #

85
     |  :                                                                    #

86
     |  :                                                                    #

87
     |  :                                                                    #

88
     |  :                                                                    #

89
     |  :                                                                    #

90
     |  :                                                                    #

91
   0 +----------------------------------------------------------------------->Mi

92
     0                                                                   108.4

93
94
--------------------------------------------------------------------------------

95
Command:            build/jacobi

96
Massif arguments:   --stacks=yes --massif-out-file=build/jacobi.out

97
ms_print arguments: build/jacobi.out

98
--------------------------------------------------------------------------------

99
100
101
    KB

102
197.0^  ##                                                                    

103
     |  # :@@:::::::::::::::::::::::::::::::::@:::::@:::::::::::::::::@::::::@

104
     |  # :@ :: : ::: ::: : ::: ::::: ::: :: :@: : :@:: ::: :: ::: :::@::::::@

105
     |  # :@ :: : ::: ::: : ::: ::::: ::: :: :@: : :@:: ::: :: ::: :::@::::::@

106
     |  # :@ :: : ::: ::: : ::: ::::: ::: :: :@: : :@:: ::: :: ::: :::@::::::@

107
     |  # :@ :: : ::: ::: : ::: ::::: ::: :: :@: : :@:: ::: :: ::: :::@::::::@

108
     |  # :@ :: : ::: ::: : ::: ::::: ::: :: :@: : :@:: ::: :: ::: :::@::::::@

109
     |  # :@ :: : ::: ::: : ::: ::::: ::: :: :@: : :@:: ::: :: ::: :::@::::::@

110
     |  # :@ :: : ::: ::: : ::: ::::: ::: :: :@: : :@:: ::: :: ::: :::@::::::@

111
     |  # :@ :: : ::: ::: : ::: ::::: ::: :: :@: : :@:: ::: :: ::: :::@::::::@

112
     |  # :@ :: : ::: ::: : ::: ::::: ::: :: :@: : :@:: ::: :: ::: :::@::::::@

113
     |  # :@ :: : ::: ::: : ::: ::::: ::: :: :@: : :@:: ::: :: ::: :::@::::::@

114
     |  # :@ :: : ::: ::: : ::: ::::: ::: :: :@: : :@:: ::: :: ::: :::@::::::@

115
     |  # :@ :: : ::: ::: : ::: ::::: ::: :: :@: : :@:: ::: :: ::: :::@::::::@

116
     |  # :@ :: : ::: ::: : ::: ::::: ::: :: :@: : :@:: ::: :: ::: :::@::::::@

117
     |  # :@ :: : ::: ::: : ::: ::::: ::: :: :@: : :@:: ::: :: ::: :::@::::::@

118
     |  # :@ :: : ::: ::: : ::: ::::: ::: :: :@: : :@:: ::: :: ::: :::@::::::@

119
     |  # :@ :: : ::: ::: : ::: ::::: ::: :: :@: : :@:: ::: :: ::: :::@::::::@

120
     |  # :@ :: : ::: ::: : ::: ::::: ::: :: :@: : :@:: ::: :: ::: :::@::::::@

121
     |  # :@ :: : ::: ::: : ::: ::::: ::: :: :@: : :@:: ::: :: ::: :::@::::::@

122
   0 +----------------------------------------------------------------------->Mi

123
     0                                                                   107.9

Repo mit dem Testcode findet sich hier:
https://gitlab.com/Bloody_Wulf/cpp_eigen_test

Mitlerweile habe ich auch eine Info fuer die endgueltige Matrizengroesse 
bekommen (mehrere zehntausend Elemente, war mir bisher nicht bekannt), 
und da braucht die Lib dann schon 5-10MB RAM. Und das ist mal ca. Faktor 
15 zu viel.

Das ganze laeuft nachher nicht auf einem M4, sondern auf etwas 
potenterem, aber immernoch embedded bare-metal. Wofuer das ganze ist, 
darf ich leider nicht sagen.

Ich werde mich nach einer anderen Loesung umsehen.

------------------------------------

Ich wuensche Euch allen schoene Feiertage.

Gruesse

  


  




  

    Beitrag melden Bearbeiten Löschen Markierten Text zitieren Antwort Antwort mit Zitat
  







      

      



  

    Re: Lib Eigen (C++) auf STM32F429, Geschwindigkeit okay?
  


  

    

      von
      
        mh (Gast)
      
      


      
    


    

      
    

    

    

  
  


  

  Lesenswert?
  

  •
  
  ▲  
  

  ▼  
  		
  

  


  

      
Kaj G. schrieb:
> Mitlerweile habe ich auch eine Info fuer die endgueltige Matrizengroesse
> bekommen (mehrere zehntausend Elemente, war mir bisher nicht bekannt),
> und da braucht die Lib dann schon 5-10MB RAM. Und das ist mal ca. Faktor
> 15 zu viel.

Ich verstehe nicht so ganz was du sagen willst. Hast du gerade erfahren, 
dass die tatsächliche Anwendung eine SVD für n x n Matritzen mit n > 
10000 machen muss? Und du hast etwas dagegen, dass eigen mehr als 10 MB 
RAM dafür benötigt?

  


  




  

    Beitrag melden Bearbeiten Löschen Markierten Text zitieren Antwort Antwort mit Zitat
  







      

      



  

    Re: Lib Eigen (C++) auf STM32F429, Geschwindigkeit okay?
  


  

    

      von
      
        Kaj G.
            (Firma: RUB)
        (bloody)
        
      
      


      
    


    

      
    

    

    

  
  


  

  Lesenswert?
  

  •
  
  ▲  
  

  ▼  
  		
  

  


  

      
mh schrieb:
> Hast du gerade erfahren,
> dass die tatsächliche Anwendung eine SVD für n x n Matritzen mit n >
> 10000 machen muss?
Nein, eine m x n Matrize, mit: m*n > 50k

Bei n x n mit n >= 10.000 waeren ja schon mind. 390MB nur fuer die 
Matrize noetig. ;)
War von mir unsauber formuliert.

mh schrieb:
> Und du hast etwas dagegen, dass eigen mehr als 10 MB
> RAM dafür benötigt?
Ich habe nichts dagegen, aber die Hardware. Eigen braucht, bei der 
benoetigten Matrizengroesse, mehr als das 25 fache des Speichers, der 
fuer die eigentliche Matrize gebraucht wird.

Ich wollte es jetzt aber spasses halber fuer eine n x n Matrize mit n = 
10.000 untersuchen. Die Analyse dauert mir aber gerade zu lange. Bei 
Abbruch wurden schon mehr als 4GB RAM (BDCSVD) gebraucht.

  


  




  

    Beitrag melden Bearbeiten Löschen Markierten Text zitieren Antwort Antwort mit Zitat
  







      

      



  

    Re: Lib Eigen (C++) auf STM32F429, Geschwindigkeit okay?
  


  

    

      von
      
        mh (Gast)
      
      


      
    


    

      
    

    

    

  
  


  

  Lesenswert?
  

  •
  
  ▲  
  

  ▼  
  		
  

  


  

      
Ich habe gerade einen kurzen Test mit deiner mini main von gitlab 
gemacht. Bei mir ist der maximale Speicherbedarf ~ 5  4  M_SIZE^2 + 
konstant. Ich habe nicht geguckt wo der Speicher benötigt wird. Aber das 
ist nur nen Faktor 5 den man erklären muss. Ne SVD ist nicht so 
kompliziert, dass man nicht in ein oder zwei Stunden herausfindet 
wieviel ne SVD brauchen sollte, und warum eigen etvl. davon abweicht.

  


  




  

    Beitrag melden Bearbeiten Löschen Markierten Text zitieren Antwort Antwort mit Zitat
  







      

      



  

    Re: Lib Eigen (C++) auf STM32F429, Geschwindigkeit okay?
  


  

    

      von
      
        Kaj G.
            (Firma: RUB)
        (bloody)
        
      
      


      
    


    

      
    

    

    

  
  


  

  Lesenswert?
  

  •
  
  ▲  
  

  ▼  
  		
  

  


  

      
mh schrieb:
> Aber das ist nur nen Faktor 5
Der Faktor ist aber nicht konstant, sondern haengt von der Groesse als 
auch von der Form (also n x n, oder m x n) der Matrize ab.

1
Valgrind HEAP SUMMARY:

2
3
10 x 10:

4
BDC:      total heap usage: 16 allocs, 16 frees, 25,000 bytes allocated

5
Jacobi:   total heap usage:  8 allocs,  8 frees, 21,136 bytes allocated

6
7
100 x 100:

8
BDC:      total heap usage: 888 allocs, 888 frees, 1,051,704 bytes allocated

9
Jacobi:   total heap usage:   8 allocs,   8 frees,   219,856 bytes allocated

10
11
200 x 100:

12
BDC:      total heap usage: 891 allocs, 891 frees, 1,820,152 bytes allocated

13
Jacobi:   total heap usage: 217 allocs, 217 frees,   706,400 bytes allocated

14
15
300 x 50:

16
BDC:      total heap usage: 453 allocs, 453 frees, 1,451,844 bytes allocated

17
Jacobi:   total heap usage: 117 allocs, 117 frees,   754,400 bytes allocated

18
19
300 x 100:

20
BDC:      total heap usage: 892 allocs, 892 frees, 2,697,368 bytes allocated

21
Jacobi:   total heap usage: 217 allocs, 217 frees, 1,147,200 bytes allocated

22
23
1000 x 1000:

24
BDC:      total heap usage: 9,267 allocs, 9,267 frees, 154,198,928 bytes allocated

25
Jacobi:   total heap usage:     8 allocs,     8 frees,  20,027,056 bytes allocated


Bei 300 x 100 werden fuer die eigentlichen Daten gerade mal ca. 118k 
gebraucht. ((300  100  sizeof(float))/1024). BDC braucht aber ca. 
1.5MB im maximum, also mehr als Faktor 10.

1
--------------------------------------------------------------------------------

2
Command:            build/bdc

3
Massif arguments:   --stacks=yes --massif-out-file=build/bdc.out

4
ms_print arguments: build/bdc.out

5
--------------------------------------------------------------------------------

6
7
8
    MB

9
1.489^                                       #                                

10
     |                                       #:::::                           

11
     |                                       #:   :       :::::::             

12
     |                                       #:   ::      :   : ::::::::@     

13
     |                                   @@@:#:   :::::::::   : :::     @     

14
     |       :@:@::::::     :   :::@:::::@@ :#:   :::    ::   : :::     @ :::@

15
     |       :@:@::::::::::::::::::@:::::@@ :#:   :::    @:   : :::     @::::@

16
     |      @:@:@::::::::::::::::::@:::::@@ :#:   :::    @:   : :::     @::::@

17
     |      @:@:@::::::::::::::::::@:::::@@ :#:   :::    @:   : :::     @::::@

18
     |      @:@:@::::::::::::::::::@:::::@@ :#:   :::    @:   : :::     @::::@

19
     |      @:@:@::::::::::::::::::@:::::@@ :#:   :::    @:   : :::     @::::@

20
     |      @:@:@::::::::::::::::::@:::::@@ :#:   :::    @:   : :::     @::::@

21
     |      @:@:@::::::::::::::::::@:::::@@ :#:   :::    @:   : :::     @::::@

22
     |      @:@:@::::::::::::::::::@:::::@@ :#:   :::    @:   : :::     @::::@

23
     |      @:@:@::::::::::::::::::@:::::@@ :#:   :::    @:   : :::     @::::@

24
     |      @:@:@::::::::::::::::::@:::::@@ :#:   :::    @:   : :::     @::::@

25
     |      @:@:@::::::::::::::::::@:::::@@ :#:   :::    @:   : :::     @::::@

26
     |      @:@:@::::::::::::::::::@:::::@@ :#:   :::    @:   : :::     @::::@

27
     |      @:@:@::::::::::::::::::@:::::@@ :#:   :::    @:   : :::     @::::@

28
     |    :@@:@:@::::::::::::::::::@:::::@@ :#:   :::    @:   : :::     @::::@

29
   0 +----------------------------------------------------------------------->Mi

30
     0                                                                   66.32

Wo der Speicher bleibt ist klar: in der Rekursion (divide-and-conquer).

  


  



  

  
:
    Bearbeitet durch User
  

  


  

    Beitrag melden Bearbeiten Löschen Markierten Text zitieren Antwort Antwort mit Zitat
  







      

      



  

    Re: Lib Eigen (C++) auf STM32F429, Geschwindigkeit okay?
  


  

    

      von
      
        mh (Gast)
      
      


      
    


    

      
    

    

    

  
  


  

  Lesenswert?
  

  •
  
  ▲  
  

  ▼  
  		
  

  


  

      
Bist du sicher, dass wir über das gleiche reden? Ich gehe von maximale 
belegtem RAM aus. Die valgrind Ausgabe sagt allocated Speicher, also die 
Summe über alle mallocs. Egal, ob dazwischen ein free ausgeführt wurde 
oder nicht.

  


  




  

    Beitrag melden Bearbeiten Löschen Markierten Text zitieren Antwort Antwort mit Zitat
  








    

    

       Thread beobachten

      |
         Seitenaufteilung abschalten

    

        


Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.



  Bestehender Account

  


  
  

  
    

      

        
          
        
        
          
        
      

      

        
          
        
        
          
        
      

    


    
    
    





  Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!

  Mit Google-Account einloggen
  





  Noch kein Account? Hier anmelden.