caml-list - the Caml user's mailing list
 help / Atom feed
* [Caml-list] Unboxed types in Ocaml
@ 2019-10-25 17:18 Malcolm Matalka
  2019-11-03 16:03 ` SP
  0 siblings, 1 reply; 2+ messages in thread
From: Malcolm Matalka @ 2019-10-25 17:18 UTC (permalink / raw)
  To: caml-list

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

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [Caml-list] Unboxed types in Ocaml
  2019-10-25 17:18 [Caml-list] Unboxed types in Ocaml Malcolm Matalka
@ 2019-11-03 16:03 ` SP
  0 siblings, 0 replies; 2+ messages in thread
From: SP @ 2019-11-03 16:03 UTC (permalink / raw)
  To: caml-list

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?

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, back to index

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-10-25 17:18 [Caml-list] Unboxed types in Ocaml Malcolm Matalka
2019-11-03 16:03 ` SP

caml-list - the Caml user's mailing list

Archives are clonable: git clone --mirror https://inbox.ocaml.org/caml-list

AGPL code for this site: git clone https://public-inbox.org/ public-inbox