25% slowdown can be dramatic for some applications.
What you keep forgetting is that's 25% of the part that you're actually using.
You keep avoiding and denying that for a program where any sort of speed matters you just aren't spending any of your time hitting the C standard library.
If a program is slow because of the C standard library and it needs to be faster, someone messed up a long time ago. That isn't the C libraries fault. You can squeeze a little more out of it if you have find a more optimized library, but it's all a drop in the ocean compared to how much faster it would go by doing basic real optimizations.
Performance-sensitive programs and libraries are often written in C. C-string representation is widely used by all programming languages, which are usually written in C or C++ (which uses C).
You can say that, but really it's almost all C++ and people avoid C strings for exactly why I outlined in detail. You don't have length up front, it's all ascii, you're dealing with pointers to arbitrary runs of bytes, etc.
This is not good for memory access patterns, dealing with lots of characters at one time, dealing with unicode, minimizing memory allocations etc.
It's true that I'm making claims and you're not accepting them.
That is true that you are making lots of claims and that I'm not accepting them, because you don't have any evidence or explanations and they don't make sense.
All I've said is that MUSL doesn't prevent someone from making fast programs and you barely have even confronted that, let alone explained how it isn't true.
Linking MUSL to any program that heavily uses the slow functions will make it slower.
Any program that is hammering the the C standard library can be sped up by orders of magnitude and 25% is nothing. Again, lifting memory allocations will speed something up by 10x, so that 25% isn't going to matter anymore because it's 25% of something that isn't even going to show up on a profiler, let alone be a bottleneck.
Your position seems to be that the title is wrong because it is theoretically possible to make MUSL-dependent programs fast according to some unstated performance metric
I think you mean it's trivially possible according to the detailed explanation I gave from a lot of experience optimizing.
Sometimes the objective of caring about performance is to have literally the fastest thing possible, not just "fast enough".
25% better might be fast enough for you, I like speeding up programs by 100x by changing to C++ instead of C and focusing on the optimizations that matter.
The title says "Don't use MUSL if you care about performance."
I use musl and I care a lot about performance. It doesn't matter because has no bearing on how fast my programs are.
I'm done with this bullshit conversation.
I'm sure it seems that way when someone doesn't accept the same claim over and over without any actual explanation or evidence. Saying the same thing and getting more upset is not an effective way to make your point. You need real information, not insults and fake quotes.
I awoke today with renewed energy to deal with your nonsense, and I think after reading this comment it deserves a (hopefully) short reply.
I use musl and I care a lot about performance. It doesn't matter because has no bearing on how fast my programs are.
This is the crux of the matter. You clearly have some investment in MUSL, that much has been apparent all along. If you actually USE it, which I'm sure you do, then you are not using the fastest possible library. Regardless of your skill, simply switching to a faster library will make a program faster. Sometimes, that's what is needed. We JUST want to find easy ways to make code as fast as possible. We aren't looking to rewrite the world.
I don't have any investment in MUSL. I wish the project well, but if it's not the fastest library then it will necessarily be unsuitable for some applications.
What you keep forgetting is that's 25% of the part that you're actually using.
First off, I didn't forget shit. There are surely programs for which the penalty is actually 25% or close to it. The penalty can actually be far worse than that due to algorithmic complexity issues. Secondly, it is quite possible that one could use the standard library almost exclusively. Thirdly, any performance drop could be significant.
You can say that, but really it's almost all C++ and people avoid C strings for exactly why I outlined in detail. You don't have length up front, it's all ascii, you're dealing with pointers to arbitrary runs of bytes, etc.
C strings are used extensively in C++. Again you prove how inexperienced you are.
This is not good for memory access patterns, dealing with lots of characters at one time, dealing with unicode, minimizing memory allocations etc.
Keep deflecting with bullshit that is irrelevant to the choice of library, and that can't be changed but for massive refactoring.
That is true that you are making lots of claims and that I'm not accepting them, because you don't have any evidence or explanations and they don't make sense.
There's only so much evidence and explanation I can provide to strangers on the internet. Then there is also the level of evidence that I can provide, such as other blog posts, that I don't feel like providing. A lot of the things I've said are true a priori (assuming some simplifications), such as the fact that a slower library will always be worse for performance than a faster library. If MUSL is measurably slower than others, then it can be a problem.
Any program that is hammering the the C standard library can be sped up by orders of magnitude and 25% is nothing. Again, lifting memory allocations will speed something up by 10x, so that 25% isn't going to matter anymore because it's 25% of something that isn't even going to show up on a profiler, let alone be a bottleneck.
As I've said many times, rewriting software is not always on the table. Even minor changes may be forbidden or burdensome for various reasons. What you're talking about is a redesign, that may not be applicable to all cases anyway.
>Your position seems to be that the title is wrong because it is theoretically possible to make MUSL-dependent programs fast according to some unstated performance metric
I think you mean it's trivially possible according to the detailed explanation I gave from a lot of experience optimizing.
Right, your position is definitely that making these changes is "trivial"... I threw in "theoretically" because I interjected my own knowledge that these optimizations are often only theoretically possible, and can't be done for many practical reasons. My wrong statement of your position made it more defensible than it actually is.
25% better might be fast enough for you, I like speeding up programs by 100x by changing to C++ instead of C and focusing on the optimizations that matter.
I don't want to get off on another tangent but you are trivializing and exaggerating a lot of stuff in this one statement. Changing languages and altering the code is not an easy win, and might actually trigger a performance setback. Switching to a faster library is a relatively easy win.
Saying the same thing and getting more upset is not an effective way to make your point. You need real information, not insults and fake quotes.
I've made my point already, you just haven't accepted it. I assume you are either incapable of understanding (perhaps temporarily), or have unstated biases as I pointed out due to being a MUSL enthusiast or contributor. You're not convincing me either way. My position is that people who care about being as fast as possible should use the fastest available library, which clearly isn't MUSL. There may be other valid reasons to use MUSL, and it may be "fast enough", but other libraries are yet faster.
This is how I see your argument so far:
- MUSL is fast enough, trust me bro.
- Ok, maybe someone measured some functions to be slower, but everyone knows that you shouldn't be using the STANDARD LIBRARY heavily. Nobody has ever used strings or memory allocation that heavily, and if they did then they are doing it wrong (even if other libraries provide adequate performance for them).
- If you have a problem with this, you just need to do some trivial optimizations, or change languages to C++. It's SUPER EASY (at least for elite MFers like myself).
- Because rewriting the code to compensate for MUSL performance is always on the table, it's never reasonable to say that MUSL is causing a performance problem.
I only added a slight amount of emphasis. You've been pretty close to that bombastic in the whole exchange. It's ridiculous, and I think you are smart enough to know better but admitting that you are wrong is beyond the pale. Instead of wasting my time, how about applying those elite optimization skills you claim to have to the MUSL code to make it faster. Then you will be able to write a blog like "Don't use glibc if you care about performance" and argue with people on HN if you want. By the way, I didn't write this blog post, and I don't have any other conflicts of interest such as being a glibc developer, so don't start up with that shit either.
C strings are used extensively in C++. Again you prove how inexperienced you are.
You can try to be patronizing if you want, but this doesn't make sense with you not understanding memory access patterns. If someone uses C++ they will use C++ strings. Have you used C++? It works well and it has been around for 40 years, you should give it a try.
Keep deflecting with bullshit that is irrelevant to the choice of library, and that can't be changed but for massive refactoring.
You painting yourself into a corner has nothing to do with a C library being a few percentage points slower. This is not a general scenario, it's something you are dealing with because you can't optimize C strings.
If you think memory access patterns are 'bullshit' you haven't done much optimization. That's everything in modern optimization.
If there is an expert somewhere around you, please talk to them so you can get up to speed on modern optimization. Minimizing allocations is table stakes, memory access is the meat.
If you have any examples on github of things you think "can't" be optimized, go ahead and link it and tell me what a profiler shows, and I will explain what to do.
I've made my point already, you just haven't accepted it.
You made your claim, you haven't had any evidence or explanation, that's how it works. You say the same thing over and over and get more upset, but that isn't evidence. Show me where musl prevents someone from writing a fast program.
Insults and hallucinated quotes aren't a good foundation for proving your point. If you have to pretend that someone said something different, then maybe you aren't really making sense.
how about applying those elite optimization skills you claim to have to the MUSL code to make it faster.
Why would I do that when I don't use the C library for performance sensitive programs? You never seem to be able to confront this. The stuff made 50 years ago isn't the fastest possible stuff. It's still pretty fast and if you want something faster, do something else. It's not that complicated but it seems to really upset you.
I don't have any other conflicts of interest such as being a glibc developer, so don't start up with that shit either.
No one said anything about that, I think you're hallucinating or predicting something that never happened.
Stop spamming me with burning straw men bro. I am slightly irritated with you because I think you're trolling me or at least wasting my time by being an idiot. I have asked some rhetorical questions in my response below. Do not feel obligated to pipe up with more nonsense in response.
Have you used C++
I mainly work in C++, and have for the past 20 years. That also entails using a fair amount of C from time to time. Even if I didn't write C or C++, the performance of the standard library would affect me, as I use much software written in these languages as well.
Why would I do that when I don't use the C library for performance sensitive programs?
If you don't use C at all then you aren't using MUSL and won't need it to be fast. If you do use MUSL then you aren't using the fastest library, so you must not care that much about performance.
No one said anything about that, I think you're hallucinating or predicting something that never happened.
I expected that you might say "what about YOU" when I pointed out your obvious conflict of interest here. That would have been a baseless attack but more logically coherent than what you've been spamming me with.
The stuff made 50 years ago isn't the fastest possible stuff. It's still pretty fast and if you want something faster, do something else. It's not that complicated but it seems to really upset you.
Finally, just because a project or language is old doesn't mean it currently has bad performance. The article suggests that if you care about performance, don't use MUSL. That is "using something else" and exactly what I've been saying this whole time. Why are you so stubborn that you can't even admit that there could very well exist a scenario where the suggestion to switch to another standard library makes sense? Nevermind that these scenarios are common, and the article is presenting one. You have suggested everything from massive refactoring to switching languages, anything but switching to a more suitable library.
I'm not sure where the entitlement and expectation comes from that you can reply to me and that I won't reply back. This seems like a transparent hail mary to continue to avoid confronting what I already explained in detail.
You can try to call my single replies "spam", but I think if you could actually respond to the things I've said you would have done it already.
If you do use MUSL then you aren't using the fastest library,
You are contradicting yourself with logic that doesn't add up.
The default libc isn't the fastest way to do things anyway. So by your own logic the title should be "don't use libc if you care about performance". This of course doesn't make sense either because if you aren't using libc then musl wouldn't matter. This is why the title doesn't make sense and why your defense of it doesn't make sense either.
You having software that is not only slow but slow because it calls into the default libc has nothing to do with this. Why aren't you mentioning taking it further and linking in a better allocator?
Maybe because it's the same idea but contradicts what you keep trying to say to avoid the actual point, which is that the title is wrong.
If you're going on a long trip and you get better shoes and can walk to your car 25% faster, how much is that going to speed up your trip overall? It will be basically nothing, because you are optimizing something almost irrelevant.
I can use musl and create software that outperforms whatever someone else makes using the default standard library. If this is possible, and I explained why it is in detail, then why would the title be true? Explain that instead of getting upset and avoiding the heart of the discussion with irrelevant tangents about your own legacy programs.
Comments
25% slowdown can be dramatic for some applications.
What you keep forgetting is that's 25% of the part that you're actually using.
You keep avoiding and denying that for a program where any sort of speed matters you just aren't spending any of your time hitting the C standard library.
If a program is slow because of the C standard library and it needs to be faster, someone messed up a long time ago. That isn't the C libraries fault. You can squeeze a little more out of it if you have find a more optimized library, but it's all a drop in the ocean compared to how much faster it would go by doing basic real optimizations.
Performance-sensitive programs and libraries are often written in C. C-string representation is widely used by all programming languages, which are usually written in C or C++ (which uses C).
You can say that, but really it's almost all C++ and people avoid C strings for exactly why I outlined in detail. You don't have length up front, it's all ascii, you're dealing with pointers to arbitrary runs of bytes, etc.
This is not good for memory access patterns, dealing with lots of characters at one time, dealing with unicode, minimizing memory allocations etc.
It's true that I'm making claims and you're not accepting them.
That is true that you are making lots of claims and that I'm not accepting them, because you don't have any evidence or explanations and they don't make sense.
All I've said is that MUSL doesn't prevent someone from making fast programs and you barely have even confronted that, let alone explained how it isn't true.
Linking MUSL to any program that heavily uses the slow functions will make it slower.
Any program that is hammering the the C standard library can be sped up by orders of magnitude and 25% is nothing. Again, lifting memory allocations will speed something up by 10x, so that 25% isn't going to matter anymore because it's 25% of something that isn't even going to show up on a profiler, let alone be a bottleneck.
Your position seems to be that the title is wrong because it is theoretically possible to make MUSL-dependent programs fast according to some unstated performance metric
I think you mean it's trivially possible according to the detailed explanation I gave from a lot of experience optimizing.
Sometimes the objective of caring about performance is to have literally the fastest thing possible, not just "fast enough".
25% better might be fast enough for you, I like speeding up programs by 100x by changing to C++ instead of C and focusing on the optimizations that matter.
The title says "Don't use MUSL if you care about performance."
I use musl and I care a lot about performance. It doesn't matter because has no bearing on how fast my programs are.
I'm done with this bullshit conversation.
I'm sure it seems that way when someone doesn't accept the same claim over and over without any actual explanation or evidence. Saying the same thing and getting more upset is not an effective way to make your point. You need real information, not insults and fake quotes.
I awoke today with renewed energy to deal with your nonsense, and I think after reading this comment it deserves a (hopefully) short reply.
This is the crux of the matter. You clearly have some investment in MUSL, that much has been apparent all along. If you actually USE it, which I'm sure you do, then you are not using the fastest possible library. Regardless of your skill, simply switching to a faster library will make a program faster. Sometimes, that's what is needed. We JUST want to find easy ways to make code as fast as possible. We aren't looking to rewrite the world.
I don't have any investment in MUSL. I wish the project well, but if it's not the fastest library then it will necessarily be unsuitable for some applications.
First off, I didn't forget shit. There are surely programs for which the penalty is actually 25% or close to it. The penalty can actually be far worse than that due to algorithmic complexity issues. Secondly, it is quite possible that one could use the standard library almost exclusively. Thirdly, any performance drop could be significant.
C strings are used extensively in C++. Again you prove how inexperienced you are.
Keep deflecting with bullshit that is irrelevant to the choice of library, and that can't be changed but for massive refactoring.
There's only so much evidence and explanation I can provide to strangers on the internet. Then there is also the level of evidence that I can provide, such as other blog posts, that I don't feel like providing. A lot of the things I've said are true a priori (assuming some simplifications), such as the fact that a slower library will always be worse for performance than a faster library. If MUSL is measurably slower than others, then it can be a problem.
As I've said many times, rewriting software is not always on the table. Even minor changes may be forbidden or burdensome for various reasons. What you're talking about is a redesign, that may not be applicable to all cases anyway.
Right, your position is definitely that making these changes is "trivial"... I threw in "theoretically" because I interjected my own knowledge that these optimizations are often only theoretically possible, and can't be done for many practical reasons. My wrong statement of your position made it more defensible than it actually is.
I don't want to get off on another tangent but you are trivializing and exaggerating a lot of stuff in this one statement. Changing languages and altering the code is not an easy win, and might actually trigger a performance setback. Switching to a faster library is a relatively easy win.
I've made my point already, you just haven't accepted it. I assume you are either incapable of understanding (perhaps temporarily), or have unstated biases as I pointed out due to being a MUSL enthusiast or contributor. You're not convincing me either way. My position is that people who care about being as fast as possible should use the fastest available library, which clearly isn't MUSL. There may be other valid reasons to use MUSL, and it may be "fast enough", but other libraries are yet faster.
This is how I see your argument so far:
- MUSL is fast enough, trust me bro.
- Ok, maybe someone measured some functions to be slower, but everyone knows that you shouldn't be using the STANDARD LIBRARY heavily. Nobody has ever used strings or memory allocation that heavily, and if they did then they are doing it wrong (even if other libraries provide adequate performance for them).
- If you have a problem with this, you just need to do some trivial optimizations, or change languages to C++. It's SUPER EASY (at least for elite MFers like myself).
- Because rewriting the code to compensate for MUSL performance is always on the table, it's never reasonable to say that MUSL is causing a performance problem.
I only added a slight amount of emphasis. You've been pretty close to that bombastic in the whole exchange. It's ridiculous, and I think you are smart enough to know better but admitting that you are wrong is beyond the pale. Instead of wasting my time, how about applying those elite optimization skills you claim to have to the MUSL code to make it faster. Then you will be able to write a blog like "Don't use glibc if you care about performance" and argue with people on HN if you want. By the way, I didn't write this blog post, and I don't have any other conflicts of interest such as being a glibc developer, so don't start up with that shit either.
C strings are used extensively in C++. Again you prove how inexperienced you are.
You can try to be patronizing if you want, but this doesn't make sense with you not understanding memory access patterns. If someone uses C++ they will use C++ strings. Have you used C++? It works well and it has been around for 40 years, you should give it a try.
Keep deflecting with bullshit that is irrelevant to the choice of library, and that can't be changed but for massive refactoring.
You painting yourself into a corner has nothing to do with a C library being a few percentage points slower. This is not a general scenario, it's something you are dealing with because you can't optimize C strings.
If you think memory access patterns are 'bullshit' you haven't done much optimization. That's everything in modern optimization.
If there is an expert somewhere around you, please talk to them so you can get up to speed on modern optimization. Minimizing allocations is table stakes, memory access is the meat.
If you have any examples on github of things you think "can't" be optimized, go ahead and link it and tell me what a profiler shows, and I will explain what to do.
I've made my point already, you just haven't accepted it.
You made your claim, you haven't had any evidence or explanation, that's how it works. You say the same thing over and over and get more upset, but that isn't evidence. Show me where musl prevents someone from writing a fast program.
Insults and hallucinated quotes aren't a good foundation for proving your point. If you have to pretend that someone said something different, then maybe you aren't really making sense.
how about applying those elite optimization skills you claim to have to the MUSL code to make it faster.
Why would I do that when I don't use the C library for performance sensitive programs? You never seem to be able to confront this. The stuff made 50 years ago isn't the fastest possible stuff. It's still pretty fast and if you want something faster, do something else. It's not that complicated but it seems to really upset you.
I don't have any other conflicts of interest such as being a glibc developer, so don't start up with that shit either.
No one said anything about that, I think you're hallucinating or predicting something that never happened.
Stop spamming me with burning straw men bro. I am slightly irritated with you because I think you're trolling me or at least wasting my time by being an idiot. I have asked some rhetorical questions in my response below. Do not feel obligated to pipe up with more nonsense in response.
I mainly work in C++, and have for the past 20 years. That also entails using a fair amount of C from time to time. Even if I didn't write C or C++, the performance of the standard library would affect me, as I use much software written in these languages as well.
If you don't use C at all then you aren't using MUSL and won't need it to be fast. If you do use MUSL then you aren't using the fastest library, so you must not care that much about performance.
I expected that you might say "what about YOU" when I pointed out your obvious conflict of interest here. That would have been a baseless attack but more logically coherent than what you've been spamming me with.
Finally, just because a project or language is old doesn't mean it currently has bad performance. The article suggests that if you care about performance, don't use MUSL. That is "using something else" and exactly what I've been saying this whole time. Why are you so stubborn that you can't even admit that there could very well exist a scenario where the suggestion to switch to another standard library makes sense? Nevermind that these scenarios are common, and the article is presenting one. You have suggested everything from massive refactoring to switching languages, anything but switching to a more suitable library.
I'm not sure where the entitlement and expectation comes from that you can reply to me and that I won't reply back. This seems like a transparent hail mary to continue to avoid confronting what I already explained in detail.
You can try to call my single replies "spam", but I think if you could actually respond to the things I've said you would have done it already.
If you do use MUSL then you aren't using the fastest library,
You are contradicting yourself with logic that doesn't add up.
The default libc isn't the fastest way to do things anyway. So by your own logic the title should be "don't use libc if you care about performance". This of course doesn't make sense either because if you aren't using libc then musl wouldn't matter. This is why the title doesn't make sense and why your defense of it doesn't make sense either.
You having software that is not only slow but slow because it calls into the default libc has nothing to do with this. Why aren't you mentioning taking it further and linking in a better allocator?
Maybe because it's the same idea but contradicts what you keep trying to say to avoid the actual point, which is that the title is wrong.
If you're going on a long trip and you get better shoes and can walk to your car 25% faster, how much is that going to speed up your trip overall? It will be basically nothing, because you are optimizing something almost irrelevant.
I can use musl and create software that outperforms whatever someone else makes using the default standard library. If this is possible, and I explained why it is in detail, then why would the title be true? Explain that instead of getting upset and avoiding the heart of the discussion with irrelevant tangents about your own legacy programs.