АО
Опять же, это все если задача многопоточная. Если там обычные корутины, то можно вообще расслабиться и не думать обо всем этом.
Size: a a a
2021 January 27
A
Ну вообще да, если есть возможность обойтись без многопоточности или хотя бы без синхронизации потоков, то лучше обойтись. Отлаживать многопоточный код то еще удовольствие... Я как-то пару месяцев race condition отлавливал
АО
Я где-то видел в дискурсе, народ жаловался, что шедулер не очень хороший. То есть он в принципе ничего, но если тасков много и они сильно различаются по времени исполнения, то процессорное время может неэффективно использоваться.
АО
Это вроде бы как можно обойти, но не совсем тривиально.
VG
Мне казалось, что @async вообще не создает отдельного потока, а выполняет таску асинхронно в том же потоке, поэтому lock или atomic не нужны
АО
Хм, если мне память не изменяет, то вроде бы ThreadPools.jl это умеет делать
АО
Мне казалось, что @async вообще не создает отдельного потока, а выполняет таску асинхронно в том же потоке, поэтому lock или atomic не нужны
Стоит просто с
Async да, он просто таски запускает, но если сами таски были созданы при помощи
@macroexpand посмотреть, чтобы проверить, что этот макрос делает. Он довольно короткий.Async да, он просто таски запускает, но если сами таски были созданы при помощи
@spawn, то тогда они будут исполнятся на тех тредах, где их запускали.VG
Да, без @spawn все нормально работает:
function test_async()
x = 0
@sync begin
for num_task = 1:100
@async begin
x += 1
end
end
end
return x
end
test_async() # 100
2021 January 28
AP
Я где-то видел в дискурсе, народ жаловался, что шедулер не очень хороший. То есть он в принципе ничего, но если тасков много и они сильно различаются по времени исполнения, то процессорное время может неэффективно использоваться.
да, threadpools.jl отлично работает для неоднородных задач - постоянно пользуюсь
при надобности он может даже нарисовать, когда и какая задача на каком треде выполнялась
при надобности он может даже нарисовать, когда и какая задача на каком треде выполнялась
AP
Atomic-операции имеют достаточно узкую сферу применения: только когда нужно менять одну переменную одной из поддерживаемых операций
Обычно lock используется вместо atomic, с ним-то можно любую последовательность операций делать
При этом если lock-секция быстрая относительно остального кода, то параллельная производительность конечно никак не пострадает. Это весьма частый случай.
Обычно lock используется вместо atomic, с ним-то можно любую последовательность операций делать
При этом если lock-секция быстрая относительно остального кода, то параллельная производительность конечно никак не пострадает. Это весьма частый случай.
AP
А ещё лучше (если это возможно конечно), полностью изолировать каждый поток и только в конце делать какие-нибудь финальные агрегации. При этом, вместо переменной которая должна изменяться, передавать массив длины
nthreads и изменять значение этого массива по индексу threadidказалось бы это должно хорошо работать, но на практике увы не так
если речь про типы маленького размера, вроде чисел или небольших структур, то такой подход сильно подпортит параллельность - ключевое слово false sharing
если речь про типы маленького размера, вроде чисел или небольших структур, то такой подход сильно подпортит параллельность - ключевое слово false sharing
АО
А можно подробнее? Я этим регулярно пользуюсь и никаких проблем не испытываю.
АО
Хмм, возможно я интуитивно стараюсь этого избегать и не пользуюсь такими штуками в tight loop.
AP
да, если не в tight loop то конечно никаких проблем
АО
Обычно я на входе в цикл выдергиваю значение переменной из этого массива, после чего ее апдейчу и в конце запихиваю назад.
АО
Но опять же, надо по задаче смотреть.
ЕП
Aleksey Zhdanov
Курсы на https://www.complexityexplorer.org/ можно посмотреть что там принято моделировать.
Спасибо! Santa Fe вынлядит немного мистической конторой, но изучить интересно )
2021 January 29
