Исходный автор статьи перегибает палку и приукрашивает ОоО, мы это уже обсуждаем в соседних комментариях. Но и Вы, увы, лукавите и перегибаете палку.
Сначала оказалось, что с опцией оптимизации -O2 внутренний цикл компилируется уже в код с 7 тактами на итерацию (вы ещё забыли включить другую рекомендуемую для Эльбруса оптимизацию -ffast).
Ну давайте вместе почитаем документацию к -ffast из man lcc:
-ffast
Включает опции -fstdlib, -faligned, -fno-math-errno, -fno-signed-zeros, -ffinite-math-only, -fno-rounding-math, -fcx-limited-range.
-fprefetch, -fmalloc-opt, -floop-apb-conditional-loads, -fstrict-aliasing, -fext-strict-aliasing.
Данная опция выключена по умолчанию, поскольку включает преобразования с вещественной арифметикой, которые могут приводить к некорректным
результатам в случае программ, предполагающих строгое соблюдение стандартов IEEE или ISO для вещественных операций и функций. Тем не менее, она
может существенно увеличить скорость программ, не требующих строго соблюдения этих стандартов. Кроме того, опция включает некоторые
потенциально опасные оптимизации (такие как loop-apb для чтений под условием, malloc-opt, удаление операций целочисленного деления), которые в
определённых случаях могут приводить к некорректному поведению программы.
А заодно и -faligned, взводимого -ffast:
-faligned (-fno-aligned)
Разрешить оптимизации, рассчитывающие исключительно на выровненные обращения в память.
Смысл опции заключается в том, что программист как бы говорит компилятору "я обязуюсь, что в исходнике программы все обращения в память являются
выровненными на свой формат", в результате чего компилятор может более эффективно выполнять некоторые оптимизации. Такими оптимизациями
являются: apb (аппаратная подкачка массивов) и arracc (аппаратная поддержка доступа к массивам) для архитектур до elbrus-v4 включительно,
автоматическая векторизация (в небольшой степени) и crp_opt (динамический разрыв зависимостей между чтениями и записями в память).
Необходимость в данной опции вызвана аппаратными особенностями Эльбруса. В архитектурах до elbrus-v5 включительно невыровненные обращения в
память работают значительно медленнее выровненных. В архитектурах до elbrus-v4 включительно аппаратная подкачка массивов не умеет работать по
невыровненным адресам; в elbrus-v5 это ограничение снято для всех операций, кроме 16-байтных; начиная с elbrus-v6 ограничение снято полностью.
Таким образом, для elbrus-v6 и выше опция -faligned имеет смысл только для оптимизации crp_opt.
Использование опции -faligned при компиляции программы, содержащей невыровненные обращения в память, может привести к некорректному поведению
программы. Для проверки выровненности обращений в память можно использовать опцию -faligned-check
По умолчанию для языков C/C++ включен режим -fno-aligned, для Фортрана -faligned
По-моему, совершенно очевидно, что эта -ffast применим лишь в очень узких, специфических случаях; скорее всего, на специализированных числодробилках. А остальной софт будет страдать. Попробуйте собрать с -ffast, скажем, firefox.
рекомендуемую для Эльбруса оптимизацию -ffast
Ввиду выше процитированной официальной документации lcc, Ваше утверждение о рекомендуемости -ffast выглядит как издёвка. Да, это сильная оптимизация, но она ломает код, если не выполняется большое количество ограничений и условия. Так что называть её рекомендуемой — так себе рекомендация. Это полезно учитывать при написании кода под Эльбрус, но мало толку при адаптации уже существующего.
Скажем так, практически реализуемый, /etc/shadow непривилегированным пользователем вытягивается на системе без каких-либо защит от spectre. Это сложная и кропотливая работа, для скрипт-кидди не подойдёт, но это реализуемо на практике.
В каких случаях требуется включать прямо все митигации?
Во всех, где важна безопасность и, например, возможна одновременная работа хотя бы двух процессов, один из которых недоверямый. Т.е. на выделенном HPC узле это не нужно, но даже на домашнем десктопе с браузером и javascript или аналогичном телефоне уже необходима. О серверах я вообще не говорю.
Вычислительно интенсивная задача и падение всего несколько процентов в разных облаках.
Вот в том-то и дело, что числодробилка. А вы возьмите сильно ветвящиеся алгоритмы или многочисленные форки и картина будет совсем иной.
На си - кластерный софт обыкновенно пишет и читает большие бинарные файлы побайтово, и так далее.
Да, это больная тема. Но софт на фортране тоже так любит: я работал с чудом, которое при чтении каждого события открывает файлик, читает событие, закрывает файлик. Только вот длина каждого события разная, индекса нет, для чтения N-го события нужно прочитать предшествующие N-1. А файл несколько гигабайт. И таких файлов тысяч десять. И почему-то оно проседало на i/o. Вот прямо удивительное дело.
Имхо, лучший код написан на фортране - возможно, просто потому, что когда писали на фортране, вычислительные ресурсы были жестко ограничены.
Уже нет. В те далёкие годы, когда софт массово писался на фортране, никаких SIMD не было, MPI / OpenMP тоже (да, я знаю, в современном фортране они поддерживаются, но несколько криво). И вот такой старый фортрановский софт начинает сильно проигрывать оттого, что SIMD не использует (а gfortran не столь умён, чтоб везде его задействовать), да и в целом с распараллеливанием плохо. За счёт этого софт на C/C++ работает в целом лучше. А всевозможные питоны имеют под капотом модули, написанные на C или C++.
Просто в ОоО операции переставляет и спекулятивно исполняет железо, а в Эльбрусе - компилятор.
Вот именно. И в Эльбрусе эту гадость легко программно отключить где нужно. Вы же говорите, что там работали раньше, значит, man lcc читали и сами прекрасно всё знаете.
А вот на x86_64 спекулятивность просто так не отключить. Обновления микрокода в купе с обновлением gcc дают некоторые fence интринсики, но это полумера, к тому же, сложная и неудобная для практического применения. Передать флаги компилятору, как в lcc, намного проще.
И вообще, опасность всех этих Spectre/Meltdown сильно преувеличена.
Meltdown вообще позволяет извлекать любые данные из любых процессов. Spectre сложнее использовать, но ваш покорный слуга /etc/shadow обычным пользователем так вытаскивал интереса ради. Так что это очень серьёзный класс проблем, который нельзя игнорировать.
Как человек, проанализировавший тонны кода из под разнообразного пользовательского софта, могу сказать, что вам просто не с чем сравнить. Так вот, в HPC ситуацию намного лучше, чем в среднем по индустрии.
Давайте определимся про какой софт речь: проприетарный или свободный. Я уже около 20 лет работаю со свободным софтом, качество, конечно, самое разное, но в целом лучше, чем в свободном или хотя бы условно открытом HPC софте.
С проприетарным софтом я мало работал, но почти всё, что я видел было совершенно ужасно, наверное, даже хуже научного свободного софта. Есть рассказы от сотрудников крупных транснациональных IT компаний, что у них качественный проприетарный софт, но ни подтвердить, ни опровергнуть это я не могу.
в общем случае OoO не равно спекулятивному исполнению.
В теории — возможно, почему бы и нет. На практике — равно. Если я не прав, приведите мне примеры OoO без run-time спекулятивности; желательно реально эксплуатируемые, т.е. за пределами инженерных образцов.
SMT вполне сможет загрузить простаивающие ядра.
Во-первых, SMT свойственны аналогичные Spectre проблемы с безопасностью: посмотрите на CVE по SMT, которые были есть и будут. Но SMT легко отключить, поэтому особой проблемой это не является.
Во-вторых, сможет или нет — зависит от задачи. Для полностью асинхронных задач, которые при этом не будут слишком толкаться по кешу данных, да поможет и хорошо. Но в HPC большинство MPI/OpenMP или гибридных задач синхронны — это значит, что N потоков будут работать со скоростью наиболее медленного из них, так что SMT лишь вредит в таких ситуациях и его либо отключают, либо делают CPU-affinity на физические ядра.
Вы тихонько умалчиваете про одну архитектурную проблему OoO: это Spectre. В то время как Meltdown — это грубая ошибка, которую можно устранить правкой микроархитектуры или заткнуть микрокодом, то класс проблем Spectre принципиально неустраним до тех пор, пока существует OoO, по крайней мерез без кеша со строгим контролем прав доступа перед проверкой на хит (мне неизвестно об оборудовании, реализующем подобный контроль, но теоретически это возможно, хотя сопутствующие накладные расходы могут убить все преимущества ОоО, не говоря уже о сложности реализации соответствующего кода со стороны ядра ОС).
Так вот, если не делать mitigations=off, а включить все средства защиты от всех известных разновидностей Spectre на всех уровнях — микрокод процессора, ядро ОС, опции компиляции всех приложений (ну те же выключенные трамплины), то потери производительности на реальных приложениях достигнут несколько раз. Вот и получим, что Эльбрусы хуже не в 5-8 раз, а в 2-3 раза, что, как говорится, две большие разницы.
И на каждый заткнутый вариант Spectre найдётся v5, v10, v100500, который тоже придётся затыкать. Так что единственный практический путь получения безопасных вычислений — это отказ от OoO. В этом смысле меня глубоко печалит, что на Эльбрусах будет добавлен динамический предсказатель ветвления, что помножит на ноль их и без того не идеальное преимущество в плане безопасности.
Вот как раз на числодробилках и вычислительных узлах HPC и OoO можно оставить, и вообще mitigations=off сделать, т.к. конкретные узлы в заданный момент времени обычно и так эксклюзивны для конкретной задачи.
На практике считаю, что безопасные вычисления возможны только при отсутствиии OoO в частности и совместных кешей в общем случае. Хорошо бы делать CPU с такими защищёнными ядрами (а-ля ранние Intel Atom без branch predictor и HTT) для ядра, ssh и иных задач, где безопасность важнее всего и большей частью ядер, сделанных под числодробилки, кодеки и прочую мультимедию, где скорость важнее безопасности. Думаю, что будущее именно за таким подходом, но это потребует принципиальной микроархитектурной переработки всех существующих решений, по крайней мере сколь либо широко применяемых.
Тем более, что HPC вычисления, как правило, сопровождают достаточно квалифицированные специалисты, которые понимают специфику своих вычислений и по природе своей работы должны углубляться в особенности процессора и могут адаптировать программу под Эльбрус.
Спасибо, насмешили. Как человек, немало лет проработавший в HPC (и как пользователь, и как администратор и архитектор подобных систем) могу сказать, что почти всегда это не так. Среднестатистический научный софт, который гоняют на HPC, написан из рук вон плохо, по принципу, чтоб хоть как-то считало и работало. Да, есть примеры, когда софт тщательно продумывается и прорабатывается под возможности конкретного оборудования, но это редкие случаи. И более важную роль играет не оптимизация под CPU, а оптимизация под interconnect: минимизация latency на IB, минимизация блокировок MPI, асинхронная работа, решение проблем ранжирования, параллельного I/O и т.п.. Конечно, использование всех особенностей CPU, помимо банальной пересборки с -march=native, тоже важно, но на вторых ролях по сравнению с проблемами I/O и межузлового взаимодействия.
Любой кэш должен обеспечивать или контроль доступа к данным или гарантированный сброс кэша при переключении контекста. В противном случае будет очередная волна уязвимостей. Если сброс при смене контекста есть смысл делать на L1 и, быть может, L2, то для L3 и уж тем более L4 нужен контроль доступа. Реализовать его можно с помощью тегирования, хотя есть и иные способы. В любом случае это сильно усложнит реализацию кэшей и, следовательно, замедлит их работу и уменьшит полезную ёмкость. Но если этого не сделать, то о разграничении прав доступа на любом уровне можно забыть. И что-то мне подсказывает, что в погоне за скорость никто этого не будет делать.
Артём, большое спасибо за доведённый до конца рассказ.
Мне очень понравилась нетривиальность развития сюжетной линии, научная и техническая продуманность деталей.
Для меня остался открытым вопрос, кто же такие титаны, детали их генезиса и естественной среды обитания. Если ими населена вся планета, то вряд ли несколько сотен колонистов настолько сильно влияют на их пищевые цепочки, чтоб титаны упорно нападали на базы — еды им должно и без этого хватать. Или они так сражаются с инопланетными захватчиками? Очевидно, определённый разум у них есть.
В общем, это открытый вопрос и, возможно, тема для будущих работ: например, освобождения Деметриона от Корпорации сопротивлением и титанами.
Часы на верхушке Эмпайр-стейт-билдинг каждый год отстают на несколько микросекунд от часов у её подножия.
Здесь ошибка. Гравитационный потенциал больше (по модулю) у основания здания, значит у основания часы будут идти медленнее, значит на верхушке часы будут спешить относительно часов у подножия. Проведите мысленный эксперимент с поверхностью нейтронной звезды: на поверхности время будет идти медленнее, чем на дальней орбите. Здесь то же самое, но эффект слабее. Да, ещё есть эффект разности линейных скоростей у основания и на вершине, но т.к. обе много меньше скорости света, то существенного вклада это не даёт.
Исходный автор статьи перегибает палку и приукрашивает ОоО, мы это уже обсуждаем в соседних комментариях. Но и Вы, увы, лукавите и перегибаете палку.
Ну давайте вместе почитаем документацию к -ffast из man lcc:
А заодно и -faligned, взводимого -ffast:
По-моему, совершенно очевидно, что эта -ffast применим лишь в очень узких, специфических случаях; скорее всего, на специализированных числодробилках. А остальной софт будет страдать. Попробуйте собрать с -ffast, скажем, firefox.
Ввиду выше процитированной официальной документации lcc, Ваше утверждение о рекомендуемости -ffast выглядит как издёвка. Да, это сильная оптимизация, но она ломает код, если не выполняется большое количество ограничений и условия. Так что называть её рекомендуемой — так себе рекомендация. Это полезно учитывать при написании кода под Эльбрус, но мало толку при адаптации уже существующего.
Скажем так, практически реализуемый, /etc/shadow непривилегированным пользователем вытягивается на системе без каких-либо защит от spectre. Это сложная и кропотливая работа, для скрипт-кидди не подойдёт, но это реализуемо на практике.
Во всех, где важна безопасность и, например, возможна одновременная работа хотя бы двух процессов, один из которых недоверямый. Т.е. на выделенном HPC узле это не нужно, но даже на домашнем десктопе с браузером и javascript или аналогичном телефоне уже необходима. О серверах я вообще не говорю.
Вот в том-то и дело, что числодробилка. А вы возьмите сильно ветвящиеся алгоритмы или многочисленные форки и картина будет совсем иной.
Да, это больная тема. Но софт на фортране тоже так любит: я работал с чудом, которое при чтении каждого события открывает файлик, читает событие, закрывает файлик. Только вот длина каждого события разная, индекса нет, для чтения N-го события нужно прочитать предшествующие N-1. А файл несколько гигабайт. И таких файлов тысяч десять. И почему-то оно проседало на i/o. Вот прямо удивительное дело.
Уже нет. В те далёкие годы, когда софт массово писался на фортране, никаких SIMD не было, MPI / OpenMP тоже (да, я знаю, в современном фортране они поддерживаются, но несколько криво). И вот такой старый фортрановский софт начинает сильно проигрывать оттого, что SIMD не использует (а gfortran не столь умён, чтоб везде его задействовать), да и в целом с распараллеливанием плохо. За счёт этого софт на C/C++ работает в целом лучше. А всевозможные питоны имеют под капотом модули, написанные на C или C++.
Вот именно. И в Эльбрусе эту гадость легко программно отключить где нужно. Вы же говорите, что там работали раньше, значит, man lcc читали и сами прекрасно всё знаете.
А вот на x86_64 спекулятивность просто так не отключить. Обновления микрокода в купе с обновлением gcc дают некоторые fence интринсики, но это полумера, к тому же, сложная и неудобная для практического применения. Передать флаги компилятору, как в lcc, намного проще.
Meltdown вообще позволяет извлекать любые данные из любых процессов. Spectre сложнее использовать, но ваш покорный слуга /etc/shadow обычным пользователем так вытаскивал интереса ради. Так что это очень серьёзный класс проблем, который нельзя игнорировать.
Давайте определимся про какой софт речь: проприетарный или свободный. Я уже около 20 лет работаю со свободным софтом, качество, конечно, самое разное, но в целом лучше, чем в свободном или хотя бы условно открытом HPC софте.
С проприетарным софтом я мало работал, но почти всё, что я видел было совершенно ужасно, наверное, даже хуже научного свободного софта. Есть рассказы от сотрудников крупных транснациональных IT компаний, что у них качественный проприетарный софт, но ни подтвердить, ни опровергнуть это я не могу.
В теории — возможно, почему бы и нет. На практике — равно. Если я не прав, приведите мне примеры OoO без run-time спекулятивности; желательно реально эксплуатируемые, т.е. за пределами инженерных образцов.
Во-первых, SMT свойственны аналогичные Spectre проблемы с безопасностью: посмотрите на CVE по SMT, которые были есть и будут. Но SMT легко отключить, поэтому особой проблемой это не является.
Во-вторых, сможет или нет — зависит от задачи. Для полностью асинхронных задач, которые при этом не будут слишком толкаться по кешу данных, да поможет и хорошо. Но в HPC большинство MPI/OpenMP или гибридных задач синхронны — это значит, что N потоков будут работать со скоростью наиболее медленного из них, так что SMT лишь вредит в таких ситуациях и его либо отключают, либо делают CPU-affinity на физические ядра.
Вы тихонько умалчиваете про одну архитектурную проблему OoO: это Spectre. В то время как Meltdown — это грубая ошибка, которую можно устранить правкой микроархитектуры или заткнуть микрокодом, то класс проблем Spectre принципиально неустраним до тех пор, пока существует OoO, по крайней мерез без кеша со строгим контролем прав доступа перед проверкой на хит (мне неизвестно об оборудовании, реализующем подобный контроль, но теоретически это возможно, хотя сопутствующие накладные расходы могут убить все преимущества ОоО, не говоря уже о сложности реализации соответствующего кода со стороны ядра ОС).
Так вот, если не делать mitigations=off, а включить все средства защиты от всех известных разновидностей Spectre на всех уровнях — микрокод процессора, ядро ОС, опции компиляции всех приложений (ну те же выключенные трамплины), то потери производительности на реальных приложениях достигнут несколько раз. Вот и получим, что Эльбрусы хуже не в 5-8 раз, а в 2-3 раза, что, как говорится, две большие разницы.
И на каждый заткнутый вариант Spectre найдётся v5, v10, v100500, который тоже придётся затыкать. Так что единственный практический путь получения безопасных вычислений — это отказ от OoO. В этом смысле меня глубоко печалит, что на Эльбрусах будет добавлен динамический предсказатель ветвления, что помножит на ноль их и без того не идеальное преимущество в плане безопасности.
Вот как раз на числодробилках и вычислительных узлах HPC и OoO можно оставить, и вообще mitigations=off сделать, т.к. конкретные узлы в заданный момент времени обычно и так эксклюзивны для конкретной задачи.
На практике считаю, что безопасные вычисления возможны только при отсутствиии OoO в частности и совместных кешей в общем случае. Хорошо бы делать CPU с такими защищёнными ядрами (а-ля ранние Intel Atom без branch predictor и HTT) для ядра, ssh и иных задач, где безопасность важнее всего и большей частью ядер, сделанных под числодробилки, кодеки и прочую мультимедию, где скорость важнее безопасности. Думаю, что будущее именно за таким подходом, но это потребует принципиальной микроархитектурной переработки всех существующих решений, по крайней мере сколь либо широко применяемых.
Спасибо, насмешили. Как человек, немало лет проработавший в HPC (и как пользователь, и как администратор и архитектор подобных систем) могу сказать, что почти всегда это не так. Среднестатистический научный софт, который гоняют на HPC, написан из рук вон плохо, по принципу, чтоб хоть как-то считало и работало. Да, есть примеры, когда софт тщательно продумывается и прорабатывается под возможности конкретного оборудования, но это редкие случаи. И более важную роль играет не оптимизация под CPU, а оптимизация под interconnect: минимизация latency на IB, минимизация блокировок MPI, асинхронная работа, решение проблем ранжирования, параллельного I/O и т.п.. Конечно, использование всех особенностей CPU, помимо банальной пересборки с -march=native, тоже важно, но на вторых ролях по сравнению с проблемами I/O и межузлового взаимодействия.
Мне очень понравилась нетривиальность развития сюжетной линии, научная и техническая продуманность деталей.
Для меня остался открытым вопрос, кто же такие титаны, детали их генезиса и естественной среды обитания. Если ими населена вся планета, то вряд ли несколько сотен колонистов настолько сильно влияют на их пищевые цепочки, чтоб титаны упорно нападали на базы — еды им должно и без этого хватать. Или они так сражаются с инопланетными захватчиками? Очевидно, определённый разум у них есть.
В общем, это открытый вопрос и, возможно, тема для будущих работ: например, освобождения Деметриона от Корпорации сопротивлением и титанами.
Интересно, данные воспоминания будут использоваться в дальнейшем сюжете или это просто лирический флэшбэк?
Вы как-то не так прочитали статью. Сказано же, что пациент обоснованно отказался от операции:
Должно быть «больше».
есть прогресс?
Здесь ошибка. Гравитационный потенциал больше (по модулю) у основания здания, значит у основания часы будут идти медленнее, значит на верхушке часы будут спешить относительно часов у подножия. Проведите мысленный эксперимент с поверхностью нейтронной звезды: на поверхности время будет идти медленнее, чем на дальней орбите. Здесь то же самое, но эффект слабее. Да, ещё есть эффект разности линейных скоростей у основания и на вершине, но т.к. обе много меньше скорости света, то существенного вклада это не даёт.