Re: [Boost-users] [Test] can tests be run in parallel?

Subject: Re: [Boost-users] [Test] can tests be run in parallel?
From: Ovanes Markarian (om_boost_at_[hidden])
Date: 2011-06-10 10:32:58

On Fri, Jun 10, 2011 at 4:18 PM, Ted Byers <r.ted.byers_at_[hidden]> wrote:

> Re: " it is still possible that all tcs in this suite can be run in
> parallel. May be some sort of work stealing algorithm ", that reminds me
> of something already built by Intel in Intel's Threading Building Blocks
> library.  There is an open source version of it, but it scales well with
> increasing numbers of cores; and it is designed and implemented in such a
> way that the programmer does not need to worry about the tedious details of
> creating threads.  I have examined it only for number crunching, but I don't
> see a reason it couldn't be used in designing and implementing test suites.
> It does, though, need a slight thift in mindset relative to what you'd
> normally do in multithreaded programs or conventional numeric algorithms
> (something you can see only by actually playing with it to do trivially
> simple things fast, like matrix multiplication).  Instead, for example, of
> putting a lock around output, you'd design the program to use a class that
> collects the results of the tests, and then outputs it in a sensible order
> to some stram (standard out or a file stream).  It might be worth a look (by
> programmers smarter than me), to see if it can hep in the context of this
> discussion, and to what extent.
>

Yes, sure. I know TBB as well. They have taken the concept of work-stealing
from Cilk (but also acquired Cilk and made it to one of the product
available with Intel parallel studio). Anyway it does not matter if Intel
has it or not, because Boost can't depend on Intel's lib. First of all
licenses might be incompatible. Secondly, this lib is available on x86
compatible architectures and there is an unoficial community port for arm
available, but this lib might be hard to port as well, since it really uses
low level stuff of the platform, to avoid such things as false sharing etc.
TBB really efficiently integrates work-stealing, to combine bfs and dfs
graph traversals to optimize stack growth etc... It is not trivial to
implement such a thing in boost test. Besides that boost test would need an
own thread abstraction layer, because boost threads uses boost test for
tests ;) There was also a discussion in the list if boost test might depend
on boost threading lib.

All in all it sound as a huge amount of work ;)

Best Regards,
Ovanes