64-bit ARM Linux Kernel Against CPU-Specific Optimizations: "Pretty Unmaintainable"

[varikonniemi]

Modern CPUs are so incredibly complex that it's implausible you won't occasionally need such tweaks.

As of today basically 2 really need such. This snowflake, and the abomination called atom.

Intel might have an excuse with atom, in that they decided to warpspeed into a market segment that they had no clue about. And the resulting product having no clue about computation is not very surprising.

This arm platform does not have such excuses.

[ssokolow]

Well, the only experience I had with win32 api was displaying simple graphics. I thought it was equally simple in other respects. This does not change the fact that win32 api is terrible, broken by design POS (not my conclusion, but a fact from reliable sources). Just like windows permissions model. After getting used to SDL, I will never have to look at win32 again.

Makes sense. POSIX is much simpler than Win32, but, from what little reading I've done for Win16 hobby programming and what little poking at Xlib I've done, I'd be willing to believe that Win32 is simpler than Xlib... but I'd consider fighting you if you say that Wayland is simpler than either of them.

Wayland is like Vulkan or RISC ISAs... it's intended to be efficient for higher-level abstractions at the cost of being unfriendly to being directly interacted with by humans.

[Volta]

I dispute that it's even easy to use. Have you seen what goes into doing a proper "Before I do this heavy work I need to know what filename to open for writing, I want to bail out early with an error message if the parent directory isn't writable" check? On POSIX platforms, it's a simple use of the faccess(2) libc function. On Windows, it's this huge, complex hunk of code to query Windows's massively overcomplicated permissions model which just gets copied and ported whenever a new language needs a portable access(2) wrapper.

Here's what it looks like when unrolled into Rust code. Compare to the POSIX counterpart just above it in the other conditional compilation block.

Well, the only experience I had with win32 api was displaying simple graphics. I thought it was equally simple in other respects. This does not change the fact that win32 api is terrible, broken by design POS (not my conclusion, but a fact from reliable sources). Just like windows permissions model. After getting used to SDL, I will never have to look at win32 again.

[F.Ultra]

Ok, but what about the users who will lose 40% performance in this scenario? It's not just about the dev pushing his patch here.

Just because these specific patches are currently blocked does not mean that the door is completely closed. Linus Walleij have suggested that a much better place for this is in the memory hierarchy manager (mm) which would make the kernel work better on all hw that have a hw prefetcher.

TL;DR: this is a hack, if you want to accelerate the memory hierarchy,
then work with the MM developers to figure out how to do that in a
structured and scientific way that will work with any prefetching hardware
on any CPU.

Yours,
Linus Walleij

[smitty3268]

But, having worked with both, I noticed a pattern. Closed source maintainers in general give you more free reign and don't care as much about "hacks", if they turn out to be helping the end product in some way. Open source maintainers are much more "purist" when it comes to the code itself, rather than the end product. They care more about that than the end product helping end users.

It's not like there is any kind of mystery around this.

Closed source projects just want to make their product work by a particular deadline, because they need to get their product on store shelves and selling by a certain date. They don't care if it's still working in 5 years, because by then they'll be working on selling the next product.

Open source projects care about making sure the design is as maintainable as possible, because they have limited manpower and wish to have good support for decades into the future. They can't simply throw money at it, like closed source projects can, because they're not leveraging sales money. And it's way tougher to find a volunteer developer to work on a project full of junk code - closed source devs just get paid to work on whatever they're told to.

If you want to see open source projects act more like closed source projects, then the solution is simple. Fund them like closed source projects. Start paying money to use them. Once the money starts flowing, they'll have pressure to deliver or the money will stop. But if people keep using them for free, then be prepared for those projects to attempt to minimize the work on their end as much as possible.

[Weasel]

It doesn't make sense in general. You have to compare to something/someone to stay in touch to reality. Is Ferrari fast or slow? You got the point. They're also obsessed with performance when comes to x86-64, but that's a different topic. Yes, someone sends a small patch to optimize one scenario on single ARM CPU. His job is finished. However, maintainers will have to deal with this for many years and they probably have more important and interesting CPUs to care about. Like Apple M.

Ok, but what about the users who will lose 40% performance in this scenario? It's not just about the dev pushing his patch here.

I don't use such slogans. You don't have to be programmer to have your own opinion on this subject. However, stop saying 'open source clowns', because they're ways above closed source clowns who do much less - have a point of reference.

Yeah, there's a ton of trash closed source software. Far more than open source. But that's not because of the maintainers, it's because the developers themselves are terrible.

But, having worked with both, I noticed a pattern. Closed source maintainers in general give you more free reign and don't care as much about "hacks", if they turn out to be helping the end product in some way. Open source maintainers are much more "purist" when it comes to the code itself, rather than the end product. They care more about that than the end product helping end users.

This is speaking in general, there's obvious exceptions on both sides, but just a trend.

There's obviously also a ton of clowns who can't even reason about control flow properly, but I'm excluding those since that's not worth a discussion.

[wangling]

ARM may have been affected by Android, with excessive fragmentation.
Even the most important manufacturer, Qualcomm, cannot provide a unified kernel for their own CPUs. They maintain dozens of different kernel branches for different CPUs, which is simply absurd.

[ssokolow]

It's easy to use, but it's full of holes due to bad designs made years ago. Such way is unacceptable on Linux.

I dispute that it's even easy to use. Have you seen what goes into doing a proper "Before I do this heavy work I need to know what filename to open for writing, I want to bail out early with an error message if the parent directory isn't writable" check? On POSIX platforms, it's a simple use of the faccess(2) libc function. On Windows, it's this huge, complex hunk of code to query Windows's massively overcomplicated permissions model which just gets copied and ported whenever a new language needs a portable access(2) wrapper.

Here's what it looks like when unrolled into Rust code. Compare to the POSIX counterpart just above it in the other conditional compilation block.

[ppcorp]

As much as I hate ARM, this does suck.

This is why open source maintainers are a joke.

Note the name of the poster, let's just take it from where it comes

[Volta]

No idea. Who cares? I hate ARM anyway.

I was talking in general, not Linux kernel specifically; this is just one example. They are always obsessed with simplicity and "maintainability" and basically lazy to have it in, holding progress back even for contributors who contribute the god damn optimizations and code. How does losing 40% performance feel like to you because of some asshat maintainer who "doesn't find it useful" (as if he's the one using it!!! the nerve!!!)

It doesn't make sense in general. You have to compare to something/someone to stay in touch to reality. Is Ferrari fast or slow? You got the point. They're also obsessed with performance when comes to x86-64, but that's a different topic. Yes, someone sends a small patch to optimize one scenario on single ARM CPU. His job is finished. However, maintainers will have to deal with this for many years and they probably have more important and interesting CPUs to care about. Like Apple M.

So spare me the typical classic bullshit "where's your patch then?" talk, anyone who ever said that proves how little experience he has contributing anything to some open source where those clowns will simply ignore or reject it. Or that they're not even programmers in the first place.

I don't use such slogans. You don't have to be programmer to have your own opinion on this subject. However, stop saying 'open source clowns', because they're ways above closed source clowns who do much less - have a point of reference.

Windows is a fucking joke but that's for completely other reasons. That platform (API) is good though.

It's easy to use, but it's full of holes due to bad designs made years ago. Such way is unacceptable on Linux.

BTW: https://www.phoronix.com/news/Linux-...-UMS-DRM-Infra

Open source maintainers are great, eh?

Forgot about LTS kernels, didn't you?