On Thu, Dec 15, 2005 at 02:17:18PM +0100, Sebastian Sylvan wrote:
Wouldn't there be a speedup to do both writes and waiting at the array level, BUT annotated with an index?
I strongly vote to leave STM as it is, and implement TArray as a library on top of it. STM implementation is probably already quite complex, and complicating it with some fancy treating of TArray would do no good for correctness. There's also some possibility that TArrays' special-case implementation would have some negative impact on efficiency of ordinary TVars. If could be implemented without any negative impact, like bugs, GHC team having less time for other things, then I am all for it. Anyway, I am not the one to decide.
Anyway, the main gist of my original post was that TArrays should be in the libraries, so that I can safely use it without having to send along my own implementation each time (and potentially colliding with someone else's implementation down the line).
Agreed.
When/if a primitve TArray is implemented, the Array-of-Tvars-approach could just be replaced, and all programs which use the TArray would get an automatic speed-boost.
I think that TArray efficiency is not as important as efficiency of STArrays, UArrays and IOArrays. After all, TArrays are bound to have greater overhead than ordinary arrays and you are not supposed to do heavy computations in STM. On the other hand, the more efficient STM is, the more scalable are our concurrent programs, so I may be wrong here. Best regards Tomasz -- I am searching for a programmer who is good at least in some of [Haskell, ML, C++, Linux, FreeBSD, math] for work in Warsaw, Poland