[cpp-threads] RE: "Agenda" for august 23-25 concurrency meeting

[Howard Hinnant]

On Aug 31, 2006, at 5:26 PM, Peter Dimov wrote:

> Howard Hinnant wrote:
>> On Aug 31, 2006, at 3:36 PM, Peter Dimov wrote:
>>
>>> There's also the thread creation overhead that can easily dominate
>>> the vector<int> copy, but I'll be willing to assume for the sake of
>>> the argument that the underlying library pools the threads and the
>>> vectors are sufficienty large. :-)
>>
>> Good.  The copy of a return can be arbitrarily expensive.
>
> Maybe we ought to measure it? A pooled_executor with the "right"  
> number of threads against a bunch of thread<R>s. You get to pick  
> the vector size. :-)

Measurements are good.  Can I also pick the return type?  I'm  
thinking about a stack of dictionaries:

typedef vector<map<string, value>> Dictionaries;

:-)

(I know Peter knows this, this is for everyone else) Returning one of  
these by value from a factory function is still O(1) in C++0X  
(assuming rvalue ref acceptance).  Today it is O(v.size()*average 
(m.size()*average(s.size()))) if RVO doesn't kick in, which can  
happen easily enough, no matter how good the compiler:

Dictionaries d;
...
d = get_em();  // Guaranteed O(N^3) in C++03.
                // Guaranteed O(1) with move semantics.
                // If asynchronously called?

People could well decide they can't afford to execute something like  
this asynchronously, and wouldn't that be ironic.

(continuation of joke from the meeting...)
NeanthertalMan: future fine for rich neighbor 'cross street in  
cavominium.  My application can only afford thread <grunt><snort>. :-)

-Howard