mikrocontroller.net

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


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Kaj G. (Firma: RUB) (bloody)


Bewertung
0 lesenswert
nicht 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).
Matrix  |BDCSVD  | JacobiSVD
        |t in ms | t in ms
---------------------------
5x5     |0.3     | 0.266
10x10   |1.9     | 1.8
15x15   |5.9     | 5.9
20x20   |13.8    | 13.8
25x25   |22.3    | 25.5
30x30   |33.9    | 43
35x35   |48      | 68.9
40x40   |63.7    | 102
45x45   |81.7    | 142
50x50   |114.2   | 200
55x55   |        | 257
60x60   |        | 347
65x65   |        | 420
70x70   |        | 530
75x75   |        | 676
80x80   |        | 774
85x85   |        | 961
90x90   |        | 1121
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:
#include "Eigen/Dense"

using namespace Eigen;

#define M_SIZE 50

int main(void)
{
    HAL_Init();
    SystemClock_Config();

    MX_GPIO_Init();
    MX_FMC_Init();
    MX_TIM1_Init();

    HAL_GPIO_WritePin(pin_out_GPIO_Port, pin_out_Pin, GPIO_PIN_SET);

    while (1)
    {
        MatrixXf A = MatrixXf::Random(M_SIZE, M_SIZE);
        VectorXf b = VectorXf::Random(M_SIZE);

        HAL_GPIO_WritePin(pin_out_GPIO_Port, pin_out_Pin, GPIO_PIN_RESET);

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

        HAL_GPIO_WritePin(pin_out_GPIO_Port, pin_out_Pin, GPIO_PIN_SET);
    }
}

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

von mh (Gast)


Bewertung
-2 lesenswert
nicht 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 ...

von abc (Gast)


Bewertung
1 lesenswert
nicht 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).

von Johannes S. (jojos)


Bewertung
1 lesenswert
nicht 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.

von Johannes S. (jojos)


Angehängte Dateien:

Bewertung
1 lesenswert
nicht 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.
Hello from DISCO_F429ZI
Mbed OS version: 5.14.2

mSize      init      bdcSvd   jacobiSvd
---------------------------------------
  3    0.010 ms    0.136 ms    0.114 ms
  4    0.013 ms    0.242 ms    0.220 ms
  5    0.016 ms    0.376 ms    0.349 ms
  6    0.018 ms    0.719 ms    0.690 ms
  7    0.022 ms    0.995 ms    0.965 ms
  8    0.026 ms    1.385 ms    1.352 ms
  9    0.031 ms    2.002 ms    1.966 ms
 10    0.035 ms    2.463 ms    2.424 ms
 11    0.041 ms    3.487 ms    3.443 ms
 12    0.048 ms    4.407 ms    4.358 ms
 13    0.055 ms    5.222 ms    5.170 ms
 14    0.061 ms    6.734 ms    6.676 ms
 15    0.069 ms    7.397 ms    7.335 ms
 16    0.077 ms   10.118 ms    8.983 ms
 17    0.086 ms   11.792 ms   11.844 ms
 18    0.096 ms   12.791 ms   12.675 ms
 19    0.105 ms   15.192 ms   15.038 ms
 20    0.116 ms   16.968 ms   17.911 ms
 21    0.126 ms   17.886 ms   20.408 ms
 22    0.138 ms   21.057 ms   23.333 ms
 23    0.149 ms   23.246 ms   25.638 ms
 24    0.161 ms   26.239 ms   31.462 ms
 25    0.175 ms   28.459 ms   32.017 ms
 26    0.188 ms   31.814 ms   34.661 ms
 27    0.202 ms   34.920 ms   38.958 ms
 28    0.215 ms   38.295 ms   44.780 ms
 29    0.230 ms   41.039 ms   47.973 ms
 30    0.245 ms   44.506 ms   52.626 ms
 31    0.261 ms   48.930 ms   57.163 ms
 32    0.279 ms   51.144 ms   63.501 ms
 33    0.295 ms   56.137 ms   71.446 ms
 34    0.313 ms   59.824 ms   77.364 ms
 35    0.330 ms   64.021 ms   79.684 ms
 36    0.348 ms   69.526 ms   84.994 ms
 37    0.368 ms   71.627 ms   90.017 ms
 38    0.387 ms   77.980 ms  106.611 ms
 39    0.407 ms   82.666 ms  117.184 ms
 40    0.428 ms   89.102 ms  121.475 ms
 41    0.449 ms   95.082 ms  130.688 ms
 42    0.470 ms   98.353 ms  138.925 ms
 43    0.491 ms  107.733 ms  147.745 ms
 44    0.514 ms  114.439 ms  162.254 ms
 45    0.537 ms  121.967 ms  167.670 ms
 46    0.562 ms  126.507 ms  180.827 ms
 47    0.585 ms  134.981 ms  183.637 ms
 48    0.611 ms  181.772 ms  197.213 ms
 49    0.634 ms  218.934 ms  212.051 ms
 50    0.660 ms  228.997 ms  231.479 ms
 51    0.686 ms  241.682 ms  234.837 ms
 52    0.713 ms  264.418 ms  262.289 ms
 53    0.739 ms  271.519 ms  269.971 ms
 54    0.768 ms  281.938 ms  289.610 ms
 
 
Hello from NUCLEO_H743ZI
Mbed OS version: 5.14.2

mSize      init      bdcSvd   jacobiSvd
---------------------------------------
  3    0.005 ms    0.048 ms    0.039 ms
  4    0.005 ms    0.081 ms    0.073 ms
  5    0.006 ms    0.124 ms    0.114 ms
  6    0.007 ms    0.233 ms    0.222 ms
  7    0.008 ms    0.318 ms    0.308 ms
  8    0.009 ms    0.436 ms    0.424 ms
  9    0.012 ms    0.624 ms    0.613 ms
 10    0.013 ms    0.760 ms    0.747 ms
 11    0.016 ms    1.066 ms    1.054 ms
 12    0.018 ms    1.338 ms    1.323 ms
 13    0.021 ms    1.583 ms    1.562 ms
 14    0.024 ms    2.014 ms    1.995 ms
 15    0.027 ms    2.198 ms    2.182 ms
 16    0.030 ms    3.117 ms    2.649 ms
 17    0.034 ms    3.652 ms    3.477 ms
 18    0.037 ms    3.882 ms    3.690 ms
 19    0.040 ms    4.632 ms    4.364 ms
 20    0.045 ms    5.129 ms    5.167 ms
 21    0.049 ms    5.272 ms    5.864 ms
 22    0.053 ms    6.321 ms    6.670 ms
 23    0.058 ms    6.970 ms    7.306 ms
 24    0.063 ms    7.850 ms    8.884 ms
 25    0.068 ms    8.492 ms    9.031 ms
 26    0.074 ms    9.498 ms    9.736 ms
 27    0.079 ms   10.358 ms   10.911 ms
 28    0.084 ms   11.283 ms   12.472 ms
 29    0.090 ms   11.961 ms   13.326 ms
 30    0.096 ms   12.974 ms   14.560 ms
 31    0.102 ms   14.294 ms   15.759 ms
 32    0.109 ms   14.936 ms   17.461 ms
 33    0.116 ms   16.637 ms   19.623 ms
 34    0.122 ms   17.701 ms   21.172 ms
 35    0.129 ms   18.796 ms   21.752 ms
 36    0.136 ms   20.337 ms   23.159 ms
 37    0.143 ms   20.657 ms   24.480 ms
 38    0.151 ms   22.550 ms   29.024 ms
 39    0.160 ms   23.783 ms   31.959 ms
 40    0.167 ms   25.711 ms   33.068 ms
 41    0.176 ms   27.451 ms   35.641 ms
 42    0.184 ms   28.136 ms   37.923 ms
 43    0.192 ms   30.970 ms   40.407 ms
 44    0.202 ms   32.706 ms   44.375 ms
 45    0.210 ms   35.043 ms   46.023 ms
 46    0.219 ms   35.960 ms   49.642 ms
 47    0.229 ms   38.108 ms   50.524 ms
 48    0.239 ms   48.215 ms   54.245 ms
 49    0.248 ms   55.326 ms   58.728 ms
 50    0.258 ms   57.998 ms   64.025 ms
 51    0.268 ms   61.431 ms   65.458 ms
 52    0.279 ms   67.094 ms   72.578 ms
 53    0.289 ms   68.222 ms   74.979 ms
 54    0.300 ms   70.554 ms   81.274 ms
 55    0.312 ms   75.299 ms   82.743 ms
 56    0.322 ms   78.851 ms   84.632 ms
 57    0.334 ms   82.780 ms   98.408 ms
 58    0.345 ms   84.396 ms   98.985 ms
 59    0.357 ms   89.510 ms  101.535 ms
 60    0.369 ms   95.451 ms  108.328 ms
 61    0.428 ms   97.379 ms  113.102 ms
 62    0.394 ms  102.776 ms  122.268 ms
 63    0.406 ms  106.267 ms  129.738 ms
 64    0.419 ms  113.470 ms  142.612 ms
 65    0.432 ms  117.002 ms  138.342 ms
 66    0.445 ms  120.279 ms  144.480 ms
 67    0.459 ms  126.243 ms  149.958 ms
 68    0.472 ms  135.481 ms  165.676 ms
 69    0.487 ms  137.607 ms  164.228 ms
 70    0.501 ms  142.316 ms  175.621 ms
 71    0.515 ms  148.183 ms  179.560 ms
 72    0.530 ms  154.451 ms  190.410 ms
 73    0.544 ms  160.569 ms  210.034 ms
 74    0.558 ms  163.870 ms  199.332 ms
 75    0.574 ms  168.268 ms  205.315 ms
 76    0.589 ms  175.763 ms  222.522 ms
 77    0.604 ms  182.049 ms  228.821 ms
 78    0.620 ms  191.724 ms  234.706 ms
 79    0.636 ms  196.732 ms  264.469 ms
 80    0.651 ms  207.548 ms  254.842 ms
 81    0.668 ms  210.594 ms  269.348 ms
 82    0.684 ms  217.470 ms  284.311 ms
 83    0.700 ms  228.048 ms  292.520 ms
 84    0.718 ms  233.186 ms  299.705 ms
 85    0.734 ms  242.007 ms  309.080 ms
 86    0.751 ms  244.601 ms  318.726 ms
 87    0.769 ms  253.876 ms  323.563 ms
 88    0.787 ms  265.796 ms  343.603 ms
 89    0.804 ms  274.344 ms  359.299 ms
 90    0.822 ms  280.532 ms  362.168 ms

++ MbedOS Fault Handler ++

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


Bewertung
1 lesenswert
nicht 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
von Kaj G. (Firma: RUB) (bloody)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht 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
von Ruediger A. (Firma: keine) (rac)


Bewertung
1 lesenswert
nicht 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
von Kaj G. (Firma: RUB) (bloody)


Bewertung
0 lesenswert
nicht 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:
--------------------------------------------------------------------------------
Command:            build/bdc
Massif arguments:   --massif-out-file=build/bdc.out
ms_print arguments: build/bdc.out
--------------------------------------------------------------------------------


    KB
520.0^                                                       #                
     |                                                       #                
     |         ::@::::::@@                                   # ::  ::  ::   @ 
     |         ::@::::::@@:::::::::::::::::::::::::::::::::::#::::::::::::@:@:
     |         ::@::::::@@::: :   ::::::   :                 #::::::::::::@ @:
     |         ::@::::::@@::: :   ::::::   :                 #::::::::::::@ @:
     |         ::@::::::@@::: :   ::::::   :                 #::::::::::::@ @:
     |         ::@::::::@@::: :   ::::::   :                 #::::::::::::@ @:
     |         ::@::::::@@::: :   ::::::   :                 #::::::::::::@ @:
     |         ::@::::::@@::: :   ::::::   :                 #::::::::::::@ @:
     |         ::@::::::@@::: :   ::::::   :                 #::::::::::::@ @:
     |         ::@::::::@@::: :   ::::::   :                 #::::::::::::@ @:
     |         ::@::::::@@::: :   ::::::   :                 #::::::::::::@ @:
     |         ::@::::::@@::: :   ::::::   :                 #::::::::::::@ @:
     |         ::@::::::@@::: :   ::::::   :                 #::::::::::::@ @:
     |         ::@::::::@@::: :   ::::::   :                 #::::::::::::@ @:
     |         ::@::::::@@::: :   ::::::   :                 #::::::::::::@ @:
     |         ::@::::::@@::: :   ::::::   :                 #::::::::::::@ @:
     |       ::::@::::::@@::: :   ::::::   :                 #::::::::::::@ @:
     |       ::::@::::::@@::: :   ::::::   :                 #::::::::::::@ @:
   0 +----------------------------------------------------------------------->Mi
     0                                                                   33.34

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


    KB
594.9^                                                  ##                    
     |                                                  # ::::                
     |                                                  # : ::                
     |                                     @::::::::::::# : ::  :: :::  @  :::
     |              @                      @: :::: : :::# : :: ::  ::: :@: :::
     |         :::::@::::@@:::::::::@::::::@: :::: : :::# : ::::: ::::::@:::::
     |         : :::@::: @ ::::::: :@: :: :@: :::: : :::# : ::::: ::::::@:::::
     |         : :::@::: @ ::::::: :@: :: :@: :::: : :::# : ::::: ::::::@:::::
     |         : :::@::: @ ::::::: :@: :: :@: :::: : :::# : ::::: ::::::@:::::
     |         : :::@::: @ ::::::: :@: :: :@: :::: : :::# : ::::: ::::::@:::::
     |         : :::@::: @ ::::::: :@: :: :@: :::: : :::# : ::::: ::::::@:::::
     |         : :::@::: @ ::::::: :@: :: :@: :::: : :::# : ::::: ::::::@:::::
     |         : :::@::: @ ::::::: :@: :: :@: :::: : :::# : ::::: ::::::@:::::
     |         : :::@::: @ ::::::: :@: :: :@: :::: : :::# : ::::: ::::::@:::::
     |         : :::@::: @ ::::::: :@: :: :@: :::: : :::# : ::::: ::::::@:::::
     |         : :::@::: @ ::::::: :@: :: :@: :::: : :::# : ::::: ::::::@:::::
     |         : :::@::: @ ::::::: :@: :: :@: :::: : :::# : ::::: ::::::@:::::
     |         : :::@::: @ ::::::: :@: :: :@: :::: : :::# : ::::: ::::::@:::::
     |         : :::@::: @ ::::::: :@: :: :@: :::: : :::# : ::::: ::::::@:::::
     |        :: :::@::: @ ::::::: :@: :: :@: :::: : :::# : ::::: ::::::@:::::
   0 +----------------------------------------------------------------------->Mi
     0                                                                   33.33

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


    KB
195.7^  :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::#
     |  :                                                                    #
     |  :                                                                    #
     |  :                                                                    #
     |  :                                                                    #
     |  :                                                                    #
     |  :                                                                    #
     |  :                                                                    #
     |  :                                                                    #
     |  :                                                                    #
     |  :                                                                    #
     |  :                                                                    #
     |  :                                                                    #
     |  :                                                                    #
     |  :                                                                    #
     |  :                                                                    #
     |  :                                                                    #
     |  :                                                                    #
     |  :                                                                    #
     |  :                                                                    #
   0 +----------------------------------------------------------------------->Mi
     0                                                                   108.4

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


    KB
197.0^  ##                                                                    
     |  # :@@:::::::::::::::::::::::::::::::::@:::::@:::::::::::::::::@::::::@
     |  # :@ :: : ::: ::: : ::: ::::: ::: :: :@: : :@:: ::: :: ::: :::@::::::@
     |  # :@ :: : ::: ::: : ::: ::::: ::: :: :@: : :@:: ::: :: ::: :::@::::::@
     |  # :@ :: : ::: ::: : ::: ::::: ::: :: :@: : :@:: ::: :: ::: :::@::::::@
     |  # :@ :: : ::: ::: : ::: ::::: ::: :: :@: : :@:: ::: :: ::: :::@::::::@
     |  # :@ :: : ::: ::: : ::: ::::: ::: :: :@: : :@:: ::: :: ::: :::@::::::@
     |  # :@ :: : ::: ::: : ::: ::::: ::: :: :@: : :@:: ::: :: ::: :::@::::::@
     |  # :@ :: : ::: ::: : ::: ::::: ::: :: :@: : :@:: ::: :: ::: :::@::::::@
     |  # :@ :: : ::: ::: : ::: ::::: ::: :: :@: : :@:: ::: :: ::: :::@::::::@
     |  # :@ :: : ::: ::: : ::: ::::: ::: :: :@: : :@:: ::: :: ::: :::@::::::@
     |  # :@ :: : ::: ::: : ::: ::::: ::: :: :@: : :@:: ::: :: ::: :::@::::::@
     |  # :@ :: : ::: ::: : ::: ::::: ::: :: :@: : :@:: ::: :: ::: :::@::::::@
     |  # :@ :: : ::: ::: : ::: ::::: ::: :: :@: : :@:: ::: :: ::: :::@::::::@
     |  # :@ :: : ::: ::: : ::: ::::: ::: :: :@: : :@:: ::: :: ::: :::@::::::@
     |  # :@ :: : ::: ::: : ::: ::::: ::: :: :@: : :@:: ::: :: ::: :::@::::::@
     |  # :@ :: : ::: ::: : ::: ::::: ::: :: :@: : :@:: ::: :: ::: :::@::::::@
     |  # :@ :: : ::: ::: : ::: ::::: ::: :: :@: : :@:: ::: :: ::: :::@::::::@
     |  # :@ :: : ::: ::: : ::: ::::: ::: :: :@: : :@:: ::: :: ::: :::@::::::@
     |  # :@ :: : ::: ::: : ::: ::::: ::: :: :@: : :@:: ::: :: ::: :::@::::::@
   0 +----------------------------------------------------------------------->Mi
     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

von mh (Gast)


Bewertung
0 lesenswert
nicht 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?

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


Bewertung
0 lesenswert
nicht 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.

von mh (Gast)


Bewertung
1 lesenswert
nicht 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.

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


Bewertung
0 lesenswert
nicht 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.
Valgrind HEAP SUMMARY:

10 x 10:
BDC:      total heap usage: 16 allocs, 16 frees, 25,000 bytes allocated
Jacobi:   total heap usage:  8 allocs,  8 frees, 21,136 bytes allocated

100 x 100:
BDC:      total heap usage: 888 allocs, 888 frees, 1,051,704 bytes allocated
Jacobi:   total heap usage:   8 allocs,   8 frees,   219,856 bytes allocated

200 x 100:
BDC:      total heap usage: 891 allocs, 891 frees, 1,820,152 bytes allocated
Jacobi:   total heap usage: 217 allocs, 217 frees,   706,400 bytes allocated

300 x 50:
BDC:      total heap usage: 453 allocs, 453 frees, 1,451,844 bytes allocated
Jacobi:   total heap usage: 117 allocs, 117 frees,   754,400 bytes allocated

300 x 100:
BDC:      total heap usage: 892 allocs, 892 frees, 2,697,368 bytes allocated
Jacobi:   total heap usage: 217 allocs, 217 frees, 1,147,200 bytes allocated

1000 x 1000:
BDC:      total heap usage: 9,267 allocs, 9,267 frees, 154,198,928 bytes allocated
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.
--------------------------------------------------------------------------------
Command:            build/bdc
Massif arguments:   --stacks=yes --massif-out-file=build/bdc.out
ms_print arguments: build/bdc.out
--------------------------------------------------------------------------------


    MB
1.489^                                       #                                
     |                                       #:::::                           
     |                                       #:   :       :::::::             
     |                                       #:   ::      :   : ::::::::@     
     |                                   @@@:#:   :::::::::   : :::     @     
     |       :@:@::::::     :   :::@:::::@@ :#:   :::    ::   : :::     @ :::@
     |       :@:@::::::::::::::::::@:::::@@ :#:   :::    @:   : :::     @::::@
     |      @:@:@::::::::::::::::::@:::::@@ :#:   :::    @:   : :::     @::::@
     |      @:@:@::::::::::::::::::@:::::@@ :#:   :::    @:   : :::     @::::@
     |      @:@:@::::::::::::::::::@:::::@@ :#:   :::    @:   : :::     @::::@
     |      @:@:@::::::::::::::::::@:::::@@ :#:   :::    @:   : :::     @::::@
     |      @:@:@::::::::::::::::::@:::::@@ :#:   :::    @:   : :::     @::::@
     |      @:@:@::::::::::::::::::@:::::@@ :#:   :::    @:   : :::     @::::@
     |      @:@:@::::::::::::::::::@:::::@@ :#:   :::    @:   : :::     @::::@
     |      @:@:@::::::::::::::::::@:::::@@ :#:   :::    @:   : :::     @::::@
     |      @:@:@::::::::::::::::::@:::::@@ :#:   :::    @:   : :::     @::::@
     |      @:@:@::::::::::::::::::@:::::@@ :#:   :::    @:   : :::     @::::@
     |      @:@:@::::::::::::::::::@:::::@@ :#:   :::    @:   : :::     @::::@
     |      @:@:@::::::::::::::::::@:::::@@ :#:   :::    @:   : :::     @::::@
     |    :@@:@:@::::::::::::::::::@:::::@@ :#:   :::    @:   : :::     @::::@
   0 +----------------------------------------------------------------------->Mi
     0                                                                   66.32
Wo der Speicher bleibt ist klar: in der Rekursion (divide-and-conquer).

: Bearbeitet durch User
von mh (Gast)


Bewertung
0 lesenswert
nicht 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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.