3. programm zu langsam (hoffnungslos denke ich)

programm zu langsam (hoffnungslos denke ich)

  • T

    ich habe mal mein project mit cachegrind profiled
    und 86,61% der instruktionen laufen in dieser Zeile ab :

    // dot product
template <class T>
T Vector<T>::operator*(const Vector& v) const
{
T ret_val=0;
for(std::size_t i=0; i < m_Dim; i++) ret_val += m_data[i] * v.m_data[i]; // 86.61%
return ret_val;
}

    ich denke mal, da irgendwas zu optimieren ist hoffnungslos, oder?
    ich könnte per hand die schleife aufrollen,aber da pfusche ich imho dem
    compiler dazwischen

    m_data ist ein pures c-array vom type T, inline dürfte auch nichts bringen,
    denn 86.61% laufen in dieser Zeile ab, und die kosten für die gesamten Aufrufe sind nur unbedeutend höher : 86.77

    vorschläge sind willkommen ...

    profiling mit kcachegrind ist leider nur im debug-modus möglich, also weiss ich auch nicht direkt, wie der gcc (oder icc, ich benutze beide) sowas optimiert, und wie man da noch was rausholen kann.

    aber immerhin schön, das ich nix optimieren muss, wenn nicht diese eine zeile 😮

    0
  • D

    Was ist den m_Dim? Oder besser gesagt, wieviel mal durchläuft er die Schlaufe?

    0
  • ?

    glaub kaum, dass man die berechnung selbst grossartig optimieren kann. überprüf lieber die stellen, an denen die methode gerufen wird und reduzier die aufrufe, sofern es möglich ist. wenn das produkt zweier vektoren einmal berechnet wurde, muss es nie ein zweites mal berechnet werden, solange sich an den beiden beteiligten vektoren nix geändert hat.

    je nach größe der vektoren könnte man hier mit ner art caching nachhelfen. die vector klasse muss sich dazu möglicherweise merken, ob sie sich geändert hat.

    wichtig ist hier allerdings dann die frage, wie gross so ein vektor ist. wenn m_dim klein ist, wird man auch mit caching nicht viel erreichen. dann hilft nur die aufrufe zu reduzieren.

    0
  • T

    also in der jetzigen version haben die Vektoren ne dimension von 500-1000,

    Das sind dann in der Klasse darüber 500-1000 aufrufe dieser Funktion aber über
    openMP parallelisiert.

    also eigentlich ist das ganze eine multiplikation einer
    (500-1000)x(500-1000) Matrix mit einem Vektor, die Matrix ist voll besetzt

    0
  • D

    Du profilest im Debug-Modus? Leider kann man da noch keine Entschiedungen treffen, welche Teile wirklich relevant sind. Eventuell optimiert dein Kompiler so gut, dass der jetzige Flaschenhals im Release-Code gar kein Problem mehr darstellt. Bestimmte Redundanzen muss der Kompiler im Debugmodus nämlich im Code so belassen, da sonst Debuggen nur noch schwer möglich wäre.

    Gruß
    Don06

    0
  • ?

    Dein Profiling im Debugmodus kannst du vergessen.

    0
  • T

    ihr habt recht, ich baue grade kernel neu, und profile dann im release-modus

    0
Anmelden zum Antworten