LWN: Comments on "Amit: How new-lines affect the Linux kernel performance"

Use built-ins?

Hi-Angel — Mon, 22 Oct 2018 07:24:13 +0000

I wonder, can these problems be worked around by using gcc built-ins for assembly instructions instead of straight writing up the assembly? I bet it would be more readable too, besides working well with optimizations.

Amit: How new-lines affect the Linux kernel performance

kpfleming — Fri, 12 Oct 2018 18:00:22 +0000

If the std::string object is itself 'const', not just the literal character array it was constructed from, then indeed there is no need for any work to be done at destruction time (since the only work which could be done would be to free the heap storage which had been allocated, but none will be allocated for a std::string which is const at compile time).

Amit: How new-lines affect the Linux kernel performance

welinder — Thu, 11 Oct 2018 14:45:44 +0000

> The problem is it's often not possible for the compiler to tell if it needs destruction or not.

In general I'd agree, but here I actually think that it would be undefined behaviour to change the string.

However, if I am wrong on that, the right thing to do would be to inline the test for the normal case (that does nothing) and handle the exceptional case non-inlined. That's 5 instructions instead of 50, so saving of ~200 bytes of code per string.

The compiler's analysis problem gets so much simpler if being right 100% of the time is not a requirement.

Amit: How new-lines affect the Linux kernel performance

roc — Thu, 11 Oct 2018 04:17:07 +0000

They're not really comparable. "ping" is something that some sites actually asked for, and therefore presumably want to use.

Amit: How new-lines affect the Linux kernel performance

plugwash — Thu, 11 Oct 2018 00:46:38 +0000

> that doesn't need destruction

The problem is it's often not possible for the compiler to tell if it needs destruction or not. As soon as you pass a pointer or reference to the string to a function the compiler has to consider the possibility that said function could replace the contents of the string with longer contents that do require destruction.

Amit: How new-lines affect the Linux kernel performance

flussence — Wed, 10 Oct 2018 19:36:19 +0000

ping is broken for the same reason DNT is: one browser forced a bad default without informed user consent (in DNT's case, MSIE), rendering it useless for opting out of the status quo, which was the whole point of these to begin with.

The worst offender in recent months is Chrome, which keeps adding “interventions” that forcibly break standard HTML and web APIs in the name of battery life or some other vague clickbait that makes for cute blog headlines. The result is that correctly written pages are broken, corporate junk adds another quarter-megabyte of bloat per page, exploiting loopholes in the browser, and users get shafted.

Amit: How new-lines affect the Linux kernel performance

Sesse — Wed, 10 Oct 2018 09:12:35 +0000

So, your fix for automatically inlining too little is to never automatically inline at all? That hardly sounds like it fixes the issue.

Amit: How new-lines affect the Linux kernel performance

Felix.Braun — Wed, 10 Oct 2018 08:37:21 +0000

Thank you for the link to the mailing list thread. Actually, it seems that they have already worked out a solution, that works for both the GCC maintainers as well as the kernel guys.

Amit: How new-lines affect the Linux kernel performance

joib — Wed, 10 Oct 2018 05:47:29 +0000

TBH, ping seems as hopelessly naive and doomed to fail as DNT.

It's all-out war between privacy and advertisers; measures which are easily circumvented are pointless.

Amit: How new-lines affect the Linux kernel performance

roc — Wed, 10 Oct 2018 02:08:02 +0000

Yeah, that was a good example of how pressure for vocal but ignorant "privacy advocates" made things worse for everyone.

Amit: How new-lines affect the Linux kernel performance

roc — Wed, 10 Oct 2018 02:07:06 +0000

Not really because the 'ping' attribute is supposed to send the ping in parallel with the page navigation, to minimize delay. But navigating away from the page will cancel any HTTP requests triggered by scripts in that page.

Amit: How new-lines affect the Linux kernel performance

epa — Tue, 09 Oct 2018 18:59:26 +0000

I wonder whether 'ping' could be implemented by a Javascript library, so the HTML source could remain readable. (And users who have Javascript turned off would use the page as normal without pinging the mothership.)

Amit: How new-lines affect the Linux kernel performance

ballombe — Tue, 09 Oct 2018 18:26:14 +0000

> The fix would be not to inline at all, unless the 'inline' compiler directive is used.

Compilers have been inlining static functions since much before the inline keyword was introduced.
It is quite common for an 'ordinary' C function to use macros that use inline asm.
Almost nobody write true asm function anymore because they cannot be inlined.

your proposal is not realistic.

Amit: How new-lines affect the Linux kernel performance

jwilk — Tue, 09 Oct 2018 17:42:20 +0000

Run this in the web console to fix the links:

for (let a of document.querySelectorAll('a[href*="/url?"')) { a.href = decodeURIComponent(a.href.match(/[?]q=([^&]+)/)[1]); }

Amit: How new-lines affect the Linux kernel performance

iabervon — Tue, 09 Oct 2018 17:38:10 +0000

It seems like it wouldn't be hard to have a minimal assembly parser. It would only need to be able to list the instructions (as opposed to labels, directives, blank lines, comments, etc) in assembly languages that GCC can generate code for. That still wouldn't determine how much machine code the assembly corresponds to, particularly after link-time optimization, but it would probably give as good estimates for inline assembly as the estimates for C.

Amit: How new-lines affect the Linux kernel performance

anadav — Tue, 09 Oct 2018 17:24:50 +0000

Google sites has been a terrible choice, which I made a long time ago - sorry for that. I copied the blog-posts to https://blog.amit.zone/ for your convenience.

Amit: How new-lines affect the Linux kernel performance

anadav — Tue, 09 Oct 2018 17:20:47 +0000

The overhead is indeed not that great. But as new features that use inline assembly are added for performance (see the "patchable constants" RFC, for example), it might become a bigger issue.

Amit: How new-lines affect the Linux kernel performance

ibukanov — Tue, 09 Oct 2018 14:04:53 +0000

They can use a better heuristic. For example, one can assign weights to the parsed tree nodes based on averages derived from a large code base and then count the totals weight for the function. It is not ideal but is way better then counting lines or statements.

Amit: How new-lines affect the Linux kernel performance

welinder — Tue, 09 Oct 2018 12:49:26 +0000

> How can it reasonably be fixed?

It can be fixed by allowing code to override cost for such a statement.

However, the whole cost-based inlining heuristic thing is a bit of a hack and it is not working very well in general.

For example -- something I have been looking into lately -- when using C-style strings in places where C++ wants an std::string. (That's C++ and not C, but the front end should not really matter for the purposes of discussing inlining.) Constructing a std::string from a constant string of 15 characters or fewer should be a simple matter of poking the right values into the std::string structure, no dynamic memory allocation involved. That is not, however, what gcc does. The decision on whether to inline depends not only on the string [reasonable] but also on other strings used in the same file [weird]. I suspect the phase of the moon plays a role too.

And for good measure, the destruction of that std::string (that doesn't need destruction) is fully inlined. That adds ~50 instructions per string and does nothing.

Amit: How new-lines affect the Linux kernel performance

mlopezibanez — Tue, 09 Oct 2018 12:40:50 +0000

The discussion continues here: https://gcc.gnu.org/ml/gcc/2018-10/msg00034.html

I don't think it will get "fixed" in the GCC side. These communications between Kernel and GCC follow a classical pattern, and it usually ends with the kernel applying a work-around because there is no easy fix, contrary to what is initially claimed, and the kernel devs are (understandably) not interested in "fixing" GCC.

Amit: How new-lines affect the Linux kernel performance

oever — Tue, 09 Oct 2018 11:52:58 +0000

In this case the link can be trivially rewritten by calling the JavaScript function decodeURIComponent() on the URI query value q.

decodeURIComponent("https%3A%2F%2Flkml.org%2Flkml%2F2018%2F10%2F4%2F25")

"https://lkml.org/lkml/2018/10/4/25"

Amit: How new-lines affect the Linux kernel performance

excors — Tue, 09 Oct 2018 11:35:09 +0000

The article points out that explicit inline markers like __attribute__((always_inline)) don't work very well when you have some wrapper function that calls the inlined function, because the wrapper function won't get inlined unless you remember to explicitly mark it too. And if it's wrapping an arch-dependent function, maybe it should be inlined on some archs and not on others, and maybe that decision should change when the code is refactored years later - it's very hard for the programmer to keep track of that and mark everything correctly. For any problem larger than a single function, the compiler is likely able to make better decisions than a human because it knows precisely what code is being compiled and how it interacts with all the other code.

Amit: How new-lines affect the Linux kernel performance

excors — Tue, 09 Oct 2018 11:16:24 +0000

Yes, and some users complained vociferously about Firefox violating their privacy by supporting ping (even if it had an opt-out for privacy-conscious users), so Firefox disabled it by default, making it highly ineffective, so now all sites continue to implement their own link tracking systems that obscure the URLs and are less efficient and can't be disabled by privacy-conscious users.

Amit: How new-lines affect the Linux kernel performance

mageta — Tue, 09 Oct 2018 11:12:19 +0000

That's a bit melodramatic. Its not "destroying" the performance of Linux, as the original author says in the patch-notes:

> I ran some limited number of benchmarks, and in general the performance
> impact is not very notable. You can still see >10 cycles shaved off some
> syscalls that manipulate page-tables (e.g., mprotect()), in which
> paravirt caused many functions not to be inlined. In addition this
> patch-set can prevent issues such as [1], and improves code readability
> and maintainability.

Amit: How new-lines affect the Linux kernel performance

epa — Tue, 09 Oct 2018 10:57:17 +0000

Didn't browsers like Firefox add a 'ping' attribute on links just so that you could get this traceback without ugly URI mangling and extra round trips? (And 'ping' is something the user can choose to turn off, of course.)

Amit: How new-lines affect the Linux kernel performance

epa — Tue, 09 Oct 2018 10:55:25 +0000

The fix would be not to inline at all, unless the 'inline' compiler directive is used. That would make the behaviour predictable and I'm sure that most projects (like Linux) would prefer that explicit approach over the supposed convenience of having the compiler guess what assembly to inline. When you write inline assembly you are already choosing to get obsessive about details, so having to specify the inline behaviour isn't much of an extra burden. Ordinary C functions, where the compiler has much more of a clue about how big they are, could still be inlined heuristically.

Amit: How new-lines affect the Linux kernel performance

excors — Tue, 09 Oct 2018 10:01:15 +0000

How can it reasonably be fixed? My non-expert understanding is that GCC essentially translates a .c file into a .s file, then passes it to the binutils assembler; and inline assembly is just an opaque string that gets pasted into that .s file. GCC simply doesn't have an assembly parser, and even if it did then it couldn't parse an inline assembly statement in isolation because of macros defined in other inline assembly statements. I don't see how it can get a reliable estimate of the number of instructions, except with some multi-pass process like PGO.

Amit: How new-lines affect the Linux kernel performance

joib — Tue, 09 Oct 2018 09:39:49 +0000

That blog says on the bottom "Made with the new Google Sites, an effortless way to create beautiful sites.". So probably the URL's get rewritten so that the mothership can hoover up some information when someone clicks on a link.

Amit: How new-lines affect the Linux kernel performance

halla — Tue, 09 Oct 2018 08:23:15 +0000

What a curious way of linking does that article use "https://www.google.com/url?q=https%3A%2F%2Flkml.org%2Flkm..." instead of "https://lkml.org/lkml/2018/10/4/25"

Amit: How new-lines affect the Linux kernel performance

ledow — Tue, 09 Oct 2018 07:54:31 +0000

Yeah... "guessing" how large code is by how many line returns in it seems the dumbest hack I've heard of in a long time.

The sort of thing you slap into the code "to solve the problem" with the intention of actually putting in proper code at some point, but surely not anything that a group of professional programmers should be leaving lying around in anything more than a prototype.

If you need to make a decision based on the compiled size of code... then you need to compile that code and find out.

In this case it's only a test for "is this big enough to inline" but that's enough to destroy performance of an entire OS if you get it right.

But how much code in gcc is using this to size things like buffers, and introduce potential overflows and security problems if it gets the metric wrong?

It's very shoddy.

Amit: How new-lines affect the Linux kernel performance

flussence — Tue, 09 Oct 2018 02:55:32 +0000

This looks like a bit of a egg-on-face moment for GCC… the same thing happened with one (or more?) of the mainstream web browsers, which wouldn't JIT compile some JS code unless the source was minified, ignoring the size of the IR. At least now it'll get fixed.