4 ms·

we could of course theoretically make everything even faster. It's nowhere near the most optimal use of the available hardware. All we'd have to give up is squi

we could of course theoretically make everything even faster. It's nowhere near the most optimal use of the available hardware. All we'd have to give up is squishy hard-to-measure things like "feature sets" and "engineering velocity." Says who? Who are these experienced people that know how to write fast software that think it is such a huge sacrifice? The reality is that people who say things like this don't actually know much about writing fast software because it really isn't that difficult. You just can't grab electron and the lastest javascript react framework craze. These kinds of myths get perpetuated by people who repeat it without having experienced the side of just writing native software. I think mostly it is people rationalizing not learning C++ and sticking to javascript or python because that's what they learned first.

sorcerer-mar 1y ago
> These kinds of myths get perpetuated by people who repeat it without having experienced the side of just writing native software. I think mostly it is people rationalizing not learning assembly and sticking to C++ or PERL because that's what they learned first. Why stop at C++? Is that what you happen to be comfortable with? Couldn't you create even faster software if you went down another level? Why don't you?
- CyberDildonics 1y ago
  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.
- const_cast 1y ago
  > Couldn't you create even faster software if you went down another level? Why don't you? No, actually, C++ is pretty much as low as you can go. Well, I mean, you can go lower but you're not going to get performance benefits. You could go down to C. But C is going to be more of the same or, more likely, slower. You're going to be swapping Templates for things like void *. You could go to assembly, but let's be honest - who can write better assembly than a C++ compiler?
  - sorcerer-mar 1y ago
    > You could go to assembly, but let's be honest - who can write better assembly than a C++ compiler? In other words, yes you can eek out more performance at lower levels. Then again at the silicon level. No, it's not worth it in 99.9999% of scenarios (because there are tradeoffs).
BobaFloutist 1y ago
I mean do you think JavaScript and Python aren't easier than C++? Then why do they exist?
- CyberDildonics 1y ago
  Javascript was made in a few weeks so that some sort of programmability could be built in to web pages. Python was made in the 90s as a more modern competition to perl for scripting. Modern C++ and systems language didn't exist and neither was made with the intention that people would write general purpose interactive programs that leveraged computers 1,000x faster so that software could run 1,000x slower.

sorcerer-mar 1y ago

> These kinds of myths get perpetuated by people who repeat it without having experienced the side of just writing native software. I think mostly it is people rationalizing not learning assembly and sticking to C++ or PERL because that's what they learned first. Why stop at C++? Is that what you happen to be comfortable with? Couldn't you create even faster software if you went down another level? Why don't you?

CyberDildonics 1y ago
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.
const_cast 1y ago
> Couldn't you create even faster software if you went down another level? Why don't you? No, actually, C++ is pretty much as low as you can go. Well, I mean, you can go lower but you're not going to get performance benefits. You could go down to C. But C is going to be more of the same or, more likely, slower. You're going to be swapping Templates for things like void *. You could go to assembly, but let's be honest - who can write better assembly than a C++ compiler?
- sorcerer-mar 1y ago
  > You could go to assembly, but let's be honest - who can write better assembly than a C++ compiler? In other words, yes you can eek out more performance at lower levels. Then again at the silicon level. No, it's not worth it in 99.9999% of scenarios (because there are tradeoffs).

BobaFloutist 1y ago

I mean do you think JavaScript and Python aren't easier than C++? Then why do they exist?

CyberDildonics 1y ago
Javascript was made in a few weeks so that some sort of programmability could be built in to web pages. Python was made in the 90s as a more modern competition to perl for scripting. Modern C++ and systems language didn't exist and neither was made with the intention that people would write general purpose interactive programs that leveraged computers 1,000x faster so that software could run 1,000x slower.