4 ms·

If only folks didn't ignore the JVM which is still wicked fast and getting faster all the time. JITs didn't fail, you are just using the ones that suck at what

by jpgvm 4y ago

If only folks didn't ignore the JVM which is still wicked fast and getting faster all the time. JITs didn't fail, you are just using the ones that suck at what you are trying to do (v8) or don't exist at all (Python). .NET and Java have convincingly proved that JIT'ed bytecode VMs are plenty fast enough for almost all general purpose computing. I wouldn't write a browser/game/kernel/hard-real-time application in one but they are awesome for data manipulation, databases, web servers, general desktop apps, etc. My point is that you don't need "shitty scripting language" + "fast AOT compiled languaeg" when you can literally just chose "fast managed bytecode language" for 99.99% of usecases (that aren't running in a browser because JS monopoly there ofc).

KMag 4y ago
AoT with periodic profile-based re-optimization (like the latest Dalvik / Android Runtime provide), perhaps also with dynamic re-optimization/on-stack replacement seems ideal. As long as you're ditching Dalvik's earlier use case for hybrid interpretation/JIT, a compact SSA-based format (like Michael Franz's et. al.'s SafeTSA) seems better suited as an intermediate format. In any case, pre-generating/caching the native code with profile-guided optimization seems ideal, giving you more time to perform expensive optimizations and also avoid repetitive re-compilation when nothing has changed about your usage patterns. Platform-independent binary distribution formats with profile-guided optimization seem like clear wins for most applications that aren't currently using hand-written assembly. Re-compiling every time the binary is launched seems wasteful. In some domains, there's also a compelling case to be made for making the garbage collector optional.
- deleted 4y ago
  [deleted]
chubot 4y ago
The JVM is better for these workloads than JITted runtimes for dynamic languages, but I'd still stay Go, Rust, and C++ are better -- both in a practical sense of what tool to use, and in theory (AoT compilation, static types, and language control over memory layout). It's not like people have been ignoring them on purpose. Plenty of code has been written in those languages, but the point of my post is that these pointer-rich workloads are even harder for them. Java seems to lack value types on the stack, which results in a lot of extra garbage for language processors (something I learned the hard way) (IIRC Guy Steele's famous "growing a language" talk over 20 years ago specifically advocated for value types in Java.) Speed isn't the only important dimension -- they often trade speed for memory usage and startup time, and those become issues. As well as the weight/size/complexity/deployment of the runtime (i.e. Go is managed, but there's no separate runtime to deploy or configure). Also IIRC Java bytecode is untyped, so the JIT has do a lot of work to recover the types again, which is weird. I think the JVM / CLR make a lot of sense for many server-side workloads. They haven't caught on much for tools deployed to people's desktops, I think for good reasons.
- pjmlp 4y ago
  JVM and .NET have had AOT compilation for 20 years now, even if not always available as free beer. > I think the JVM / CLR make a lot of sense for many server-side workloads. They haven't caught on much for tools deployed to people's desktops, I think for good reasons. Only if we are talking about "Linux Desktop".
- kaba0 4y ago
  > but I'd still stay Go, Rust, and C++ are better How does go fit in with the other two? I hate that it somehow considered low level, when it is closer to JS in execution semantics/performance/everything. Also, Java byte code is typed.
  - jpgvm 4y ago
    Go exists in a weird space. It's not the top performer but is respectable (as long as you don't pressure the GC too much) however it's also not very expressive. This leads to it not being favoured as a high level language because it lacks the primitives to write very concise code. On the other hand it has a big runtime and a GC so it's too high level for many true systems programming tasks. This lack of high level language features coupled with it's higher level runtime means that it finds itself occupying a space between systems languages like Rust and C++ but "lower" than Python/JS/Ruby/Kotlin/Swift/etc. Essentially it ends up competing with Java on the server and supplanting C/C++ for systemsy tools in fields it got to before Rust arrived on the scene.
    - kaba0 4y ago
      That’s a good summary. I just see it way too often bundled together with low-level languages and it benefits no one to prefer/not prefer a language based on false knowledge.
  - chubot 4y ago
    With respect to performance and semantics, it's not closer to JS -- it's a typed language that uses types for AoT compilation, like C++ and Rust. The GC is a big difference, but it's also a pretty good one from what I know. The author of esbuild is understands software performance deeply (e.g. architected Figma in the browser in C++). He tried esbuild in both Rust and Go, and preferred Go for performance. https://esbuild.github.io/faq/ https://esbuild.github.io/faq/ There are some comments about it here on HN. edit: found some: https://news.ycombinator.com/item?id=22336284 https://news.ycombinator.com/item?id=22336284 https://news.ycombinator.com/item?id=22338442 https://news.ycombinator.com/item?id=22338442 https://news.ycombinator.com/item?id=30094498 https://news.ycombinator.com/item?id=30094498

by jpgvm 4y ago

KMag 4y ago

AoT with periodic profile-based re-optimization (like the latest Dalvik / Android Runtime provide), perhaps also with dynamic re-optimization/on-stack replacement seems ideal. As long as you're ditching Dalvik's earlier use case for hybrid interpretation/JIT, a compact SSA-based format (like Michael Franz's et. al.'s SafeTSA) seems better suited as an intermediate format. In any case, pre-generating/caching the native code with profile-guided optimization seems ideal, giving you more time to perform expensive optimizations and also avoid repetitive re-compilation when nothing has changed about your usage patterns. Platform-independent binary distribution formats with profile-guided optimization seem like clear wins for most applications that aren't currently using hand-written assembly. Re-compiling every time the binary is launched seems wasteful. In some domains, there's also a compelling case to be made for making the garbage collector optional.

deleted 4y ago
[deleted]

chubot 4y ago

The JVM is better for these workloads than JITted runtimes for dynamic languages, but I'd still stay Go, Rust, and C++ are better -- both in a practical sense of what tool to use, and in theory (AoT compilation, static types, and language control over memory layout). It's not like people have been ignoring them on purpose. Plenty of code has been written in those languages, but the point of my post is that these pointer-rich workloads are even harder for them. Java seems to lack value types on the stack, which results in a lot of extra garbage for language processors (something I learned the hard way) (IIRC Guy Steele's famous "growing a language" talk over 20 years ago specifically advocated for value types in Java.) Speed isn't the only important dimension -- they often trade speed for memory usage and startup time, and those become issues. As well as the weight/size/complexity/deployment of the runtime (i.e. Go is managed, but there's no separate runtime to deploy or configure). Also IIRC Java bytecode is untyped, so the JIT has do a lot of work to recover the types again, which is weird. I think the JVM / CLR make a lot of sense for many server-side workloads. They haven't caught on much for tools deployed to people's desktops, I think for good reasons.

pjmlp 4y ago
JVM and .NET have had AOT compilation for 20 years now, even if not always available as free beer. > I think the JVM / CLR make a lot of sense for many server-side workloads. They haven't caught on much for tools deployed to people's desktops, I think for good reasons. Only if we are talking about "Linux Desktop".
kaba0 4y ago
> but I'd still stay Go, Rust, and C++ are better How does go fit in with the other two? I hate that it somehow considered low level, when it is closer to JS in execution semantics/performance/everything. Also, Java byte code is typed.
- jpgvm 4y ago
  Go exists in a weird space. It's not the top performer but is respectable (as long as you don't pressure the GC too much) however it's also not very expressive. This leads to it not being favoured as a high level language because it lacks the primitives to write very concise code. On the other hand it has a big runtime and a GC so it's too high level for many true systems programming tasks. This lack of high level language features coupled with it's higher level runtime means that it finds itself occupying a space between systems languages like Rust and C++ but "lower" than Python/JS/Ruby/Kotlin/Swift/etc. Essentially it ends up competing with Java on the server and supplanting C/C++ for systemsy tools in fields it got to before Rust arrived on the scene.
  - kaba0 4y ago
    That’s a good summary. I just see it way too often bundled together with low-level languages and it benefits no one to prefer/not prefer a language based on false knowledge.
- chubot 4y ago
  With respect to performance and semantics, it's not closer to JS -- it's a typed language that uses types for AoT compilation, like C++ and Rust. The GC is a big difference, but it's also a pretty good one from what I know. The author of esbuild is understands software performance deeply (e.g. architected Figma in the browser in C++). He tried esbuild in both Rust and Go, and preferred Go for performance. https://esbuild.github.io/faq/ https://esbuild.github.io/faq/ There are some comments about it here on HN. edit: found some: https://news.ycombinator.com/item?id=22336284 https://news.ycombinator.com/item?id=22336284 https://news.ycombinator.com/item?id=22338442 https://news.ycombinator.com/item?id=22338442 https://news.ycombinator.com/item?id=30094498 https://news.ycombinator.com/item?id=30094498