3 ms·

> He has said the language does matter and has talked about why Lua lends itself to good JIT performance. I didn't say it's equally easy. The problem is essent

by vardump 11y ago

> He has said the language does matter and has talked about why Lua lends itself to good JIT performance. I didn't say it's equally easy. The problem is essentially "find fastest set of operations that give equivalent output". That can be a very hard problem to solve. For practical purposes, some languages make it easier, some harder.

CyberDildonics 11y ago
What you aren't factoring in is that dynamic languages mean that input can change the types of variables, so types essentially become inputs. Then there is the issue of heap allocation of most if not all variables since their life times are hard if not impossible to determine. Heap allocation is fast, but not so fast that you can do it for every variable.
- vardump 11y ago
  Compilers have been steadily advancing for 40 years now. Doing a lot of things previously deemed too hard or almost impossible. I'm pretty sure there will be further breakthroughs compiling more dynamic cases into some high performance form. > Then there is the issue of heap allocation of most if not all variables since their life times are hard if not impossible to determine. It's actually other way around. In most JITted "scripting languages", by far most variables have lifetimes that can be determined and stack allocated. https://en.wikipedia.org/wiki/Escape_analysis https://en.wikipedia.org/wiki/Escape_analysis
  - CyberDildonics 11y ago
    So you think scripting languages that have no type constraints will somehow advance to the point of being the same as writing native code? Or.. do you think that maybe you know only scripting and dynamic languages and you want to believe that at some point a solution will come to you instead you having to learn programming at a lower level? I've seen the latter attitude in plenty of people. It is better to just bite the bullet and learn a lower level language. And there is always Julia.
    - vardump 11y ago
      > So you think scripting languages that have no type constraints will somehow advance to the point of being the same as writing native code? Absolutely. It's just a matter of time. Javascript JITters and LuaJIT are pretty good examples already. And there's so much more that can be done! > maybe you know only scripting and dynamic languages and you want to believe that at some point a solution will come to you instead you having to learn programming at a lower level? I do C/C++ (20+ years of experience). And a lot of other languages. Firmware and kernel driver development. 6502 (almost 30 years ago), 68k, x86 (+SSE/AVX/etc.), ARM (+NEON/etc)... Sufficiently low level? > I've seen the latter attitude in plenty of people. There's a difference between where the buck is at right now and where it's going.
      - deleted 11y ago
        [deleted]
      - CyberDildonics 11y ago
        Ok, but what evidence suggests this to you other than optimism? What I see is dynamic languages having more underpinnings of fast native code or things like web assembly, which make them effectively faster. I don't see any evidence that dynamic languages in general will somehow get much faster though.
        vardump 11y ago
        > Ok, but what evidence suggests this to you other than optimism? Intuition and optimism is a major part of it I guess. The fact that compilers have gotten increasingly clever over time. If current tracing JITs could handle branching in the trace instead of bailing out of any unexpected branch with a guard condition, we'd be closer to native performance. From data side, for example Google's V8 can infer hidden classes and member types, turn javascript object (read: hash) into a binary structure, akin to C struct. Well, one idea here: I envision profiling and tracing "superJITs" that can build a model of deterministic target code data flow (including target internal state), execution flow and computation. Not looking so much at the code itself at binary level, but analyzing the critical points that actually decide or compute something. Once the model is built, the "superJIT" will compute constraints for model validity and build AST out of it. Data flow is used to see through hash tables and other transformations and where predictable, used to build binary structs for transient and state data. Simplify and optimize. Vectorize where possible. Output executable binary. Cache to RAM and to disk. Limitations will of course be number of execution paths and too complicated data flow taints. Rarer execution paths could be pruned and special cased, and just generating fast code for the very likely paths. Is this particular idea realistic? Frankly, I have no idea. Do I think something similar will be built? Yes, but of course with constraints. The performance gap might never be completely removed, but incrementally narrowed. Perhaps eventually to few percent range. We'll see.
laumars 11y ago
strongly typed variables will always be faster than duck typing. Manual memory management will always be faster than garbage collection. Saying the language doesn't matter with regards to the performance is completely inaccurate.
- 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.

by vardump 11y ago

CyberDildonics 11y ago

What you aren't factoring in is that dynamic languages mean that input can change the types of variables, so types essentially become inputs. Then there is the issue of heap allocation of most if not all variables since their life times are hard if not impossible to determine. Heap allocation is fast, but not so fast that you can do it for every variable.

vardump 11y ago
Compilers have been steadily advancing for 40 years now. Doing a lot of things previously deemed too hard or almost impossible. I'm pretty sure there will be further breakthroughs compiling more dynamic cases into some high performance form. > Then there is the issue of heap allocation of most if not all variables since their life times are hard if not impossible to determine. It's actually other way around. In most JITted "scripting languages", by far most variables have lifetimes that can be determined and stack allocated. https://en.wikipedia.org/wiki/Escape_analysis https://en.wikipedia.org/wiki/Escape_analysis
- CyberDildonics 11y ago
  So you think scripting languages that have no type constraints will somehow advance to the point of being the same as writing native code? Or.. do you think that maybe you know only scripting and dynamic languages and you want to believe that at some point a solution will come to you instead you having to learn programming at a lower level? I've seen the latter attitude in plenty of people. It is better to just bite the bullet and learn a lower level language. And there is always Julia.
  - vardump 11y ago
    > So you think scripting languages that have no type constraints will somehow advance to the point of being the same as writing native code? Absolutely. It's just a matter of time. Javascript JITters and LuaJIT are pretty good examples already. And there's so much more that can be done! > maybe you know only scripting and dynamic languages and you want to believe that at some point a solution will come to you instead you having to learn programming at a lower level? I do C/C++ (20+ years of experience). And a lot of other languages. Firmware and kernel driver development. 6502 (almost 30 years ago), 68k, x86 (+SSE/AVX/etc.), ARM (+NEON/etc)... Sufficiently low level? > I've seen the latter attitude in plenty of people. There's a difference between where the buck is at right now and where it's going.
    - deleted 11y ago
      [deleted]
    - CyberDildonics 11y ago
      Ok, but what evidence suggests this to you other than optimism? What I see is dynamic languages having more underpinnings of fast native code or things like web assembly, which make them effectively faster. I don't see any evidence that dynamic languages in general will somehow get much faster though.
      - vardump 11y ago
        > Ok, but what evidence suggests this to you other than optimism? Intuition and optimism is a major part of it I guess. The fact that compilers have gotten increasingly clever over time. If current tracing JITs could handle branching in the trace instead of bailing out of any unexpected branch with a guard condition, we'd be closer to native performance. From data side, for example Google's V8 can infer hidden classes and member types, turn javascript object (read: hash) into a binary structure, akin to C struct. Well, one idea here: I envision profiling and tracing "superJITs" that can build a model of deterministic target code data flow (including target internal state), execution flow and computation. Not looking so much at the code itself at binary level, but analyzing the critical points that actually decide or compute something. Once the model is built, the "superJIT" will compute constraints for model validity and build AST out of it. Data flow is used to see through hash tables and other transformations and where predictable, used to build binary structs for transient and state data. Simplify and optimize. Vectorize where possible. Output executable binary. Cache to RAM and to disk. Limitations will of course be number of execution paths and too complicated data flow taints. Rarer execution paths could be pruned and special cased, and just generating fast code for the very likely paths. Is this particular idea realistic? Frankly, I have no idea. Do I think something similar will be built? Yes, but of course with constraints. The performance gap might never be completely removed, but incrementally narrowed. Perhaps eventually to few percent range. We'll see.

laumars 11y ago

strongly typed variables will always be faster than duck typing. Manual memory management will always be faster than garbage collection. Saying the language doesn't matter with regards to the performance is completely inaccurate.

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.