Since the real objective here is to try out Open BLAS, I dusted off my ancient rotorcraft code - all F77 - and tried linking it two ways:

1) -llapack -lopenblas

In this case lapack.so itself was built against libopenblas.

2) -L./lapack -L./blas -llapack -lblas

builds only mini static versions of lapack and blas with just the required routines, using the supposedly-slow netlib reference implementations.

#1 should be faster, right?

However, #2 produced an executable that ran a smidgen faster.

How about that. Maybe it does some inlining that's not possible when one links dynamically? Just a hypothesis.

This is what we call low-priority goofing off.



On 5/25/25 19:25, Peter J. Teuben wrote:
My tangent of the day is amusecode.org <http://amusecode.org>

On Sun, May 25, 2025, 19:18 J. Milgram <milg...@cgpp.com> wrote:

    Truth is, speed isn't an issue, I was just doing some catch-up
    upgrading and wanted to make sure I was getting what I expected to
    see. I agree... If I needed speed, I'd go with good old Fortran...
    and reel off the analysis cases with GNU parallel. That said a
    good BLAS is nice to have to link Fortran programs against.

    I seldom actually use octave, except to do little things.

    But I took the time to build this OpenBLAS package, and, dang it,
    I want to see it work!


    On May 25, 2025 at 18:47, Peter J. Teuben <teu...@umd.edu> wrote:

    Of course if speed is really an issue, is look at a more
    compilable language.. I looked at my Kubuntu 25.04 I'm using
    today, now it's a snap package. Horrific new world.

    Disk caching and LD preload should fix any latencies ineoyld
    think, or does your code loop in shell calling octave for small jobs?

    On Sun, May 25, 2025, 18:23 J. Milgram <milg...@cgpp.com> wrote:


        Thanks Derek, and Peter.

        To check whether it was statically linked (had same thought),
        I did:

        locate -ir 'lib.*blas.a$'

        ... which turned up nothing (except some ancient libblas.a
        builds in an
        out-of-the way non-system project directory) which convinces
        me that
        there's no static blas library on my system to link anything
        to. Same
        with liblapack.

        Have done my best with the build scripts and it seems like at
        one point
        "configure" sets LIBS="-lopenblas $LIBS" which is encouraging
        but the
        configure script is so dense I can't be sure that this
        applies to the
        executable as installed, and not just to one of the
        short-lived config
        test programs it builds along the way.

        I was sure that octave had a runtime option to dump all
        interesting
        configuration info but maybe I'm imagining it.

        BTW my interest in this is as much about understanding how
        ldd works as
        it is about getting octave to run faster...

        thanks again!

        Judah


        On 5/25/25 17:13, Derek Juba wrote:
        > On 5/25/25 17:02, J. Milgram wrote:
        >> Here's a mystery I'm hoping someone can explain:
        >>
        >> I just built octave (9.2.0). As usual, an easy build.  But
        this time
        >> I'm curious: How can I confirm that it linked against
        OpenBLAS and
        >> not one of the  other blas's I  have installed?
        >>
        >> ldd /usr/bin/octave doesn't turn up any blas libraries at
        all. (huh?!)
        >>
        >> The build procedure  is advertised as using the first blas
        it finds
        >> from the list [ OpenBLAS, atlas, netlib reference
        implementation ]. I
        >> have the first and third installed so  am hoping for OpenBLAS.
        >>
        >> Anyone know a way to check this? Or why ldd doesn't show the
        >> executable linked to any blas at all?
        >>
        >> thanks! And a meaningful Mem Day to all.
        >>
        >> Judah
        >>
        >>
        >>
        >
        > My first though is that perhaps ldd doesn't show blas libs
        because
        > they were statically linked?
        >
        > In any case, you might want to look at build logs to what,
        if any,
        > blas was used.
        >
        > -Derek
        >

-- =====
        milg...@cgpp.com
        301-257-7069



You received this email because you are subscribed to the UM Linux User's Group (UM-LINUX) mailing list. If you would like to unsubscribe from this list, simply send an email to lists...@listserv.umd.edu with the message signoff UM-LINUX in the body.

--
=====
milg...@cgpp.com
301-257-7069

You received this email because you are subscribed to the UM Linux User's Group 
(UM-LINUX) mailing list. If you would like to unsubscribe from this list, 
simply send an email to lists...@listserv.umd.edu with the message signoff 
UM-LINUX in the body.

Reply via email to