GNU C Library 2.17 Announced, Includes Support For 64-bit ARM 68
hypnosec writes "A new version of GNU C Library (glibc) has been released and with this new version comes support for the upcoming 64-bit ARM architecture a.k.a. AArch64. Version 2.17 of glibc not only includes support for ARM, it also comes with better support for cross-compilation and testing; optimized versions of memcpy, memset, and memcmp for System z10 and zEnterprise z196; and optimized version of string functions, on top of some quite a few other performance improvements, states the mailing list release announcement. Glibc v 2.17 can be used with a minimum Linux kernel version 2.6.16."
Re: (Score:1)
GNU is for steers and queers. And I don't see any steers around here.
Good lord, you can't even troll right. "And programmers don't have horns" might have been slightly better. Please try harder next time.
Re: (Score:1)
Re:Christ... (Score:4, Interesting)
really don't understand why a few people here attack anything to do with Linux. Linux is different, not a threat.
It is a threat. A threat to MS developers, a threat to MS shareholders, a threat to those who earn their living cleaning malware off of folks' computers.
For the rest of us, though, it's a blessing.
Re: (Score:3, Interesting)
Linux is no threat to anyone, its just an excuse people like to use.
Programers, even MS ones can move elsewhere. Linux won't 'take over the world' ever if the $7/hour programmers can't write code for it. Most companies are unwilling to spend large sums of money for programmers who have their head up RMSes ass and think they're worth ridiclous sums of money, so its not a threat. Programming isn't all that difficult if you have the proper info. Not everyone can deal with the requirements of C, but then th
Re:Christ... (Score:5, Informative)
you spend your time dicking with things that were solved 20 years ago but everyone thinks they need to reinvent and do differently without ever asking why it should be done differently in the first place. Its no more a blessing then any other mental illness, you just don't recognize it.
Well, wooden wheels were first.. eventually metal with tires... as materials improve, sometimes re-inventing the wheel becomes a good idea...
Re: (Score:2)
There is a difference between improving and re-inventing.
I also didn't say that things never get re-invented, just that Linux fans tend to do it without asking why. Everyone thinks they're the new Linus thats going to invent the new way of doing everything that kicks everyone elses way to the curb. There are plenty of people that do make awesome improvements, but those people are drown out by the shear number of people that change things without asking why things should be changed.
Smartphones are a great
Mod parent up... (Score:1)
Re: (Score:3)
When it comes to code, 99 times out of 90, starting over is a stupid idea. You don't throw out the idea of a toilet in space, you refine the toilet to work in space based on existing tech and new requirements. A space toilet works a lot differently, but its not a re-invention.
Linux audio is a perfect example of needless reinvention. OSX and Windows both seem to have no problem with one sound system even with apps that require very low latency and supporting audio in general yet Linux has how many differe
Re: (Score:2)
If Linux became main stream, it would just get malware as well.
That's true, any OS can be trojaned.
Windows users don't notice malware until they've got 900 different variants installed that do something like change their home page.
Even that doesn't faze them. I don't know how many computers I've seen with Yahoo! as the home page and so many damned toolbars (most of which are redundant) that there's hardly any room on the screen for content. And that's not even considered by most to be "malware" just because
Re: (Score:1)
I'm a GNU/Linux fanboy, but this:
Linux is also more robust. A flaky power supply will have Windows bluescreening, crashing, freezing, and/or rebooting (often with data loss or corruption), while Linux on the same machine will just slow down a little.
Is purest grade-A bullshit.
Broken hardware is broken hardware - neither Linux nor Windows has any means to work around a bad power supply.
Re: (Score:2)
I experienced it firsthand in a dual-boot computer with XP and Mandriva five or so years ago. Win got flakier and flakier while Lin went on seemingly unfazed until Windows wouldn't boot. Two days later nothing would boot.
Re: (Score:1)
Two days later nothing would boot.
So, frankly, by purest accident Linux hid a serious hardware problem from you.
This is nothing to do with Linux being more robust than Windows. It may mean that on your hardware Linux was using less (electrical) power than Windows, or it may have been simple chance.
Re: (Score:1)
you spend your time dicking with things that were solved 20 years ago but everyone thinks they need to reinvent and do differently without ever asking why it should be done differently in the first place
A better description of Windows has never been written.
Why the Linux kernel limitation (Score:1)
I read the mailing list post and they do mention the minimum Linux kernel version needed to work with this C library, but it doesn't say why. I'm curious as to what new features they are using that are not in early 2.6.x kernels. For that matter I'm curious as to whether Hurd works with this C library. The Hurd project isn't mentioned anywhere in the mailing list post.
Re:Why the Linux kernel limitation (Score:4, Informative)
I read the mailing list post and they do mention the minimum Linux kernel version needed to work with this C library, but it doesn't say why. I'm curious as to what new features they are using that are not in early 2.6.x kernels. For that matter I'm curious as to whether Hurd works with this C library.
Because it relies on the kernel API compatible with 2.6.16 and later.
The Hurd project isn't mentioned anywhere in the mailing list post.
It's my understanding that the Hurd project uses a customized version of glibc.
Re: (Score:2)
The Hurd project isn't mentioned anywhere in the mailing list post.
It's my understanding that the Hurd project uses a customized version of glibc.
That should be read as: "If you're compiling on Linux, we're assuming that you have 2.6.16 or later". This is because we assume presence of some features in some of the Linux-specific code. Hurd is not mentioned anywhere because there weren't any noteworthy changes to hurd-specific requirements.
Re:Why the Linux kernel limitation (Score:5, Informative)
Re:Why the Linux kernel limitation (Score:5, Informative)
For those of you trying to figure out what he's talking about, here's a list of *at syscalls.
http://linux.die.net/man/2/openat [die.net]
Notice at the bottom of the page the group of similar file access system calls ending in "at". So for handling files with certain kinds of paths you use openat() instead of open()
I learned something.
Re:Why the Linux kernel limitation (Score:4, Informative)
The mailing list post says it is used '... in GNU systems, and is careful to also say '... most systems running the Linux kernel ...', from which I infer that they're two different things. If GNU systems doesn't mean the Hurd, then what would it mean?
Besides Linux there is at least one variant of BSD [wikipedia.org] to add to the GNU family mix. Note on the same page there is an OpenSolaris flavor too.
Re:optimized better than the builtins? (Score:4, Funny)
Re: (Score:1)
got verb?
Re: (Score:2, Insightful)
He must have accidentally it. The whole thing!
Re: (Score:1)
That will mean one group of programmers is left stuck with the boring maintenance and bug fixing while the other teams are doing the fun bits. In a company this might fly for a short while until people start quiting their jobs. In open source this idea will never work.
This is why most FOSS projects are so short lives. It's easy to have a good idea. Prototyping software is also considerably easier than say, a combustion engine. The hard part is making it proper and maintaining it that way.
Re:optimized better than the builtins? (Score:5, Informative)
It's not so simple for two reasons:
(i) Builtins are used only when gcc wants to inline their code. This may not always be the case. Their usage may (I think) also depend on the nature of the arguments (e.g., are they constant? is their length known? etc.). And there are other weird cases (passing memcpy() function pointer or whatever). Even if you don't explicitly disable builtins, your program may call these functions.
(ii) This specific part of the announcement concerns ifunc-related optimizations. This means that the version appropriate (most optimized) for the processor the program is _currently running on_ is chosen at runtime. In x86 world, at runtime (during the first call to the function), a SSE4-enabled function may be chosen over default function if the processor supports SSE4, for example. And you have just a single binary of your program to handle.
Re: (Score:3)
The non-builtin ones are typically used for large arguments for memcpy. I'm not familiar with the GCC implementation, but LLVM's memcpy() optimisation knows roughly the cost of a call to memcpy() and will use a sequence of inline loads and stores to avoid the call, but will just call memcpy otherwise. The reason for this is better instruction cache usage. A call to memcpy() requires saving any caller-save registers (this can be cheap, as the register allocator will try to put temporaries that are not use
Ulrich Drepper (Score:2)
is not gonna be happy
Re: (Score:2, Funny)
I'm not sure the man has ever been happy. I'm pretty sure he'd grit his teeth through an orgasm, if he ever had one. I wager he would reproduce in a laboratory though.
Re: (Score:2)
I wager he would reproduce in a laboratory though.
Fortunately the tech isn't ready yet. And we can hope, perhaps something bad could happen to Lennart Poettering as well?
eglibc (Score:5, Interesting)
Looks like the eglibc fork was a good thing for the project. Rather than having one maintainer that resists and fights an architecture for personal reasons, the project is now being proactive in integrating a new ARM architecture.
Now if we could only get away from having so many Android-only bionic-targeting blobs.
FLOSS development as it should be (Score:5, Insightful)
From the release announcement:
* Port to ARM AArch64 contributed by Linaro.
From that organization [linaro.org]'s website:
"it wants to provide the best software foundations to everyone, and to reduce non-differentiating and costly low level fragmentation."
"Linaro was established in June 2010 by founding members ARM, Freescale, IBM, Samsung, ST-Ericsson and Texas instruments (TI). Members provide engineering resources and funding. Linaro's goals are to deliver value to its members through enabling their engineering teams to focus on differentiation and product delivery, and to reduce time to market for OEM/ODMs delivering open source based products using ARM technology."
(member list quite a bit longer than above names)
In other words: many commercial enterprises, that are in it for the money and fighting each other in the marketplace, but working together to improve something that's out there in the open, free for all to use. So that what's common to all, is the best it can be, and each vendor can focus its resources on what makes their product different from the rest of the pack.
Sigh - how much better life could be if that principle were applied more often...
Re: (Score:3)
In other words: many commercial enterprises, that are in it for the money and fighting each other in the marketplace, but working together to improve something that's out there in the open, free for all to use. So that what's common to all, is the best it can be, and each vendor can focus its resources on what makes their product different from the rest of the pack. Sigh - how much better life could be if that principle were applied more often...
Before you go bubbling over with the nobility of it all, I'd say its a pretty ruthless business decision based on "near" and "far" competition. All the ARM companies are competing between themselves, but they also know ARM as a whole is competing with Intel and x86 so they're allies in fighting the bigger enemy. The same way RHEL and SLES and Ubuntu LTS and whatnot are competing for server support, but they're also all fighting Microsoft in the grander OS market. It happens very often in business that your
lyrro (Score:1)
I wish I had a 64-bit arm.
Re: (Score:2)
Re: (Score:2)
... You do realize if they just used the intel compiler they wouldn't need their own customized assembly versions of standard (i.e. simple) library functions, right?
I fail to see the impressive part. Impressive would have been fixing GCC to optimize simple functions on its own.
memcmp (and the other functions like it) is something that gets repeated in slight variations in code A LOT, and is trivial to implement. This is almost a textbook optimizer target if I've ever seen one.
Re: (Score:2)
Well, that would impose a dependency on the Intel compiler to get the performance.
That would be nice, but these aren't the GCC developers.
Re:Take THAT (Score:5, Interesting)
In fairness, this is complicated a lot by two issues:
1. Many of the optimizations that help things like memcpy, memcmp, etc. are utterly wrong and backwards in any loop that actually DOES SOMETHING in its body; they only end up being optimal in the degenerate case where everything but the load and store is loop overhead and the optimal result is achieved by eliminating overhead. And on some CPU models such as most modern 32-bit x86's and some 64-bit ones, the optimal result is actually attained with a special instruction that's not usable in general for more complex loops (i.e. "rep movsb"). Factors like these make optimizing these specific functions in the compiler a task that's largely separate from general-case optimization, and when the main target libc is already providing the asm anyway, there's little demand/motivation to get the compiler to do something that won't even be used.
2. Distros want a binary library that can run optimally on all variants of a particular instruction set architecture. Relying on the compiler to optimize functions for which the optimal variant is highly cpu model specific would only give a binary that runs optimally on one model, unless a lot of logic is added to the build system to rebuild the same source file with different optimizations. This is not prohibitively difficult, but it's also not easy, and it's not worthwhile when the compiler can't even deliver the desired optimization quality yet.
Overall I agree that machine-specific asm in glibc (and elsewhere) is a disease that results in machine-specific bugs and maintenance hell, but when there are people demanding the performance and pushing benchmark-centric agendas, it's hard to fight it...
Re: (Score:2)
1. There are plenty of people writing things VERY close to the exact same think that in many cases the compiler could reduce to the same thing if it knew how to recognize it.
2. I fail to see why the compiler can pull in someone else's asm and work perfectly but it can't be made to figure it out on its own. It already has to do exactly that.
I understand why they did it, but in regard to the post I was responding to, this isn't something to go around bragging about when your basically saying "we finally hand
Re: (Score:2)
I fail to see the impressive part. Impressive would have been fixing GCC to optimize simple functions on its own.
memcmp (and the other functions like it) is something that gets repeated in slight variations in code A LOT, and is trivial to implement. This is almost a textbook optimizer target if I've ever seen one.
The optimizations talked about here are specific to processor models (e.g. AVX and SSE for intel) and not just architectures. Compiling them into programs is a bad idea^^, so improving gcc is not an option. The glibc mem* functions have implementations for each of those processor features and the right function to use gets implemented via the STT_GNU_IFUNC [kernel.org] mechanism based on the features the current processor has.
^^ If you don't know why it's a bad idea, it's because you don't want to compile your program
Re: (Score:3)
although with all the chaos around with armN means for various N, who knows.
mmm, AIUI aarch64 has NO asm level compatibility with 32-bit arm architectures so having build systems treat it as a completely unknown architecture (and hence using the generic C implementations) rather than treating it as a variant of arm (and hence trying to use arm assembler routines and failing to build because of it) is probablly a good thing
Re: (Score:2)
Bleh (Score:3, Interesting)
Please ignore this post (Score:5, Insightful)
Re: (Score:3)
strlcpy? (Score:2)
Did they add strlcpy and strlcat?