You are very unlikely to write assembly that is more optimized than what a modern compiler could produce for anything longer than a trivial program. I don’t know if it made sense at the time of the original RCT, but OpenRCT would definitely not benefit from being written in assembly.
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.
Probably not as optimized though.
RCT could run on a toaster from the 90’s (ok, maybe early 2000’s) and looked amazing for the time.
OpenRCT can run on a toaster from the 2010’s and looks great because of the timeless art style of the original.
It’s still an incredible feat, though!
You are very unlikely to write assembly that is more optimized than what a modern compiler could produce for anything longer than a trivial program. I don’t know if it made sense at the time of the original RCT, but OpenRCT would definitely not benefit from being written in assembly.
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.