Daniel Lemire's blog

, 4 min read

For software performance, can you always trust inlining?

6 thoughts on “For software performance, can you always trust inlining?”

  1. Leo Boytsov says:

    In early 2000s when I first got interested in compression algorithms for IR, I had found that a C++ compiler often refused to inline functions, which was detrimental to performance. So, I rewrote all these little functions as macros. Fun-fun. Now C++ compilers are more clever and this kinda of stuff is less useful (plus implementing everything using macros is difficult, you need to use some ugly hacks and things like ##), I guess it may still fail sometimes. And, of course, such failures are probably more common in C# and Java, which were always less geared towards efficiency compared to C++.

  2. Dru Nelson says:

    Interesting that it is generating 32 bit code instead of 64 bit Intel code.

  3. As regular reader, I noticed recently, an erratic special character made your posts temporarily disappear from my handcrafted blog reader. I’ve waited abit for correction. Please fix using validation from https://validator.w3.org/feed/check.cgi?url=https%3A%2F%2Flemire.me%2Fblog%2Ffeed%2F Thank you.

  4. steve heller says:

    The correct answer to “For software performance, can you always trust X” is “No”, for any value of X.

  5. Kunal says:

    We have taken a note of this and opened https://github.com/dotnet/runtime/pull/61408 to fix the issue, but I believe the C# code itself to detect if there is ASCII or not can be simplified using MoveMask. Here is an example of how we do it :

    https://github.com/dotnet/runtime/blob/e64cce6fbbde72d1ea61010bd08f11ba7b51afc9/src/libraries/System.Private.CoreLib/src/System/Text/ASCIIUtility.cs#L290-L297

    1. The proposed function (in the blog post) aims to determine if 16 bytes are made of ASCII digits. I am also not claiming that it is optimal (or even correct).