bug-guix
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#63986: Julia is very slow


From: Efraim Flashner
Subject: bug#63986: Julia is very slow
Date: Tue, 26 Sep 2023 12:27:40 +0300

On Mon, Sep 25, 2023 at 04:46:57PM +0200, Ludovic Courtès wrote:
> Hi,
> 
> Simon Tournier <zimon.toutoune@gmail.com> skribis:
> 
> > It is almost good except one strong annoyance [1]@
> >
> > Singular value decomposition |   57     57  5.0s
> > Hermitian: Error During Test at 
> > /gnu/store/zkx6p7kz3m5k5w5iy0l1d09b2n8b0ib3-julia-genericlinearalgebra-0.2.5/share/julia/loadpath/GenericLinearAlgebra/test/rectfullpacked.jl:12
> >   Got exception outside of a @test
> >   could not load symbol "dsfrk_64_":
> >   
> > /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.

-- 
Efraim Flashner   <efraim@flashner.co.il>   רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]