search

ghdl / docker

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

Size optimize the VUnit images #32

Closed LukasVik closed 3 years ago

LukasVik commented 3 years ago

Motivation: These docker images are used in CI in tsfpga and other projects. At the moment, in tsfpga, pulling the docker image represent a significant portion of the CI time. In order to save execution time, bandwidth and power, keeping docker images small should always be a priority.

In summary, -27 MB for the stable image, -75 MB for master image.

See the individual commits for details and some discussion around the individual changes.

LukasVik commented 3 years ago

Additionally, 115 MB could be saved in mcode images by not installing gcc and libc6-dev in run_debian.dockerfile. This does however affect the testsuite of ghdl. The following tests fail without gcc:

testsuite/gna/bug097
testsuite/gna/issue1226
testsuite/gna/issue1228
testsuite/gna/issue1233
testsuite/gna/issue1256
testsuite/gna/issue1326
testsuite/gna/issue450
testsuite/gna/issue531
testsuite/gna/issue98
testsuite/vpi/vpi001
testsuite/vpi/vpi002
testsuite/vpi/vpi003

All these tests seem to be testing VPI. However saving 115 MB from the mcode image is very tempting. That would make it very minimal, and perfect for CI.

It is not obvious to me that gcc should be included in the mcode docker image for the sake of being able to run vpi examples. I could add a mechanism to the GHDL testsuite so that these test do not run unless gcc is available on the system. In this scenario, if someone wants to use VPI, they would have to install a compiler of their choice on top of this image, or use ghdl/ghdl:gcc .

eine commented 3 years ago

Additionally, 115 MB could be saved in mcode images by not installing gcc and libc6-dev in run_debian.dockerfile.

I believe this is the elephant in the room. As you guessed, GCC is added to mcode images for co-simulation purposes. When LLVM or GCC backends are used, GHDL can build C sources "internally". This allows providing VHDL sources and C sources, and let GHDL do the magic. With mcode, that's not possible, because it can only interact with pre-built shared libraries. Hence, a C compiler is required for users to convert their co-simulation C/C++ sources into a shared library. Providing it in the runtime image is convenient because it ensures that any image can be used for co-simulation with foreign languages.

Having said that, you are correct; we should not force all the users to download GCC, unless they need/want to.

I could add a mechanism to the GHDL testsuite so that these test do not run unless gcc is available on the system. In this scenario, if someone wants to use VPI, they would have to install a compiler of their choice on top of this image, or use ghdl/ghdl:gcc .

Please, go ahead. See examples of tests skipped for other reasons:

Related to previous comments about the purpose of these images, a few months ago some ghdl/cosim:* images were created. I think it makes sense now to make ghdl/vunit more specific, and create ghdl/cosim:mcode and ghdl/cosim:py. I propose the following roadmap:

LukasVik commented 3 years ago

Please, go ahead.

I will get to it in the upcoming days. Maybe tomorrow, maybe next week.

Thank for your help!

eine commented 3 years ago

@LukasVik, BTW, you might like wagoodman/dive.

LukasVik commented 3 years ago

@LukasVik, BTW, you might like wagoodman/dive.

Yeah that tool is great. I used it a lot in this investigation.

LukasVik commented 3 years ago

I have cleaned up the commits and fixed all your suggestions. I think this PR is ready to merge.

LukasVik commented 3 years ago

I have created #34 for followup work so that this PR can be closed.