Совсем пустой бесконечный цикл не нужен, поэтому и причислен к UB. Но цикл с чем-нибудь вроде __asm __volatite(...) уже не является совсем пустым и не вызывает UB.
С небольшими оговорками можно сказать что инструкции NOP/PAUSE/HLT или их аналоги есть на всех архитектурах CPU:
с точки зрения кодирования команд CPU эти инструкции могут быть синонимами других реальных инструкций. Например, на x86: NOP = XCHG AX, AX; PAUSE = REP XCHG AX, AX
исполнительное ядро CPU (в том числе в зависимости от модели/ревизии) может либо обрабатывать их в точности в соответствии с кодированием (Intel 8086 вместо NOP реально выполнял XCHG AX, AX), либо в соответствии с дополнительной семантикой (Intel 486 начал именно выполнять PAUSE уступая шину, а не REP NOP).
в худшем случае вместо NOP/PAUSE/HLT могут использоваться (замещаться при ассемблировании) заведомо безобидные и всегда доступные инструкции. Например, условный или безусловный переход к следующей команде.
Чуть менее чем во всех мультизадачных ОС используется именно такой паттерн: idle-задача с минимальным приоритетом в виде бесконечного цикла с HLT-подобной инструкцией (остановка CPU до прерывания).
В чуть более продвинутых системах этот паттерн немного оптимизируется для исключения лишних переключений контекста — грубо говоря, HLT переноситься в планировщик и терминирует цикл при отсутствии активных задач.
TL;DR — ClickHouse будет "как тузик грелку" PostgreSQL во всех своих целевых сценариях использования, ибо именно для этого CH был сделан. Т.е. чем ближе совокупность "данные + запросы" к назначению CH, тем ближе буду результаты сравнительных бенчмарков с PG к "как тузик грелку" (в два и более раз).
Такое моё утверждение может показаться слишком сильным и категоричным, но чем больше кто-либо будет погружаться во внутреннее устройство PG и CH, тем больше будет соглашаться. Причем это нисколько не принижает достоинства PG, просто не каждым микроскопом удобно забивать шурупы ;)
Если совсем грубо и коротко, то в своих целевых сценариях CH почти не делает лишнего и очень эффективно использует железо (SIMD, последовательное чтение, сжатие и т.п.). В таких сценариях Постгресу (мягко говоря) крайне сложно тягаться с CH, оставаясь при этом именно Постресом (сохраняя ACID поверх MVCC путем COW/ShadowPaging). Со стороны CH при этом отсутствуют транзакции и удаление/изменение данных в привычном для PG понимании. Т.е. CH тут быстрее, в частности, потому что много не позволяет.
Какого-либо пренебрежения к "возможностям PG" я не вижу. Точнее говоря, в моем понимании, посыл автора не в "принижении PG", а в демонстрации возможностей FDW. Другими словами, главным я вижу не "насколько PG медленнее CH" (в целевых для CH сценариях это неизбежно), а то что Clickhousedb_fdw позволяет через готовый PG-интерфейс (ODBC и т.д.) в дополнение к PG получить также и часть мощности CH. Причем во многих случаях с относительно небольшой наценкой.
Проседание Q14 показывает текущее положение дел в Clickhousedb_fdw, т.е. не готовность к production. Грубо говоря, Clickhousedb_fdw (пока) умеет "перебрасывать" на сторону CH только относительно простые join-ы (complex join pushdown NOT supported).
Поэтому, чуть более сложный join будет выполняться на стороне PG. Другими словами, если Clickhousedb_fdw не полностью справляется с трансляцией запроса, то сначала будут выполнены подзапросы на стороне CH, затем эти данные будут загружены внутрь PG и уже после будут join-ится. Проседание Q14 как раз хорошо показывает последствия.
Реализация complex join pushdown сводиться к волокитной трансляции из PG-диалекта SQL в CH-SQL. Это местами очень занудная, а местами нетривиальная задача. Причем если делать по-хорошему, то следует обеспечить разумно-оптимальную трансляцию "экс-территориальных" join-ов, когда в одном запросе используются как таблицы из CH, так и из PG, а желательно и из другого FDW. Короче, пока ребята из Percona это отложили, и (мне) понятно почему.
WSL2 даст нормальную поддержку всех системных вызовов Linux и ≈10-кратное ускорение операций с файлами, но только если их размещать "внутри Linux" (на EXT4, а не в Windows). Однако, доступ к "виндовым" файлам из WSL2 замедлится ≈вдвое.
Короче, для вас (видимо) что-либо поменяется принципиально только если убрать Windows-прокладку.
По моему скромному мнению, развитие GCC в основном тормозит не лицензия, а более мутное внутреннее устройство (по историческим причинам) и, как следствие, высокий порог входа. Как пример, GPL как-то не особо мешает развитию Linux.
Тем не менее, лицензия Apache 2.0 действительно позволяет коммерческим компаниям гораздо лучше (понятнее и с меньшими рисками) защищать свои инвестиции при разработке собственных продуктов на основе clang. Фактически в upstream clang-а сейчас большинство инфраструктурных изменений попадает именно так — для выстраивания базиса закрытых разработок.
выпиливать из форка всё лишнее, либо самим раскатывать изменения.
фиксировать интерфейс базовых/общих компонентов и иметь проблемы со своими доработками, либо иметь проблемы с импортом доработок и исправлений из upstream.
и т.п.
Короче, форк не требует убеждать community, в обмен на выполнение соответствующей работы своими руками (объём которой будет постоянно расти).
С "секретным железом" нет никаких проблем, пока вы не передаёте кому-либо условный GCC с вашими "правками для секретного железа". Но и в этом случае, в соответствии с GPL, вы обязаны показать исходники только тем, кому дали готовый компилятор и только по их требованию (которого может НЕ быть по массе причин).
Более того, передаваемые исходники должны обеспечивать возможность сборки компилятора, но вовсе НЕ обязаны содержать какую-либо документацию по "секретному железу" или как-либо его раскрывать.
В реальности же, всё это крайне трудно формализировать до уровня служебных инструкций и соглашений по коммерческой тайне внутри компании. Практически невозможно контролировать и наказать сотрудника за слив информации (доказать что он умышленно раскрыл коммерческую тайну).
Тем не менее, у Apple не было тогда и нет сейчас "секретного железа", которое бы требовал правок компилятора. Тогда планировались, а теперь есть софтверные механизмы защиты завязанные на фичи компилятора, но не "железо". Причем (насколько мне известно) всё необходимое давно есть и в GCC ;)
Ну да, andreybokhanko несколько упросил и смешал разные обстоятельства и причины, приправив "секретным железом".
В случае Apple было примерно так:
Хотелось Objective-C компилятор cо специфическими фичами для Darwin.
Хотелось C компилятор с дополнительными фичами для Objective-C и Darwin.
При использовании GCC требовалось:
Расплачиваться трудоемкостью за толщину культурного слоя и техдолг внутри GCC.
Убеждать community принимать эти правки, в том числе вносить изменения в общие/базовые компоненты и "раскатывать" эти изменения по другим (ненужным для Apple) архитектурам CPU.
"Засвечивать" все свои идеи и открывать реализацию под GPL.
Поэтому логично что "манагеры эпла" решили попробовать, когда появился подходящий PhD с работающим (пусть и академическим) проектом. А потом поперло...
Да, но причина немного в другом — эти операции выполняются тормозной NTFS (со всеми проблемами WSL1), но добавляются накладные расходы маршалинга через виртуальную сеть. А с NTFS в Linux всё более-менее.
WSL1 = тормозят все системные вызовы, но больше всего связанные с файловыми операциями (ибо эмуляция средствами тормозной NTFS).
WSL2 = сильно тормозит доступ к файлам расположенным внутри винды (ибо доступ через виртуальную сеть с эмуляцией средствами тормозной NTFS), но остальное работает почти как в Linux.
Ящик водки и всех обратно!
Как-то навеяло.
Приходит "Хабр" к доктору:
;)
Эх, 2N лет назад...
На всякий:
__volatile+__asm("":::"memory")даёт именноstd::memory_order_acq_rel.Т.е. в плюсах для аналогичного эффекта нужно std::atomic_signal_fence(std::memory_order_acq_rel), а не что-то другое.
Совсем пустой бесконечный цикл не нужен, поэтому и причислен к UB. Но цикл с чем-нибудь вроде
__asm __volatite(...)уже не является совсем пустым и не вызывает UB.С небольшими оговорками можно сказать что инструкции NOP/PAUSE/HLT или их аналоги есть на всех архитектурах CPU:
Честно говоря я уже запутался в том, кто и что здесь пытался сформулировать и обсудить. В реальность уже лет 20-30 примерно так:
__asm __volatile("bla-bla-bla")— чтобы компилятор не выбросил конструкцию и не задумывался о UB в бесконечных циклах.__asm __volatile("bla-bla-bla" ::: "memory")— тоже самое, плюс уведомление компилятора об изменении любых переменных в памяти.__asm __volatile("HLT" ::: "memory")— в idle-задаче или планировщике.__asm __volatile("PAUSE" ::: "memory")— в циклах ожидания на блокировках.__asm __volatile("NOP")— для заполнения при выравнивании и в циклах задержки.Чуть менее чем во всех мультизадачных ОС используется именно такой паттерн: idle-задача с минимальным приоритетом в виде бесконечного цикла с HLT-подобной инструкцией (остановка CPU до прерывания).
В чуть более продвинутых системах этот паттерн немного оптимизируется для исключения лишних переключений контекста — грубо говоря, HLT переноситься в планировщик и терминирует цикл при отсутствии активных задач.
TL;DR — ClickHouse будет "как тузик грелку" PostgreSQL во всех своих целевых сценариях использования, ибо именно для этого CH был сделан. Т.е. чем ближе совокупность "данные + запросы" к назначению CH, тем ближе буду результаты сравнительных бенчмарков с PG к "как тузик грелку" (в два и более раз).
Такое моё утверждение может показаться слишком сильным и категоричным, но чем больше кто-либо будет погружаться во внутреннее устройство PG и CH, тем больше будет соглашаться. Причем это нисколько не принижает достоинства PG, просто не каждым микроскопом удобно забивать шурупы ;)
Если совсем грубо и коротко, то в своих целевых сценариях CH почти не делает лишнего и очень эффективно использует железо (SIMD, последовательное чтение, сжатие и т.п.). В таких сценариях Постгресу (мягко говоря) крайне сложно тягаться с CH, оставаясь при этом именно Постресом (сохраняя ACID поверх MVCC путем COW/ShadowPaging). Со стороны CH при этом отсутствуют транзакции и удаление/изменение данных в привычном для PG понимании. Т.е. CH тут быстрее, в частности, потому что много не позволяет.
Какого-либо пренебрежения к "возможностям PG" я не вижу. Точнее говоря, в моем понимании, посыл автора не в "принижении PG", а в демонстрации возможностей FDW. Другими словами, главным я вижу не "насколько PG медленнее CH" (в целевых для CH сценариях это неизбежно), а то что Clickhousedb_fdw позволяет через готовый PG-интерфейс (ODBC и т.д.) в дополнение к PG получить также и часть мощности CH. Причем во многих случаях с относительно небольшой наценкой.
Проседание Q14 показывает текущее положение дел в Clickhousedb_fdw, т.е. не готовность к production. Грубо говоря, Clickhousedb_fdw (пока) умеет "перебрасывать" на сторону CH только относительно простые join-ы (complex join pushdown NOT supported).
Поэтому, чуть более сложный join будет выполняться на стороне PG. Другими словами, если Clickhousedb_fdw не полностью справляется с трансляцией запроса, то сначала будут выполнены подзапросы на стороне CH, затем эти данные будут загружены внутрь PG и уже после будут join-ится. Проседание Q14 как раз хорошо показывает последствия.
Реализация complex join pushdown сводиться к волокитной трансляции из PG-диалекта SQL в CH-SQL. Это местами очень занудная, а местами нетривиальная задача. Причем если делать по-хорошему, то следует обеспечить разумно-оптимальную трансляцию "экс-территориальных" join-ов, когда в одном запросе используются как таблицы из CH, так и из PG, а желательно и из другого FDW. Короче, пока ребята из Percona это отложили, и (мне) понятно почему.
WSL2 даст нормальную поддержку всех системных вызовов Linux и ≈10-кратное ускорение операций с файлами, но только если их размещать "внутри Linux" (на EXT4, а не в Windows). Однако, доступ к "виндовым" файлам из WSL2 замедлится ≈вдвое.
Короче, для вас (видимо) что-либо поменяется принципиально только если убрать Windows-прокладку.
Всё так, но (вероятно) не все читали (или поняли) анонс.
Видимо поэтому продолжаются какие-то сборы и сравнения мягкого с мелким ;)
Сейчас-то да, но когда в Apple принимали решение о женитьбе на clang ситуация была совсем иная.
По моему скромному мнению, развитие GCC в основном тормозит не лицензия, а более мутное внутреннее устройство (по историческим причинам) и, как следствие, высокий порог входа. Как пример, GPL как-то не особо мешает развитию Linux.
Тем не менее, лицензия Apache 2.0 действительно позволяет коммерческим компаниям гораздо лучше (понятнее и с меньшими рисками) защищать свои инвестиции при разработке собственных продуктов на основе clang. Фактически в upstream clang-а сейчас большинство инфраструктурных изменений попадает именно так — для выстраивания базиса закрытых разработок.
Форкнуть-то можно, но затем:
Короче, форк не требует убеждать community, в обмен на выполнение соответствующей работы своими руками (объём которой будет постоянно расти).
С "секретным железом" нет никаких проблем, пока вы не передаёте кому-либо условный GCC с вашими "правками для секретного железа". Но и в этом случае, в соответствии с GPL, вы обязаны показать исходники только тем, кому дали готовый компилятор и только по их требованию (которого может НЕ быть по массе причин).
Более того, передаваемые исходники должны обеспечивать возможность сборки компилятора, но вовсе НЕ обязаны содержать какую-либо документацию по "секретному железу" или как-либо его раскрывать.
В реальности же, всё это крайне трудно формализировать до уровня служебных инструкций и соглашений по коммерческой тайне внутри компании. Практически невозможно контролировать и наказать сотрудника за слив информации (доказать что он умышленно раскрыл коммерческую тайну).
Тем не менее, у Apple не было тогда и нет сейчас "секретного железа", которое бы требовал правок компилятора. Тогда планировались, а теперь есть софтверные механизмы защиты завязанные на фичи компилятора, но не "железо". Причем (насколько мне известно) всё необходимое давно есть и в GCC ;)
Ну да, andreybokhanko несколько упросил и смешал разные обстоятельства и причины, приправив "секретным железом".
В случае Apple было примерно так:
Поэтому логично что "манагеры эпла" решили попробовать, когда появился подходящий PhD с работающим (пусть и академическим) проектом. А потом поперло...
Да, но причина немного в другом — эти операции выполняются тормозной NTFS (со всеми проблемами WSL1), но добавляются накладные расходы маршалинга через виртуальную сеть. А с NTFS в Linux всё более-менее.
Нет, немного иначе:
Если учесть что в WSL1 принципиально не могут работать некоторые вещи, то самое рациональное решение — использовать WSL2 с размещением файлов в EXT4, а не в NTFS.
Капитан очевидность лет 10 бубнит что переходить стоит, но сразу на Linux ;)
Теперь точно получит (
И тогда CPU будет кушать примерно вдвое больше энергии.
Лучше
__asm __volatite("").P.S.
Интересна логика (и познания) "первого минуса" ;)