E
Компиляторы эмитят подходящие барьеры чтобы гарантировать специфицированное языком поведение.
в любой непонятной ситуации эмить барьер
Size: a a a
2020 January 13
MS
Всегда так делаю.
AT
в любой непонятной ситуации эмить барьер
У такого гайдлайна на самом деле только 2 возможных исхода: 1) пользователи недоумевают откуда берутся неведомые баги, потому что гарантии не выполняются; 2) пользователи ноют про низкую производительность программ. 😉
E
корректность > производительность
AT
Точнее, линейная комбинация этих вариантов. 😂
AT
корректность > производительность
Так гайдлайн ни того, ни другого не гарантирует. 🤷♀️
M
Если вас интенрсует "хоть какой-то бенчмарк", то вот есть non-vendor biased, но очень старый бенчмарк от независмого деятеля — https://www.stefankrause.net/wp/?p=9 . Мы там обогнали на одном из бенчей GCC, и вровень с llvm. Но бенчмарк очень специфический и очень старый, поэтому в общем-то не о чем.
«JET 6.4 on the other hand managed to improve such that it runs even a little bit faster than GCC. This is really remarkable since JET runs with bounds checks enabled and fannkuch has quite a few indirect array access operations».
Вот это действительно чудеса, даже с bounds checks обогнал GCC на тривиальных числодробилках.
А LLVM там вообще гонялся в JIT режиме. В общем то да, очень странный бенчмарк
Но спасибо хоть за такой ответ!
Вот это действительно чудеса, даже с bounds checks обогнал GCC на тривиальных числодробилках.
А LLVM там вообще гонялся в JIT режиме. В общем то да, очень странный бенчмарк
Но спасибо хоть за такой ответ!
E
не то чтобы ллвм в джите сильно от аот отличается для числодробилок
МБ
корректность > производительность
В данном случае со всеми этими lockfree структурами, вроде же, всё наоборот. Гоняются за мифическим снижением задержек
AT
В данном случае со всеми этими lockfree структурами, вроде же, всё наоборот. Гоняются за мифическим снижением задержек
Гм, на практике, безусловно, используются "некорректные" алгоритмы, в смысле, например, алгоритмов с гонками, которые теряют некоторую часть событий, где это не критично, и прочие вероятностные и нечёткие алгоритмы, но окромя этих специальных случаев, вроде бы, никто не ставит под вопрос необходимость корректной реализации алгоритмов и структур общего назначения? В том числе и lock-free.
AT
Более того, ставят вопросы не только корректности, но и всякой там fairness и прочих тонких материй.
МБ
Более того, ставят вопросы не только корректности, но и всякой там fairness и прочих тонких материй.
Ну так это решается семафорами. А когда говорят о свободе от блокировок, то стремятся прежде всего к скорости
AT
Ну так это решается семафорами. А когда говорят о свободе от блокировок, то стремятся прежде всего к скорости
Не в ущерб корректности, тем не менее - нет?
EM
Не в ущерб корректности, тем не менее - нет?
тут вопрос в том, что значит "корректность" в контексте lock-free
AT
Evgenii Moiseenko
тут вопрос в том, что значит "корректность" в контексте lock-free
Да, вроде, то же самое, что и для "lock-full" - отсутствие гонок и дедлоков (лайвлоков). Нет?
МБ
Не в ущерб корректности, тем не менее - нет?
Ну. Ущерба никто не хочет, конечно. Но эти все алгоритмы сильно привязаны к особенностям железа: на одном CPU всё отлично, на другом лезут невоспроизводимые баги. Поэтому, к таким средствам прибегают, по моему опыту, только тогда, когда нужна именно производительность
EM
Да, вроде, то же самое, что и для "lock-full" - отсутствие гонок и дедлоков (лайвлоков). Нет?
гонки на атомарных переменных в lock-free алгоритмах это норма
AT
Evgenii Moiseenko
гонки на атомарных переменных в lock-free алгоритмах это норма
"гонки на атомарных переменных" - это не оксюморон ли? 😃
K
Я думаю имеется в виду контроль гонок
МБ
"гонки на атомарных переменных" - это не оксюморон ли? 😃
Ну. Нет. Во всех этих алгоритмах есть гонки. Иначе не выбрать победителя