[Caml-list] RFC: get/set vs get/ref

[William Chesters <williamc@paneris.org>]

John Max Skaller writes:
 > The difference is exemplified by the following techniques
 > for incrementing a character:
 > 
 > 	s.set ((s.get(pos) + 1),pos)  // get/set method
 > 	s.ref(pos).++                 // ref method
 > 
 > Clearly, ref methods are more powerful and more efficient,
 > but on the other hand they expose the underlying implementation
 > and prevent hooking changes to the mutable state.

I was a little disappointed that while ocaml compiles the "bare"
increment case right,

    a.(i) <- a.(i) + 1   =>   addl $2, -2(%eax, %ebx, 2)

it doesn't do such a good job on 

    let set s i y = s.a.(i) <- y and get s i = s.a.(i)
    in
    fun s i -> set s i ((get s i) + 1)

      =>

      movl    (%eax), %ecx
      movl    -2(%ecx, %ebx, 2), %ecx
      addl    $2, %ecx
      movl    (%eax), %eax
      movl    %ecx, -2(%eax, %ebx, 2)

apparently because of the lack of common subexpression elimination
(the CS here being `s.a').  The argument against CSE seems to be that
it doesn't do anything the programmer can't do for themselves,
probably with a net gain in readability, if they really care.  But
I have seen several examples like Max's where it would actually help
in reducing the cost of crossing an abstraction barriers.

(By the way, KAI's famous optimising C++ actually INTRODUCES common
subexpressions and leaves them for the platform C backend to
eliminate!  If you define a variable using a const expression and
never modify it, it goes through substituting the expression wherever
the variable appears.  The idea I suppose is to create opportunities
for constant folding etc.  But it is extremely frustrating with gcc,
which doesn't always do the expected CSE completely---there is
absolutely no way to work around it short of introducing a spurious
global reference to the variable.  This is an example of over-complex
and unpredictable optimisation making trouble for the programmer.

Nevertheless I do think a little more support in ocaml for cost-free
abstractions would be a win.)

-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr