Linus Torvalds Hits Nasty Performance Regression With Early Linux 6.8 Code

[sophisticles]

I don't think it is surprising at all. The machine is still very fast and probably fast enough for what it is supposed to do. 22 seconds are not that bad, are they?

More than that, people seem to place way too much emphasis on compile performance in general.

The heavy lifting is done when you are writing and testing the code, not when you are compiling it.

Compilation time is the excuse you need to get a sandwich, get a drink, make a phone call, watch a video or go for a walk.

No one is actually sitting there watching the code get compiled.

[sophisticles]

I'm all for automated testing, but this looks like a case you would expect to only catch when testing with a human at the helm.

The biggest problem with open source software is all the automated testing that is relied on instead of good old fashioned hand on testing.

This is why there are so many open source projects with bugs that last for years.

[Weasel]

More than that, people seem to place way too much emphasis on compile performance in general.

The heavy lifting is done when you are writing and testing the code, not when you are compiling it.

Compilation time is the excuse you need to get a sandwich, get a drink, make a phone call, watch a video or go for a walk.

No one is actually sitting there watching the code get compiled.

Dude, you are so clueless. It's not about compiling the kernel being slower. HE USES THE NEW KERNELS because unlike a lot of "open source champs" who just don't give a fuck about their work and don't use their own products because they clearly consider them inferior, he uses his kernel for production.

The fact it regressed his kernel compilation times is a PERFORMANCE REGRESSION in the new kernel. It has nothing to do with the compilation process itself taking longer: on an older kernel, it compiles fast still.

So it's a serious performance regression with respect to scheduling, and I'm glad this gets found because it affects EVERY SCHEDULED app. Compilation is affected a lot since it uses a ton of threads, so yeah.

[pmorph]

More than that, people seem to place way too much emphasis on compile performance in general.

The heavy lifting is done when you are writing and testing the code, not when you are compiling it.

Compilation time is the excuse you need to get a sandwich, get a drink, make a phone call, watch a video or go for a walk.

No one is actually sitting there watching the code get compiled.

Writing and testing code in an efficient way is greatly helped by having fast compile times.

[oleid]

Dude, you are so clueless. It's not about compiling the kernel being slower. HE USES THE NEW KERNELS because unlike a lot of "open source champs" who just don't give a fuck about their work and don't use their own products because they clearly consider them inferior, he uses his kernel for production.

The fact it regressed his kernel compilation times is a PERFORMANCE REGRESSION in the new kernel. It has nothing to do with the compilation process itself taking longer: on an older kernel, it compiles fast still.

So it's a serious performance regression with respect to scheduling, and I'm glad this gets found because it affects EVERY SCHEDULED app. Compilation is affected a lot since it uses a ton of threads, so yeah.

Please read the discussion thread again. It was not about the regression, it was about getting new hardware.

[yump]

More than that, people seem to place way too much emphasis on compile performance in general.

The heavy lifting is done when you are writing and testing the code, not when you are compiling it.

Compilation time is the excuse you need to get a sandwich, get a drink, make a phone call, watch a video or go for a walk.

No one is actually sitting there watching the code get compiled.

As far as I can tell, since Linus' work mostly consists of integrating other peoples patches, which have already been written and (in theory) tested, he has a much higher ratio of compiling than most. But even then the potential time saved by upgrading has to be compared against the time and effort of configuring and qualifying a new workstation.

[Hans Bull]

How would you write a test case to consider the total compilation time? Considering the billion ways to build a Linux kernel?

Difficult to imagine that kernel compilation time was the only workload affected by this regression.

[zloturtle]

I don't think it is surprising at all. The machine is still very fast and probably fast enough for what it is supposed to do. 22 seconds are not that bad, are they?

It is well known that giving developers fast machines risk them writing less efficient code.

[sophisticles]

Dude, you are so clueless. It's not about compiling the kernel being slower. HE USES THE NEW KERNELS because unlike a lot of "open source champs" who just don't give a fuck about their work and don't use their own products because they clearly consider them inferior, he uses his kernel for production.

The fact it regressed his kernel compilation times is a PERFORMANCE REGRESSION in the new kernel. It has nothing to do with the compilation process itself taking longer: on an older kernel, it compiles fast still.

So it's a serious performance regression with respect to scheduling, and I'm glad this gets found because it affects EVERY SCHEDULED app. Compilation is affected a lot since it uses a ton of threads, so yeah.

You are responding to something I didn't actually say.

[bug77]

The biggest problem with open source software is all the automated testing that is relied on instead of good old fashioned hand on testing.

This is why there are so many open source projects with bugs that last for years.

You can't do just "old fashioned hands on testing" without a solid base of automated tests. It simply can't be done.