search for: parallel_for_each

Hello all, Last year I submitted a bug regarding the use of 'parallel_for_each' and Windows Concurrency Library. We have found that when compiling in Visual Studio 2015 and 2017 with /MTd, the use of 'concurrency::parallel_for_each' can cause unhandled exceptions when the program is exiting. https://bugs.llvm.org/show_bug.cgi?id=34976 After having some difficult...

...we just delete the ifdefs? We could in theory disable it just for debug builds, but that could create some hard to reproduce bugs. Cheers, Rafael Owen Reynolds via llvm-dev <llvm-dev at lists.llvm.org> writes: > Hello all, > > Last year I submitted a bug regarding the use of 'parallel_for_each' and > Windows Concurrency Library. We have found that when compiling in Visual > Studio 2015 and 2017 with /MTd, the use of 'concurrency::parallel_for_each' > can cause unhandled exceptions when the program is exiting. > > https://bugs.llvm.org/show_bug.cgi?id=34976 >...

...sing more threads. - We shouldn't do "too clever" things with threads. Currently, we are using multi-threads only at two places where they are highly parallelizable by nature (namely, copying and applying relocations for each input section, and computing build-id hash). We are using parallel_for_each, and that is very simple and easy to understand. I believe this was a right design choice, and I don't think we want to have something like workqueues/tasks in GNU gold, for example. - Run benchmarks with --no-threads if you are not focusing on multi-thread performance. -------------- next pa...

...nt-middle COUNT Number of threads to use in middle pass --thread-count-final COUNT Number of threads to use in final pass I don't think we need the full generality/flexibility of initial/middle/final, but --thread-count could be useful (at least for experimenting). The current interface of `parallel_for_each` doesn't allow to specify the number of threads to be run, so, assuming lld goes that route (it may not), that should be extended accordingly. -- Davide "There are no solved problems; there are only problems that are more or less solved" -- Henri Poincare

...middle pass >> --thread-count-final COUNT Number of threads to use in final pass >> >> I don't think we need the full generality/flexibility of >> initial/middle/final, but --thread-count could be useful (at least for >> experimenting). The current interface of `parallel_for_each` doesn't >> allow to specify the number of threads to be run, so, assuming lld >> goes that route (it may not), that should be extended accordingly. > > > I agree that these options would be useful for testing, but I'm reluctant to > expose them as user options becau...

...houldn't do "too clever" things with threads. Currently, we are >> using multi-threads only at two places where they are highly parallelizable >> by nature (namely, copying and applying relocations for each input section, >> and computing build-id hash). We are using parallel_for_each, and that is >> very simple and easy to understand. I believe this was a right design >> choice, and I don't think we want to have something like workqueues/tasks in >> GNU gold, for example. > > > Sorry for the late response. > > Copying and applying relocation...

On Sat, Mar 14, 2015 at 2:52 AM, Nick Kledzik <kledzik at apple.com> wrote: > Rui, > > Thanks for this write up and the work you are doing to improve performance. > A couple of thoughts: > > * In the old days, linking was I/O bound so the linker run tended to be the > same speed as cat’ing all the input files together. Now that spinning disks > are less common, I/O

On Thu, Nov 17, 2016 at 9:50 AM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > On Nov 17, 2016, at 9:41 AM, Rui Ueyama via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > On Thu, Nov 17, 2016 at 6:12 AM, Teresa Johnson via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> >> >> On Thu, Nov 17, 2016 at 4:11 AM, Rafael Espíndola