I have found Rust compilation (Via Cargo) on the Framework 13 AMD 7840U is incredibly slow, what used to take mere minutes on an 11th Gen Intel i7 is now taking around 4–6 hours.
I can’t seem to figure out the cause. Even with tuned in latency-performance configuration and cores hitting 4.2GHz. It however isn’t using more than 100% of a single core at a time. It is however using all cores during compile.
During compilation, there’s no slow down on the system running any day to day tasks. It seems to be limited in how fast it can munch through the compilation, the CPU temp is usually hitting 90*C. The old intel Laptop had far worse cooling than this Framework, so I’m a little confused.
I’ve noticed this during builds of alacritty, eza and spotify_player.
I’m running Debian Sid, with the latest updates, using only 64bit packages. On Kernel ‘6.7.9-amd64’. I have also installed all AMD firmware that’s listed on the Debian wiki. The BIOS is on V03.03b. I have 16GB of RAM, 2GB reserved as VRAM.
Thermal throttling. If you’re confident the CPU is running at a reasonable clock though, you can probably rule this out.
Swapping. Is your RAM getting maxed out, causing your system to rely on swap?
Some kinda virtualization gone wrong. You’re not compiling inside docker buildx or anything like that right? I’ve gotten 6 hour compile times in the past when compiling for ARM with docker buildx because of the qemu overhead.
We do not test against Debian. I agree with others, this is likely thermal throttling, but would want to see it against a fully updated Fedora 39 install to be sure as I have not had issues with cargo on it.
Thermal throttling seems unlikely to me. Usage would still be pinned even if it was throttling, and 4-6 hours seems like a lot. You don’t have this issue with other intensive workloads right?
My intuition says there’s just something wrong with your cargo configuration or rust on your system. As Matt suggested, live booting a USB to sanity check may be helpful!
What’s your default target for rustup? Should be stable-x86_64-unknown-linux-gnu.
What linker are you using? Should be x86_64-linux-gnu-gcc.
Maybe there’s something wonky on debian causing rustup to set those wrong. Just spitballing 'cause if it’s not thermal throttling, swap, or virtualization then I’m running out of good ideas
I can suggest you doing rustup update to see if it would make any difference. It could be that on the older machine you used different version of rustc.
Also it is worth checking iostat so see what’s happening, because sometimes iowait can be misinterpreted as 100% CPU load when in fact it’s busy waiting for data. That can also explain why it feels responsive under normal load, since typical apps do not yield multi-gigabyte writes within short amount of time.
It could be that you have degraded FS and/or SSD that sabotages your I/O.
OK Super weird, nothing is showing in iotop for the builds. I’m currently compiling both tealdeer and bat and they aren’t showing. pretty much just firefox, thunderbird and xorg pop up.
While this is happening I’m also noticing actions like archiving in thunderbird is hanging and opening a screenshot in gimp is super slow. I think you might be right in it being an SSD issue. I’ll run some tests.
OK, coming back to this the next day, I think I’ve found the overarching issue with the compilation, as tweaking it made builds run superfast. It had nothing to do with the SSD itself.
I had Clam On Access scanning /tmp and var/tmp. It was having issues with something I guess and blocking access to files cargo was using. I haven’t looked into logs, and unless someone else encounters this I’m not going to. But I now only have Clam on access scanning my downloads.
Insane speed boost by doing this.
It makes sense as ClamAV was using a lot of resources while building with cargo, should have noticed it sooner.
