>musl is actually ~2x slower than glibc

But hey at least muh naïve bloat free implementations, right? Pfff

Attached: screenshot.jpg (1242x712, 297K)

That, and it's easy to produce a small static binary with it.

Glibc's performance comes at code bloat, which really does bloat binaries especially when statically linking. For that matter, glibc can't even be fully statically linked, unlike musl.
Pic related makes strlen fast but adds more assembly to the binary.

Attached: strlen.png (998x2373, 244K)

>Statically linking libc
Are you retarded?

Bloat does not affect you in any way. Miso has not been proven to host fewer vulnerabilities than glibc. It's all in your head. The CPU doesn't care about bloat, it has random access to all parts of the binary.

Oh noes! However will my 1 TB hard drive fit 5 MB more of a binary!

My router has 128MiB of RAM and 16MiB of flash. Thanks to OpenWRT shipping with musl, everything fits.

Oh you're one of m those snowflakes

Memory access is still a big deal and the CPU definitely cares if your binary can fit in its cache or if you bloated it with stuff to the point where it has to use RAM instead which is an order of magnitude slower than its cache.

Like I said, your CPU has random access and can jump over bloat. In fact, this hypothesis is false because evidently glibc is faster than musl, often twice so.

What are you on about, retard?

Can you tell us how to install/use musl-clang properly please?

>bit hacking microoptimization in even the simplest possible functions
GNU freetards are actual lunatics, I love it.

Attached: fun allowed.jpg (425x450, 53K)

You can use a slow CS undergrad implementation of strlen if you want.

No, I'm serious. It's a "get shit done better for the end user" approach instead of suckless LOC circlejerking. I respect that.

2 swedes do the job while one American comments.

As a whole, you're fucking wrong. Yes, your CPU has "random access" but it means nothing here when the location of your data can vary and you can either take 10 cycles or hundreds cycles to access this data "randomly" even if the code execution speed is the same. That being said, glibc for the most part is fast because its increased code size doesn't increase registerr pressure and CPU caches can still handle it. It's when you start doing stuff like Qt binaries which can run in the 10s of megabytes where CPU caches can't fit stuff into cache and the scourge that is Electron exacerbates this issue.

Attached: file.png (1529x1000, 158K)

>microoptimization
It's twice the speedup. Given strlen is O(n), it's not a micro-optimization, it's actually the naive optimization, reading words at a time vs single bytes always is.

You realize it's for embedded use? Plus all those retro retards.

>CPU has random access
How can someone be so stupid? Do you even know what pipelines are?

>many enterprise firmwares use musl
>ha snaowlake xDD
I bet you also use browser spellcheck.

Dunno, I'm a Rust tranny using the x86_64-unknown-linux-musl target. It's as easy as cargo build --target=x86_64-unknown-linux-musl

Attached: trans.jpg (450x579, 84K)

>firmwares
>shitty anemic embedded devices
Yeah okay. Stop shilling musl for desktops/laptops.

What's the deal with glibc's UTF8 decoding?