3 ms·
> strongly typed variables will always be faster than duck typing. If the types can be deducted, they'll be just as fast. And when not, you fall into a dynamic
by vardump 11y ago
> strongly typed variables will always be faster than duck typing.
If the types can be deducted, they'll be just as fast. And when not, you fall into a dynamic case. Such as polymorphism in OOP languages, pointers in C, etc.
> Manual memory management will always be faster than garbage collection.
That's a very strong statement. So you're saying it'll always be faster in terms of total used CPU time to use manual memory management vs. garbage collection?
I wouldn't dare to make a strong statement about memory management either way!
If you're talking about shared heap manual memory allocation, like C malloc/free style, that shared part will make sure it won't scale with CPU core count. You'll also need to track lifetimes of your object destruction. What if some other thread followed a pointer into the structure you're about to free and got pre-empted by the operating system? That calls for more thread synchronization, and puts hard limits to your scalability.
I think if CPUs with tens or hundreds of cores become popular, garbage collection might be the only realistic way to avoid object lifetime synchronization bottlenecks.
> Saying the language doesn't matter with regards to the performance is completely inaccurate.
It affects the difficulty of compiling it into a performant form. Dynamic features do make it more difficult, but just look at the progress in dynamic language compilation in recent years.
Who could have guessed for example Javascript could ever be within order of magnitude of C/C++ performance? But now it is there, and the gap is only getting narrower. In my own tests, occasionally I've seen Javascript and Lua JITters generating practically same code as "gcc -O3 -march=native" does!
- laumars 11y ago"if", "could", "occasionally....practically the same".... you're talking about a lot of theoretical fringe cases to produce similar yet not the same performance results. And to what end? You're not disproving my point if you have to invent a use case where C is crippled to the point that Javascript is only "practically the same". Sorry, but that's just hypothetical hokum. There's no denying that a lot of optimisations can occur with (and for want a better term) "scripting" languages. Nor that "scripting" languages aren't serious tools for serious development these days. But I also think it's fair to say that one language would out perform another in an idiomatic like-for-like contest - simply because those languages that trade in raw CPU performance do so at the gain of development time / productivity or application portability. Thankfully these days most target platforms are powerful enough that we don't need to go that low level in pursuit of performance. And even on many popular cloud services / web sites where micro-optimisations can quickly multiply, productivity is often still a critical metric (case in point: I've barely touched C++ in recent years yet have written thousands of lines of Go, Perl, Javascript, etc). So rather than arguing hypothetical fringe cases, we really should be praising praising the "slower" languages for providing useful abstractions.