Glibc 2.29 Released With getcpu() On Linux, New Optimizations

[phoronix]

Phoronix: Glibc 2.29 Released With getcpu() On Linux, New Optimizations

Ending out January is the version 2.29 release of the GNU C Library (glibc)...

http://www.phoronix.com/scan.php?pag...-2.29-Released

[milkylainen]

Great. Now how about polishing up turd arch implementations of some of the most commonly used functions too?
Like all the mem* and str* functions which move and copy memory?
Still bummed about all the PPC (_not_ Power) performance that gets washed down the toilet.

[xorbe]

Couldn't the result of getcpu() change like the wind, what good is that info unless the thread is pinned? Random number generator?

[brrrrttttt]

Couldn't the result of getcpu() change like the wind, what good is that info unless the thread is pinned? Random number generator?

You answered your own question. It's good if you're pinned (which is somewhat likely if you're in a situation where you care!).

[rene]

sound like an amazing getcpu() feature release ;-) PS: potentially error prone change:
* An archaic GNU extension to scanf, under which '%as', '%aS', and '%a[...]' meant to scan a string and allocate space for it with malloc, is now restricted to programs compiled in C89 or C++98 mode with _GNU_SOURCE defined. This extension conflicts with C99's use of '%a' to scan a hexadecimal floating-point number, which is now available to programs compiled as C99 or C++11 or higher, regardless of _GNU_SOURCE.

[lkundrak]

Now how about polishing up turd arch implementations of some of the most commonly used functions too?

Sorry to say so, but you managed to embarrass yourself by forgetting to attach a patch to your strong words.

[cybertraveler]

The mention of the C-SKY 32 bit CPU got me wondering: why aren't more low-power CPUs intended for use in embedded systems, portable systems or SBCs (like the Raspberry Pi), 32 bit only?

When I think of modern low power devices, they often have under 4GB of memory and it's usually far less than that. The last Raspberry Pi I used had just 1 GB. So using 64 bit CPUs likely yields memory wastage due to the fact pointers and the fastest types will use 64 bits of space instead of 32.

If you have a Physical Address Extension feature in your 32 bit CPU, it even allows it to operate with more than 4 GB of memory (but with a limit of 4 GB per process). This provides some future proofing

The main reasons I can think of for this drift towards low power 64 bit CPUs are:

• Effort has been put into enhancing the 64 bit archiecture but not the 32 bit one. As such, people are just going with the flow to get the faster chips
• memory mapping of files. Presumably a 32bit system can only memory map a file of up to 4 GB in size. a 64 bit CPU can map out much larger files. This is a very convenient programming feature.
• many 64 bit CPUs can run in a 32 bit mode, so devs do have that option. Presumably this is not without cost though; even if that cost is just complexity.
• marketing people

There's some interesting words about how the Nintendo 64, 64 bit CPU was used here:

https://en.wikipedia.org/wiki/Ninten...rocessing_unit

The claim is, it was mostly used in 32 bit mode for the very reasons I would expect.

[arjan_intel]

Couldn't the result of getcpu() change like the wind, what good is that info unless the thread is pinned? Random number generator?

it's statistically not horrible, meaning if you want to use it as an index into, say, an array of "mostly per cpu" structures, you'll get 95% or even 99% or more the "right" answer, and if the cost of being wrong is just a few cache misses/etc (e.g. performance) then that can be a very valid use of this

[Weasel]

The main reasons I can think of for this drift towards low power 64 bit CPUs are:

• Effort has been put into enhancing the 64 bit archiecture but not the 32 bit one. As such, people are just going with the flow to get the faster chips
• memory mapping of files. Presumably a 32bit system can only memory map a file of up to 4 GB in size. a 64 bit CPU can map out much larger files. This is a very convenient programming feature.
• many 64 bit CPUs can run in a 32 bit mode, so devs do have that option. Presumably this is not without cost though; even if that cost is just complexity.
• marketing people

You forgot: "developer" laziness which is probably the biggest one. Other than that, I agree with your post.

I'm guessing we'll see a shift as we can't really squeeze much more out of transistors at this point, so can't waste it on laziness as much (good thing!).

[gilboa]

Couldn't the result of getcpu() change like the wind, what good is that info unless the thread is pinned? Random number generator?

We use it for (non-atomic) statistics counting across multiple processes and threads.

- Gilboa