13 ms·

C++ doesn't fight the stack more than any good JIT. In fact, it may be less capable in noticing ways to inline functions given that it's a statically compiled l

C++ doesn't fight the stack more than any good JIT. In fact, it may be less capable in noticing ways to inline functions given that it's a statically compiled language. It's only current advantage with the stack is tail call optimization which is coming to V8 very soon. Funny that the C++ guy is talking about abstractions, where them V-Tables at?

Jensson 5y ago
They talked about stack of libraries beneath you, not the execution stack. If an API call takes 10 microseconds because several "premature optimization is the root of all evil" abstractions in between then doing that just 10k times already nets you 100ms which is a very noticeable stutter. So with that limitation you are now forced to create elaborate data structures with caching etc to try to work around this slow API call. However doing the same querying in C++ without those abstractions where each call takes 10 nanoseconds means that you no longer have to try to create complex data structures to work around that slow API call, even if you do it a million times it would only take 10 milliseconds and maybe drop a frame.
- npigrounet 5y ago
  Nowadays JS is as fast as C++, if not faster.
  - goldenkey 5y ago
    Let me respond for him. He meant abstraction as in "stack of dependencies." Because everyone knows that's what abstraction means, right?! Because we all know NPM is a disaster as opposed to C++ dependency management which doesn't even exist in a standard form. /s
    - Jensson 5y ago
      Microsoft has a C++ API you use to make programs for windows. If you write in C++ you will code directly against that. If you write in Javascript then you will code against someone else's API that they wrote to interface with the Microsoft API. If you write in Javascript another step up then you will code your plugin against the VSCode API which then uses the Electrons wrapper around Microsofts API to do stuff, if there aren't more libraries in between. This stack of abstractions turned out to be too slow to solve the problem mentioned in the article we are talking about, so to solve it they moved the entire thing up one step in the stack. In these situations it is common to have a problem that is really easy to solve but the API abstractions you have to work with doesn't support the operations at the speeds you need to solve it. If you have never experienced that then you aren't working on performance intensive projects where every bit counts and your input on this topic doesn't matter. I have worked on performance intensive libraries crossing programming language boundaries and the abstraction boundaries absolutely puts a limit on the amount of performance you can get. Well designed abstractions are less obstructive but plenty of them aren't well designed and even the well designed ones have overhead.
      - npigrounet 5y ago
        JS is almost close to the metal nowadays thanks to the stunningly optimized JIT.
        amw-zero 5y ago
        Can you initialize a kernel with JS?
        goldenkey 5y ago
        Of course. Have you not seen the VMs written in JS? https://bellard.org/jslinux/ https://bellard.org/jslinux/
        amw-zero 5y ago
        That is a VM running in a web browser. If I was thinking about a joke that was so comically far away from the metal, that’s pretty much what I would use as an example. This is why it’s very difficult to have conversations. Most programmers really don’t even know how computers work.
        goldenkey 5y ago
        Heh, I know plenty about how computers work. You didn't specify what hardware you wanted targeted. Emulated devices are just abstractions. Here is a real kernel: https://news.ycombinator.com/item?id=7958194 https://news.ycombinator.com/item?id=7958194 It's so difficult to have conversations with engineers that don't know x86 assembly. They never stop complaining. If only I could NOP them! ;-)
      - goldenkey 5y ago
        Ah, so this is all coming from a Microsoft C++ guy. Well better get to using those undocumented ntdll calls since you really need those uOps. It's not like the standard libraries of other languages is written in C or anything... ;-)
      - 5y ago
int_19h 5y ago
Claims that JITs can produce code that's routinely faster than C++ have been around since Java. So far, the promised gains haven't really materialized. It appears that optimizations that can be gleaned from dynamically profiling a running program simply don't provide enough benefit to account for optimization opportunities lost because the JIT has to be "fast enough", and from language semantics that is inherently hard to compile to fast code (of which C++, quite intentionally, has little). V8 is not an exception. Your specific example - inlining functions - is not particularly illustrative, since C++ can inline just fine across translation unit (and thus also static library) boundaries with link-time optimization. What it can't do is inline across shared library boundaries, but large C++ apps are usually mostly statically linked for redist anyway.
- goldenkey 5y ago
  Java is not V8, it isn't Dalvik either. Java is a memory hungry turd that never delivered, agreed. But let's not forget that Google made their own runtime for Android and invested millions into V8. https://news.ycombinator.com/item?id=17648139 https://news.ycombinator.com/item?id=17648139 > What it can't do is inline across shared library boundaries, but large C++ apps are usually mostly statically linked for redist anyway. I'm guessing you've never looked inside System32 on Windows or /usr/*/lib on Unix. I don't see shared libraries as a bad thing, they are great for reducing disk and memory usage. Let's not make bullshit up about how most applications are statically compiled with all their dependencies ;-)
  - int_19h 5y ago
    Java is not V8, of course, because one is a language, and the other one is a VM. Java is also not JS. Semantics of Java are much better suited to effective compilation than that of JS, due to static typing and (in many cases) early binding. Consequently, modern Java VMs have the best JITs in the industry - faster than V8 - and they're still not on par with C++. Most applications dynamically link to system libraries. On Linux, this is kinda fuzzy because package managers handle everything; and yes, I agree, on Linux the norm for distro-packaged software is dynamic linking. But stuff packaged as Flatpak etc is much more likely to be statically linked to anything other than libc. And idiomatic C++ tends to involve lots of templates, which are inherently "statically linked". (Also, native code is broader than C/C++ - it includes e.g. Go, which drops even the libc dependency, and Rust.) On Windows and macOS, though, where "app is a self-contained folder" has been the rule rather than the exception for a long time now, dependencies that don't come from the OS are often statically linked.
robpalmer 5y ago
TCO is coming to V8? Is there a source for this?

Jensson 5y ago

They talked about stack of libraries beneath you, not the execution stack. If an API call takes 10 microseconds because several "premature optimization is the root of all evil" abstractions in between then doing that just 10k times already nets you 100ms which is a very noticeable stutter. So with that limitation you are now forced to create elaborate data structures with caching etc to try to work around this slow API call. However doing the same querying in C++ without those abstractions where each call takes 10 nanoseconds means that you no longer have to try to create complex data structures to work around that slow API call, even if you do it a million times it would only take 10 milliseconds and maybe drop a frame.

npigrounet 5y ago
Nowadays JS is as fast as C++, if not faster.
- goldenkey 5y ago
  Let me respond for him. He meant abstraction as in "stack of dependencies." Because everyone knows that's what abstraction means, right?! Because we all know NPM is a disaster as opposed to C++ dependency management which doesn't even exist in a standard form. /s
  - Jensson 5y ago
    Microsoft has a C++ API you use to make programs for windows. If you write in C++ you will code directly against that. If you write in Javascript then you will code against someone else's API that they wrote to interface with the Microsoft API. If you write in Javascript another step up then you will code your plugin against the VSCode API which then uses the Electrons wrapper around Microsofts API to do stuff, if there aren't more libraries in between. This stack of abstractions turned out to be too slow to solve the problem mentioned in the article we are talking about, so to solve it they moved the entire thing up one step in the stack. In these situations it is common to have a problem that is really easy to solve but the API abstractions you have to work with doesn't support the operations at the speeds you need to solve it. If you have never experienced that then you aren't working on performance intensive projects where every bit counts and your input on this topic doesn't matter. I have worked on performance intensive libraries crossing programming language boundaries and the abstraction boundaries absolutely puts a limit on the amount of performance you can get. Well designed abstractions are less obstructive but plenty of them aren't well designed and even the well designed ones have overhead.
    - npigrounet 5y ago
      JS is almost close to the metal nowadays thanks to the stunningly optimized JIT.
      - amw-zero 5y ago
        Can you initialize a kernel with JS?
        goldenkey 5y ago
        Of course. Have you not seen the VMs written in JS? https://bellard.org/jslinux/ https://bellard.org/jslinux/
        amw-zero 5y ago
        That is a VM running in a web browser. If I was thinking about a joke that was so comically far away from the metal, that’s pretty much what I would use as an example. This is why it’s very difficult to have conversations. Most programmers really don’t even know how computers work.
        goldenkey 5y ago
        Heh, I know plenty about how computers work. You didn't specify what hardware you wanted targeted. Emulated devices are just abstractions. Here is a real kernel: https://news.ycombinator.com/item?id=7958194 https://news.ycombinator.com/item?id=7958194 It's so difficult to have conversations with engineers that don't know x86 assembly. They never stop complaining. If only I could NOP them! ;-)
    - goldenkey 5y ago
      Ah, so this is all coming from a Microsoft C++ guy. Well better get to using those undocumented ntdll calls since you really need those uOps. It's not like the standard libraries of other languages is written in C or anything... ;-)
    - 5y ago

int_19h 5y ago

Claims that JITs can produce code that's routinely faster than C++ have been around since Java. So far, the promised gains haven't really materialized. It appears that optimizations that can be gleaned from dynamically profiling a running program simply don't provide enough benefit to account for optimization opportunities lost because the JIT has to be "fast enough", and from language semantics that is inherently hard to compile to fast code (of which C++, quite intentionally, has little). V8 is not an exception. Your specific example - inlining functions - is not particularly illustrative, since C++ can inline just fine across translation unit (and thus also static library) boundaries with link-time optimization. What it can't do is inline across shared library boundaries, but large C++ apps are usually mostly statically linked for redist anyway.

goldenkey 5y ago
Java is not V8, it isn't Dalvik either. Java is a memory hungry turd that never delivered, agreed. But let's not forget that Google made their own runtime for Android and invested millions into V8. https://news.ycombinator.com/item?id=17648139 https://news.ycombinator.com/item?id=17648139 > What it can't do is inline across shared library boundaries, but large C++ apps are usually mostly statically linked for redist anyway. I'm guessing you've never looked inside System32 on Windows or /usr/*/lib on Unix. I don't see shared libraries as a bad thing, they are great for reducing disk and memory usage. Let's not make bullshit up about how most applications are statically compiled with all their dependencies ;-)
- int_19h 5y ago
  Java is not V8, of course, because one is a language, and the other one is a VM. Java is also not JS. Semantics of Java are much better suited to effective compilation than that of JS, due to static typing and (in many cases) early binding. Consequently, modern Java VMs have the best JITs in the industry - faster than V8 - and they're still not on par with C++. Most applications dynamically link to system libraries. On Linux, this is kinda fuzzy because package managers handle everything; and yes, I agree, on Linux the norm for distro-packaged software is dynamic linking. But stuff packaged as Flatpak etc is much more likely to be statically linked to anything other than libc. And idiomatic C++ tends to involve lots of templates, which are inherently "statically linked". (Also, native code is broader than C/C++ - it includes e.g. Go, which drops even the libc dependency, and Rust.) On Windows and macOS, though, where "app is a self-contained folder" has been the rule rather than the exception for a long time now, dependencies that don't come from the OS are often statically linked.

robpalmer 5y ago

TCO is coming to V8? Is there a source for this?