Hacker News Reader

Comment by sp332 | Hacker News Reader

I was about to point out that it compiled in 4.8 seconds back in 2002 http://es.tldp.org/Presentaciones/200211hispalinux/blanchard... But then I remembered that it was only 4 million lines of code back then (v2.5.x) and now it's 18 million! https://www.linuxcounter.net/statistics/kernel (Edit: fixed second link)

View on HN

The difference being of course that this 4.8-second compile in 2002 was done on an IBM p690 which cost half a million dollars. Whereas the 15.6-second compile was done on the EPYC 7601 which is only $4k for the CPU, ~$6k for a whole machine.

$6k vs $500k... Let that sink in :)

did they fix the random crash issue when running gcc?

https://www.phoronix.com/scan.php?page=news_item&px=Ryzen-Co...

AMD Forum Thread: https://community.amd.com/thread/215773

Last response from AMD: "The vast majority of users using Ryzen for Linux code and development have reported very positive results. ... A small number of users have reported some isolated issues and conflicting observations. AMD is working with users individually to understand and resolve these issues."

I doubt there's any single root cause here. "I get crashes when running big compiles" is a classic symptom of hardware that is almost, but not quite, stable. This can be due to power delivery problems, thermals, marginal RAM, overclocks, faulty CPU (yeah, it happens sometimes) and so on.

There used to be a long running joke (I think perhaps Linus even coined it?) that the kernel codebase grew about as fast as CPU performance improved. I guess that died around the time AMD released their dual core CPUs..

It seems reasonable, considering anyone working on it enough to need to recompile would have a minimum change time correlated with compilation time. (Incremental compilation aside)

Going to get a cup of coffee takes the same amount of time as it did 15 years ago, so devs still need a compile time which is roughly equivalent. 15 seconds would be much too fast, for example.

"What Intel giveth, Microsoft taketh away"

I haven't compiled it since the days of Slackware but it took at least on hour on my Pentium 90. (Then I discovered Debian.)

Remember gentoo Linux

Actually considering it for the next build. 16 amd core CPU. Probably 4 machines to crunch on something in the next few years.

These are awesome times we live in.

I'll admit the endless compiling was often torturous, but I have the Gentoo docs to thank for most of what I know about the innards of Linux and operating systems. Bet I'm not alone in judging the time spent worth it :)

My time in Gentoo was absolutely worth it for the same reasons. There are dozens of us! Dozens!

I still recommend it to people who are serious about diving into Linux.

I'd say I learned more by playing around with Slackware, but Gentoo provides all those nice tools to mantain a consistent system.

Is that an apples-to-apples comparison (either both monolith or both all-modules kernels, both with all drivers enabled?)

I recall, back in the long long ago, running through `make menuconfig` and disabling what I didn't need to get a smaller kernel + shorter build-times.

No, I'm sure lots of things have changed. More of the code would be using C99 semantics now, and I have no idea how GCC would have improved or regressed since then. It's possible that it's trading improved runtime performance on ever-more complex hardware for longer compile times.

The kernel is still c89.

I see that gnu89 is the default, to avoid compatibility problems with older code, but does that mean there is no code in the kernel which requires gnu99? I saw some work was done to make the whole kernel gnu11 compatible as well.

https://stackoverflow.com/questions/20600497/which-c-version...

Right, but I was too lazy to do my own analysis and just extrapolated from that 2013 post to guess that the number is higher now.

Reply on news.ycombinator.com