10 ms·

What, "Runtime Performance Of C/C++ Or Faster" ? Obviously they can't rival the speed of "C/C++" so they're probably going to go with "Faster", which isn't a re

What, "Runtime Performance Of C/C++ Or Faster" ? Obviously they can't rival the speed of "C/C++" so they're probably going to go with "Faster", which isn't a real language so it's going to be easy to beat.

koolba 8y ago
I’m not familiar with the details but I’d wager they’re referring to JIT compilation which can exceed precompiled native code as it can (in theory) account for actual usage patterns.
- jerf 8y ago
  That was a fun theory 15-20 years ago. We've now got piles of evidence it doesn't work that way. JITs can accelerate slow languages, at a stiff RAM penalty, but they still remain noticeably slower than faster languages. Claims to the contrary at this point will require concrete demonstration. Starting from the union of Perl 5 and Perl 6 is just about the worst starting point for that goal I can imagine. (Not necessarily because "Perl sucks", but because any such solution to that problem is probably going to require writing the language with that goal from day 1, not taking existing languages as a given. Or, like LuaJIT, cutting things that don't fit. And between Perl 5 and Perl 6, there are sooooo many "things"....)
  - hyperpape 8y ago
    I'm with you about the overall point that Perl5/6 are not going to get C/C++ speed. However, on the specific point, why do you think the JIT forces high memory usage? In the case of Java, my perception is that it's the pervasive use of boxed types everywhere and a standard library that's past its sell-by-date that drives bloated memory usage. Maybe my sense of things is a little skewed by my work: I work on server processes that use gigs of memory. There, the resources for the JVM/JIT itself usually use vastly less memory than the java objects contained in the heap (probably 10x, and this is for a monolith with thousands of classes).
    - richardwhiuk 8y ago
      It's the pervasive requirement of a dynamically typed language, not the JIT per say.
      - snapdangle 8y ago
        And yet Perl 6 has been droppping their performance floor by enormous factors, with a lot of room for improvement still. Everyone always shrugged at me when I explained that Perl 6 was designed to be able to be fast, with the ability to outstrip Perl and even other languages. And now that it's happening? They are still shrugging, but its the uncomfortable shrug of someone trying to shake off an inconvenient truth.
        village-idiot 8y ago
        A lot of them are probably shrugging because they have 0 interest in Perl, and you telling them more about Perl is not going to change their mind. I personally could not care less about Perl 6’s speed, I will never use it anyways.
        jerf 8y ago
        "And yet Perl 6 has been droppping their performance floor by enormous factors, with a lot of room for improvement still." Considering the literally-unusable performance that Perl 6 has had within fairly recent memory, getting a lot faster hasn't been that impressive. Plus, goals aren't results. I'll believe Perl 6 is natively fast when somebody actually shows it outcompeting, say, Rust, on some non-trivial task, written in the native idiom. No fair just sitting there in a loop and adding integers, which is easy-mode for a JIT. Show me a real program, that I didn't have to write in a magical subset of Perl 6 to get the performance (a problem Javascript has, "fast JIT'ed Javascript" is a mysterious and ever-changing subset, where your performance can be tanked at any moment by the smallest of changes), and don't tell me about how it's a 100x faster than last year, show me how it's faster than Rust now. Or, heck, just show me beating Go. I'll believe when I see it. And I will believe it when I see it. I have no problem with that. But I've seen the whole "as good as or better than C" claims a lot over the years, and the people making those claims are batting nearly 0.000. (Rust is pretty much the only language with a chance.) You seem to believe in the existence of a bunch of people who have somehow wrapped their identity around hating Perl 6. That's not it; what you're seeing is that the Perl 6 community burned through their goodwill literally years ago, and now people are just exasperated when the topic comes up. If it helps you to identify as some sort of persecuted minority, hey, go nuts [1], it's a very popular option nowadays, but the Perl 6 community is years past the point where mocking the potential customers into trying it is going to do any good. You're going to need hard evidence... really, really hard evidence, probably rather a lot of it, more than you'll probably think is fair but such is the hole the Perl 6 community has dug itself into over the years... to convince people, not mockery. [1]: Actually I think it's a terrible and very unhealthy idea; you'll find none of the collected ancient wisdom of humanity will tell you that constantly nursing a persecution complex is the way to wisdom or happiness. But such is the zeitgeist of the era.
  - koolba 8y ago
    I didn’t mean to say I think it’s possible in this particular case for arbitrary code (particular for something as wild as Perl!). I was merely explaining (what I think) is the logic behind the approach. The only circumstance I can see where a true JIT will beat out native code is when there are many possible paths of execution such that all may not be possible to evaluate at compile time. In that case it’s not even really interpreted vs compiled so much as static vs adaptive.
  - FridgeSeal 8y ago
    > JITs can accelerate slow languages, at a stiff RAM penalty, but they still remain noticeably slower than faster languages. The Julia language would like a word. It compiles to native machine code via LLVM, which is the same backend that a lot of statically typed languages use, and bar it's very first run, it can run blindingly fast: I've been using it instead of Python at work for Data Science things and it's been great.
    - kibwen 8y ago
      As I understand it, Julia's current implementation is not a JIT in any comparable sense to the JVM. Julia's JIT does not use any runtime information to optimize code; it's literally just statically compiling each function on-demand as they are encountered. You would get equivalent runtime performance by having a separate up-front compiler step, as C has. And actually, this sort of implies that Julia doesn't do inlining, the mother of all optimizations, which would mean that you'd be sacrificing quite a lot of runtime performance compared to an up-front compiled implementation. https://discourse.julialang.org/t/notes-on-the-julia-compiler-jit-vs-static/4275 https://discourse.julialang.org/t/notes-on-the-julia-compile...
      - byt143 8y ago
        Actually Julia is aggressively inlined because it's easy to statically determine function calls at compile time...that's why the libraries are able to use such nice abstractions. It's already ahead of time compilable, just needs some work to emit smaller binaries and cover some corner cases
        kibwen 8y ago
        Good to know, thanks.
      - jashmatthews 8y ago
        > As I understand it, Julia's current implementation is not a JIT in any comparable sense Going straight to machine code via baseline compilation is a common JIT technique. Until a couple of years ago, V8 compiled everything.
- gnulinux 8y ago
  This is said every single time when "JIT" is mentioned but I've never heard an argument how that might be possible. For all I know you'll have two problems (1) your heuristic should be so damn fast that it compensates for the runtime analysis time, this is non-trivial for JIT but trivial for AoT since runtime analysis cost is 0 (2) you need to tell us a story about how can this heuristic be so specialized that I cannot write my program, profile it on some training data (bunch of program inputs), profile and optimize (gcc and llvm can do this trivially). I never saw any code solving (1) or (2). Do we have any evidence JIT being faster than AoT? No, I see no such evidence. Even the most cutting edge JIT compilers like LuaJIT or JVM are lightyears behind gcc, llvm, rustc etc... Do we have any evidence we can perform more optimizations at runtime compared to compile-time, no I don't see any evidence. JIT was a nice, powerful, avant-garde idea that could change everything, but I don't think it turned out to be the superstar we all thought it'd be.
  - chrisseaton 8y ago
    A JIT can do all the optimisations that a static compiler can, and then of top of that it can do additional optimisations that a static compiler can't.
    - marcosdumay 8y ago
      > A JIT can do all the optimisations that a static compiler can As long as it has <100ms of compilation time.
      - chrisseaton 8y ago
        Why do all JITs need to run in <100ms? If you run your trading app once a day, all day, and warm it up for an hour first, and want max speed, why do you care if it takes a few seconds to compile?
        bquinlan 8y ago
        If that is the scenario that you care about, then you can use profile guided optimization in statically compiled languages. Clang has instructions on how to do so here: https://clang.llvm.org/docs/UsersManual.html#profile-guided-optimization https://clang.llvm.org/docs/UsersManual.html#profile-guided-...
- ComputerGuru 8y ago
  LuaJit comes close to pulling this off in some cases (and does in a select few), but obviously not across the board in general use.

koolba 8y ago

I’m not familiar with the details but I’d wager they’re referring to JIT compilation which can exceed precompiled native code as it can (in theory) account for actual usage patterns.

jerf 8y ago
That was a fun theory 15-20 years ago. We've now got piles of evidence it doesn't work that way. JITs can accelerate slow languages, at a stiff RAM penalty, but they still remain noticeably slower than faster languages. Claims to the contrary at this point will require concrete demonstration. Starting from the union of Perl 5 and Perl 6 is just about the worst starting point for that goal I can imagine. (Not necessarily because "Perl sucks", but because any such solution to that problem is probably going to require writing the language with that goal from day 1, not taking existing languages as a given. Or, like LuaJIT, cutting things that don't fit. And between Perl 5 and Perl 6, there are sooooo many "things"....)
- hyperpape 8y ago
  I'm with you about the overall point that Perl5/6 are not going to get C/C++ speed. However, on the specific point, why do you think the JIT forces high memory usage? In the case of Java, my perception is that it's the pervasive use of boxed types everywhere and a standard library that's past its sell-by-date that drives bloated memory usage. Maybe my sense of things is a little skewed by my work: I work on server processes that use gigs of memory. There, the resources for the JVM/JIT itself usually use vastly less memory than the java objects contained in the heap (probably 10x, and this is for a monolith with thousands of classes).
  - richardwhiuk 8y ago
    It's the pervasive requirement of a dynamically typed language, not the JIT per say.
    - snapdangle 8y ago
      And yet Perl 6 has been droppping their performance floor by enormous factors, with a lot of room for improvement still. Everyone always shrugged at me when I explained that Perl 6 was designed to be able to be fast, with the ability to outstrip Perl and even other languages. And now that it's happening? They are still shrugging, but its the uncomfortable shrug of someone trying to shake off an inconvenient truth.
      - village-idiot 8y ago
        A lot of them are probably shrugging because they have 0 interest in Perl, and you telling them more about Perl is not going to change their mind. I personally could not care less about Perl 6’s speed, I will never use it anyways.
      - jerf 8y ago
        "And yet Perl 6 has been droppping their performance floor by enormous factors, with a lot of room for improvement still." Considering the literally-unusable performance that Perl 6 has had within fairly recent memory, getting a lot faster hasn't been that impressive. Plus, goals aren't results. I'll believe Perl 6 is natively fast when somebody actually shows it outcompeting, say, Rust, on some non-trivial task, written in the native idiom. No fair just sitting there in a loop and adding integers, which is easy-mode for a JIT. Show me a real program, that I didn't have to write in a magical subset of Perl 6 to get the performance (a problem Javascript has, "fast JIT'ed Javascript" is a mysterious and ever-changing subset, where your performance can be tanked at any moment by the smallest of changes), and don't tell me about how it's a 100x faster than last year, show me how it's faster than Rust now. Or, heck, just show me beating Go. I'll believe when I see it. And I will believe it when I see it. I have no problem with that. But I've seen the whole "as good as or better than C" claims a lot over the years, and the people making those claims are batting nearly 0.000. (Rust is pretty much the only language with a chance.) You seem to believe in the existence of a bunch of people who have somehow wrapped their identity around hating Perl 6. That's not it; what you're seeing is that the Perl 6 community burned through their goodwill literally years ago, and now people are just exasperated when the topic comes up. If it helps you to identify as some sort of persecuted minority, hey, go nuts [1], it's a very popular option nowadays, but the Perl 6 community is years past the point where mocking the potential customers into trying it is going to do any good. You're going to need hard evidence... really, really hard evidence, probably rather a lot of it, more than you'll probably think is fair but such is the hole the Perl 6 community has dug itself into over the years... to convince people, not mockery. [1]: Actually I think it's a terrible and very unhealthy idea; you'll find none of the collected ancient wisdom of humanity will tell you that constantly nursing a persecution complex is the way to wisdom or happiness. But such is the zeitgeist of the era.
- koolba 8y ago
  I didn’t mean to say I think it’s possible in this particular case for arbitrary code (particular for something as wild as Perl!). I was merely explaining (what I think) is the logic behind the approach. The only circumstance I can see where a true JIT will beat out native code is when there are many possible paths of execution such that all may not be possible to evaluate at compile time. In that case it’s not even really interpreted vs compiled so much as static vs adaptive.
- FridgeSeal 8y ago
  > JITs can accelerate slow languages, at a stiff RAM penalty, but they still remain noticeably slower than faster languages. The Julia language would like a word. It compiles to native machine code via LLVM, which is the same backend that a lot of statically typed languages use, and bar it's very first run, it can run blindingly fast: I've been using it instead of Python at work for Data Science things and it's been great.
  - kibwen 8y ago
    As I understand it, Julia's current implementation is not a JIT in any comparable sense to the JVM. Julia's JIT does not use any runtime information to optimize code; it's literally just statically compiling each function on-demand as they are encountered. You would get equivalent runtime performance by having a separate up-front compiler step, as C has. And actually, this sort of implies that Julia doesn't do inlining, the mother of all optimizations, which would mean that you'd be sacrificing quite a lot of runtime performance compared to an up-front compiled implementation. https://discourse.julialang.org/t/notes-on-the-julia-compiler-jit-vs-static/4275 https://discourse.julialang.org/t/notes-on-the-julia-compile...
    - byt143 8y ago
      Actually Julia is aggressively inlined because it's easy to statically determine function calls at compile time...that's why the libraries are able to use such nice abstractions. It's already ahead of time compilable, just needs some work to emit smaller binaries and cover some corner cases
      - kibwen 8y ago
        Good to know, thanks.
    - jashmatthews 8y ago
      > As I understand it, Julia's current implementation is not a JIT in any comparable sense Going straight to machine code via baseline compilation is a common JIT technique. Until a couple of years ago, V8 compiled everything.
gnulinux 8y ago
This is said every single time when "JIT" is mentioned but I've never heard an argument how that might be possible. For all I know you'll have two problems (1) your heuristic should be so damn fast that it compensates for the runtime analysis time, this is non-trivial for JIT but trivial for AoT since runtime analysis cost is 0 (2) you need to tell us a story about how can this heuristic be so specialized that I cannot write my program, profile it on some training data (bunch of program inputs), profile and optimize (gcc and llvm can do this trivially). I never saw any code solving (1) or (2). Do we have any evidence JIT being faster than AoT? No, I see no such evidence. Even the most cutting edge JIT compilers like LuaJIT or JVM are lightyears behind gcc, llvm, rustc etc... Do we have any evidence we can perform more optimizations at runtime compared to compile-time, no I don't see any evidence. JIT was a nice, powerful, avant-garde idea that could change everything, but I don't think it turned out to be the superstar we all thought it'd be.
- chrisseaton 8y ago
  A JIT can do all the optimisations that a static compiler can, and then of top of that it can do additional optimisations that a static compiler can't.
  - marcosdumay 8y ago
    > A JIT can do all the optimisations that a static compiler can As long as it has <100ms of compilation time.
    - chrisseaton 8y ago
      Why do all JITs need to run in <100ms? If you run your trading app once a day, all day, and warm it up for an hour first, and want max speed, why do you care if it takes a few seconds to compile?
      - bquinlan 8y ago
        If that is the scenario that you care about, then you can use profile guided optimization in statically compiled languages. Clang has instructions on how to do so here: https://clang.llvm.org/docs/UsersManual.html#profile-guided-optimization https://clang.llvm.org/docs/UsersManual.html#profile-guided-...
ComputerGuru 8y ago
LuaJit comes close to pulling this off in some cases (and does in a select few), but obviously not across the board in general use.