Но проблема в том, что даже если компилятор сгенерирует инструкции чтения в порядке, соответствующем коду программы, реальный порядок выполнения на процессоре может меняться в зависимости от состояния пайплайна - так что от гарантий языка толку мало. Если в приведённом примере *timer может меняться кем то ещё (неважно, другим потоком или внешним устройством) - то мы имеем data race, исправлять который надо соответствующими средствами языка и процессора.
если это две команды из двух разных точек программы? Которые исполняются в различных контекстах.
Мы тут обсуждаем два чтения внутри одного арифметического выражения без сайд эффектов (t = *timer - *timer; ). В общем случае, когда между чтениями есть ещё какой то код, переставлять конечно можно не всегда.
Мы тут о порядке соседних обращений к памяти. Он в нормальных условиях (когда это действительно память, которая возвращает то, что в последний раз было записано) значения не имеет и перестановка на результат не влияет, так что процессор может делать так, как удобнее. Для "ненормальных" условий (когда данные может менять другой поток или внешнее устройство) есть специальные команды, без них ни процессор, ник компилятор корректность не гарантируют.
ключевое слово DRF-SC
Ну да, всё правильно написано - "This model assumes that hardware has memory synchronization operations separate from ordinary memory reads and writes. Ordinary memory reads and writes may be reordered between synchronization operations, but they may not be moved across them." Нужен порядок - используйте synchronization operations.
Если инструкции декодированы и переданы в back end на одном такте, то дальше определить, какая из них первая, как вторая, можно только при явных ограничениях на порядок. В слабой модели памяти ограничений нет - кто проползёт быстрее по пайплайну, тот и пойдёт первым к контроллеру памяти (ну или какому то другому в случае MMIO), хочется порядка - расставляйте fence явно.
Динамическое предсказание нормально обработает случай, когда у нас на одних входных данных один паттерн переходов, на других - другой, и нам сегодня приходят одни данные, а завтра другие. Чем поможет компилятор - не понимаю.
-mtune влияет только на скедулинг кода, но не даёт использовать инструкции, которых может не быть на другом железе (скажем, AVX или AVX512).
Через omp simd можно векторизовать (особенно если хочется использовать GPU
OMP Offload явно отдельная тема, там кроме векторизации много нюансов ) Но и на CPU выигрыш от omp simd может быть заметный - хотя соглашусь, что это тоже тема для отдельной статьи.
так как мы занимаемся параллелизацией.
А про выставление affinity в следующей серии расскажете? Оно, конечно, на многосокетной системе важнее, но и на клиентской машинке перекидывание потока с ядра на ядро не так безобидно.
Кроме векторизации там ещё много всего есть (сходу не скажу, например, включает ли -O3 IPO/LTO, можно с -ip/ipo поиграться). И в любом случае в последнее время рекомендуется векторизовать явно через omp simd. Сталкивался с тем, что с новой версией icc автовекторизация слетала, думаю в фортране то же самое. Ну и -march всё таки стоит обоим компиляторам сказать, а то сгенерят какой нибудь древний SSE.
PS В современном gcc "Vectorization is enabled at -O2 which is now equivalent to the original -O2 -ftree-vectorize -fvect-cost-model=very-cheap" https://gcc.gnu.org/gcc-12/changes.html
В используемом автором языке (когда строки передаются в формате указатель+длина) проблем быть не должно.
А на каком языке приведённый код?
Вот за это - https://careers.yadro.com/vacancy/4724/ - дают 110? Не верю.
Спасибо, вот это уже интересно, надо почитать повнимательнее.
Но проблема в том, что даже если компилятор сгенерирует инструкции чтения в порядке, соответствующем коду программы, реальный порядок выполнения на процессоре может меняться в зависимости от состояния пайплайна - так что от гарантий языка толку мало. Если в приведённом примере *timer может меняться кем то ещё (неважно, другим потоком или внешним устройством) - то мы имеем data race, исправлять который надо соответствующими средствами языка и процессора.
Мы тут обсуждаем два чтения внутри одного арифметического выражения без сайд эффектов (t = *timer - *timer; ). В общем случае, когда между чтениями есть ещё какой то код, переставлять конечно можно не всегда.
Ну так переупорядочивание двух соседних чтений sequential consistency никак не нарушает.
Мы тут о порядке соседних обращений к памяти. Он в нормальных условиях (когда это действительно память, которая возвращает то, что в последний раз было записано) значения не имеет и перестановка на результат не влияет, так что процессор может делать так, как удобнее. Для "ненормальных" условий (когда данные может менять другой поток или внешнее устройство) есть специальные команды, без них ни процессор, ник компилятор корректность не гарантируют.
Ну да, всё правильно написано - "This model assumes that hardware has memory synchronization operations separate from ordinary memory reads and writes. Ordinary memory reads and writes may be reordered between synchronization operations, but they may not be moved across them." Нужен порядок - используйте synchronization operations.
Ссылку на соответствующий пункт в документации можно? Неформальное объяснение на https://developer.arm.com/documentation/100941/0101/The-memory-model говорит скорее об обратном.
Попробовал, ничего не ставится.
Архитектура ARM прошла мимо вас?
Если инструкции декодированы и переданы в back end на одном такте, то дальше определить, какая из них первая, как вторая, можно только при явных ограничениях на порядок. В слабой модели памяти ограничений нет - кто проползёт быстрее по пайплайну, тот и пойдёт первым к контроллеру памяти (ну или какому то другому в случае MMIO), хочется порядка - расставляйте fence явно.
Ну банально кинули обе микрооперациии загрузки одновременно на два разных load/store порта, но в первом потом пошли столлы из за кеш миссов.
Чаще таких людей повышают (что, в принципе, отдаляет их от принятия технических решений и хоть как то решает проблему с эффективностью).
В HPC чаще всего простые циклы с минимумом сложных ветвлений. Вопрос как оно себя на каком нибудь парсинге XML поведёт.
Это только когда ветка встречается первый раз, дальше предсказание работает на основе информации в BTB.
Динамическое предсказание нормально обработает случай, когда у нас на одних входных данных один паттерн переходов, на других - другой, и нам сегодня приходят одни данные, а завтра другие. Чем поможет компилятор - не понимаю.
-mtune влияет только на скедулинг кода, но не даёт использовать инструкции, которых может не быть на другом железе (скажем, AVX или AVX512).
OMP Offload явно отдельная тема, там кроме векторизации много нюансов ) Но и на CPU выигрыш от omp simd может быть заметный - хотя соглашусь, что это тоже тема для отдельной статьи.
А про выставление affinity в следующей серии расскажете? Оно, конечно, на многосокетной системе важнее, но и на клиентской машинке перекидывание потока с ядра на ядро не так безобидно.
Кроме векторизации там ещё много всего есть (сходу не скажу, например, включает ли -O3 IPO/LTO, можно с -ip/ipo поиграться). И в любом случае в последнее время рекомендуется векторизовать явно через omp simd. Сталкивался с тем, что с новой версией icc автовекторизация слетала, думаю в фортране то же самое. Ну и -march всё таки стоит обоим компиляторам сказать, а то сгенерят какой нибудь древний SSE.
PS В современном gcc "Vectorization is enabled at
-O2which is now equivalent to the original-O2 -ftree-vectorize -fvect-cost-model=very-cheap" https://gcc.gnu.org/gcc-12/changes.htmlДля честности надо было гну компилятору тоже только -O3 оставить. Или заняться подбором ключей для интеловского - отдельное увлекательное занятие )
В сухом остатке - правильно понимаю, что ввели что-то типа Principal Engineer/Fellow в Гугле,Интеле и т.п.?