[PATCH] D148728: [Support][Parallel] Add sequential mode to TaskGroup::spawn().

Alexey Lapshin via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Sat Apr 22 12:35:42 PDT 2023


avl added inline comments.


================
Comment at: llvm/lib/Support/Parallel.cpp:16
 #include <future>
-#include <stack>
+#include <queue>
 #include <thread>
----------------
avl wrote:
> andrewng wrote:
> > Unfortunately, at least in my testing on Windows, this change causes a drop in performance of around 3-4%. I believe that's why `std::stack` is used.
> > Unfortunately, at least in my testing on Windows, this change causes a drop in performance of around 3-4%. I believe that's why `std::stack` is used.
> 
> will check it.
>Unfortunately, at least in my testing on Windows, this change causes a drop in performance of around 3-4%. I believe that's why std::stack is used.

yes, there is small performance degradation in case std::queue is used instead of std::stack.
But, to have it noticeable, there should be created very large amount of tasks.
For the 100000000 tasks the std::queue works 8sec slower:

```

llvm::parallel::TaskGroup tg;
for (size_t Idx = 0; Idx < 100000000; Idx++) {
  tg.spawn([](){});
}

                        Time(sec)  Memory(kB)

queue TaskGroup          121.28    441568

stack TaskGroup          113.61    471820
```

Generally, it is a bad idea to create such amount of tasks.
parallelFor has optimization to not create a lot of tasks.
There is no any performance difference if parallelFor is used:

```

parallelFor(0,100000000,[](size_t){});

                        Time(sec)  Memory(kB)

queue parallelFor          0.03    9128

stack parallelFor          0.03    9128
```

So, probably using std::queue is OK.

Or, Dou you have a test case when using queue still bad idea?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D148728/new/

https://reviews.llvm.org/D148728



More information about the llvm-commits mailing list