Re: [boost] Pondering Futures

Subject: Re: [boost] Pondering Futures
From: Johan Torp (johan.torp_at_[hidden])
Date: 2009-01-11 06:25:52

Mathias Gaunard-2 wrote:
> 
>> For a lot of parallelizable problems, we can never hope for any
>> particularily good programming models in a languages as C++ or with the
>> desktop operating systems we have today. Needless to say, that shouldn't
>> stop us from extracting as much parallel performance as we can from the
>> current software stack. See the first part of my thesis at
>> www.johantorp.com
>> for an in-depth discussion.
> 
> How to schedule optimally depends on the application, yes.
> Just let the user customize the scheduler behavior then.
> 

That way you get non-portable code adapted for some particular
architecture(s). Ideally you'd like code to execute well on future,
non-existing processors too.

Mathias Gaunard-2 wrote:
> 
> As for heterogeneous architectures, this is of course an open problem 
> that C++ cannot solve because you cannot predict which piece of code 
> will be faster on which processor.
> But I don't think C++-like languages are unable to do parallelization 
> well on heterogeneous architectures, even those with NUMA effects.
> 

It can be possible with knowledge of the hardware. But simply scheduling
work onto N cores will not work well when you move to manycore processor,
you'll need more complex hardware models. But knowledge about hardware
should be in the operating system and drivers, not in user level code. Both
to simplify coding and to get portable code.

But even if you aim at non-portable code, C++ is a poor at expressing
parallel code for many other reasons:
- Threads are heavy-weight and difficult to program with (dead locks, race
conditions, indeterminism, composability problems) and are very explicit.
You can build some other flow control mechanisms (lighter such as
fibers/co-routines, more implicit such as thread pools etc) but others
(transactional memory, nested data level parallelism, etc) can't be
implemented efficiently.
- C++ has a UMA shared memory model and provides reference semantics without
any sense of purity. You might need to have implicit or explicit control
over where code is stored in memory too, C++ does not provide this.
- There is no way to proactively load a cache or express that you intend to
access certain memory locations.
- You can not set up efficient data streams. As we move towards manycore and
transistors become ubiquitous, it seems probable that you'd often like to
schedule memory interconnect access rather than tasks.
- You want to do scheduling based on all processes running, not per C++
application. If all applications have their own threadpools we might get
better performance if none of them did. .NET can handle this.

Now don't get me wrong. There's no one language that is going to be good at
expressing all kinds of parallelism - we will need a lot of parallel
programming models. C++ can be used for some basic parallel code but is
poorly suited for a lot of others, especially when we go to manycore. 

Best Regards, Johan Torp
www.johantorp.com
-- 
View this message in context: http://www.nabble.com/Pondering-Futures-tp21359362p21398146.html
Sent from the Boost - Dev mailing list archive at Nabble.com.