Re: Easiest way to extend CAS (casMutVar#) to boxed/unboxed Vector elements?
On 10/01/2012 17:19, Ryan Newton wrote: Hello there, I was wondering what the recommendations would be for getting CAS on [mutable] vector elements? I thought that as a first step I might create an a library that does the trick only for unboxed vectors, by using bits-atomic (i.e. FFI + GCC intrinsics). Roman Leshchinskiy recommended against depending on GCC. He thought, therefore, that not only boxed arrays but unboxed ones would need an extra PrimOp to be handled properly: You can't rely on gcc extensions because code is usually compiled with the native code generator nowadays and doesn't go through gcc. The dependency on gcc will (hopefully) be dropped eventually anyway. So you'd probably also want primops for unboxed arrrays and Addr#. Any advice? 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. 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 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
