Boost logo

Boost :

Subject: Re: [boost] [next gen future-promise] What to call the monadic return type?
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-05-30 08:35:42

On 30 May 2015 at 0:19, Thomas Heller wrote:

> However, what is proposed in this thread is hardly usable in
> any context where concurrent operations may occur. What you missed is the
> message that it is not memory allocation or the existance of exception
> handling code that makes the futures "slow". In fact what makes futures
> slow is the mechanism to start asynchronous tasks (If you have the finest
> task granularity you can imagine).

And that has nothing to do with futures per se.

Your claim (and that of those involved with HPX) is that optimising
futures beyond what HPX has done is pointless because you found no
cost benefit [relative to how the rest of HPX is implemented]. Which
is fine, for HPX, but in your C++ Now presentation as soon as you
said your futures were always using jemalloc I instantly knew you had
just undermined all your claims about your design of futures. Only
FreeBSD has jemalloc as its system allocator. Generic C++ code,
especially library code, can make zero assumptions about dynamic
memory allocation except that it can be catastrophically slow. I
mentally budget about 1000 cycles for any malloc or free call,
overkill but not wrong on a low end ARM CPU.

The part in the square brackets is unstated by you and your
colleagues, and you and your colleagues have a nasty habit of
assuming that HPX is the end all and be all of perfect design, and
therefore the part in brackets need not be stated because it is now
some absolute truth. You then proceed to make sweeping assumptions
that all other work on futures is futile as if the case were closed,
and that we are not listening to you "the experts", and that
therefore discussion or even thought that you are not perfectly
correct in the general design is verging on blasphemy.

But let me put this to you from a Boost community perspective:

1. Why haven't any of HPX's design choices been peer reviewed here?

2. Why isn't HPX being contributed to Boost, or the parts of HPX
where it would be sensible to do so? Why do HPX authors repeatedly
keep the new and often very useful libraries they write away from
Boost? Even the non-HPX libraries?

3. Why do those working on HPX not contribute to the Boost community
in general as they once used to in the past? Where are the reviews of
libraries? Where are the pull requests fixing bugs? What mentoring of
GSoC projects has been done in the last three years?

What gives you, or any of your colleagues, the right to lecture
people here about design imprimatur when none of your designs nor
code have passed peer review here, and the last time I can see any of
you contributed substantially to the community here was late 2012? If
you or your colleagues were the active maintainer of the definitive
Boost library implementing these then your lecturing would be taken
very seriously. But all your work is occurring in an ivory tower very
far removed from peer review here, and the fact you as a group are
not engaging with the processes nor community here substantially
weakens your authority.

Nobody is undervaluing the depth of experience and the talent in the
HPX team, nor you as a group's previous very substantial
contributions to Boost and indeed the C++ standard. I for one have a
huge respect for all of you, though as a group you make it hard
sometimes. Your attitude as a group of people, well it stinks, and
the bad attitude was noticed at C++ Now by a number of people. If as
a group you did more positive contributing to the Boost community and
less negative hectoring, especially in private conversations when the
person you are beating down is not there, we'd all get along much

> What's stupid is the assumption that your task decomposition has to go down
> to a single instruction on a single data elemtn.

Sigh. It's like talking to a brick wall sometimes. You appear to be
actively refusing to change your preheld convictions that whatever I
am doing I must be wrong. This is despite at least six people
contributing positive ideas and feedback to this thread, at least
three of whom have written and shown the community code implementing
those new ideas.

For the record, it's not about task decomposition, nor was it ever.
It's about affording the maximum possible scope to the compiler's
optimiser by not using design patterns which get in the way. That's
why turning thousands of lines of code into a single mov $5, %eax
instruction is important, because that's a unit testable proxy for
the right design. I am the first to realise that in 95% of the use
cases the compiler can't do such dramatic reductions, but to discount
such optimiser friendly design out of hand as being automatically not
worth the effort seems churlish.


ned Productions Limited Consulting

Boost list run by bdawes at, gregod at, cpdaniel at, john at