Ну, автопром - это немецкое все ? Меня в свое время микроновцы в Мюнхене водили в лабораторию, которая под автопромовские тесты была сделана. Infineon и Bosch - тоже достаточно специфично. Если говорить про крупные компании, то одним из крупнейших работодателей является IBM, правда их сейчас Huawei щиплет. И все же - самые интересные проекты в немецких университетах и научных центрах типа того же Юлиха
А какая, если не секрет, минималка в Германии? Если честно, после всех моих зарубежных поездок на предыдущей работе, Германия - единственная страна, куда я согласился бы уехать. Но: в плане работы (hardware/software), на мой взгляд, там наиболее интересны академические проекты, там реально очень много интересного делается, а вот с коммерческими компаниями как-то не очень...
Сейчас ситуация меняется. Спрос на квалифицированных инженеров растет, и компании понемноггу начинают понимать, что и платить им надо нормальные деньги. Плюс, как это ни странно, есть возможности на удаленке работать на западные комании. Еще один мой бывший коллега (проработавший, кстати, достаточно долго в российском Cadence, пока они разработки здесь не свернули), очень крутой и талантливый, так и работает на одну широко известную в узких кругах компанию. И там значительная часть команды в России на удаленке сидит.
Ну, насчет штата Айдахо все не так плохо ?. Во-первых, в Бойсе располагается компания Micron. Мой бывший коллега проработал там несколько лет, а сейчас живет там же, хотя работает на другую, гораздо более крупную компанию ?. Думаю, Юрий знает, кого я имею в виду. Кстати, сам Бойсе на меня произвел на удивление приятное впечатление, не одидал такого от картофельного штата ?. Во-вторых, там рядом Покателло, где располагается ON Semi. Так что в Айдахо вполне можно инженеру-микроэлектронщику развернуться ?
Помимо векторных операций, для больших тестов в MP MFLOPS существенна пропускная способность памяти, и в конечном итоге все в нее упирается. А так — да, с нормальными опциями вот результат с машины с 2 x Xeon Gold 6132 (28 ядер, 56 с гипертредингом):
64 Bit MP SSE MFLOPS Benchmark 1, 56 Threads, Thu May 21 15:36:12 2020
Test 4 Byte Ops/ Repeat Seconds MFLOPS First All
Words Word Passes Results Same
Data in & out 102400 2 140000 0.082168 348945 See log No
Data in & out 1024000 2 14000 0.079809 359257 See log No
Data in & out 10240000 2 1400 0.147738 194073 See log No
Data in & out 102400 8 140000 0.099896 1148074 See log No
Data in & out 1024000 8 14000 0.083505 1373428 See log No
Data in & out 10240000 8 1400 0.142038 807447 See log No
Data in & out 102400 32 140000 0.264153 1736687 See log No
Data in & out 1024000 32 14000 0.212867 2155113 See log No
Data in & out 10240000 32 1400 0.214916 2134560 See log No
То есть если мы запишем файл с именем «мой_файл», где в строке будет буква «й» без декомпозиции, потом прочитаем директорию в виде списка строк, то мы в этом списке исходную строку «мой_файл» не найдем?
Но это, как раз, показатель того, что вся эта проблема — высосана из пальца и к поддержке на уровне языка отношения не имеет
P.S. Самое занятное, что даже попытка договориться об использовании какой-либо из нормализованных форм не поможет, так как есть много примеров эквивалентных с точки зрения Unicode строк, которые имеют разные нормализованные представления. Например, к этому приводит использование лигатур.
На мой взгляд, самой большой проблемой является то, что человек воспринимает имя файла как последовательность графем, а не code units или code points. И в разных окружениях (ОС/локаль/конкретная библиотека, etc.) одна и та же последовательнось графем может быть представлена в виде разных последовательностей code points. И без поддержки эквивалентности между кодовыми последовательностями корректной работы не добиться. Более того, у нас в практике был случай, когда файл с русским именем, содержащим букву «й», в одном окружении был заархивирован, а в другом его по имени не удалось извлечь из архива ровно по этой причине. В любой Unix-системе в каталоге легко могут быть четыре разных файла, которые для пользователя будут все выглядеть как «мой_файл» :) И попробуйте неподготовленному человеку объяснить, что это разные имена :)
На самом деле, здесь есть другая проблема — если коммерческий продукт активно развивается и хочет идти в ногу со временем, то так или иначе он будет использовать новые возможности языка и библиотеки. И в этом случае он не будет работать на старых дистрибутивах со старыми версиями стандартной библиотеки даже при неизменном ABI. А обновлять дистрибутив на стабильно работающем боевом сервере никто не желает. Поэтому остается единственно приемлемый вариант «все свое ношу с собой». Конечно при неизменном ABI можно не таскать остальные библиотеки, но это только в том случае, если они остаются старых версий. А тут уже оказывается, что далеко не все мэйнтэйнеры так же пекутся о совместимости ABI в новых версиях библиотек. Да еще, если оставаться на старых библиотеках, порой патчи безопасности на них нужно накладывать, т.е. опять же делать свою сборку и тащить с собой. В общем — «куда ни кинь — всюду клин». Так что неизменность ABI не сильно спасает коммерческих вендоров.
Представьте, например, какую-нибудь сложную lock-free структуру данных… ну, например, дерево, у которого есть разные типы узлов, тип определяется битовым тегом, а дочерние узлы лежат по атомарным указателям… Это только то, что сразу в голову приходит.
Иногда без работы с памятью никак. Что Вы будете делать, если у Вас, например, в структурах данных, которые могут алиаситься, присутствуют атомарные поля?
На самом деле, спор ни о чем — есть много случаев, когда алиасинг вреден и его можно и нужно избегать, есть и обратные примеры.
Во-первых, bit_cast только появился в стандарте.
Во-вторых, bit_cast осуществляет преобразование между типами, создавая копию, он не позволяет работать непосредственно с памятью.
А так, естественно, код в приведенном примере будет работать корректно.
P.S. Я не призываю убрать strict aliasing, в большинстве случаев это действительно полезное ограничение, но можно было подумать и о тех случаях когда он создает лишний геморрой. Можно же, наверное, сделать атрибут [[may_alias]] или что-нибудь в этом роде…
Вот, например, пара проблем из реальной жизни:
1) Когда одно и то же место в памяти может быть переиспользовано для хранения данных разных типов, а сам тип определяется, исходя из значения какого-то битового поля. Для того, чтобы это корректно работало, приходится делать юнион из соответствующих типов и массива char[], при этом установка битового поля происходит естественным образом через присваивание элемента юниона, а проверку всегда приходится делать через массив char[].
2) Если у меня есть логическая организация памяти в виде, скажем 64-разрядных слов (такой формат данных), а в этих словах могут храниться данные меньших размеров, то единственный корректный способ их извлечь/записать — это через битовые операции с 64-разрядными словами, напрямую работать с этими данными по указателю нельзя никоим образом.
Может, эти примеры и достаточно специфические, но при работе с низкоуровневыми форматами данных подобные проблемы встречаются с завидной регулярностью.
В данном случае сложно сказать, что является триггером, так как конкретный вышприведенный пример мне не удалось скомпилировать так, чтобы компилятор выкинул инициализацию полей. Т.е. я пробовал и gcc, и clang разных версий — не получается. Кстати, пример можно легко модифицировать с использованием realloc(), у которого атрибута нет (атрибут указывает на невозможность алиасинга, что для realloc'a неверно).
Но то, что стандарт поправили — это хорошо.
На самом деле здесь есть некое лукавство, ибо собственно ABI частью стандарта не является, более того, ABI очень сильно платформно-зависим (даже повсеместно применяемый Itanium C++ ABI содержит очень много архитектурно-зависимых нюансов). В моем понимании комитет может только выдать рекомендации по новому ABI, но никак не стандартизовать его. И решение по переходу на новый ABI в конечном итоге останется за вендором. Но для начала нужно реализовать поддержку нового ABI компиляторами.
На самом деле, самое интересное — это как раз интегрировать корутины с сетевой библиотекой, чтобы псевдоблокирующая семантика в коде транслировалась в co_yield + неблокирующий ввод/вывод. Жаль, что совсем по-человечески это без дополнительной поддержки со стороны ОС не сделать (кстати, в винде с IOCP это должно имплементироваться проще, чем в юниксах), но даже наполовину по-человечески будет уже огромным прорывом.
На самом деле, я не вижу больших проблем с переходом на новый ABI. Ну будут в переходный период разные версии библиотек с разным ABI, и что в этом такого? Это necessary evil. Вон в винде почти каждое приложение тащит с собой свою версию VC рантайма, и никто не возмущается.
Вот только про алиасинг не надо… Это отдельная головная боль, ибо в реальной жизни правила алиасинга в C++ при отсутствии механизмов управления ими на уровне языка приносят больше проблем, чем оптимизаций.
Ну, автопром - это немецкое все ? Меня в свое время микроновцы в Мюнхене водили в лабораторию, которая под автопромовские тесты была сделана. Infineon и Bosch - тоже достаточно специфично. Если говорить про крупные компании, то одним из крупнейших работодателей является IBM, правда их сейчас Huawei щиплет. И все же - самые интересные проекты в немецких университетах и научных центрах типа того же Юлиха
А какая, если не секрет, минималка в Германии? Если честно, после всех моих зарубежных поездок на предыдущей работе, Германия - единственная страна, куда я согласился бы уехать. Но: в плане работы (hardware/software), на мой взгляд, там наиболее интересны академические проекты, там реально очень много интересного делается, а вот с коммерческими компаниями как-то не очень...
Сейчас ситуация меняется. Спрос на квалифицированных инженеров растет, и компании понемноггу начинают понимать, что и платить им надо нормальные деньги. Плюс, как это ни странно, есть возможности на удаленке работать на западные комании. Еще один мой бывший коллега (проработавший, кстати, достаточно долго в российском Cadence, пока они разработки здесь не свернули), очень крутой и талантливый, так и работает на одну широко известную в узких кругах компанию. И там значительная часть команды в России на удаленке сидит.
Ну, насчет штата Айдахо все не так плохо ?. Во-первых, в Бойсе располагается компания Micron. Мой бывший коллега проработал там несколько лет, а сейчас живет там же, хотя работает на другую, гораздо более крупную компанию ?. Думаю, Юрий знает, кого я имею в виду. Кстати, сам Бойсе на меня произвел на удивление приятное впечатление, не одидал такого от картофельного штата ?. Во-вторых, там рядом Покателло, где располагается ON Semi. Так что в Айдахо вполне можно инженеру-микроэлектронщику развернуться ?
То есть если мы запишем файл с именем «мой_файл», где в строке будет буква «й» без декомпозиции, потом прочитаем директорию в виде списка строк, то мы в этом списке исходную строку «мой_файл» не найдем?
Безусловно.
На самом деле, спор ни о чем — есть много случаев, когда алиасинг вреден и его можно и нужно избегать, есть и обратные примеры.
Во-вторых, bit_cast осуществляет преобразование между типами, создавая копию, он не позволяет работать непосредственно с памятью.
А так, естественно, код в приведенном примере будет работать корректно.
1) Когда одно и то же место в памяти может быть переиспользовано для хранения данных разных типов, а сам тип определяется, исходя из значения какого-то битового поля. Для того, чтобы это корректно работало, приходится делать юнион из соответствующих типов и массива char[], при этом установка битового поля происходит естественным образом через присваивание элемента юниона, а проверку всегда приходится делать через массив char[].
2) Если у меня есть логическая организация памяти в виде, скажем 64-разрядных слов (такой формат данных), а в этих словах могут храниться данные меньших размеров, то единственный корректный способ их извлечь/записать — это через битовые операции с 64-разрядными словами, напрямую работать с этими данными по указателю нельзя никоим образом.
Может, эти примеры и достаточно специфические, но при работе с низкоуровневыми форматами данных подобные проблемы встречаются с завидной регулярностью.
Но то, что стандарт поправили — это хорошо.
На самом деле, самое интересное — это как раз интегрировать корутины с сетевой библиотекой, чтобы псевдоблокирующая семантика в коде транслировалась в co_yield + неблокирующий ввод/вывод. Жаль, что совсем по-человечески это без дополнительной поддержки со стороны ОС не сделать (кстати, в винде с IOCP это должно имплементироваться проще, чем в юниксах), но даже наполовину по-человечески будет уже огромным прорывом.
На самом деле, я не вижу больших проблем с переходом на новый ABI. Ну будут в переходный период разные версии библиотек с разным ABI, и что в этом такого? Это necessary evil. Вон в винде почти каждое приложение тащит с собой свою версию VC рантайма, и никто не возмущается.
Параллелизм тоже сразу будет в раздаче?
Вот только про алиасинг не надо… Это отдельная головная боль, ибо в реальной жизни правила алиасинга в C++ при отсутствии механизмов управления ими на уровне языка приносят больше проблем, чем оптимизаций.