Comment by CyberDildonics
4 days ago
Your original comment was saying you have to give up features and development speed to have faster software. I've seen this claim before many times, but it's always from people rationalizing not learning anything beyond the scripting languages they learned when they got in to programming.
I explained to you exactly why this is true, and it's because writing fast software just means doing some things slightly differently with a basic awareness of what makes programs fast, not because it is difficult or time consuming. Most egregiously bad software is probably not even due to optimization basics but from recomputing huge amounts of unnecessary results over and over.
What you said back is claims but zero evidence or explanation of anything. You keep talking about assembly language, but it has nothing to do with getting huge improvements for no time investment, because things like instruction count are not where the vast majority of speed improvements come from.
I mean, you’re the one who started this off with the insane claim that there’s no tradeoff, then claimed there are no optimizations available below C++ (i.e. C++ is the absolute most optimized code a person can write).
This is a hallucination that has nothing to do with your original point. The vast majority of software could be sped up 100x to 1000x easily if they were written slightly different. Asm optimizations are extremely niche with modern CPUs and compilers and the gains are minuscule compared to C++ that is already done right. This is an idea that permeates through inexperienced programmers, that asm is some sort of necessity for software that runs faster than scripting languages.
Go ahead and show me what specifically you are talking about with C++, assembly or any systems language or optimization.
Show me where writing slow software saves someone so much time, show me any actual evidence or explanation of this claim.
So again, what you're saying is there is a tradeoff. You just think it should be made in a different place than where the vast majority of engineers in the world choose to make it. That's fine! It's probably because they're idiots and you're really smart, but it's obviously not because there's no tradeoff.
> that asm is some sort of necessity for software that runs faster than scripting languages.
It seems you're not tracking the flow of the conversation if you believe this is what I'm saying. I am saying there is always a way to make things faster by sacrificing other things developer productivity, feature sets, talent pool, or distribution methods. You agree with me, it turns out!
So again, what you're saying is there is a tradeoff. You just think it should be made in a different place than where the vast majority of engineers in the world choose to make it.
Show me what it is I said that makes you think that.
That's fine! It's probably because they're idiots and you're really smart, but it's obviously not because there's no tradeoff.
Where did I say any of this? I could teach anyone to make faster software in an hour or two, but myths like the ones you are perpetuating make people think it's difficult or faster software is more complicated.
You originally said that making software faster 'decreases velocity and sacrifices features' but you can't explain or backup any of that.
You agree with me, it turns out!
I think what actually happened is that you made some claims that get repeated but they aren't from your actual experience and you're trying to avoid giving real evidence or explanations so you keep trying to shift what you're saying to something else.
The truth is that if someone just learns to program with types and a few basic techniques they can get away from writing slow software forever and it doesn't come at any development speed, just a little learning up front that used to be considered the basics.
Next time you reply show me actual evidence of the slow software you need to write to save development time. I think the reality is that this is just not something you know a lot about, but instead of learning about it you want to pretend there is any truth to what you originally said. Show me any actual evidence or explanation instead of just making the same claims over and over.
> I could teach anyone to make faster software in an hour or two,
Is one or two hours of two engineers' time more than zero hours, or no?
> just a little learning up front
Is a little learning more than zero learning, or no?
IMO your argument would hold a lot more weight if people felt like their software (as users) is slow, but many people do not. Save for a few applications, I would prefer they keep their same performance profile and improve their feature set than spend any time doing the reverse. And as you have said multiple times now: it does indeed take time!
If your original position was what it is now, which is "there's low hanging fruit," I wouldn't disagree. But what you said is there's no tradeoff. And of course now you are saying there is a tradeoff... so now we agree! Where any one person should land on that tradeoff is super project-specific, so not sure why you're being so assertive about this blanket statement lol.
3 replies →
For what it is worth, there is room for improvement in how people use scripting languages. I have seen Kodi extensions run remarkably slowly and upon looking at their source code to see why, I saw that everything was being done in a single thread with blocking on relatively slow network traffic. There was no concurrency being attempted at all, while all of the high performance projects I have touched in either C or C++ had concurrency. The plugin would have needed a major rewrite to speed things up, but it would have made things that took minutes take a few seconds if it were done. Unfortunately, doing the rewrite was on the wrong side of a simple “is it worth the time” curve, so I left it alone:
https://xkcd.com/1205/
Just today, I was thinking about the slow load times of a bloated Drupal site that heard partially attributable to a YouTube embed. I then found this, which claims to give a 224x performance increase over YouTube’s stock embed (and shame on YouTube for not improving it):
https://github.com/paulirish/lite-youtube-embed
In the past, I have written electron applications (I had tried Qt first, but had trouble figuring out how what I wanted after 20 hours of trying, and got what I needed from electron in 10). The electron applications are part of appliances that are based on the Raspberry Pi CM4. The electron application loads in a couple seconds on the CM4 (and less than 1 second on my desktop). Rather than using the tools web developers often use that produce absurd amounts of HTML and JS, I wrote nearly every line of HTML and JavaScript by hand (as I would have done 25 years ago) such that it was exactly what I needed and there was no waste. I also had client side JavaScript code running asynchronously after the page loaded. To be fair, I did use a few third party libraries like express and an on screen keyboard, but they were relatively light weight ones.
Out of curiosity, I did a proof of concept port of one application from electron to WebKitGTK with around 100 lines of C. The proof of concept kept nodejs running as a local express server that was accessed by the client side JavaScript running in the WebKitGTK front end via HTTP requests. This cut memory usage in half and seemed to launch slightly faster (although I did not measure it). I estimated that memory usage would be cut in half again if I rewrote the server side JavaScript in C. Memory usage would likely have dropped even more and load times would have become even quicker if I taught myself how to use a GUI toolkit to eliminate the need for client side HTML and JavaScript, but I had more important things to do than spend many more hours to incrementally improve what already worked (and I suspect many are in the same situation).
To give a final example, I had a POSIX shell script that did a few tasks, such as polling a server on its LAN for configuration updates to certain files and doing HA failover of another system were down, among other things. I realized the script iterated too slowly, so I rewrote it to launch a subshell as part of its main loop that does polling (with file locking to prevent multiple sub shells from doing polling at the same time). This allowed me to guarantee HA failover always happens within 5 seconds of another machine going down, and all it took were using concepts from C (threading and locking). They were not as elegant as actual C code (since subshells are not LWPs and thus need IPC mechanisms like file locks), but they worked. I know polling is inefficient, but it is fairly foolproof (no need to handle clients being offline when it is time for a push), robustness was paramount and development time was needed elsewhere.
In any case, using C (or if you must, C++) is definitely better than a scripting language, provided you use it intelligently. If you use techniques from high performance C code in scripting languages, code written in them often becomes many times faster. I only knew how to do things in other languages relatively efficiently because I was replicating what I would be doing in C (or if forced, C++). If I could use C for everything, I would, but I never taught myself how to do GUIs in C, so I am using my 90s era HTML skills as a crutch. However, reading this exchange (and writing this reply) has inspired me to make an effort to learn.