3 ms·

Performant execution for any vector language (APL/J/K) requires amortizing the array actions. For example, summing an array should invoke an action in the VM th

Performant execution for any vector language (APL/J/K) requires amortizing the array actions. For example, summing an array should invoke an action in the VM that adds together all of the elements of the array with only a single type look-up. I am skeptical of targeting an array language to a VM that requires a type check on every element of the array. Numpy handles this by performing all its actions in a C library independently of the CPython VM.

jashmatthews 9y ago
Would it be so hard to unbox homogenous arrays for BEAM? I know at least V8 does it for arrays of doubles.
geocar 9y ago
> I am skeptical of targeting an array language to a VM that requires a type check on every element of the array. Numpy handles this by performing all its actions in a C library independently of the CPython VM. If arrays are implemented as binaries then you should be fine. > For example, summing an array should invoke an action in the VM that adds together all of the elements of the array with only a single type look-up. Erlang makes it easy to add NIF when you want sum to be a little bit faster. I think this is the last problem anyone needs to solve though, the elegance of array-language solutions is far more important than their performance. That they're also performant is how we know all other languages are wrong :)
- equalunique 9y ago
  Would be interesting to hear what kinds of BEAM-specific concepts would be important for a well-designed implementation. I was curious to learn more about what a "NIF" is and this was helpful towards understanding: http://erlang.org/doc/tutorial/nif.html http://erlang.org/doc/tutorial/nif.html Also I found this which shows there are many examples where NIFs extend what Erlang can do: http://beam-wisdoms.clau.se/en/latest/interfacing.html http://beam-wisdoms.clau.se/en/latest/interfacing.html
derefr 9y ago
I believe that HiPE-compiled BEAM code already has the type-checks lifted up to the earliest point in the module it can manage. The resultant code would still do an initial type-check on each element of the input list (in order to, essentially, prove that the thing you were handed is a homogenous array), but then all the transformations of that list would carry through the homogenous-ness if possible (which it isn't always, if you're allowing custom mapping functions, because there's no way to require that a fun has a particular return type. Otherwise, though, I believe it "just works.")

jashmatthews 9y ago

Would it be so hard to unbox homogenous arrays for BEAM? I know at least V8 does it for arrays of doubles.

geocar 9y ago

> I am skeptical of targeting an array language to a VM that requires a type check on every element of the array. Numpy handles this by performing all its actions in a C library independently of the CPython VM. If arrays are implemented as binaries then you should be fine. > For example, summing an array should invoke an action in the VM that adds together all of the elements of the array with only a single type look-up. Erlang makes it easy to add NIF when you want sum to be a little bit faster. I think this is the last problem anyone needs to solve though, the elegance of array-language solutions is far more important than their performance. That they're also performant is how we know all other languages are wrong :)

equalunique 9y ago
Would be interesting to hear what kinds of BEAM-specific concepts would be important for a well-designed implementation. I was curious to learn more about what a "NIF" is and this was helpful towards understanding: http://erlang.org/doc/tutorial/nif.html http://erlang.org/doc/tutorial/nif.html Also I found this which shows there are many examples where NIFs extend what Erlang can do: http://beam-wisdoms.clau.se/en/latest/interfacing.html http://beam-wisdoms.clau.se/en/latest/interfacing.html

derefr 9y ago

I believe that HiPE-compiled BEAM code already has the type-checks lifted up to the earliest point in the module it can manage. The resultant code would still do an initial type-check on each element of the input list (in order to, essentially, prove that the thing you were handed is a homogenous array), but then all the transformations of that list would carry through the homogenous-ness if possible (which it isn't always, if you're allowing custom mapping functions, because there's no way to require that a fun has a particular return type. Otherwise, though, I believe it "just works.")