Boost logo

Boost :

Subject: Re: [boost] interest in an asynchronous linear algebra library?
From: Oswin Krause (Oswin.Krause_at_[hidden])
Date: 2015-11-22 14:18:05


Hi,
> <rant>
> Why do people fall into the trap of the NIH syndrome over and over
> again?
> *sigh*
> </rant>

This is not NIH. I am happily using all kinds of external libraries.
However, for a general purpose library, especially when targeting
something as boost I hesitate to do it without providing a reasonable
fallback implementation, especially if it is a library i can not assume
to be readily installed and available on a regular unix system.

My experience with users of my libraries is: most users just want to
play around with it and do not care about it being fast and efficient.
Thus requiring them to install a lot of external dependencies can make
them loose interest - and i do not want that
Later, when they want to try it out for real tasks they will remember
that they should install the external libraries and then they can
actually make use of it and see the improvements of it.
(I do not work together with skilled programmers, but students, they
struggle getting boost installed on their windows machines and then
getting cmake to find boost, so i really don't want to add more
hurdles!).

> Anyways, while HPX supports distributed computing, you don't have to
> use it
> for this. HPX can be used just fine for SMP style (local only)
> applications
> as well. In fact we have shown that by simply switching from
> std::async/std::future to hpx::async/hpx::future you can achieve a
> speedup
> of up to a factor of 3-4 (depending on the application).

This for example would be a reason for me to provide a default
implementation using std::future that i can exchange by the hpx::
versions using a preprocessor directive.

Btw:
is there a specific reason for that speedup? is there just less overhead
of the implementation or is it improved scheduling of tasks?

> That does not
> entail utilizing some of the more sophisticated features HPX provides
> you
> with (extending futures like proposed by the Concurrency TS, dataflow,
> parallel algorithms, task regions, GPU integration, etc.). Those
> usually
> give you an additional benefit in terms of speedup, readability, and
> maintainability.

And this would be an example where i would rather wait using the
features unless I can find ways to make everything work with some
default implementation.

Best,
Oswin


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk