Fast Kernel Headers v2 Posted - Speeds Up Clang-Built Linux Kernel Build By ~88%

[coder]

I keep hearing whining about "this is slow to compile" or "this language doesn't have that feature". Makes me sad.

I can't totally agree with this sentiment, overall. Developers talk about their tools like any other profession. The quality of these discussions is going to vary, but that's not to say they have no value.

I'll grant you that some of the language advocacy tends to get overheated and causes people to entrench their positions, which is not conducive to education or their purported goal.

[bug77]

I can't totally agree with this sentiment, overall. Developers talk about their tools like any other profession. The quality of these discussions is going to vary, but that's not to say they have no value.

I'll grant you that some of the language advocacy tends to get overheated and causes people to entrench their positions, which is not conducive to education or their purported goal.

Discussions I have no problem with. My problem is when it's just whining and the developer refuses to acknowledge they should have used/learned a different language. "Look how hard it is to hammer nails with this microscope, they should have put a good handle on it - that's why I'm inefficient at my job."

[coder]

Discussions I have no problem with. My problem is when it's just whining and the developer refuses to acknowledge they should have used/learned a different language. "Look how hard it is to hammer nails with this microscope, they should have put a good handle on it - that's why I'm inefficient at my job."

Yeah, I get it. Some venting is to be expected, and it's hard to know whether the conversation really did them no good without following up to see if it impacted the way they approach such tasks/issues. Sometimes, a heated discussion will move my position, but not until after it burns out. So, it's only by following-up that you'd know for sure.

Sometimes, it takes a while to learn a languages idioms and its relative strengths and weaknesses, including what sorts of programming models and problem domains it supports. A lot of this tends to come out in discussions with peers, colleagues, teaching assistants, mentors, etc. Not everyone has such a support network, and some people just naturally like to dive in and complain to anyone who'll listen when they encounter troubles.

Maybe I'm not understanding which sorts of discussions you have in mind, but maybe you'd do well to remember that learning can sometimes be a messy process.

[tildearrow]

I regularly visited a german website for IT news and at some point they started to include pictures in every article because it somehow got them a better scoring by google or something in that line.

Oooooooo! Now I understand why the change..........................................

[rmfx]

So much fuss for a damn thumbnail. Get a life people.

[bug77]

Yeah, I get it. Some venting is to be expected, and it's hard to know whether the conversation really did them no good without following up to see if it impacted the way they approach such tasks/issues. Sometimes, a heated discussion will move my position, but not until after it burns out. So, it's only by following-up that you'd know for sure.

Sometimes, it takes a while to learn a languages idioms and its relative strengths and weaknesses, including what sorts of programming models and problem domains it supports. A lot of this tends to come out in discussions with peers, colleagues, teaching assistants, mentors, etc. Not everyone has such a support network, and some people just naturally like to dive in and complain to anyone who'll listen when they encounter troubles.

Maybe I'm not understanding which sorts of discussions you have in mind, but maybe you'd do well to remember that learning can sometimes be a messy process.

Like you said, I myself have learned a lot though discussions with peers, so I'm always up for that. But there are always those that do nothing but whine. A more serious offender is the programmer that learns a single language and a single build tool and then complains about every other language and build tool being different.
Even here, on Phoronix, you can't have an article about Rust, for example, without the knee-jerk reactions: "it's slow to compile", "but you can have type safety in C/C++ if you're careful enough", "I don't like cargo". Usually from the same posters.

[threader]

<..snip...> I'll follow up on how it goes.

That didn't go too well, fast headers V2 failed to generate arch/powerpc/include/generated/* properly, some files were generated some were not, like asm-offsets.h and page_types.h so I grabbed 5.16 0, stuffed the config in there and this is where I had to add -maltivec to arch/powerpc/mm/mmu_context and came */lib/step.c . . This is where the assembler barfed on the 'ptesync' opcode that's been around since the beginning of time ....
So now I'm glaring at mainline like a question mark, thankfully this is how I've spent my time the past few years, as a question mark glaring at the kernel wondering why it wont boot for arm*. But why gives.. I tried the Debian. 5.15 config before getting my bucket of words to post online.

[smitty3268]

That didn't go too well, fast headers V2 failed to generate arch/powerpc/include/generated/* properly, some files were generated some were not, like asm-offsets.h and page_types.h so I grabbed 5.16 0, stuffed the config in there and this is where I had to add -maltivec to arch/powerpc/mm/mmu_context and came */lib/step.c . . This is where the assembler barfed on the 'ptesync' opcode that's been around since the beginning of time ....
So now I'm glaring at mainline like a question mark, thankfully this is how I've spent my time the past few years, as a question mark glaring at the kernel wondering why it wont boot for arm*. But why gives.. I tried the Debian. 5.15 config before getting my bucket of words to post online.

Did you read the patch announcement?

- Supported architectures at the moment are:
- ARM64 # build & boot tested
- MIPS # build tested # 32-bit & 64-bit
- Sparc # build tested # 32-bit & 64-bit
- X86 # build & boot tested, my main desktop runs this # 32-bit & 64-bit

Other architectures don't even build, primarily due to the necessity to port the per_task() infrastructure to them. Fixing that & making the tree mergable will be my next focus, assuming there's broad consensus about this approach.

[threader]

Did you read the patch announcement?

Yes, the announcement and PPC missing what partly what prompted me to try it. Anyway i found that 'ptesync' is ppc64 only, and PPC32 should do something like eieieo; tlbsync; tlbie instead. So at least mainline is building now and I can continue trying to to nudge fast headers in about 12 hours

[caligula]

Off topic, but I'm constantly amazed to keep even experienced developers that fail to grasp two simple things (imho):
1. the more featured a language is, the more it takes to compile; you want generics, type inference, even inheritance, named parameters, be prepared to pay a price
2. longer compile times are always justified when they result in faster production code (which is almost all the time); languages like Java or C# may appear fast to compile, but they do not link anything - you'll pay a hefty runtime penalty for that

That's why I mentioned Pascal. Pascal and C are from the same era. Pascal appeared 1970, C in 1972. Pascal was always famous for being fast to compile unlike C that has a horrible syntax. Ever heard of Turbo Pascal? "generics, type inference, even inheritance, named parameters" -- neither of these two languages support any of those.

What this article mentions is mostly a language front-end issue. "longer compile times are always justified when they result in faster production code" -- well this particular speedup doesn't have any significant effect on the resulting binary, AFAIK. I fully acknowledge that optimization, code generation, and linking can be dog slow. I also agree the code should be optimized as much as possible. But it's an unrelated issue.