3 ms·

Elixir still runs on the Erlang VM, which is dynamically typed, so we should not expect any meaningful performance gain from typing Elixir code. This d

Elixir still runs on the Erlang VM, which is dynamically typed, so we should not expect any meaningful performance gain from typing Elixir code. This doesn't follow at all. Lots of code runs on the x64 machine which is mostly untyped and still gets performance gains from type information in the source language. The whole point of a compiler is to have different behaviour between source and target language. If the source language has a static type system that the compiler uses to control code transforms, you get performance/errors regardless of whether the target has a type system.

gnull 3y ago
> Erlang VM, which is dynamically typed > x64 machine which is mostly untyped Dynamically typed and untyped are not the same, no?
- gnull 3y ago
  Also: x86 is very much statically typed. Your types are 8-, 16-, 32- and 64-bit words. Each machine instruction knows the exact types of its operands, so there's no overhead on determining the types of values at runtime (like you'd need to do in case of dynamic typing).
  - JonChesterfield 3y ago
    It's a tangent but a good one. Machine code, at least x64/aarch64/amdgpu and the like, cannot be considered statically typed. 1/ there is no static checker 2/ if there was, the interpreter would run the failing code anyway 3/ memory can be integers, floats, machine instructions all at the same time 4/ registers overlap, e.g. writing to a 'i32' probably zeros the adjacent 32 bits in the same register 5/ instructions on the same register sometimes refer to floats and sometimes to integers It also isn't dynamically typed, though a kernel might kill the program or hardware crash on some operations. I think it's most usefully considered untyped in that there's no ahead of time verification and there's no runtime checking either.
    - gnull 3y ago
      What is "untyped" exactly? Google tells me it's the same as "dynamically typed". Remember the context. The thread started with Elang VM making it impossible to make code faster, due to the need to accommodate Erlang's dynamic typing features and do runtime checks for that. Top comment said that dynamic typing per se can't be the obstacle for programs being faster, and gave x86 as an example of a presumably dynamic VM which does not limit the speed of the programs. So "dynamically typed" from the article here meant that there's some runtime checks you can't unsubscribe from, and due to them there's a cap on how much faster you can make your code. It applies to some extent to x86, there's also checks there like segfault for example, and maybe you could save some space on silicon if you removed them and required the machine code to be verified to never cause segfaults. But I argue that this is too much of a stretch. Runtime checks that x86 performs are negligibly simple, and x86 is not a valid counter-example for the article's point. In my view the article's point is valid. > 1/ there is no static checker "return 0" is the static checker for x86 machine code. But seriously: this is not a necessary condition for something to be statically typed, it can't be. > 2/ if there was, the interpreter would run the failing code anyway Failing code does not exist. All code is valid. Haskell is undoubtedly statically typed. But division by zero will still cause a runtime error. > 3/ memory can be integers, floats, machine instructions all at the same time Ok. Disregard what I said about machine words. The only datatype in x86 is byte. Some operations use 2 bytes, some use 4. They may interpret them differently (some may see an int, some float), but it changes nothing, since both int and float operations are operations on bytes.
- JonChesterfield 3y ago
  Spent so long trying to get quote formatting on a mobile that I didn't notice I've replied to the op, not the subthread. Bad times. Whether x64 is typed or untyped feels like the start of an argument about whether xmm registers have the same type as stack memory which is kind of interesting but orthogonal to elixer. I would agree that static, dynamic and untyped are distinct things. You can compile from a source language with any type system to a target language with any type system. I think, there may be edge cases around excessively constrained languages. As an extreme example, the target machine says nothing about whether you can constant fold 1+2 into 3 in the source language, but the source language can definitely block or enable that minimal optimisation.
lolinder 3y ago
The key difference between x64 and the BEAM is that the BEAM does dynamic type checking on the fly no matter how thoroughly you type check your code ahead of time. x64 just sees bytes, so if you want to leave off type checking you can, hence the performance gains. EDIT: Also, when I go to look for this quote I can't find it. Did you somehow end up on last year's announcement of an upcoming type system for Elixir [0]? [0] https://elixir-lang.org/blog/2022/10/05/my-future-with-elixir-set-theoretic-types/ https://elixir-lang.org/blog/2022/10/05/my-future-with-elixi...
- JonChesterfield 3y ago
  People did not like that example choice. The type checking beam does can coincide with the checking the source language does but that's not fundamental. Say you compile SML to beam. Would you conclude that the compiler isn't able or allowed to do anything with the types in the source language?
  - lolinder 3y ago
    I'm not sure where you're going with that. I'm not saying that a compilation has to be 1-to-1, I'm saying that Erlang's VM will always spend cycles type checking at runtime regardless of how thorough your compiler is. And I believe that's all José is saying in the article you're quoting from.
    - JonChesterfield 3y ago
      The code the VM spends time checking is different if the source language compiler emits different code, such as if it uses type information instead of discarding it, and different code has different runtime performance.
- JonChesterfield 3y ago
  It's in a sibling post about type systems, not in the op, and I have an off by one in where I have replied to
josevalim 3y ago
Hi Jon, wrong thread but I got it. :D The Erlang VM bytecode contains the type operations in there, such as get_map_key or get_tuple_element or get_list_head. So it would still be checking the types unless we rely on a mechanism for annotating the bytecode with additional information (which they are already using for the JIT). It may be possible in the future but it is not an immediate concern at the moment.

gnull 3y ago

> Erlang VM, which is dynamically typed > x64 machine which is mostly untyped Dynamically typed and untyped are not the same, no?

gnull 3y ago
Also: x86 is very much statically typed. Your types are 8-, 16-, 32- and 64-bit words. Each machine instruction knows the exact types of its operands, so there's no overhead on determining the types of values at runtime (like you'd need to do in case of dynamic typing).
- JonChesterfield 3y ago
  It's a tangent but a good one. Machine code, at least x64/aarch64/amdgpu and the like, cannot be considered statically typed. 1/ there is no static checker 2/ if there was, the interpreter would run the failing code anyway 3/ memory can be integers, floats, machine instructions all at the same time 4/ registers overlap, e.g. writing to a 'i32' probably zeros the adjacent 32 bits in the same register 5/ instructions on the same register sometimes refer to floats and sometimes to integers It also isn't dynamically typed, though a kernel might kill the program or hardware crash on some operations. I think it's most usefully considered untyped in that there's no ahead of time verification and there's no runtime checking either.
  - gnull 3y ago
    What is "untyped" exactly? Google tells me it's the same as "dynamically typed". Remember the context. The thread started with Elang VM making it impossible to make code faster, due to the need to accommodate Erlang's dynamic typing features and do runtime checks for that. Top comment said that dynamic typing per se can't be the obstacle for programs being faster, and gave x86 as an example of a presumably dynamic VM which does not limit the speed of the programs. So "dynamically typed" from the article here meant that there's some runtime checks you can't unsubscribe from, and due to them there's a cap on how much faster you can make your code. It applies to some extent to x86, there's also checks there like segfault for example, and maybe you could save some space on silicon if you removed them and required the machine code to be verified to never cause segfaults. But I argue that this is too much of a stretch. Runtime checks that x86 performs are negligibly simple, and x86 is not a valid counter-example for the article's point. In my view the article's point is valid. > 1/ there is no static checker "return 0" is the static checker for x86 machine code. But seriously: this is not a necessary condition for something to be statically typed, it can't be. > 2/ if there was, the interpreter would run the failing code anyway Failing code does not exist. All code is valid. Haskell is undoubtedly statically typed. But division by zero will still cause a runtime error. > 3/ memory can be integers, floats, machine instructions all at the same time Ok. Disregard what I said about machine words. The only datatype in x86 is byte. Some operations use 2 bytes, some use 4. They may interpret them differently (some may see an int, some float), but it changes nothing, since both int and float operations are operations on bytes.
JonChesterfield 3y ago
Spent so long trying to get quote formatting on a mobile that I didn't notice I've replied to the op, not the subthread. Bad times. Whether x64 is typed or untyped feels like the start of an argument about whether xmm registers have the same type as stack memory which is kind of interesting but orthogonal to elixer. I would agree that static, dynamic and untyped are distinct things. You can compile from a source language with any type system to a target language with any type system. I think, there may be edge cases around excessively constrained languages. As an extreme example, the target machine says nothing about whether you can constant fold 1+2 into 3 in the source language, but the source language can definitely block or enable that minimal optimisation.

lolinder 3y ago

The key difference between x64 and the BEAM is that the BEAM does dynamic type checking on the fly no matter how thoroughly you type check your code ahead of time. x64 just sees bytes, so if you want to leave off type checking you can, hence the performance gains. EDIT: Also, when I go to look for this quote I can't find it. Did you somehow end up on last year's announcement of an upcoming type system for Elixir [0]? [0] https://elixir-lang.org/blog/2022/10/05/my-future-with-elixir-set-theoretic-types/ https://elixir-lang.org/blog/2022/10/05/my-future-with-elixi...

JonChesterfield 3y ago
People did not like that example choice. The type checking beam does can coincide with the checking the source language does but that's not fundamental. Say you compile SML to beam. Would you conclude that the compiler isn't able or allowed to do anything with the types in the source language?
- lolinder 3y ago
  I'm not sure where you're going with that. I'm not saying that a compilation has to be 1-to-1, I'm saying that Erlang's VM will always spend cycles type checking at runtime regardless of how thorough your compiler is. And I believe that's all José is saying in the article you're quoting from.
  - JonChesterfield 3y ago
    The code the VM spends time checking is different if the source language compiler emits different code, such as if it uses type information instead of discarding it, and different code has different runtime performance.
JonChesterfield 3y ago
It's in a sibling post about type systems, not in the op, and I have an off by one in where I have replied to

josevalim 3y ago

Hi Jon, wrong thread but I got it. :D The Erlang VM bytecode contains the type operations in there, such as get_map_key or get_tuple_element or get_list_head. So it would still be checking the types unless we rely on a mechanism for annotating the bytecode with additional information (which they are already using for the JIT). It may be possible in the future but it is not an immediate concern at the moment.