Re: [boost] [thread] Alternate future implementation and future islands.

Subject: Re: [boost] [thread] Alternate future implementation and future islands.
From: Gottlob Frege (gottlobfrege_at_[hidden])
Date: 2015-03-27 16:24:47

On Fri, Mar 20, 2015 at 5:19 AM, Giovanni Piero Deretta
<gpderetta_at_[hidden]> wrote:
> On 19 Mar 2015 19:51, "Niall Douglas" <s_sourceforge_at_[hidden]> wrote:
>>
>> On 19 Mar 2015 at 18:05, Giovanni Piero Deretta wrote:
>>
>> > > Your future still allocates memory, and is therefore costing about
>> > > 1000 CPU cycles.
>> >
>> > 1000 clock cycles seems excessive with a good malloc implementation.
>>
>> Going to main memory due to a cache line miss costs 250 clock cycles,
>> so no it isn't. Obviously slower processors spin less cycles for a
>> cache line miss.
>
> Why would a memory allocation necessarily imply a cache miss. Eh you are
> even assuming an L3 miss, that must be a poor allocator!
>
>>
>> > Anyways, the plan is to add support to a custom allocator. I do not
> think
>> > you can realistically have a non allocating future *in the general
> case* (
>> > you might optimise some cases of course).
>>
>> We disagree. They are not just feasible, but straightforward, though
>> if you try doing a composed wait on them then yes they will need to
>> be converted to shared state. Tony van Eerd did a presentation a few
>> C++ Now's ago on non-allocating futures. I did not steal his idea
>> subconsciously one little bit! :)
>>
>
> I am aware of that solution My issue with that design is that it require an
> expensive rmw for every move. Do a few moves and it will quickly dwarf the
> cost of an allocation, especially considering that an OoO will happily
> overlap computation with a cache miss, while the required membar will stall
> the pipeline in current CPUs (I'm thinking of x86 of course). That might
> change in the near future  though.
>

Just to be clear, my non-allocating promise/future was meant to be
more of a proof-of-concept, not necessarily optimal efficiency.
I would need to recheck, but I think most of it requires only acquire
or release, not full sequential consistency, if that helps.  I rarely
write anything that requires full sequential consistency.

Anyhow, carry on.  I like that there are people looking into this
stuff. Looking forward to the outcomes.

Tony