I feel like that's only true if I was asked to "write the assembly for this c++ program." If I'm actually implementing something big in assembly, I'm not going to do 90% of the craziness someone might be tempted to do in c++. Something that is super easy in c++ doesn't mean it's easy for the CPU. Writing assembly, I'm going to do what's easy for the CPU (and efficient) because, now, I'm in the same domain.
The bottom line is cranking up the optimization level can get you a 2-5x win. Using memory efficiently can give you a 10-100x win.
Using memory efficiently can give you a 10-100x win.
Yes, it can. But why is this exclusive to assembly? What are you planning to do with your memory use in assembly that is not achievable in C++ or other languages? Memory optimizations are largely about data structures and access patterns. This is available to you in C++.
Also, if you don't want 90% of the craziness of C++ then why not just code in C++ without 90% of the craziness? As far as I know what's what a lot of performance-critical projects do. They operate with a feature whitelist/blacklist. Don't tell me you have the discipline to work entirely in assembly and the knowledge to beat the compiler at the low level stuff that is not available to you in C++ but you can't manage avoiding the costly abstractions.
I think it speaks volumes how rarely you hear about programs being programmed in assembly. It's always this one game and never any meaningful way to prove that it would gain performance by not being written in C++ when using a modern compiler.
I shouldn't have used C++ as the example. Even C would work. I agree with everything you're saying, but the original premise. I think if you put ASM vs C, C++, rust, etc, performance would fall near 50/50.
I'm not the best assembly guy, and I'm not advocating we all write it. But I always felt that the compiler optimization assumption was wrong or weak. Everything would be aligned nicely for my sanity, not performance =]
I feel like that's only true if I was asked to "write the assembly for this c++ program." If I'm actually implementing something big in assembly, I'm not going to do 90% of the craziness someone might be tempted to do in c++. Something that is super easy in c++ doesn't mean it's easy for the CPU. Writing assembly, I'm going to do what's easy for the CPU (and efficient) because, now, I'm in the same domain.
The bottom line is cranking up the optimization level can get you a 2-5x win. Using memory efficiently can give you a 10-100x win.
Yes, it can. But why is this exclusive to assembly? What are you planning to do with your memory use in assembly that is not achievable in C++ or other languages? Memory optimizations are largely about data structures and access patterns. This is available to you in C++.
Also, if you don't want 90% of the craziness of C++ then why not just code in C++ without 90% of the craziness? As far as I know what's what a lot of performance-critical projects do. They operate with a feature whitelist/blacklist. Don't tell me you have the discipline to work entirely in assembly and the knowledge to beat the compiler at the low level stuff that is not available to you in C++ but you can't manage avoiding the costly abstractions.
I think it speaks volumes how rarely you hear about programs being programmed in assembly. It's always this one game and never any meaningful way to prove that it would gain performance by not being written in C++ when using a modern compiler.
I shouldn't have used C++ as the example. Even C would work. I agree with everything you're saying, but the original premise. I think if you put ASM vs C, C++, rust, etc, performance would fall near 50/50.
I'm not the best assembly guy, and I'm not advocating we all write it. But I always felt that the compiler optimization assumption was wrong or weak. Everything would be aligned nicely for my sanity, not performance =]