| > is like asking which syntax (letters) is faster - syntax of Rust, Java or C++? This is actually a bad example because C style decls are provably, objectively, bad. They make parsing harder and once the types are non-trivial, they are absurdly hard to read and write. The case in point being non-trivial function pointers in C. The syntax for declaring a function pointer of a type that returns a function pointer is hidious. Meanwhile here is how you define a function in that returns a function that returns a string in a modern language (Typescript): type NumberToStringFunction = (num: number) => () => string;
Compare that to C typedef char* (*(*NumberToStringFunction)(int))(void);
> And same as with CPUs - everything is up to the implementationIt is very easy to add CPU features that place a hard limit on performance. That is why Arm64 dropped all the conditional stuff! (Any instruction that limits the potential branch prediction is going to severely impact potential CPU performance.) History is littered with failed CPU architectures that just couldn't scale up, Intel's famous folly being Itanium. That said, x86 is mature and it dropped some of its less pleasant aspects with x64. Also IMHO drivers matter more for laptops than the CPU does. A bad driver keeping the GPU on w/o need or just not being able to enter the lower sleep states in general, will kill battery faster than anything else. |
The example is good, I just dont understand why you focused on compiler performance or developer experience. It doesnt imply program's performance.
We were talking purely about performance/energy eff of generated binary, not other RELEVANT things like developer experience/low compilation times because it is outside the scope of this discussion.
Yes, C++ is poorly designed language, but point that syntax (letters) don't imply language's performance stands. The result is up to the implementation: compiler, runtime/vm, std libs, etc.