search

clash-lang / clash-compiler

Haskell to VHDL/Verilog/SystemVerilog compiler
https://clash-lang.org/
Other
1.43k stars 151 forks source link

"Setting up GHC" slowdown when going from GHC 9.0 to 9.4 #2710

Open gergoerdi opened 5 months ago

gergoerdi commented 5 months ago

I'm trying to upgrade Pong to use Clash 1.8 with a recent version of GHC. I've managed to upgrade to Clash 1.8/GHC 9.0, but then when I try to switch to GHC 9.4, I start getting problems in Clashilator.

I'll need to investigate some of them on my side first, but one thing I noticed is that with GHC 9.0, the "Setting up GHC" step takes <1s and on GHC 9.4 it takes almost a minute. You can try it on this temporary branch just running stack build --flag clash-pong:verilator:

clash-pong > GHC: Setting up GHC took: 57.114s
clash-pong > GHC: Compiling and loading modules took: 2.587s
clash-pong > Clash: Parsing and compiling primitives took 0.125s
clash-pong > GHC+Clash: Loading modules cumulatively took 1m0s
clash-pong > Clash: Compiling Pong.topEntity
clash-pong > Clash: Normalization took 0.287s
clash-pong > Clash: Netlist generation took 0.015s
clash-pong > Clash: Compiling Pong.topEntity took 0.414s
clash-pong > Clash: Total compilation took 1m0s
martijnbastiaan commented 5 months ago

Perhaps same as https://github.com/clash-lang/clash-compiler/issues/2684 ?

martijnbastiaan commented 5 months ago

And maybe the same as https://github.com/martijnbastiaan/doctest-parallel/issues/78..

christiaanb commented 5 months ago

Is the executable dynamically linked?

martijnbastiaan commented 5 months ago

@gergoerdi This is the same issue as doctest-parallel runs into. Downgrading to GHC 9.4.7 / LTS 21.21 "fixes" the issue.

gergoerdi commented 5 months ago

Is the executable dynamically linked?

Stupid question but -- how do I tell?

gergoerdi commented 5 months ago

Stupid question but -- how do I tell?

OK so with stack build --cabal-verbose --verbose I was able to find the setup program generated by Cabal, which is what is running Clash in-proc (using Clash.Main.defaultMainWithAction) and indeed it is dynamically linked. I have no idea how to control this, since this program is built by Cabal/Stack from Setup.hs.

gergoerdi commented 5 months ago

@gergoerdi This is the same issue as doctest-parallel runs into. Downgrading to GHC 9.4.7 / LTS 21.21 "fixes" the issue.

FWIW I can confirm this.

gergoerdi commented 5 months ago

Stupid question but -- how do I tell?

OK so with stack build --cabal-verbose --verbose I was able to find the setup program generated by Cabal, which is what is running Clash in-proc (using Clash.Main.defaultMainWithAction) and indeed it is dynamically linked. I have no idea how to control this, since this program is built by Cabal/Stack from Setup.hs.

According to more stack build --cabal-verbose --verbose, the setup program gets compiled with the following flags:

ghc-9.4.8
        --make
        -odir /home/cactus/prog/clash/pong/.stack-work/dist/x86_64-linux/ghc-9.4.8/setup
        -hidir /home/cactus/prog/clash/pong/.stack-work/dist/x86_64-linux/ghc-9.4.8/setup
        -i -i.
        -clear-package-db -global-package-db -package-db=/home/cactus/sdk/stack/snapshots/x86_64-linux/27724336f5cab67ecb9719f752c3eaa6ba6a8ae2f840f16180637123d005e264/9.4.8/pkgdb -package-db=/home/cactus/prog/clash/pong/.stack-work/install/x86_64-linux/27724336f5cab67ecb9719f752c3eaa6ba6a8ae2f840f16180637123d005e264/9.4.8/pkgdb
        -hide-all-packages -package-id=Cabal-3.8.1.0 -package-id=base-4.17.2.1 -package-id=clashilator-0.1.3-IfbBYrcr43e6EtNP5GgB1K
        -optP-include -optP/home/cactus/prog/clash/pong/.stack-work/dist/x86_64-linux/ghc-9.4.8/setup/setup_macros.h
        /home/cactus/prog/clash/pong/Setup.hs
        /home/cactus/sdk/stack/setup-exe-src/setup-shim-6HauvNHV.hs
        -main-is StackSetupShim.mainOverride
        -o /home/cactus/prog/clash/pong/.stack-work/dist/x86_64-linux/ghc-9.4.8/setup/setup
        -threaded

Nothing immediately jumps at me that would set -dynamic.

christiaanb commented 5 months ago

I was only asking whether the executable was dynamically linked, because I know that the clash binaries have a very slow startup time when they are statically linked (on non-Windows platforms) to Haskell libraries. So if you're saying that your binary is dynamically linked to other Haskell libraries, than that is not the issue.

I think you confirmed that the issue doesn't show itself with GHC 9.4.7, which suggests it's the same issue that was hurting doctest-parallel: https://gitlab.haskell.org/ghc/ghc/-/issues/23464