Re: Unboxed mutable variables (was: Easiest way to extend CAS (casMutVar#) to boxed/unboxed Vector elements?)
On 12/01/2012 17:55, Johan Tibell wrote: On Thu, Jan 12, 2012 at 12:54 AM, Simon Marlowmarlo...@gmail.com wrote: For boxed arrays you need a PrimOp of course (like catMutVar#). For unboxed arrays you could get away with FFI, but a PrimOp would be better because it could be inline. But to get it inline would mean modifying the native and LLVM backends to support CAS operations. If I were you I would use FFI for now. The cost of the out-of-line call is much less than the cost of the CAS anyway. A gcc dependency is not a big deal, it's available on all Unix-like platforms and I don't see us removing it from the Windows installs any time soon. In a recent project (http://hackage.haskell.org/package/ekg) I found myself wanting unboxed mutable integers with CAS semantics (to implement simple counters). What would be required to support (1) unboxed mutable variables, and (2) CAS semantics for these. I guess (2) is easy once you have (1). Just add some new primops. I think by (1) you mean mutable variables containing unboxed values, right? I normally use an unboxed array of length 1 for these. There's not much overhead - only an extra word in the heap compared to implementing them natively. I'm guessing you care more about the overhead of the operations than the space overhead of the counter itself, and a 1-element unboxed array should be just fine in that respect. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Unboxed mutable variables (was: Easiest way to extend CAS (casMutVar#) to boxed/unboxed Vector elements?)
On Thu, Jan 12, 2012 at 10:25 AM, Simon Marlow marlo...@gmail.com wrote: I think by (1) you mean mutable variables containing unboxed values, right? Yes. I normally use an unboxed array of length 1 for these. There's not much overhead - only an extra word in the heap compared to implementing them natively. I'm guessing you care more about the overhead of the operations than the space overhead of the counter itself, and a 1-element unboxed array should be just fine in that respect. I will run some benchmarks. If it turns out that using an unboxed array is costly, what would it take to get real mutable variables containing unboxed values? -- Johan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Unboxed mutable variables
On 12/01/2012 18:37, Johan Tibell wrote: On Thu, Jan 12, 2012 at 10:25 AM, Simon Marlowmarlo...@gmail.com wrote: I think by (1) you mean mutable variables containing unboxed values, right? Yes. I normally use an unboxed array of length 1 for these. There's not much overhead - only an extra word in the heap compared to implementing them natively. I'm guessing you care more about the overhead of the operations than the space overhead of the counter itself, and a 1-element unboxed array should be just fine in that respect. I will run some benchmarks. If it turns out that using an unboxed array is costly, what would it take to get real mutable variables containing unboxed values? It'd need a new heap object type, which is fairly invasive (lots of RTS changes). Not prohibitive, but more invasive than adding a primop for example. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
