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