This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
| Other format: | [Raw text] | |
Sure, but then I'm back to managing my own thread pool, which I thought that <future> tried to avoid. I should rephrase that question: is it possible *for std::async* to make a more intelligent decision? On 14-03-17 10:57, Periklis Tsirakidis wrote: > Ko Stoffelen <k.stoffelen@cs.ru.nl> writes: > >> Hi, >> >> I have a bunch of tasks that I'd like to execute in parallel as fast as >> possible. I'm using std::async for this purpose, without a launch >> policy, which is then std::launch::async | std::launch::deferred by >> default. Now if I understand correctly, the C++ standard leaves it to >> the implementation how it should handle this launch policy. libstdc++ >> always first tries to create a new thread and only if that raises an >> exception, the task is deferred. >> >> https://gcc.gnu.org/onlinedocs/gcc-6.1.0/libstdc++/api/a01298_source.html#l01716 >> >> In practice, this could imply that I'm running >100 threads on 4 cores >> and the OS is only switching tasks all the time, actually delaying the >> computation. Is it possible to make a more intelligent decision at >> runtime, based on, e.g., the number of cores or the current CPU load? >> >> Thanks, >> >> Ko >> > You could, ask std::thread::hardware_concurrency() before selecting a > policy. For cpu load you need some library to ask for it, i think. > > jm2c,
Attachment:
signature.asc
Description: OpenPGP digital signature
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |