Comment by CyberDildonics
4 days ago
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.
> 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?
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.
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.
12 replies →
> 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?
> 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).
I mean do you think JavaScript and Python aren't easier than C++? Then why do they exist?
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.