News for hackers. Stuff that matters.
Re:C Strings and my slow descent to madness by stephc_int13 on Thursday April 06, 2023 @07:40PM (#35476064)
On the contrary, I expected the Nintendo DS SDK to be well optimized, performance of memcpy can be critical on such a constrained hardware. And it was optimized, just not with the best tricks.

I got the prefetching trick from Intel source code, except that I replaced the PLD instruction by a simple dummy load.

And about strlen, you'd be surprised, some implems are very good, and some are not, depends on the compiler and the library. I've ran benchmarks, I was surprised too.

To be honest, I don't really need super fast strlen, but I was curious and also learning to write fast SIMD code, basic string handling is a nice exercise.

Re:C Strings and my slow descent to madness by asveikau on Thursday April 06, 2023 @08:24PM (#35476447)
I think this expectation doesn't vibe with my understanding of how people used to think about embedded or consoles. You shipped them and they were done. The games industry was also often trying to ship quickly. Small teams too. Latest tweaks to memcpy or fine tuning or revisiting the finer points of an already adequate SDK is low priority.

By contrast, many more people are updating optimizations to GCC or clang for arm, more frequently and over a longer timeframe.

Re:C Strings and my slow descent to madness by stephc_int13 on Thursday April 06, 2023 @09:15PM (#35476839)
You're probably right about consoles, and I was surprised to be wrong, but I checked, just to be sure.

GCC and Clang are very nice compilers, but they are a different thing than the std lib. glibc, musl, the Windows C Runtime, iOS, Android, all have different implementations, sometimes outdated.

Re:C Strings and my slow descent to madness by asveikau on Friday April 07, 2023 @01:19AM (#35478306)
Gcc and clang are relevant here because memcpy is a builtin. It will not call libc for this.

Same is true of MSVC.

It's been that way on most modern compilers for about 20 years.

That's why I'm saying rolling your own may be futile. Compilers, not just libc, have paid a lot of attention to getting those things fast.

Re:C Strings and my slow descent to madness by stephc_int13 on Friday April 07, 2023 @08:20AM (#35480817)
What is true for memcpy (especially on small buffers) is not systematically true for string functions.

But testing is always there to the rescue, and these days we have Godbolt.

Re:C Strings and my slow descent to madness by counttheforks on Thursday April 06, 2023 @09:38PM (#35476998)
Any data to back up that FUD?
Re:C Strings and my slow descent to madness by stephc_int13 on Thursday April 06, 2023 @10:44PM (#35477389)
Of course I have data, do you think I am pulling benchmarks out of a hat?

But I have not published those benchmarks, if this is what you're asking, the Nintendo thing I am afraid I cannot reproduce easily as I no longer have this devkit on hand.

About the strlen benchmark, this is something I've done a few years ago, that could be easy to run again, but I am not sure this is worth the effort just to convince a random dude on the internet...

Re:C Strings and my slow descent to madness by counttheforks on Friday April 07, 2023 @08:30AM (#35480907)
> do you think I am pulling benchmarks out of a hat?

Yes. Share the data or you're spreading FUD.

Re:C Strings and my slow descent to madness by qubidt on Saturday April 08, 2023 @08:47PM (#35499108)
You're being silly. Nothing they said was FUD, it was just a (not particularly controversial) anecdote