Виртуалки разные бывают. Если с эмуляцией команд, то да. А если команды исполняются нативно с использованием харварной виртуализации, то проблем не должно быть.
В случае этого парня мы уже разобрались. При увеличении числа потоков атомики опять уверенно побеждают. Дело в том, что Go использует самопальный мьютекс на атомиках, чтобы реже вызывать системный. Но при увеличении числа потоков больше 2х, это перестаёт работать, так как планировщик Go уже не может хитрить и строго попеременно запускать горутины, для того, чтобы не использовать системный мьютекс.
Достаточно было увеличить число потоков и атомарные операции показали себя во всей красе.
Видимо, у вас выигрыш у мьютексов получался при 2 потоках из-за того, что планировщик Go удачно давал время каждой горутине так, что они не пересекались и не вызывались системные мьютексы.
Я не призываю переписывать все мьютексы на атомарных операциях, то что я рассказал, это скорее proof-of-concept. Но при этом нужно знать об атомарных операциях и почаще их использовать — инструмент великолепный и быстрый!
Кстати, смешной момент в том, что мьютексы в Го написаны примерно также, через CompareAndSwap. С подключением системного вызова, чтобы в цикле не жарить проц.
Большинство людей даже и не знает об атомарных операциях и что они поддерживаются на уровне процессора.
Я их реально использую в коде. Они упрощают и убыстряют многие моменты параллельной работы.
У меня рабочая гипотеза, что на архитектуре Zen3 атомарные процедуры сложения работают как-то неэффективно.
Или, наоборот, на Zen3 аппаратные инструкции связанные с мьютексами как-то подтянули.
Понял. В го мьютексы пытаются сделать захват через атомарную операцию и если не удалось используют системный мьютекс. Поэтому в каких-то случаях (удачных) соревнуются 64х битные атомарные операции и 32х битные (которые в го используются для первой попытки захвата мьютекса).
А в неудачных случаях, когда мьютексы захватываются непопеременно, то атомарные операции обгоняют. Из-за подключения системного мьютекса из ОС.
Вначале Go предпринимает попытку по-быстрому захватить свой собственный мьютекс через атомарную операцию, а если не получается, то использует системный вызов runtime_SemacquireMutex, а при разблокировке runtime_Semrelease.
Кстати, работа с семафором в системном мьютексе (поле sema), делается на небезопасных указателях, для которых динамически выделяется память. А для получения нового куска памяти используются также системные вызовы.
И ещё, интересный момент, когда я написал свой мьютекс на аналогичных операциях он оказался значительно медленнее более сложного Го-мьютекса. Это трудно поддаётся объяснению. Кроме как тем, что всё-таки используется системный семафор, который хорошо интегрирован с планировщиком задач ОС.
Мой мьютекс можно попробовать улучшить ещё одним способом. Я использовал 64-х битную операцию CompareAndSwap, а в Го-мьютексе 32-х битная.
Пакет testing не подходит для этой цели. Мьютекс используют системные вызовы, думаю, testing их не считает. Лучше измерить время внутри Go через time.Now() и time.Since()
Вы тестируете в WSL. В виртуальной среде атомные команды могут исполняться неэффективно
Для такого случая я бы сделал пул воркеров, в каждый из которых отправлял бы те же интервалы, только меньшие. Частичные суммы считал бы в самих воркерах, а результирующие частичные суммы каждый воркер бы сложил атомно или через канал после того, как входной канал с интервалами будет закрыт.
В таком случае число атомных сложений (или через канал) будет равно число воркеров. И это будет дешево.
Балансировка при таком подходе тоже автоматически выполняется.
Для частичных сумм в диапазоне [nBegin, nEnd) это будет обычный инкремент суммы. Естественно, что таким образом нужно обрабатывать очень большие массивы, чтобы был выигрыш.
Я бы сделал так: сам массив разместил бы в общей памяти, а в каждую горутину передавал бы индексы начала интервала для суммирования и конца интервала для суммирования, полученные суммы участков массива сложил бы атомными сложениями, или отправил по каналу в суммирующую горутину.
То есть у меня есть пул воркеров, которые читают канал, в который приходят структуры {nBegin: int, nEnd int}. Далее каждый воркер суммирует в нужном диапазоне и отправляет результат в суммирующую горутину (или атомно складывает)
Откуда такая информация?
А разве когда-либо этот француз сидел за колючей проволокой в концлагере? Немцы же очень гуманно оккупировали Францию.
В MySql давным давно есть хранимые процедуры, а движок InnoDB - замечательный. Но Оракл уже 10 лет почти не развивает MySql.
Facebook и ВК сделаны на MySql. Были. Возможности упущены. Теперь уже нельзя рекомендовать MySql для серьёзных проектов.
Оракл купил mysql, чтобы убить её развитие. Поэтому сейчас mysql хуже postgre.
1 файл может быть фрагментирован больше, чем 3 отдельных файла.
Спасибо за ценный комментарий.
Есть где-то полный список этих HSA_OVERRIDE?
Пока нашёл частичный тут.
Под ROCm под Windows вы имеете ввиду HIP SDK?
Вы можете поддержать эту идею в свежем треде на форуме PyTorch.
А вот тред, который ведётся с 2021 года.
ЧТо такое КП?
И что значит "активность пробивается"?
Виртуалки разные бывают. Если с эмуляцией команд, то да. А если команды исполняются нативно с использованием харварной виртуализации, то проблем не должно быть.
В случае этого парня мы уже разобрались. При увеличении числа потоков атомики опять уверенно побеждают. Дело в том, что Go использует самопальный мьютекс на атомиках, чтобы реже вызывать системный. Но при увеличении числа потоков больше 2х, это перестаёт работать, так как планировщик Go уже не может хитрить и строго попеременно запускать горутины, для того, чтобы не использовать системный мьютекс.
Книжный "Республика" на Тверской работает круглосуточно. Так что это просто книжный "Москва" испортился.
Если напишите коммент на эту тему, то будет всем полезно.
Я сделал 4 плюсующих потока и 4 минусующих.
Atomic Time 4.431332195s
Sum 0
Mutex Time 47.299236939s
Sum 0
Достаточно было увеличить число потоков и атомарные операции показали себя во всей красе.
Видимо, у вас выигрыш у мьютексов получался при 2 потоках из-за того, что планировщик Go удачно давал время каждой горутине так, что они не пересекались и не вызывались системные мьютексы.
1-я цитата фальшивая. Я такого не писал.
Вот реальная цитата:
Кстати, смешной момент в том, что мьютексы в Го написаны примерно также, через CompareAndSwap. С подключением системного вызова, чтобы в цикле не жарить проц.
Большинство людей даже и не знает об атомарных операциях и что они поддерживаются на уровне процессора.
Я их реально использую в коде. Они упрощают и убыстряют многие моменты параллельной работы.
В моих случаях на голом железе атомики быстрее на:
1) AMD EPYC 7542 32-Core Processor
2) AMD Opteron 2435
У меня рабочая гипотеза, что на архитектуре Zen3 атомарные процедуры сложения работают как-то неэффективно.
Или, наоборот, на Zen3 аппаратные инструкции связанные с мьютексами как-то подтянули.
Понял. В го мьютексы пытаются сделать захват через атомарную операцию и если не удалось используют системный мьютекс. Поэтому в каких-то случаях (удачных) соревнуются 64х битные атомарные операции и 32х битные (которые в го используются для первой попытки захвата мьютекса).
А в неудачных случаях, когда мьютексы захватываются непопеременно, то атомарные операции обгоняют. Из-за подключения системного мьютекса из ОС.
Вы почти правы. Ценное замечание.
Вначале Go предпринимает попытку по-быстрому захватить свой собственный мьютекс через атомарную операцию, а если не получается, то использует системный вызов runtime_SemacquireMutex, а при разблокировке runtime_Semrelease.
Кстати, работа с семафором в системном мьютексе (поле sema), делается на небезопасных указателях, для которых динамически выделяется память. А для получения нового куска памяти используются также системные вызовы.
И ещё, интересный момент, когда я написал свой мьютекс на аналогичных операциях он оказался значительно медленнее более сложного Го-мьютекса. Это трудно поддаётся объяснению. Кроме как тем, что всё-таки используется системный семафор, который хорошо интегрирован с планировщиком задач ОС.
Мой мьютекс можно попробовать улучшить ещё одним способом. Я использовал 64-х битную операцию CompareAndSwap, а в Го-мьютексе 32-х битная.
Пакет testing не подходит для этой цели. Мьютекс используют системные вызовы, думаю, testing их не считает. Лучше измерить время внутри Go через time.Now() и time.Since()
Вы тестируете в WSL. В виртуальной среде атомные команды могут исполняться неэффективно
Для такого случая я бы сделал пул воркеров, в каждый из которых отправлял бы те же интервалы, только меньшие. Частичные суммы считал бы в самих воркерах, а результирующие частичные суммы каждый воркер бы сложил атомно или через канал после того, как входной канал с интервалами будет закрыт.
В таком случае число атомных сложений (или через канал) будет равно число воркеров. И это будет дешево.
Балансировка при таком подходе тоже автоматически выполняется.
Для частичных сумм в диапазоне [nBegin, nEnd) это будет обычный инкремент суммы. Естественно, что таким образом нужно обрабатывать очень большие массивы, чтобы был выигрыш.
Я бы сделал так: сам массив разместил бы в общей памяти, а в каждую горутину передавал бы индексы начала интервала для суммирования и конца интервала для суммирования, полученные суммы участков массива сложил бы атомными сложениями, или отправил по каналу в суммирующую горутину.
То есть у меня есть пул воркеров, которые читают канал, в который приходят структуры {nBegin: int, nEnd int}. Далее каждый воркер суммирует в нужном диапазоне и отправляет результат в суммирующую горутину (или атомно складывает)
В Го нет нормальных механизмов для того, чтобы отличать один тред от другого. Я видел какие-то хаки для этого.
Я думаю, если вы сформулируете вашу задачу без привязки к тредам, то есть более правильное решение в парадигме Го. В чём задача?