[Caml-list] Unboxed types in Ocaml

[Caml-list] Unboxed types in Ocaml

[Malcolm Matalka]

I just watched the following video[0] given by Stephen Dolan, and I
really enjoyed it.  I think performance is something that most anybody
can appreciate the value of and has been effected by.  I have a few
questions/thoughts:

- Given the content of the talk I don't disagree (nor feel qualified to
  disagree) with the proposed solution.  I wonder though: are the range
  of layouts so numerous to support an additional syntax?  The three
  layouts shown are value, immediate, and bit#, and tuples of them, are
  there other ones though?  Is there a clear logical extreme this has?
  Are there other types information that will cleanly fit into this way
  of expressing meta information things (maybe linear typing?)?  Also, I
  look at ATS which has a whole lot of type modifiers and seems kind of
  zany, is there anything we should keep in mind to keep Ocaml from
  going nuts with the modifiers?

- One reason I really liked this approach is because it touches on
  something that has been bothering me in high-level languages for
  awhile, and that is in order to get a high-level language to have
  certain performance characteristics you often have to do these
  incantations that are pretty related to how the optimizer works.
  Ocaml has plenty of these if one reads the Jane St doc on it.  And
  while it's nice to be able to get code to be performant, it's also
  really fragile.  The next programmer to come along in that code may
  not be aware it's structured in a particular way for performance
  reasons.  They also might need to make a change and not have the
  knowledge of how to change the code in a way that maintains those
  characteristics.  Or the compiler could change and invalidate that
  pattern.  What's great here is instead of structuring code in a way
  that you feel pretty sure the compiler will unbox the values, you tell
  the compiler and, most importantly, you get a compilation error if you
  do something wrong.  There is no ambiguity.  I know that is different
  than if one gets the performance characteristics they expect, but at
  least they know that what they intended to happen to the values
  actually happened.  This seems like a first step in moving knowledge
  that is meaningful to people about performance into the compiler, are
  there other opportunities for this in the language as well?  I think
  Ocaml already does a great job of being high-level, performant, and
  having a run-time that you can understand, so I wonder if it is well
  positioned as a language where these sort of changes could come into
  it and be impactful.

- Any idea on when this might be coming to a release near me?

/Malcolm

[0] https://www.youtube.com/watch?v=RV-4Xddk0Yc

Re: [Caml-list] Unboxed types in Ocaml

[SP]

On 25/10/2019 18:18, Malcolm Matalka wrote:
> I just watched the following video[0] given by Stephen Dolan, and I
> really enjoyed it.  I think performance is something that most anybody
> can appreciate the value of and has been effected by.  I have a few
> questions/thoughts:
> [...]
> [0] https://www.youtube.com/watch?v=RV-4Xddk0Yc

Is it worth the complexity? Might there be a simpler way of implementing this?