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

[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.

[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.

[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.

[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!).

[xorbe]

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

[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.

[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?page=news_item&px=Glibc-2.29-Released