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