Feat: Replaced the old lockfree queue with the moodycamel ConcurrentQ…

[toxicteddy00077]

Description

Closes #7050

The staged queue in thread_queue.hpp stored task_description* as a pointer (virtue of boost::lockfree::queue requiring copyable types). Thus we are forced to have one malloc/free per normal-priority task the default path for hpx::async which can become expensive for larger task size.

In this PR, I replace the staged queue backend with the moodycamel::ConcurrentQueue (concurrentqueue_fifo), the pattern for which already exists in the thread_queue_mc.hpp

[StellarBot]

Can one of the admins verify this patch?

[hkaiser]

Are you able to compare the performance before and after your change? Is there a significant difference?

[toxicteddy00077]

@hkaiser I would say there is no extreme performance improvement , with varying speedups for different API, but mostly averaging around ~1.45. The improvements are there as you can see on the sent test output. on image left I have the 'before' performance, and on the right 'after'

[hkaiser]

@hkaiser I would say there is no extreme performance improvement , with varying speedups for different API, but mostly averaging around ~1.45. The improvements are there as you can see on the sent test output. on image left I have the 'before' performance, and on the right 'after'

Frankly, that's more than I expected. Thanks!

[hkaiser]

LGTM, thanks!

[Pansysk75]

We did have some issues in the past when using the MoodyCamel queue in the scheduler. It does not guarantee FIFO ordering for items inserted by different threads, which can create some deadlocks (at least, in some of our tests).

I'm not sure if it will be an issue here, but I thought it would be worth bringing up.

Relevant comment with more explanation:
#6428 (comment)

[hkaiser]

We did have some issues in the past when using the MoodyCamel queue in the scheduler. It does not guarantee FIFO ordering for items inserted by different threads, which can create some deadlocks (at least, in some of our tests).

I'm not sure if it will be an issue here, but I thought it would be worth bringing up.

Relevant comment with more explanation: #6428 (comment)

That might not be a problem for the queue that holds the task descriptions, those don't depend on any strict ordering.

[hkaiser]

@hkaiser I would say there is no extreme performance improvement , with varying speedups for different API, but mostly averaging around ~1.45. The improvements are there as you can see on the sent test output. on image left I have the 'before' performance, and on the right 'after'

Frankly, that's more than I expected. Thanks!

@toxicteddy00077 May I ask you to run the test more than once (100 times?) and collect the averages?

[toxicteddy00077]

@hkaiser I have distilled the output over 100 runs(see image). I am also attatching the csv files which store output per run.
improved.csv
basleline.csv

I have compared the averages as you can see below

[hkaiser]

@toxicteddy00077 Thanks for looking into this! The results are encouraging and unexpected!