Re: ...some commands are much slower than their C ancestors and others don't support all the opt...
Well, that all sounds fair. I suspect a fair few things are down to such vagaries as compiler optimisations as well.
There is a general point here, though, which I think another commenter has made, about the trade-off between robustness and speed. For example, unchecked memory access is always going to require less computation than bounds-checking. This either translates to slower, or more computationally intensive.
There is an argument to be made that such tasks could conceivably be hived off into dedicated hardware, which could limit the impact on speed, but still increase overall power usage, and, if you're lucky, also summon the eldritch horrors that come with asynchronicity, such as race conditions.
Biting the hand that feeds IT
