-
Notifications
You must be signed in to change notification settings - Fork 81
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Picolibc release version #383
Comments
Hi Kevin, thank you for the detailed analysis and great input! Let us see what can we do for the upcoming LLVM 18 based release and get back here. |
Another bit of input - having tried just the "release" version on the benchmark that was showing the worst performance hit (an XML parser), that alone didn't help that much. It turns out that the nano malloc implementation was actually having more of an effect.
|
#441 added option to select between |
Release version of picolibc added; newlib package is now part of the release, I will close this issue. |
We've been running benchmarks to compare performance with other toolchains for Cortex-M55, and the compiler is performing pretty well on the actual compilation - clearly superior to GCC because of its MVE capabilities, if not at the heights of Arm Compiler.
But the overall benchmark results are coming out firmly below the Arm GCC package because of Picolibc, which is optimised for size rather than speed. 45% faster on vectorisable code doesn't compensate for being nearly 4 times slower on parsing operations.
There is a Meson configuration for picolibc, so could you expose an option and provide the speed-optimsed variant in the multilibs?
picolibc/picolibc#258
picolibc/picolibc#259
Another issue we hit was the "tinystdio", which made semihosting support intolerably slow - one character at a time. Overall we'd rather like a "newlib" equivalent config of picolibc rather than the "newlib-nano" equivalent it seems to default to.
Although maybe if newlib is being re-added in an upcoming release, then that can be the full library, and picolibc can remain in its "nano"/"tiny" config. But still, a release rather than minsize option for that "tiny" would be good. The minsize speed penalty is very big.
The text was updated successfully, but these errors were encountered: