Комментарии 9
НЛО прилетело и опубликовало эту надпись здесь
Отступ в сторону: именно поэтому лет с пять назад заставил себя читать все мануалы на английском, за пару лет подтянув уровень языка до беглого., Не хотел бы быть тем разработчиком (я не про sedot, а вообще абстрактный, без языка и руки на пульсе), который узнает все спустя год (оригинал в вордовском файле читал как раз в районе прошлой весны).
А автору спасибо за перевод :-).
А автору спасибо за перевод :-).
+1
TPL и PLINQ хороши когда у вас есть подготовленный
IEnumerable<T>
или когда механизм автопараллелизации применяется к совсем неприлично простой задаче. И уж отчно не для того чтобы выжать максимум из железа. Когда же алгоритм сложный и я испытываю потребность в PLINQ или TPL, я выбираю Intel TBB, OpenMP и ручное использование SSE.-1
Под false cache sharing, я полагаю, имелся в виду false hash sharing, т.е. ложное совпадение хэшей == совпадение хэшей для различающихся значений. Думаю, дальше пояснять детали не обязательно?
0
Да, похоже, что Вы правы. Просто мне казалось, что по крайней мере по теме программирования, если термин не гуглится, то его и не существует, в статье именно false sharing, который все считают false cache sharing. Однако если есть хэш, то, естественно, есть и коллизии. Это не добавляет информации об умысле авторов, поясните, пожалуйста детали. Или имелось ввиду просто сохранять в словарь по индексу выходные значения? Тогда 4 пункта немного не вяжутся между собой.
0
Как я себе это представляю:
Хэш-коллекцию просят найти данные по ключу A.
Вычисляется хэш ha = H(A).
В наборе хэшей ищется ha.
Обнаруживается, что с этим хэшем ассоциирован один элемент.
На всякий случай делается проверка, что ключ этого элемента совпадает с ключом A (этого можно не делать, если достоверно известно, что при поиске значений используются только те же ключи, что при наполнении коллекции).
Найденный элемент — результат поиска (если его ключ == A).
В том случае, если элементов очень много (и ключей соответственно тоже), возрастает вероятность того, что H(A) == H(P) == H(Q) ==… == H(Z). В этом случае с ha будет ассоциировано несколько элементов. Когда это обнаруживается, приходится делать перебор по этим элементам и обязательно сравнивать каждый ключ с искомым. Cравнение ключей менее эффективно, чем сравнение их хэшей.
Хэш-коллекцию просят найти данные по ключу A.
Вычисляется хэш ha = H(A).
В наборе хэшей ищется ha.
Обнаруживается, что с этим хэшем ассоциирован один элемент.
На всякий случай делается проверка, что ключ этого элемента совпадает с ключом A (этого можно не делать, если достоверно известно, что при поиске значений используются только те же ключи, что при наполнении коллекции).
Найденный элемент — результат поиска (если его ключ == A).
В том случае, если элементов очень много (и ключей соответственно тоже), возрастает вероятность того, что H(A) == H(P) == H(Q) ==… == H(Z). В этом случае с ha будет ассоциировано несколько элементов. Когда это обнаруживается, приходится делать перебор по этим элементам и обязательно сравнивать каждый ключ с искомым. Cравнение ключей менее эффективно, чем сравнение их хэшей.
0
Для PLINQ число выполняемых потоков задается строго.
Неправда. Смотрим документацию метода ParallelEnumerable.WithDegreeOfParallelism():
Degree of parallelism is the maximum number of concurrently executing tasks that will be used to process the query.
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Когда использовать Parallel.ForEach, а когда PLINQ