Comments 5
Жесть…
Хм… интересно. Пришлось тут прибегнуть к Parallel Extensions и PLINQ в диссертационной работе.
Только не очень понятно, для чего увеличивать очередь вдвое каждый раз, как она заканчивается. Ведь если у нас будет очень большая исходная коллекция в конечном итоге все потоки будут иметь максимально возможную очередь на обработку. Так?
Только не очень понятно, для чего увеличивать очередь вдвое каждый раз, как она заканчивается. Ведь если у нас будет очень большая исходная коллекция в конечном итоге все потоки будут иметь максимально возможную очередь на обработку. Так?
Так, ведь при большом кол-ве элементов, они будут передаваться на обработку в последствии большими пачками, что логично, так как снижает расходы на «расфасовку».
Также хочу заметить, что в потоке выстраивается очереди, поэтому по умолчанию он старается равномерно распределить нагрузку обработки всех элементов по потокам в зависимости их текучей занятости, т.е. обработал предыдущую пачку элементов, тогда лови вторую, которая в два раза больше или равна макс.значению элементов.
Также хочу заметить, что в потоке выстраивается очереди, поэтому по умолчанию он старается равномерно распределить нагрузку обработки всех элементов по потокам в зависимости их текучей занятости, т.е. обработал предыдущую пачку элементов, тогда лови вторую, которая в два раза больше или равна макс.значению элементов.
Sign up to leave a comment.
PLINQ: распределение данных между рабочими потоками