wakawaka28

I think you must consider geology and the economic health of each area together.

Is everyone here so afraid of downvotes or out of touch that they don't remember "10% for the big guy" Biden? I know the US doesn't exactly get "Foreign Aid" but our politicians sure do, and it's a broad spectrum problem.

I'm confused. How does this disagree with me? You can do the same process with the same model, and that is what I was talking about doing.

You can have the same LLM check itself, especially if you start over with slightly different prompts or context. They sometimes get things right and sometimes don't. Although, if you genuinely have no way to know whether the answer is right or wrong, or the errors are severe, then these checks will not accomplish much. This checking can be better than nothing.

"Becoming"? Lol it's been a reality for a long time. It's just ramping up now.

>>When their business is crucial to society and can't function without the workers at the given price

>Yes, absolutely, if by "given price" you mean "the price Americans should reasonably be paid". But this particular combination of two things is probably nonexistent.

That isn't really what I meant. It is conceivable that there could be a critical business for which there are simply not enough workers to meet demand at the price customers can afford. I think there is an underlying assumption that if the money is there, the workers will be too. Generally, that is how things work in the long run, but in the case of skilled vocations there can be a long lag before qualified people step in.

What I'm describing here is just acknowledging the demand curve for labor and its implications. It's very basic economics. If the input costs for a product go up too high, it will necessarily reduce the consumption regardless of how badly wanted the product happens to be. I don't think it is tenable in the long term to have have a majority of people in society clamoring for something that is too expensive because of labor, especially to the benefit of a cartel of workers who these people also regard as overpaid. I think the immigration of medical doctors is one of these in the extreme. Most people think doctors are paid well, and do not care if doctors don't like immigration because they perceive the prices to be too high. There may be many reasons that healthcare is expensive, but a tight supply of qualified labor is obviously one of these.

>> [Who's to say that] a business should fail because of a politically imposed scarcity of labor?

>Again, probably not what would actually happen. If businesses are forced to hire Americans, they would not "fail". Rather, investors/leadership may choose to go do some other more-profitable business, but not because the business can't survive.

I think you are forgetting that businesses can and do lose money all the time. Most businesses fail, in fact. The point of investing is to make a profit. If that cannot be attained after a reasonable ramp up period, then investors will eat their losses and go away. That is the definition of a business not surviving. If you can't show that your expenses (including labor) will eventually result in a profit, then you don't have a viable business idea and no investor would sink money into it.

The classic case of this happening is all the factories that closed due to competition in China and elsewhere. Those factories indeed had to hire Americans for their physical proximity, if nothing else, and at that price point they could not sustain themselves. Even having higher quality did not save most of them. Consumers didn't care enough about quality or patriotism to sustain those factories.

>We are talking about the lack of socially normal humans in US leadership, not economic constraints. I.e. the kind of person you have to compel to be a non-negative force in society via legislation.

It is totally an economic problem: oversupply of labor driven by market dynamics. The solution that helps American workers is to slow down immigration by a lot. It has knock-on effects though, such as higher prices and potentially lower quality for a lot of things. It would also shift people around within the domestic economy.

>Yes, there have always been unscrupulous Scrooges among those running things, but often their goals happen to benefit society as a whole enough that we don't have to step in this dramatically.

Profit-seeking behavior lowers prices for everyone in the long run. If I were to summarize the problem I would say: Extreme exchange ratios and rapid/easy movement of resources internationally are causing threats to certain sectors of the workforce, including national security threats and impoverishment of skilled workers in wealthy nations (especially the US).

I'm surprised you can't find something to agree with in the first paragraph. I feel compelled to restate and clarify points I glossed over, to see which one you disagree with:

1. Foreign researchers can communicate with colleagues fairly well over the internet (in real time, even). Physical presence is not required to do academic research, at least in mathematics or CS.

2. Degree mills, fake credentials, paper mills, etc. exist to get names on stuff for a fee. This is used to game the immigration system.

3. Many US degree programs are used as a vector for immigration more than education, and people who immigrate this way usually try to meet the minimum requirements to stay in the US and do little beyond that.

4. Even when it comes to research, most research just isn't that good and doesn't contribute that much to society.

5. Getting jobs in academia is difficult.

6. Immigration lowers wages due to the basic laws of economics.

7. Given the fact that we have mediocre researchers in abundance, such that they can't find work in academia, there is negligible societal benefit to importing mediocre foreign researchers en masse. Additionally, this is devastating to the local labor market.

8. All other things equal (to the extent it is reasonable to determine), a country should try to ensure that native citizens get priority in hiring, rather than importing replacements.

If you disagree with #8, perhaps you should consider who is going to be willing to spill their blood and give up their treasure to defend a country that undermines them at every turn.

You're right, they used to care or at least said the right things. Then I guess they realized that they could get more voters by simply importing them lol...

>What I've seen is a local workforce (typically, then a mix of 1st gen Americans) being asked to train their replacements. Some replacements on Visas and some remote. But what gall to ask you to train your [cheaper] replacements.

This destroys their entire argument about the necessity of the imports, even if it is relatively rare. (Note that I don't think it's rare to be replaced by foreigners. I think it's rare to be forced or incentivized to train them, especially with knowledge that you will actually be replaced.)

Recently I heard something crazy like 9 of 10 new jobs since the pandemic is held by foreign-born people, even as many US-born are unemployed. 20% of US-born men is unemployed. This is not a primary source but it should get you started if you're interested: https://www.numbersusa.org/blog/nine-out-of-ten-new-jobs-hav...

We are mostly in agreement. I'm pretty sure we need to sympathize with employers in situations like this, at times, though. It doesn't help anyone to reduce every shortage to a supposed moral fault in the employers lol. At what point do we become sympathetic to them? When their business is crucial to society and can't function without the workers at the given price? Or is it when the market rate for a job is offensive to other kinds of workers at jobs of similar difficulty? I think the societal need is a plausible reason, but it leads to this slippery slope we started off complaining about. It boils down to: who's to say how expensive is too expensive, or that a business should fail because of a politically imposed scarcity of labor?

I'm not making any political statement here, or at least that was not my intention. Life is short and there are infinite things we could be learning about. The advanced math I'm talking about avoiding here is not recreational math, but you could potentially apply the same logic to recreational math. Personally I see a big difference between "routine" abstract/advanced math and recreational math, though there can be some overlap. People have written books about what makes a pleasant puzzle, for example. Some puzzles are deceptively simple to state and impossible to solve without elite level theories. I think one of the characteristics of a good puzzle is that it can be solved with reasonable effort and not consume your whole life. Another is that it not be so contrived and abstract, that you need to be heavily initiated to even understand it. The worst are the ones that require a ton of mechanical computations even after you figure out the key insight. I don't think those are very fun either. But then again, there are people who don't get tired of Sudoku lol...

>They can't prove themselves abroad. Consider the example of "Attention is all you need" paper. That paper came into existence thanks to talented people from around the world coming together in one place and then collaborating. It would not have happened if the contributors stayed in their own countries.

I think this is a stretch, especially now that we have the internet. I also wouldn't be opposed to non-immigrant research visas, perhaps a specialized type of H1-B visa (since most of these people are not independently wealthy). But what I don't want is any random foreigner who has their name on some academic papers to be considered top talent. There are paper mills that crank these people out (putting their names on papers without any involvement), and besides that most research is just not that good. Why would we want a bunch of mediocre foreign researchers to come and take jobs away from mediocre American researchers? As we know, getting jobs in academia is very difficult as-is.

You got me on China trying to stop talent from leaving. It's an authoritarian country though. You can't even travel around freely inside the country lol! I threw China in there because a lot of H1-Bs and students are actually Chinese, but China is not where most of them come from.

You also got me on China allegedly trying to get talent to move to China. Their people seem to have had a predictable reaction. That's really something, considering that they can get in trouble for criticizing their government. I guess they thought it was worth the risk, because doing nothing would screw them even harder.

It's funny how the loyalties of imported "talent" are not front and center in any discussion of how their presence is "strategically important." I think we are getting strategically shafted by lax immigration laws.

That isn't what it means to have a shortage. In many cases Americans are discouraged from applying for these jobs. They can overspecify the criteria or be overly skeptical about your resume, write the job listing poorly, or hide the job listing entirely. What a shortage really means from their perspective is that they can't find enough workers for the price they want to pay (as opposed to what they can afford). However, I don't find that satisfying. I might have a legitimate business idea that would work only if I could find 100 great engineers willing to work for far below average. That would be considered insane in isolation, but if several large companies get together and issue the same complaint like "We can't move ahead because there are not enough engineers in our price range" then they call it a shortage. But I don't think American workers should have to tolerate these people flooding the market just because they can make money by doing so lol...

I think everyone (or virtually everyone) is OK with actual world-leading researchers coming to the US. But what we don't want is the labor market flooded with foreign "talent". The system is designed to try to get the researchers and noteworthy people, but corrupt people have found ways around all of it. There are paper mills, degree mills, cheating rings, etc. Plus firms that exist solely to funnel foreigners into the US for a fee.

There is always an economic argument to be made for importing the cheapest or allegedly "best" labor, but it's mostly about saving money even if it means destroying domestic workers. It sounds better when we're talking about a scientist instead of a construction worker or meat packer, but it's kind of the same problem. There are many cases of American workers being forced to train H1-B replacements, or being blatantly discriminated against for being, shall we say, obviously American.

If foreign researchers are able to prove themselves abroad and contribute as you say, I assume they can continue doing that in most cases without coming to the US to take jobs. If immigrants are such a great resource, why are poor countries not trying harder to keep those people from leaving? Why doesn't China import a bunch of Indians for IT work, or vice versa?

It wouldn't be 95%. The US is like 5% of the world, but it disproportionately contains the most qualified workers in many fields. Also, in many cases, even if a worker was somehow qualified, they would be lacking some basic skill like English proficiency or basic cultural compatibility, that would make them actually unqualified on net. But your overall sentiment is right. There are hundreds of millions of people who want to come to the US and make less than you.

It is also a fact that "most qualified" is fuzzy. It comes down to something more like, performance per dollar, or "culture fit", or some other thing. Unless you are trying to absolutely have the most advanced shit in the world at any price, "qualifications" or "talent" are not the ultimate factors. Having been in this industry for a while, most foreign workers obviously aren't "the best" like that. They're not even more talented or hard-working than the average American worker. But they usually work for less and the job gets done (roughly speaking), and their mere presence drives down everyone's wages.

OK now you're getting into some more useful topics. Linear algebra is a great one with tons of applications. But if you want my advice, prioritize useful stuff and spend less time on theoretical baubles or bedrock-level boilerplate. This is unless, of course, you enjoy puzzles and hard work with little application.

I often ignore mathematics that is not completely useful to me these days lol. I get the appeal of learning neat theories and feeling like you got it all figured out, but I'd rather limit my studies to topics that are likely to bear fruit in my life. Complication and abstraction does not necessarily deter me, but it has been my observation that overly complicated or abstract ideas rarely pay off in my endeavors.

Those "stupid computations" comprise the bulk of useful work in the world. If one learns enough to do that, there may be no reason to go further. You're proving my point about the pretentiousness of insisting on the theory when one doesn't need it.

Nothing in your comment makes me want to go learn more theory, and I would argue that it's nonsense to anyone who is not a mathematician.

Imagine arguing that the only way to understand or appreciate basic set logic is to know all about infinite sets and ZF axioms... Most people, even mathematicians, will not understand all of that and have only heard about it in the most basics if at all.

A similar phenomenon happens with philosophy. Imagine arguing that simple logic is "stupid" and that one can only reason well if they have a total understanding of epistemology. I happen to think epistemology matters, and that people can benefit from at least being aware of it, but it is really a separate topic from actual mechanical logic and argumentation.

Well, it's a fit for visual processing only in simple cases. If your graph looks like spaghetti, you need other ways to think about it. If the `git log --oneline --graph` view (or whatever options trigger it) is not good enough, then a full-blown GUI won't do it for me either.

It's still specialized, but looking it up has gotten easier. It's better to use the right tool for the job. What's next, are you gonna tell ChatGPT to list your files too?

This seems like great stuff. Some libraries already do this, so why not standardize the behavior (to the extent it can be done)?

It's mighty pretentious to say that one needs all that theory to simply answer the question lol. For many questions, only the most rudimentary theory is plenty to get an answer, that is exactly the same answer as a more elaborate theory would yield.

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 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.

>There are a few problems here. The first saying that anything is dramatically worse. The second is thinking that nothing can be changed. The third is thinking that there are lots of programs out there that spend all their time in C string functions yet nothing can be altered except for linking in a different standard library.

25% slowdown can be dramatic for some applications. Secondly, I didn't say that nothing can be changed. I said that change is expensive. Thirdly, I think linking another library is probably acceptable to get an easy 25% speedup! This problem was probably discovered by somebody saying "Why is this shit so slow when I link with MUSL?"

Regarding "Nothing can be altered except for linking" -- There are many such cases. This especially happens with upstream code. If you use a library that you aren't willing or able to fork, you have to deal with its limitations. This can happen for open-source projects, or for private commercial projects.

>You hallucinated a quote and made up something completely different in your head.

I summarized your whole position in an ironic quote to show you how dumb it is. I'm sorry you don't see how you come off. Calling my rhetoric "hallucination" is laughable. I could swear I'm arguing with a bot.

>I'm saying it isn't a problem because the problems are easily fixable and musl doesn't prevent them from being fixed.

Your fix suggestion amounts to calling for a huge refactoring, as I said. MUSL does not prevent you from doing that, but it's easier to just not link MUSL if it's causing problems for you.

>You think these programs are bottlenecked by the C-string functions in their standard library? That's a bold claim. Why would a program completely dependent on strings even use C string functions in the first place? You have to scan to a newline to find the length, they work with ascii and they are known to be incredibly insecure. What you're saying doesn't make sense.

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).

>I deny that there are programs that can only be sped up by switching to a different C library and nothing else, since that's nonsense.

This statement is the real nonsense. Again with the "I've never seen it, so it can't exist" bullshit.

>People can do whatever they want, all I've ever said is that musl doesn't prevent anyone from making a fast program. That's it.

No, that's not all you've said. You said the title is wrong. You said (roughly speaking) that the choice of standard library is never a decision point for performance. The title of this article may be a bit exaggerated, but there's a clear example of poor MUSL performance in the article. It's also not JUST slow string functions, it's slow memory allocation too. What's next, you gonna say you've never seen a program that needs lots of memory allocation? Or that I should go fork some upstream project to work around MUSL's limitations?

>You can go for the insults and try to be patronizing again, I expect that as the last resort of someone frustrated that repeating their claim isn't taken as evidence. I explained a lot in detail about why musl isn't going to prevent anyone from writing fast software because I've done it over and over.

You can keep saying it over and over and it won't be any more true. It's true that I'm making claims and you're not accepting them. What you should ask yourself is what I have to gain by making these claims. The answer is nothing. I'm beginning to think you're a troll. Your username certainly suggests it.

>You seem to be saying that you can speed up legacy programs somewhat that weren't made well in the first place with a faster libc and I'm sure that's true, but it has nothing at all to do with the premise the musl prevents a program from being fast or even is much of a bump in the road.

I am CLEARLY saying that. Linking MUSL to any program that heavily uses the slow functions will make it slower. Since MUSL is not the default for most software, this will be observed as totally unnecessary and inexcusable performance degradation. If you're trying to build the fastest version of some software, you should use the fastest libraries.

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, so the title is necessarily wrong. What you don't see is that no matter what performance metric you choose, if I wrote the program to be fast with MUSL, it would be EVEN FASTER with a faster library. It might be "fast enough" for somebody with MUSL alone. But if that somebody cares about performance (like the title says) then they will use the fastest library they can. They won't refactor all their code to make MUSL work faster. Sometimes the objective of caring about performance is to have literally the fastest thing possible, not just "fast enough".

>You don't have any evidence or explanation that musl prevents someone from writing fast software, which is the title and the title is wrong.

The title doesn't say that MUSL will stop you from writing fast software. I never said that either. The title says "Don't use MUSL if you care about performance." But keep burning that straw man bro. I'm done with this bullshit conversation.

>To be clear, you're saying that in video games and robotics people are using strings instead of numbers and when that becomes a performance problem you think simple C string functions are to blame? How about not using strings as values?

To bring this back to the article, the problem is actually that one library does this worse than others. If you are unfortunate enough to already rely on these functions performing up to a certain standard, then having them become dramatically worse is in fact an issue.

Why don't you just not use slow functions? Well, that goes back to my references to refactoring. Even if you could get approval to refactor the stuff, it's still risky and a lot of work. Compare that to just not using an oddball standard library with worse performance...

>Well, it isn't. It's unlikely that musl prevents anyone from making a fast program. It doesn't even make sense. In the off chance anything was a real bottleneck you could bring in something faster and you would want to do that anyway.

THAT IS THE POINT OF THE ARTICLE TITLE: If you require performance in certain key areas, MUSL may not be acceptable.

>I have done a lot of optimization and I've never seen the standard library be a problem for exactly what I just outlined.

The article here is literally complaining about a standard library's performance, which is not uncommon in the blog-o-sphere. So, you are ignoring evidence right in your face. People like me are telling you it sometimes matters, and people blog about such problems frequently, but you still aren't getting it.

I can only tell you vaguely about codebases I've worked on. I can't tell you where, or show you code, or anything like that. Get used to it.

>A lot of what you're saying is just "it's a problem because it is, trust me". That isn't evidence or an explanation.

Everything you've said is "It's NOT a problem because I'VE never seen it be a problem!" When the evidence is right in front of your face and people are telling you, yes, it is a problem. Do you think I'm getting paid to share this wisdom with you?

If you don't think string processing is a bottleneck, you should consider how many applications are document-based and string-based. Basically, it's a MAJORITY of applications in the world, and I'd put money on that.

>As soon as allocation is slow you can avoid allocations (which you should do anyway) or use a different one (which you would do even with a standard libc anyway).

More "just refactor bro" or "just use a different library" (the point of the article). Only one of these is likely to be practical in any given situation, especially since MUSL is not the default for most stacks.

>The benefit from a regular libc over musl is minuscule compared to the real solutions to optimizing.

Bro, if the stats in the article are right (and I have no reason to doubt) the difference is significant (at least numerically). It's easy to tell other people to go do a ton of work to optimize. The radically easier solution is to just not use MUSL if that's your problem. Again, the entire point of the article.

>Trying for insults doesn't add any sort of technical explanation.

Saying you're inexperienced is not insulting, especially since you're a stranger. You clearly deny having experience with the stuff I'm talking about, which I think is common-knowledge in optimization circles, and then insist on labor-intensive solutions to easily solved problems. Some insulting thoughts have crossed my mind here but I know we've all been inexperienced at some point, so I'm trying to keep it civil to teach you something.

>To be very clear any program written by someone who says their memory allocator is their bottleneck is something I could speed up by orders of magnitude and the standard library isn't going to matter.

This is youthful arrogance (I can only assume you're young; if not, you at least haven't matured in your career). It's not always possible to do such optimization, from either a technical perspective or a pragmatic one. Most people do not have authority to go on an optimization binge across their codebases, assuming the penalty is even paid by their own code (it often comes from upstream libraries!). Even if you did have the authority, expertise, and time to do the optimization, it could be a horrible idea and introduce a LOT of potential bugs.

I like the idea of MUSL, and wish the project well. I may even use it for something one day. But none of this makes their performance better. It may be that getting better performance would compromise their other objectives, such as simplicity.

>I would dispute this in anything that isn't mostly about string processing and in that case you can always easily grab different string functions, which you should probably do anyway if strings are that important.

I'm telling you that I've seen it, in stuff as diverse as video games and robotics. Lots of things use strings as values. It's easy to say "just change everything in millions of lines of code" when you aren't the one who has to make that change.

By the way most software does copious amounts of string processing... I think that should be common knowledge, but I guess it isn't.

>This doesn't sound like a general purpose statement that applies to anything broadly.

You sound like you have zero experience. If your config is in strings, and hundreds of thousands of lines of code already rely on the string-ness of the data, then you just can't make the change easily.

>All I'm saying is the the title is wrong and musl doesn't do much to prevent speed in a program. If someone was really trying to optimize, blaming the standard library is not going to get them very far and it's easy to work around, but needing to do that is very rare.

I believe the title is accurate. People in performance-sensitive areas gripe about libraries, even standard libraries, quite often. I don't mean to insult you but you're making bold assertions despite clearly lacking the experience to know how things are done in industry generally.

26% slower could turn into a huge hardware bill, and could render the library unusable for some purposes. There are many applications for which 26% is negligible, but it ain't nothing...

>Performance wise it's unlikely C string functions are actually the bottleneck in a program. Maybe for specific programs a naive memory copy function could benefit from AVX instructions.

Many programs use lots of strings. It tends to become a bottleneck. It also tends to be very difficult to improve because the strings are everywhere in that kind of program, and refactoring to eliminate them is either impossible or very risky.

I don't think they are talking about getting the artifact at the same time as the source or any such thing. They are saying, the metadata required to reproduce a build is not present in that sdist format, and there's no place to attach it. So, if you got an artifact and separately got the source, you couldn't verify it without another source of information about how to do the build itself in exactly the same way. It goes beyond pure reproducibility as well. Without that metadata to set up your environment, you may see bugs or other differences in your build that are not in the distributed artifact.