3 ms·

Couldn't you create even faster software if you went down another level? Why don't you? No and if you understood what makes software fast you would know that.

Couldn't you create even faster software if you went down another level? Why don't you? No and if you understood what makes software fast you would know that. Most software is allocating memory inside hot loops and taking that out is extremely easy and can easily be a 7x speedup. Looping through contiguous memory instead of chasing pointers through heap allocated variables is another 25x - 100x speed improvement at least. This is all after switching from a scripting language, which is about a 100x in itself if the language is python. It isn't about the instructions it is about memory allocation and prefetching.

sorcerer-mar 1y ago
Sorry but it is absolutely the case that there are optimizations available to someone working in assembly that are not available to someone working in C++. You are probably a lazy or inexperienced engineer if you choose to work in C++. In fact, there are optimizations available at the silicon level that are not available in assembly. You are probably a lazy or inexperienced engineer if you choose to work in assembly.
- CyberDildonics 1y ago
  Go ahead and give me examples of what you mean. I'm talking about speeding software up by 10x-100x by language choice, then 7x with extremely minimal adjustments (allocate memory outside of hot loops), then 25x - 100x with fairly minimal design changes (use vectors, loop through them straight). I'm also not saying people are lazy, I'm saying they don't know that with something like modern C++ and a little bit of knowledge of how to write fast software MASSIVE speed gains are easy to get. You are helping make my point here, most programmers don't realize that huge speed gains are low hanging fruit. They aren't difficult, they don't mean anything is contorted or less clear (just the opposite), they just have to stop rationalizing not understanding it. I say this with knowledge of both sides of the story instead of guessing based on conventional wisdom.
  - sorcerer-mar 1y ago
    So you agree there’s a trade off between developer productivity and optimization (coding in assembly isn’t worth it, but allocating memory outside of hot loops is) You agree with my original point then?
    - CyberDildonics 1y ago
      Are you seriously replying and avoiding everything we both said? I'll simplify it for you: Writing dramatically fast software that is 1,000x or even 10,000 times faster than a scripting language takes basically zero effort once you know how to do it and these assembly optimization are a myth that you would have already shown me if you could.
      - sorcerer-mar 1y ago
        “Zero effort once you know how to do it” is another way of saying “time and effort.” Congratulations you’ve discovered the value of abstractions! 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). Not my fault you stake out indefensible positions.
        CyberDildonics 1y 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.

sorcerer-mar 1y ago

Sorry but it is absolutely the case that there are optimizations available to someone working in assembly that are not available to someone working in C++. You are probably a lazy or inexperienced engineer if you choose to work in C++. In fact, there are optimizations available at the silicon level that are not available in assembly. You are probably a lazy or inexperienced engineer if you choose to work in assembly.

CyberDildonics 1y ago
Go ahead and give me examples of what you mean. I'm talking about speeding software up by 10x-100x by language choice, then 7x with extremely minimal adjustments (allocate memory outside of hot loops), then 25x - 100x with fairly minimal design changes (use vectors, loop through them straight). I'm also not saying people are lazy, I'm saying they don't know that with something like modern C++ and a little bit of knowledge of how to write fast software MASSIVE speed gains are easy to get. You are helping make my point here, most programmers don't realize that huge speed gains are low hanging fruit. They aren't difficult, they don't mean anything is contorted or less clear (just the opposite), they just have to stop rationalizing not understanding it. I say this with knowledge of both sides of the story instead of guessing based on conventional wisdom.
- sorcerer-mar 1y ago
  So you agree there’s a trade off between developer productivity and optimization (coding in assembly isn’t worth it, but allocating memory outside of hot loops is) You agree with my original point then?
  - CyberDildonics 1y ago
    Are you seriously replying and avoiding everything we both said? I'll simplify it for you: Writing dramatically fast software that is 1,000x or even 10,000 times faster than a scripting language takes basically zero effort once you know how to do it and these assembly optimization are a myth that you would have already shown me if you could.
    - sorcerer-mar 1y ago
      “Zero effort once you know how to do it” is another way of saying “time and effort.” Congratulations you’ve discovered the value of abstractions! 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). Not my fault you stake out indefensible positions.
      - CyberDildonics 1y 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.