[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#63986: Julia is very slow
From: |
Ludovic Courtès |
Subject: |
bug#63986: Julia is very slow |
Date: |
Fri, 29 Sep 2023 10:46:07 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) |
Hi,
Efraim Flashner <efraim@flashner.co.il> skribis:
> On Mon, Sep 25, 2023 at 04:46:57PM +0200, Ludovic Courtès wrote:
[...]
>> >
>> > /gnu/store/h5mgc7ar7a05f9rwrd1makhzays5wd3s-julia-1.8.3/bin/../lib/julia/liblapack.so:
>> > undefined symbol: dsfrk_64_
>>
>> The ‘_64’ suffix is added by a patch in this very series, that adds
>> ‘SYMBOLSUFFIX=64_’ to ‘openblas-ilp64’.
>>
>> I don’t know what the rationale was for that configuration change, but
>> this is a good area of investigation.
>>
>> Efraim, WDYT?
>
> the SYMBOLSUFFIX change seems to be standard across other distributions,
> and in fact there seem to be packages out there which rely on it
> directly.
>
> Looking at this error specifically and also the pcre2-8 errors we get
> during the 'test phase for julia, it seems the suggested fix is to build
> those libraries with julia. So we'd want to replace the pcre2 and the
> lapack libraries in the julia sources (for pcre2 for all the
> architectures, for lapack for x86_64 specifically) and let julia build
> and link to them during the build phase.
That would seem like a step backwards though, no? Usually we prefer to
unbundle things.
Actually, why does liblapack.so end up in Julia itself, as opposed to
just linking to libopenblas.so?
Ludo’.