On 6 Jul 2014 at 5:20, Gottlob Frege wrote:
Niall, is your non-allocating future promise going to borrow from my C++Now
slides, or are you trying a different direction?
You proposed a non-allocating future promise at C++ Now???
I just rechecked your slides and I see nothing related? Can you
supply me some detail?
The direction I was going to take was to extend proposed
std::experimental::optional as the value store which would also
allow Vicente's monadic framework to interop seamlessly with future
promise. The promise and future would be tied together with two
atomically updated pointers. As much as it is very straightforward,
what has diverted me is that my attempt used memory transactions (I
tried both __transaction_atomic and Intel TSX) and their performance
greatly surprised me, as I think it probably did to the other devs on
Boost.Thread who I CC-ied privately.
I then resolved to learn a feel for memory transactions as I clearly
didn't have the experience, so for the past two weeks I have been
implementing a concurrent_unordered_map based on memory
transactions. My first attempt was a simple forward linked list which
worked well up until the load factor went past about four, at which
point performance collapsed. So the current attempt is based on a
table design where if the transaction is unavailable, it uses the
bottom bit of the pointer to the value as a fallback spinlock as is
required by Intel TSX.
Debugging it has been slow going, not helped by this sort of work
being hard to mentally gear into after a day of work plus Clara had
her vaccinations this past week, which hasn't made for much sleep.
I'll get there eventually and probably find the traditional split
order list method of implementing concurrent_unordered_map is far
faster :( (though, to be honest, I cannot currently see how that
would be possible as split order lists are not as cache friendly as
what I am doing).
Niall
--
ned Productions Limited Consulting
http://www.nedproductions.biz/
http://ie.linkedin.com/in/nialldouglas/
