Slashdot Mirror
GLIBC 2.16 Brings X32 Support, ISO C11 Compliance, Better Performance
An anonymous reader writes "The GNU C Library version 2.16 was released with many new features over the weekend. The announcement cites support for the Linux x32 ABI, ISO C11 compliance, performance improvements for math functions and some architectures, and more than 230 bug fixes."
If you can point me to a spreadsheet program that opens both ODS and XSLX files, is feature complete with respect to the OOXML formula specification, doesn't cost more than 100 € and runs on GNU/Linux, I will consider it :-p. Of course, it should work *better* than LibreOffice.
I ain't saying LibreOffice shines on this. I should really take the time to profile it and file a bug against it. But it works most of the time for me and gets the job done better than many other alternatives. The fact that it uses *a lot* of memory for really complex models (we are talking about a million computed cells or so, anyways), should be fixable in the long run.
42.
64 bit architectures give you 64-bit registers and a 64-bit address space (since pointers are, traditionally, integers that fit in registers[1]). On x86, there are a number of other advantages to using the 64-bit long mode: guaranteed SSE so you don't need slow x87 code, more registers, PC-relative addressing (useful for position-independent code) and so on. The cost of using these is that now every pointer is bigger. This has knock-on effects in terms of data cache usage.
The X32 ABI allows you to have all of the benefits of the 64-bit mode except for the larger address space. If you're using under 4GB of memory, then it can, in theory give an improvement in memory and cache usage.
There are two down sides. The first is that, in my testing of C, C++ and Objective-C code, I've found that it's very rare on a 64-bit platform for pointers to account for even 10% of the total memory usage, and usually it's a lot less. This is made worse by the fact that the X64 and X32 ABIs are incompatible, so you may need two copies of the same library in memory if you have code using both.
I was quite enthusiastic about the idea of something like X32 five or so years ago when it was very rare for programs to want more than 4GB of address space, but now it's far less clear that there's a real advantage.
[1] Not with the architecture I'm currently working with, and I'm spending a lot of time fixing compiler assumptions that this is always the case.
I am TheRaven on Soylent News
If someone could explain to me why x86 architecture is suddenly named x32 , i would be happy too. The name has been working fine for 40 years, despite its difficult teen years where it only represented 16bit.
Good question. I looked at the linked article and it took me a while to figure out.
x64 CPUs aren't just x86 CPUs with larger memory addresses. They also have more registers, and are guaranteed to support certain additional instructions that aren't necessarily available in an x86 CPU (e.g. SSE). "x32" mode exploits the additional registers & instructions, without actually using 64-bit memory addressing. I think the idea is that it's supposed to allow for most of the benefits of the x64 instruction set without incurring the caching penalties of larger pointers. Honestly I'm not sure how useful that really is.
It's not. X32 is the name of a programming model, not an architecture. And the X32 programming model cannot be used on the x86 architecture, X32 is a programming model for the AMD64 architecture.
The most important aspect of a programming model for C is that it defines the sizes of basic types like char, short, int, long, and pointers. Many other aspects follow more or less directly from the sizes of those types. X32 is unusual in that it is 64 bit code, but pointers are only 32 bits. When a pointer is in a CPU register the lower 32 bits is the actual value, and the upper 32 bits are always zero.
Do you care about the security of your wireless mouse?
X32 is for running 32-bit apps in a 64-bit native execution environment.
On Windows this practice is called "thunking" or "Windows-on-Windows", where it takes the form of a partially emulated legacy kernel which then backhands its requests to the real kernel.
On Linux, since we usually compile things for the platform as-needed, it's more about efficiency than compatibility. If you don't need 64-bit processing, sometimes it's faster to stick with 32-bit code. If you can live with the 4gb address space, your pointers are half the size, resulting in a smaller memory footprint, which then reduces cache pressure, potentially yielding significant speed improvements for some workloads. Due to the use of 32-bit pointers in this scenario, a 32-bit compatibility layer is required to interface with system libraries. You can't just stick a 32-bit libc and expect it to work, because of its intimate relationship with the kernel.
-Billco, Fnarg.com
I think there are more advantages. Think embedded device, which is a market X86 is trying to move into.
Note that, on multiple processors, the legacy x86 and the x64 implementations are (almost completely) separated, using different processor resources. Between the larger/better resources, and the higher number of register, the x64 pipeline gets a better performance in the same processor. The lower memory usage also helps to improve performance, but its impact is minor.
So, one of the things that has changed in this latest release is that only the ELF binary format is supported. What does this actually mean though? I guess it means they dropped a.out and COFF, but does anyone still use those?
Is this particularly a problem, perhaps for embedded *nix? (I.e. is ELF bigger or worse in resource terms compared to the other two formats?)
As far as I can tell from reading Wikipedia, ELF is much the better format generally, but is it worse in some situations?
Actually, did GLIBC support MS Windows PE format before now (a modified form of COFF)? Or what about the Mac Mach-O format?
GCC can build different file formats, is that also going to change?
Microsoft has its own compiler and Apple has moved away from it, maintaining support when they are doing much better themselves is probably not a high priority.
Neither Windows nor Mac OS X uses glibc, so it is not a problem. gcc uses the appropriate libc for the platform.
The negatives:
* On a mixed x86-64 and X32 system, you have to load two copies of shared libraries (this doesn't happen with exclusively X32 systems).
It's not that the extra copies is the problem.
The problem is that you effectively have to have two different /usr/lib directories. With potentially two different sets of the libraries. Same consequently goes for the /usr/include. Compiling and running software occasionally becomes nightmarish experience.
After enjoying it thoroughly on the commercial *nix variants (Solaris and HP-UX), I have hopes that Linux will not do it and keep it clean: either fully 64bit system or fully 32bit system.
All hope abandon ye who enter here.
On an embedded system, you'll be saving 5-10% memory usage by only supporting X32 and not X64. It may be worth it...
I am TheRaven on Soylent News
Actually, did GLIBC support MS Windows PE format before now
On Linux systems, the PE format is handled by Wine if I remember correctly.
You've always been able to run 32-bit applications with a 64-bit kernel. x32 is not required for this.
In my opinion, it is designed pimarily so that Intel's embedded processors run Android well in the short term. Atom architecture in particular benefits in that some pointer offset calculations are faster when done in 32-bit vs 64-bit. Here are some great discussion links: http://blog.flameeyes.eu/2012/06/debunking-x32-myths http://lwn.net/Articles/503412/
Actually no it's not... Linux has that already and it works just fine, anyone who has gone through the pain of getting flash player to work before the x64 port can tell you. This is actually more similar (albeit with more restrictions) to setting the /LARGEADDRESSAWARE:NO option on the linker in Visual C++. An option you'll notice that comes with a significant warning about interoperability. Microsoft solved this problem by making pointer handling the developer's job, this meant that they could continue to use x86-64 libraries without an issue but all malloc operations would return addresses that are safe to sign extend.
The benefit on windows is that you:
Any and all content posted above may be ignored, considered irrelevant, or otherwise dismissed.
So, one of the things that has changed in this latest release is that only the ELF binary format is supported. What does this actually mean though?
That you can no longer run Linux executables based on the a.out format. The a.out format was phased out in 1996.
but does anyone still use those?
No, nobody does.
Is this particularly a problem, perhaps for embedded *nix? (I.e. is ELF bigger or worse in resource terms compared to the other two formats?)
No, because people stopped using the a.out format to store Linux executables long before Linux started appearing on embedded devices. On a side note, many MCUs use ELF as their preferred executable format, so I don't think there's a "size" problem with it.
As far as I can tell from reading Wikipedia, ELF is much the better format generally, but is it worse in some situations?
No, that's why nobody has used it since 1997. Even if it was competitive with ELF, and it isn't, maintaining two different binary formats to contain the executables of the same OS would be overkill - especially almost 20 years after the first format has been deprecated.
Actually, did GLIBC support MS Windows PE format before now (a modified form of COFF)? Or what about the Mac Mach-O format?
GCC can build different file formats, is that also going to change?
Glibc is only for running Linux or Hurd (I think) executables. These OSes only use ELF. Glibc never ran on Windows or Mac. GCC is a completely separate project, and of course it supports generating executables for Windows, hence it will target PE/COFF of course on those OSes. There is no relationship with Glibc.
Actually, you need three copies, one for i386, one for X64 and one for X32. You should only need copies of libraries though, not of headers (which use #ifdef for multiple platforms).
I am TheRaven on Soylent News
Actually, you need three copies, one for i386, one for X64 and one for X32. You should only need copies of libraries though, not of headers (which use #ifdef for multiple platforms).
I should have spelled it out better: many pieces of software already now make a presumption what /usr/lib is: some insist that those must be 32bit libraries, some insist on the 64bit ones. LD_LIBRARY_PATH works most of the time - until you hit an application which to do its work launches other applications.
As for the headers... I have seen enough breakages to stop believing that #ifdefs are the solution: different software and different systems refer to the same thing with under names. Good luck finding a working combination. E.g. some functions are available in 32bit variant but not in 64bit variant, and vice versa. (That was recent fsck up of compiling VIM on the AIX 7: compile as 32bit, _XOPEN_SOURCE=600 - and it would fail linking because some 32bit libs are missing; try to compile as 64bit - only to find that _XOPEN_SOURCE wouldn't work and piles and piles of function declarations are missing. I had to hack the includes/defines into the config.h for the VIM to compile and link. (autoconf hasn't spotted it because it apparently couldn't imagine the functions missing.))
Linux now is more or less clean of the madness.
All hope abandon ye who enter here.
Moreover, support for a.out is still there in the kernel. Assuming that you can find some a.out binaries today, and have a reason to run one of them on a contemporary system, you can still do it by having an old libc around. Different versions of libc can coexist on the same system.
I hope Firefox doesn't try this trick. Although it doesn't need to use > 4GB, it does need support for leaking more than that. I have an 8GB swap partition, mostly to stop firefox crashing more than once a week!
The goal is to merge eglibc back into glibc, yes. After the previous glibc steering committee disbanded, it switched to being run by an informal three-person committee, one of whom (Joseph Myers) is also one of the lead maintainers of eglibc, so the two projects' leadership are no longer at odds. And Myers has suggested that the goal is to start moving eglibc changes over into the main glibc branch.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
On an embedded system, you'll be saving 5-10% memory usage by only supporting X32 and not X64. It may be worth it...
Yeah, this was my thought as well. x86 just doesn't seem to happen much in the embedded space, but I guess somewhere there is an embedded x86 vendor running millions of units (perhaps the contributor).
I doubt it's the +10% memory size that's keeping vendors away from x86, though.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
I was quite enthusiastic about the idea of something like X32 five or so years ago when it was very rare for programs to want more than 4GB of address space, but now it's far less clear that there's a real advantage.
That same thought struck me as well. At that time, when we were seemingly 'nowhere near 4GB', a x32 ABI would have made sense. But now, by the time it's ready, it's use by date seems to be near, if not already gone.
Look at the spec. You only have to read the first sentence. The chapter on X32 starts
Do you care about the security of your wireless mouse?
Who the fuck would sign-extend a pointer?
The amd64 ABI requires this. Currently, only 48 bits are used, which makes it tempting to use the rest for some flags, etc. Back in the days, this was a problem on Amiga (forgot which models): old programs suddenly stopped working when newer CPUs stopped ignoring higher bits of the address. Thus, to make sure no one will have bad ideas like this, amd64 CPUs actually check if the unused bits are sign-extended, and smite offenders with an exception.
And why are addresses signed? So there's a clear distinction between the address space of the user-mode program and the operating system.
The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.