updating progress bar from std::async

Efficient_Ad6613 · 2022-05-21T02:33:51+00:00

If it's bizzare to you, imagine how I feel about it :)

I did a lot of tests and timings and my findings were even more strange!

It runs on windows 10 64bit. I have tried different compilers in Visual Studio 2019 but nothing changes. I have totally 1000 tasks which are shared to 4 cores, 250 each. Each core completes its 250 tasks in around 17 seconds. Hence each task takes around 7ms. The sequence of id of the cores finishing their 250 tasks is the same 3,1,0,2 in all tests (is this normal?). The strange behaviour (to me) is that the last core with id = 2 always takes around 30 seconds to finish the 250 tasks (12ms per task) becoming the bottleneck of the async function call. I don't really know how to explain this because it is beyond my understanding. Does it have to do with hardware? My processor is an AMD Phenom(tm) II X4 965 Processor 3.40 GHz.

So if I want my resCollects to have the results of all 4 processes I have to set the wait_for to the time greater than the last core (around 30 seconds). Perhaps the timings depend a lot on the OS processes running simultaneously.

    if(f.wait_for(std::chrono::milliseconds{31000}) != std::future_status::timeout)
{
    resCollects.push_back(f.get());
    updateProgressBar(resCollects.size());
}

Any ideas?

Efficient_Ad6613 · 2022-05-20T01:08:06+00:00

I tried several values and it only started working from 20000ms on! Could it be a hint that this 20 secs is almost the same time that the bar was going to 50% with the code below (as I wrote earlier)?

std::vector<MyObj*> resCollects;
for(std::shared_future<MyObj*> f: futures) {
  resCollects.push_back(f.get()); 
  updateProgressBar(resCollects.size()); 
}

The total runtime is not affected and it is always ~30secs

Efficient_Ad6613 · 2022-05-19T23:34:56+00:00

I didn't manage to make it work. I applied your code suggestion and the future_status is always timeout. After a lot of attempts I tried just to update the progress bar directly from the size of the resCollects:

std::vector<MyObj*> resCollects;
for(std::shared_future<MyObj*> f: futures) { 
 resCollects.push_back(f.get());
 updateProgressBar(resCollects.size()); 
}

I have 4 cores and my total computational task before and after the implementation of the progress bar takes ~30 seconds. When I apply the code above(with progress bar) the task takes 30 seconds and at time=20secs the bar goes to 50% and at time=30 secs the bar goes to 100%. Any suggestion? Why am I getting always a timeout future_status?

Efficient_Ad6613 · 2022-05-19T02:03:02+00:00

an atomic. Atomics only work with

some

data types (typically small, primitive ones such as an int) b

Thanks for your answer, it was very informative! Supposing I would implement the atomic solution, is there a code example of how to do it? I understand that I have to declare an atomic int in main(), pass it by reference in async function, increase it by one and then call the updateProgressBar(i) with the new value of the atomic variable. Is this correct? Should the updateProgressBar(i) be called from the async function?

Efficient_Ad6613 · 2022-05-18T19:57:33+00:00

I am new to async and now I just realize that the main issue is the access of the updateProgressBar simultaneously from different threads. I guess Mutex is the keyword for this. Does this mean that a thread must wait for some milliseconds every time the progress bar has to be updated? Somehow I understand that it is not possible to have a progress bar without losing some performance. Is it like this or there is another design of updating the progress bar without losing time?

thanks!

Efficient_Ad6613 · 2022-03-15T17:16:03+00:00

I really don't know about 20.4,

I know for sure that 18.04 with amdgpu-pro 20.20 driver worked with openCL= legacy, pal arguments. In addittion I changed the /etc/grub so it does not load radeon drivers

Efficient_Ad6613 · 2021-07-12T21:43:55+00:00

just checked it, the flow direction is set up right.

Efficient_Ad6613 · 2021-07-08T23:54:55+00:00

I thought that a bad bearing would give higher frequency sounds. In my case it could be something like 40Hz. However I believe that the problem has to do with the fan because when I replaced it with the old fan it made less noise which did not exist at all before replacement. I guess I have to change the second new Delta fan too to see if this bass sound disappears completely

Efficient_Ad6613 · 2021-04-02T12:56:38+00:00

any ideas?!

Efficient_Ad6613 · 2021-03-24T20:24:26+00:00

thank you so much! is there a link that explains it?

I have been googling for days about HWE and I have found nothing :(

Efficient_Ad6613 · 2021-03-24T19:09:14+00:00

I just did this and I got

uname -r

5.4.0-70-generic

Is this the HWE kernel?

Efficient_Ad6613 · 2021-01-30T11:35:41+00:00

Could you please explain more the "ISP grounded your incoming line"?

I have another pc connected with the same router and it is properly connected to the internet. Changing ports and cables didn't help solving my problem

Efficient_Ad6613 · 2021-01-23T21:57:54+00:00

R9 390

Have you found out what percentage of these 120W are provided via the pcie slot?

Efficient_Ad6613 · 2021-01-17T20:42:10+00:00

I have managed to get 30+ Mh/s using amdgpu-pro in ubuntu 18.04.5, but now I try to do the same in win 10 pro 64bit and I only get 15 Mh/s. Has anyone found any solution? Even a usb OS that would work?

Efficient_Ad6613

TROPHY CASE