Arm Developer Provides More Glibc Optimizations - Memem & Strstr

[phoronix]

Phoronix: Arm Developer Provides More Glibc Optimizations - Memem & Strstr

Arm's Wilco Dijkstra landed some more optimizations this past week in the Glibc development code for the upcoming GNU C Library 2.30 release...

http://www.phoronix.com/scan.php?page=news_item&px=Glibc-Arm-Optimizations-Mem-Str

[DebianLinuxero]

http://codytaylor.org/2009/05/debian-switching-from-glibc-to-eglibc.html

Do you remember that times?

[tuxd3v]

http://codytaylor.org/2009/05/debian...to-eglibc.html

Do you remember that times?

I do,
Lets wait now for Glibc 2.30

[xpue]

Memem

Memmem, maybe?

[tildearrow]

Memem.

[Guest]

Memem.

Meme 'em

[mb_q]

I wonder why such things are in libc anyway... They don't talk with OS, there is zero chance for one-fits-all implementation, and anyhow quite likely either parser or some index is a way better idea in a performance-critical code.

[phoron]

I wonder why such things are in libc anyway... They don't talk with OS, there is zero chance for one-fits-all implementation, and anyhow quite likely either parser or some index is a way better idea in a performance-critical code.

Well, I'm no expert, but I find it quite logical that a string search algorithm, being a well known and studied thing, which may be needed in many programs, should not be reimplemented in every program. Then you might want it to be implemented in a different library, not libc, but after all it's libc because it is the library you need to build C programs. It's not called liblinux or libPOSIXInterfaces or whatever.
Even if the purpose was merely to interface with the kernel then it might yet need some string search somewhere or some of these basic algorithms. And yes a kernel interface library might depend on an algorithms library, and be separated, and maybe that would be a little cleaner, but in the end all programs would end up including both libraries because all programs would need some kernel interface. So it is not so bad having it all in libc. Besides, a string search algorithm might need to allocate memory, and a kernel interface library might need to search strings so if they were separated they would maybe have mutual dependencies.
I mean it's not like a full blown algorithms and datastructures library, just some basics.
But yes, libm is separated so we could have some libcstr or whatever, but I don't see it so terrible.

[thesandbender]

I wonder why such things are in libc anyway... They don't talk with OS, there is zero chance for one-fits-all implementation, and anyhow quite likely either parser or some index is a way better idea in a performance-critical code.

strstr is part of the C standard (since the original ANSI standard) and it's functionality that a large majority of even basic programs are going to need, more specifically it's functionality that operating systems, supporting core utilities and the C compiler itself needs. memmem isn't part of the standard but it's a logical extension of strstr.

And no, no implementation is going to run the best on all processors... but that's not the purpose of a standard library.