Aurelien Jarno
2025-01-08 21:00:01 UTC
Reply
PermalinkPackage: release.debian.org
Severity: important
Hi,
I love the idea behind riscv, but I am concerned about riscv's current
performance. As an example, the build times for gcc-13/gcc-14 on riscv is
measured 5-13 days, which 1-2œ the standard testing delay.
https://buildd.debian.org/status/logs.php?pkg=gcc-14&arch=riscv64
13 days is specific to version 14.2.0-11, which does not run theSeverity: important
Hi,
I love the idea behind riscv, but I am concerned about riscv's current
performance. As an example, the build times for gcc-13/gcc-14 on riscv is
measured 5-13 days, which 1-2œ the standard testing delay.
https://buildd.debian.org/status/logs.php?pkg=gcc-14&arch=riscv64
testsuite in parallel to debug #1089007. The same version takes 2d 10h
on a fast amd64 build daemon:
https://buildd.debian.org/status/logs.php?pkg=gcc-14&arch=amd64
Now that the issue has been fixed, we are back to the 5-7 days area,
which we agree is still too long.
This slowest seems unsustainable. Consider for pu-uploads, the deadline for
uploads are generally a week before the point release and this would still
not be sufficient for riscv to build the package in time for the RT to
include package into the point release.
This might be gcc specific problem or a concrete buildd being inadequate
(linux, firefox-esr, and libreoffice seems to show much better build times).
Nevertheless, I feel it warrants some analysis of the problem to understand
if this will become a problem for Debian post release.
We are aware that certain packages take quite long to build on theuploads are generally a week before the point release and this would still
not be sufficient for riscv to build the package in time for the RT to
include package into the point release.
This might be gcc specific problem or a concrete buildd being inadequate
(linux, firefox-esr, and libreoffice seems to show much better build times).
Nevertheless, I feel it warrants some analysis of the problem to understand
if this will become a problem for Debian post release.
riscv64 build daemons, the other important known ones are ceph,
llvm-toolchain-*, paraview and webkit2gtk. The build time of gcc-* is
even more extreme, as it requires more build resources with every newer
version, additional enabled languages and new features like profiled
bootstrap. In addition there are variations in the tests run the between
different architectures.
The current riscv64 build daemons are all based on HiFive Unmatched,
which has been released 4 years go, and thus as you pointed, relatively
slow. We do have access to faster hardware options, such as Milk-V
Pioneer and HiFive Premier P550, both of which offer significantly
improved build times. However, these systems currently lack full
upstream kernel support, which prevents their use as build daemons. That
said P550 systems are already deployed for debci.
From our tests these systems would allow us to bring the GCC build time
back to reasonable levels, and also to reduce the number of riscv64
build daemons. Upstreaming for the Milk-V Pioneer has already started,
but not yet for the HiFive Premier P550. In both cases we expect to be
able to support them in a Debian kernel during the beginning of the
Forky cycle, when backport kernels closely following upstream kernels
will be possible again. Note that we also considered JH7110-based
hardware, already supported by the Trixie kernel. While it offers a
significant performance increase (~80%), it has an 8GiB memory
limitation, making it not worth the hassle to deploy, especially when
better hardware is already available.
Regards
Aurelien, for the riscv64 porters
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
***@aurel32.net http://aurel32.net
Aurelien Jarno GPG: 4096R/1DDD8C9B
***@aurel32.net http://aurel32.net