Re: [boost] interest in an asynchronous linear algebra library?

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