6 ms·

Dynamic language, which allows anything to be changed at any time.

by seunosewa 4y ago

titzer 4y ago
It's clearly more complicated than that. JavaScript is also highly dynamic and JITs there often give 10-100x speedup.
- nicoburns 4y ago
  My impression is that Ruby is more dynamic than pretty much everything else. I think this is true in terms of language features, but also in terms of the style that code is written in practice.
  - pjmlp 4y ago
    This tends to come up, also as reason why Python has yet to have a proper JIT, yet we have Smalltalk, Common Lisp, SELF and Dylan to prove otherwise. In Smalltalk's case, it was its JIT that ended up powering Hotspot.
    - titzer 4y ago
      C2 was a clean rewrite by the Rice folks and C1 was, afaik, part of the Animorphic acquisition, which was written from scratch, though by Lars Bak and co who did indeed work on Smalltalk before. But AFAICT all they reused was the assembler.
      - pjmlp 4y ago
        Sure, I also don't mean that the code was taken 1:1, rather that there are a couple of languages that are as dynamic, with relatively good performance on dynamic compiler implementations.
  - jeffparsons 4y ago
    This matches my (day job) experience. My greatest practical frustration from this is the difficulty of trying to claw back performance when it becomes important. I'd like more ways to say "from this point on, none of X, Y, or Z will change", and get some performance guarantees in return. For example, we have some code that dynamically generates a whole lot of classes from protobuf definitions. It's bad enough that it takes nearly a minute just to load an run all that code, but even after that I'm paying the cost of assuming that any of those definitions might change at any moment. So I have awful load times, and awful runtime performance. I guess what I'm asking is: do you see a future where there is more explicit control afforded to people who want to pick their own tradeoffs without resorting to writing everything performance-sensitive in extensions written in C/Rust/whatever?
    - nicoburns 4y ago
      > do you see a future where there is more explicit control afforded to people who want to pick their own tradeoffs without resorting to writing everything performance-sensitive in extensions written in C/Rust/whatever? In Ruby: probably not. In general: yes. Julia is probably the closest we have to this today with it's gradual typing. I would like to see more of this (and I suspect we will at some point).
    - titzer 4y ago
      JSVMs will optimize top-level script variables to assumed-const and then inline said constant into accesses that are known through scope resolution to bind to those globals, deoptimizing that code if the global is ever modified. Is Ruby dynamically scoped in a way where that is infeasable?
      - peterfirefly 4y ago
        Not as far as I can tell. It is very dynamic but so is Javascript (and Self). I think the problem is different: Ruby is severely underspecified and the only way to get good enough compatibility is to piggyback on the official implementation with its interpreter, gc, libraries, C interface, build tools, package management, etc. I also think, but this is just a hypothesis, that most programs use library code implemented in C almost all the time, precisely because Ruby is so slow. That means a JIT has to reimplement lots of library code in a way that makes it JITable/inlineable and that is a lot of work + it's hard to keep it exactly compatible. It is hard to do that in a way that removes all the (probably very obvious) inefficiencies. Python has the same problem + it used to have a JIT-hostile leadership. Ruby is quite friendly towards JITs.
chlorion 4y ago
Common Lisp is also a dynamic language. In CL, classes can be redefined at runtime and the changes effect already instantiated instances! This is just an example, not the only dynamic feature of course. Common Lisp has SBCL which generates very fast AOT native code despite the dynamic nature of the language, so I am not sure that being dynamic is a great excuse for being slow.

Dynamic language, which allows anything to be changed at any time.

titzer 4y ago

It's clearly more complicated than that. JavaScript is also highly dynamic and JITs there often give 10-100x speedup.

nicoburns 4y ago
My impression is that Ruby is more dynamic than pretty much everything else. I think this is true in terms of language features, but also in terms of the style that code is written in practice.
- pjmlp 4y ago
  This tends to come up, also as reason why Python has yet to have a proper JIT, yet we have Smalltalk, Common Lisp, SELF and Dylan to prove otherwise. In Smalltalk's case, it was its JIT that ended up powering Hotspot.
  - titzer 4y ago
    C2 was a clean rewrite by the Rice folks and C1 was, afaik, part of the Animorphic acquisition, which was written from scratch, though by Lars Bak and co who did indeed work on Smalltalk before. But AFAICT all they reused was the assembler.
    - pjmlp 4y ago
      Sure, I also don't mean that the code was taken 1:1, rather that there are a couple of languages that are as dynamic, with relatively good performance on dynamic compiler implementations.
- jeffparsons 4y ago
  This matches my (day job) experience. My greatest practical frustration from this is the difficulty of trying to claw back performance when it becomes important. I'd like more ways to say "from this point on, none of X, Y, or Z will change", and get some performance guarantees in return. For example, we have some code that dynamically generates a whole lot of classes from protobuf definitions. It's bad enough that it takes nearly a minute just to load an run all that code, but even after that I'm paying the cost of assuming that any of those definitions might change at any moment. So I have awful load times, and awful runtime performance. I guess what I'm asking is: do you see a future where there is more explicit control afforded to people who want to pick their own tradeoffs without resorting to writing everything performance-sensitive in extensions written in C/Rust/whatever?
  - nicoburns 4y ago
    > do you see a future where there is more explicit control afforded to people who want to pick their own tradeoffs without resorting to writing everything performance-sensitive in extensions written in C/Rust/whatever? In Ruby: probably not. In general: yes. Julia is probably the closest we have to this today with it's gradual typing. I would like to see more of this (and I suspect we will at some point).
  - titzer 4y ago
    JSVMs will optimize top-level script variables to assumed-const and then inline said constant into accesses that are known through scope resolution to bind to those globals, deoptimizing that code if the global is ever modified. Is Ruby dynamically scoped in a way where that is infeasable?
    - peterfirefly 4y ago
      Not as far as I can tell. It is very dynamic but so is Javascript (and Self). I think the problem is different: Ruby is severely underspecified and the only way to get good enough compatibility is to piggyback on the official implementation with its interpreter, gc, libraries, C interface, build tools, package management, etc. I also think, but this is just a hypothesis, that most programs use library code implemented in C almost all the time, precisely because Ruby is so slow. That means a JIT has to reimplement lots of library code in a way that makes it JITable/inlineable and that is a lot of work + it's hard to keep it exactly compatible. It is hard to do that in a way that removes all the (probably very obvious) inefficiencies. Python has the same problem + it used to have a JIT-hostile leadership. Ruby is quite friendly towards JITs.

chlorion 4y ago

Common Lisp is also a dynamic language. In CL, classes can be redefined at runtime and the changes effect already instantiated instances! This is just an example, not the only dynamic feature of course. Common Lisp has SBCL which generates very fast AOT native code despite the dynamic nature of the language, so I am not sure that being dynamic is a great excuse for being slow.