On 30/01/2014 11:40, Makarius wrote:
The puristic approach to structutal equality in SML turns out as a
benefit these days, when the system runs with loosened brakes on
multicore hardware. Neither the JVM nor OCaml could afford that (but I
think Haskell / GHC does).
The measurements I did suggested that using the relaxed consistency in
the GC did not make an appreciable difference. However, I would expect
that in the future it would help. Using an atomic test-and-set requires
a system-wide hardware lock and it seems better to do that only for
mutable data rather than when each immutable cell is copied.
I did not know about the unique status of locally generated exceptions
yet. Does the SML standard actually say anything about exception
equality? Would you recommend that as a practical approach? It seems
to be a candidate for incompatibilities between non-equal SMLs.
Type exn is not an equality type but it is possible to detect "equality"
using pattern matching.
> fun f () = let exception e in (e, fn e => true | _ => false) end;
val f = fn: unit -> exn * (exn -> bool)
> val (a, tstA) = f() and (b, tstB) = f();
val a = e: exn
val b = e: exn
val tstA = fn: exn -> bool
val tstB = fn: exn -> bool
> tstA a;
val it = true: bool
> tstA b;
val it = false: bool
> tstB a;
val it = false: bool
> tstB b;
val it = true: bool
>
Actually, I had another look at the code and it doesn't seem as though
there is any advantage in using an exception rather than a ref.
Exceptions are actually represented by refs but I had a feeling that
they might be marked as "byte references" which would have reduced the
overhead during garbage collection. Using a counter (i.e. using an
immutable int) is better still.
David
_______________________________________________
polyml mailing list
polyml@inf.ed.ac.uk
http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
