[boost][uBLAS] sind ranges langsam?



  • Moin Leute 🙂

    ich benutze seit einiger Zeit intensiv uBLAS. Bisher hatte ich es eigentlich immer recht gedankenls verwendet, sobald ich lineare Algebra verwenden musste. Heute habe ich dann gemerkt, dass die Prämise "uBLAS ist automatisch schnell" nicht zu gelten scheint. Stichwort noalias bei Zuweisungen.

    Nun habe ich mal überprüft, was mir sonst noch so wiederfahren kann und bin dabei über die vector-ranges gestolpert. Ursprünglich dachte ich, dass die zero-cost wären, und ich einfach on-the-fly einen großen Vector in kleine Teile aufsplitten kann, wenn ichs brauche.

    Beispielcode von heute(RealVector und RealVectorRange sind typedefs auf die ublas typen vector<...> und vector_range<...>):

    RealVector parameters;
    for(size_t neuron=0;neuron!=m_neurons.size();++neuron){
        size_t start=neuron*size;
        RealVectorRange range=subrange(parameters,start,start+size);
        neuronParameters=//...ein komplexer Vector;
    }
    

    Nun steht aber auf der boost-Homepage zu range_vector(die grad passend down ist):
    Complexity: Linear depending from the size of the range.

    Ich konnte das nicht glauben und habe mich durch den Code gewühlt - aber ich konnte nichts finden, was in irgendeine Richtung gedeutet hat, und Google weiß auch nichts.
    Wisst ihr vielleicht, ob das mit der Laufzeit wirklich so schlimm ist? Ich kann da sirgendwie nicht glauben, weil subranges doch eine so elementare Operation sind. Lineare Laufzeit wäre für mich tödlich und ich will irgendwie nicht wieder indizes rumschieben und alle Werte von Hand berechnen...

    (und bevor jemand premature Optimization sagt: in meinem Fall ist genau die LinAlg der Bottleneck, weil die Operationen ca 10 Millionen mal aufgerufen werden in einem Durchlauf).

    Und wo wir gerade dabei sind: kennt ihr weitere Sachen, womit man sich bei uBLAS schnell ins Bein schießt, was Rechenzeit angeht?



  • Was soll lineare Komplexität dabei haben? Das Anlegen der Ranges? Das fände ich auch merkwürdig. Beim Überfliegen des Codes ist mir nicht aufgefallen, das darauf hinweist.
    Vielleicht mal mit einem Debugger dabei gehen, und gucken, ob bei den Ranges irgendwo iteriert wird.



  • Das ein zige, was mir auffällt ist das:

    BOOST_UBLAS_INLINE
    const_iterator begin () const {
        return find (0);
    }
    

    und find ist:

    const_iterator find (size_type i) const {
        const_subiterator_type it (data_.find (start () + i));
    //...
            }
    

    eventuell könnte das lineare zeit brauchen, je nachdem welchen Vektor man verwendet. Aber sonst sehe ich nichts.



  • otze schrieb:

    Moin Leute 🙂

    ich benutze seit einiger Zeit intensiv uBLAS.

    Die ist nicht sonderlich schnell im Vergleich zu anderen BLAS Implementationen. Wenn es schnell sein soll dann sollte man eher zur GotoBLAS, ACML, MKL o.ä. greifen.


Log in to reply