Beam VM Wisdoms (2019) • Hacker News Board

Re: Beam VM Wisdoms (2019)

#11

Post by rkangel » Wed, Apr 21, 2021, 4:40 PM UTC

hinkley wrote: post #8

I thought modern processors had enough branch prediction that threaded interpreters were no longer faster than a normal switch loop. Wonder if that also applies to aarm64

The BEAM runs on a variety of targets from your superscalar out-of-order targets like x64 down to much more embedded things. This may affect the performance tradeoffs.

Re: Beam VM Wisdoms (2019)

#12

Post by jeff-davis » Wed, Apr 21, 2021, 4:44 PM UTC

hinkley wrote: post #8

I thought modern processors had enough branch prediction that threaded interpreters were no longer faster than a normal switch loop. Wonder if that also applies to aarm64

Wouldn't the branch predictor be overwhelmed at some point?

Re: Beam VM Wisdoms (2019)

#13

Post by kvakvs » Wed, Apr 21, 2021, 5:09 PM UTC

Severian wrote: post #9

foobarbecue wrote: post #2

There sure has been some definition creep of ELI5...

I guess the first and foremost for an ELI5 is WTF is BEAM VM? The "BEAM VM ELI5" page doesn't explain what it is specifically, and how it's not a Hypervisor VM, but as a bytecode interpreter in Erlang. When I see 'VM' I think first of a hypervisor virtual machine. Maybe I'm a bit of a curmudgeon, but I'd like to think an ELI5 would at least bring in the basics. http://beam-wisdoms.clau.se/en/latest/eli5-vm.html

This is not "introducing BEAM VM" type of website. More like a reference for more reading for those who already tried Erlang or Elixir or LFE or another language running on it. So they should come with at least the initial knowledge what this is.

Source: I created this website.

Re: Beam VM Wisdoms (2019)

#14

Post by neurostimulant » Wed, Apr 21, 2021, 5:11 PM UTC

Severian wrote: post #9

foobarbecue wrote: post #2

There sure has been some definition creep of ELI5...

I guess the first and foremost for an ELI5 is WTF is BEAM VM? The "BEAM VM ELI5" page doesn't explain what it is specifically, and how it's not a Hypervisor VM, but as a bytecode interpreter in Erlang. When I see 'VM' I think first of a hypervisor virtual machine. Maybe I'm a bit of a curmudgeon, but I'd like to think an ELI5 would at least bring in the basics. http://beam-wisdoms.clau.se/en/latest/eli5-vm.html

I guess most people that uses erlang (or apps made with erlang) know what BEAM is, just like people that uses java or java apps know what JVM is, so the author doesn't feel the need to explain it anymore.

Re: Beam VM Wisdoms (2019)

#15

Post by TechBro8615 » Wed, Apr 21, 2021, 5:14 PM UTC

Severian wrote: post #9

foobarbecue wrote: post #2

There sure has been some definition creep of ELI5...

I guess the first and foremost for an ELI5 is WTF is BEAM VM? The "BEAM VM ELI5" page doesn't explain what it is specifically, and how it's not a Hypervisor VM, but as a bytecode interpreter in Erlang. When I see 'VM' I think first of a hypervisor virtual machine. Maybe I'm a bit of a curmudgeon, but I'd like to think an ELI5 would at least bring in the basics. http://beam-wisdoms.clau.se/en/latest/eli5-vm.html

I've never used Erlang, but have read up on it a few times over the years. I think a large reason why it's not more popular is that the concepts are so abstract and hard to grok, partially because -- as you mention -- there is a lot of overloading of terms from Unix land. e.g. a VM isn't a VM by the definition used in most colloquial contexts [0], a process isn't a Unix process, etc. And yet despite all this, you can run it on Unix systems. This is confusing.

There isn't really a solution to it, since it's not like Erlang can start from scratch and rename everything, but I really think this kind of cognitive overhead discourages people from learning new languages. The same challenges exist in languages like Haskell.

That said -- "devs are too lazy to read" is no reason to stop innovating. Erlang seems quite cool and I hope I get an excuse to use it in production one day.

[0] Yes, I know that Beam satisfies all the technical requirements to be a VM (https://en.wikipedia.org/wiki/Comparison_of_application_virt...) My point is more that, colloquially, people usually refer to a VM in the sense of a guest operating within a Hypervisor.

Re: Beam VM Wisdoms (2019)

#16

Post by neurostimulant » Wed, Apr 21, 2021, 5:29 PM UTC

This is quite a deep rabbit hole! Recently I decided to try learning erlang/elixir so reading about the beam vm internal is fascinating even though I barely know the language at all.

Re: Beam VM Wisdoms (2019)

#17

Post by monocasa » Wed, Apr 21, 2021, 5:47 PM UTC

TechBro8615 wrote: post #15

Severian wrote: post #9

Earlier quoted context omitted.

I guess the first and foremost for an ELI5 is WTF is BEAM VM? The "BEAM VM ELI5" page doesn't explain what it is specifically, and how it's not a Hypervisor VM, but as a bytecode interpreter in Erlang. When I see 'VM' I think first of a hypervisor virtual machine. Maybe I'm a bit of a curmudgeon, but I'd like to think an ELI5 would at least bring in the basics. http://beam-wisdoms.clau.se/en/latest/eli5-vm.html

I've never used Erlang, but have read up on it a few times over the years. I think a large reason why it's not more popular is that the concepts are so abstract and hard to grok, partially because -- as you mention -- there is a lot of overloading of terms from Unix land. e.g. a VM isn't a VM by the definition used in most colloquial contexts [0], a process isn't a Unix process, etc. And yet despite all this, you can…

> My point is more that, colloquially, people usually refer to a VM in the sense of a guest operating within a Hypervisor.

Python, Ruby, Java, and JavaScript want a word with you. Bytecode VMs being called just 'VMs' colloquially is extremely common.

Re: Beam VM Wisdoms (2019)

#18

Post by _y5hn » Wed, Apr 21, 2021, 6:08 PM UTC

klibertp wrote: post #3

foobarbecue wrote: post #2

There sure has been some definition creep of ELI5...

What 5 y.o. wouldn't understand an explanation as simple as this: > This way it is easy to jump to a location in C code which handles next opcode. Just read a void* pointer and do a goto *p. This feature is an extension to C and C++ compilers. This type of VM loop is called direct-threaded dispatch virtual machine loop. ...I guess the author works with quite smart 5 years olds, right...

I coded C++, virtual dispatch and knew what void *ptr can be used for at 10. With right incentives children can learn anything, not that it helps in a world of domination.

Re: Beam VM Wisdoms (2019)

#19

Post by TechBro8615 » Wed, Apr 21, 2021, 6:10 PM UTC

monocasa wrote: post #17

TechBro8615 wrote: post #15

Earlier quoted context omitted.

I've never used Erlang, but have read up on it a few times over the years. I think a large reason why it's not more popular is that the concepts are so abstract and hard to grok, partially because -- as you mention -- there is a lot of overloading of terms from Unix land. e.g. a VM isn't a VM by the definition used in most colloquial contexts [0], a process isn't a Unix process, etc. And yet despite all this, you can…

> My point is more that, colloquially, people usually refer to a VM in the sense of a guest operating within a Hypervisor. Python, Ruby, Java, and JavaScript want a word with you. Bytecode VMs being called just 'VMs' colloquially is extremely common.

Yeah, I mean, ultimately my argument is that devs are too lazy to understand documentation, but of course I don't consider myself one of those, so I can't defend the claim that my biased and imaginary sample of devs understands VMs in the same way as your sample.

That said, I will stand by the argument that most people (myself included) are too lazy to understand documentation.

Re: Beam VM Wisdoms (2019)

#20

Post by Joker_vD » Wed, Apr 21, 2021, 6:33 PM UTC

hinkley wrote: post #8

I thought modern processors had enough branch prediction that threaded interpreters were no longer faster than a normal switch loop. Wonder if that also applies to aarm64

They do, but a switch loop has only one indirect branch which can got to $INSTRUCTION_COUNT different places, and with direct threading there are $INSTRUCTION_COUNT branches, and different branches have separate histories.