ghdl / docker

Scripts to build and use docker images including GHDL
40 stars 10 forks source link

Size of GCC packages #12

Open eine opened 5 years ago

eine commented 5 years ago

Sizes of Buster images:

ghdl/run:buster-gcc        96MB
ghdl/run:buster-llvm-7     116MB
ghdl/run:buster-mcode      84.6MB

ghdl/ghdl:buster-gcc-8.3.0 303MB - 96MB  = 207MB
ghdl/ghdl:buster-llvm-7    123MB - 116MB = 7MB
ghdl/ghdl:buster-mcode     88MB  - 84.6  = 3.4MB

It is surprising that GHDL tarballs with mcode or LLVM backends require less than 10MB, but GCC requires >200MB! I think we might be doing something wrong, such as adding build artifacts to the GCC tarball (which should not be there).

Image ghdl/ghdl:buster-gcc-8.3.0 can be inspected with wagoodman/dive:

docker run --rm -it \
  -v /var/run/docker.sock:/var/run/docker.sock \
  wagoodman/dive \
  ghdl/ghdl:buster-gcc-8.3.0

dive_gcc

dive_gcc2

@tgingold, in the first screenshot I'm concerned with lib/ghdl/*/*/*.o files. Should all of those be there? With LLVM or mcode backend only lib/ghdl/*/*/*.cf files exist. Regarding the second screenshot, libexec/gcc/x86_64-pc-linux-gnu/8.3.0/cc1 requires 239MB, and ghdl1 in the same dir requires 237MB! Is this ok?

Last, as seen in the second screenshot, info and man pages for ghdl are added. However, I believe this is not the same man doc that we generate with sphinx (see ghdl/ghdl#733). Where does it come from?

tgingold commented 5 years ago

@tgingold, in the first screenshot I'm concerned with lib/ghdl///.o files. Should all of those be there? With LLVM or mcode backend only lib/ghdl///.cf files exist.

Then I think there is an issue with the LLVM image: it needs the .o files.

Regarding the second screenshot, libexec/gcc/x86_64-pc-linux-gnu/8.3.0/cc1 requires 239MB, and ghdl1 in the same dir requires 237MB! Is this ok?

Looks OK. I suppose that ghdl1-llvm uses shared libraries for the LLVM part, while they don't exist for gcc.

Last, as seen in the second screenshot, info and man pages for ghdl are added. However, I believe this is not the same man doc that we generate with sphinx (see ghdl/ghdl#733). Where does it come from?

I suppose it comes from doc/ghdl.1

eine commented 5 years ago

Then I think there is an issue with the LLVM image: it needs the .o files.

My bad, you are correct. The LLVM image includes *.o files too.

Looks OK. I suppose that ghdl1-llvm uses shared libraries for the LLVM part, while they don't exist for gcc.

That makes sense. So, with LLVM we are only building a frontend, but with GCC we need to rebuild a completetely new GCC in order to include the frontend. Should the GCC version of the system and the version of the GCC sources that are used as GHDL's backend be the same, would it be possible to optimize this?

Otherwise, it might be worth mentioning it in https://ghdl.readthedocs.io/en/latest/building/Building.html, so users are aware that GCC requires 20x space (2-3x if taking the size of docker images as a reference).

I suppose it comes from doc/ghdl.1

Wow, that must be so out of date! What about updating it with https://github.com/ghdl/ghdl/releases/download/v0.36/ghdl.1?

tgingold commented 5 years ago

That makes sense. So, with LLVM we are only building a frontend, but with GCC we need to rebuild a completetely new GCC in order to include the frontend. Should the GCC version of the system and the version of the GCC sources that are used as GHDL's backend be the same, would it be possible to optimize this?

Yes, that can be optimized. ghdl uses the system gcc for linking. There might be issues for coverage however.

Wow, that must be so out of date! What about updating it with https://github.com/ghdl/ghdl/releases/download/v0.36/ghdl.1?

Why not.

eine commented 5 years ago

Yes, that can be optimized. ghdl uses the system gcc for linking. There might be issues for coverage however.

Great, I'll leave this issue open to track this. Unfortunately, I cannot focus on it now.

Why not.

I'll think about a reasonable procedure to 'automate' it. Say, updating it just before every tagged commit.