У вас несколько неверное представление, поэтому вы пару раз перемешали мух с котлетами:
Назвать LLVM IR байт-кодом не совсем корректно, мягко говоря. Тогда и исходник на C — тоже байт код, ибо тоже состоит из байтов ;)
В терминах LLVM IR программа манипулирует "примерно регистрами" заданной разрядности. Поэтому (наоборот) такая IR-программа будет относительно переносима между (не привязана к) 8-битной ATMega, 40-битному SHARC, 32/64-битному x86 и т.д.
На практике LLVM IR переносим примерно как шарообразный конь в вакууму. Т.е. пока некий код "шарообразный" и "в вакууме" — он переносим, а если чуточку иначе — сразу бац и коллапс волновой функции по массе причин ;)
В самом clang атрибут "pure" не документирован, но на зло для совместимости с gcc поддерживается фронтендом и обрабатывается бэкендом, а также честно виден через __has_attribute(pure).
Встречая [[gnu::pure]] clang насильно включает noexcept(true), т.е. задним числом меняет тип функции (начиная с C++17).
Всё происходит молча, без каких-либо предупреждений, при включении любой диагностики, и даже при наличии у функции явного noexcept(false).
Теперь представьте, что у вас проект с использованием десятка продвинутых C++ библиотек, в одной из которых есть трех-этажные шаблонны с абсолютно обоснованным использованием [[gnu::pure]] в паре-тройке функций, т.е. с втихую добавленными noexcept(true).
Этот noexcept(true) неплохо "протекает" через инлайнинг и IPO. При этом clang много чего оптимизирует/совмещает кадры стека и т.д. Соответственно, в каких-то случаях появление исключения приведет к вызову std::terminate(), а в других нет.
При каких-нибудь жалких 10-20К строк кода отлаживать сплошное удовольствие. Я провозился несколько часов, пока не дошел до "поштучного" анализа unwind-таблиц. Что характерно, эта бага-фича гуглится элементарно, как только понимаешь связь между [[pure]] и проблемами с исключениями. Но никак не раньше ;)
Доступность санитайзеров и их дружба друг-с-другом зависит от платформы, версии софта и т.п. Например, если не ошибаюсь, в gcc 10.x на x86_64 можно включить UndefinedBehaviorSanitizer (ubsan) одновременно с AddressSanitizer (asan) или с MemorySanitizer. А при выключенном asan можно всегда включить отдельно LeakSanitizer c любым другим санитайзером. Но лучше смотреть https://github.com/google/sanitizers и доку по конкретному компилятору.
Для памяти: LeakSanitizer по-умолчанию включается одновременно с AddressSanitizer. Использование AddressSanitizer + MemorySanitizer (т.е. две отдельные сборки и два прогона) примерно соответствуют прогону под Valgrind с трекингом аллокаций.
Для гонок: ThreadSanitizer, но я им почти не пользуюсь (писал выше).
UndefinedBehaviorSanitizer: отлавливает массу всякой фигни, особенно в легаси-коде писанном для x86. Мне много раз помогал с unaligned access.
Roaring Bitmaps не совсем то что вам нужно (не считая проблем шарповой реализации). А вот с CSharpFastPFOR померятся вполне уместно. Собственно этого достаточно чтобы соотнести результат вашего VLQ с остальными competitors в score-таблицах у TurboPFor и т.п.
Кроме этого, это поможет вам самим сориентироваться и решить куда двигаться дальше. Ну и конечно было-бы любопытно увидеть статью-продолжение с разбором полетов.
P.S.
На всякий — про качество кода CSharpFastPFOR мне ничего не известно, т.е. там тоже могут быть какие-то перлы.
Нет, совсем не так. Вне зависимости от ученой степени ваша работа может представлять интерес (не быть дилетантской и наивной), если хотя-бы одно из двух:
Вы со знанием дела теоретически показываете что предложили новый подход или улучшили уже известный.
Вы практически (бенчмарком) показываете ценность вашего подхода и/или идеи. Например, можно померятся силами с TurboPFor (там в README достаточно таблиц с результатам различных реализаций).
А пока вы просто не понимаете как смешно выглядите, уж извините за прямоту.
Есть ряд научных работ (разных ученых/исследователей) по теме сжатия целочисленных последовательностей, в которых собрано и проанализировано немало различных идей/подходов.
Есть FastPFOR (включая https://github.com/Genbox/CSharpFastPFOR), streamvbyte, TurboPFor и немало других реализаций под разные задачи/требования, где использованы результаты этих научных работ.
Кроме этого есть и упомянутые Roaring Bitmap (в том числе на C#, на Java и даже на JS).
Соответственно, замечательно что вы пытаетесь самостоятельно разобраться и придумать что-то новое. Однако, без ознакомления с наработанным опытом из первого пункта (совершенно вне зависимости от остальных) результат вашей работы (включая статью) рискует быть излишне дилетантским и наивным.
Пардон, ну так вы для начала просто прочитайте публикации Daniel Lemire по ссылкам.
Причем если Дэниеля внятно спросить что-то beyond RTFM (тем более по-французски), то он очень хорошо отвечает.
Daniel Lemire с коллегами занимался этой темой (Integer Compression) более 6 лет. Собрал, наработал и опробовал массу идей, опубликовал около десятка работ и довел до ума несколько реализаций. А в https://github.com/lemire/FastPFor/blob/master/README.md пожалуй лучший набор ссылок по теме, как на научные работы (т.е. идеи с глубокой проработкой и выкладками), так и на реализации (с оптимизацией и т.д.).
С одной стороны, здорово что вы пытаетесь самостоятельно разобраться в теме и что-то придумать. Однако, не стоит делать публикаций без минимального ознакомления с примерно общеизвестной (хотя и в узких кругах) информацией по теме. Уж извините, вовсе не хочу обидеть, но это достаточно вредный дилетантизм.
Статистическая гипотеза = предположение о виде распределения и свойствах случайной величины, которое можно подтвердить или опровергнуть применением статистических методов к данным выборки.
p-значения полезны при оценке того, насколько несовместимы данные с некоторой статистической гипотезой.
p-значения могут использоваться в качестве индикатора случайной ошибки в результатах экспериментов/измерений/выборок с известной/доказанной статистической гипотезой.
Чем больше "замеров" и чем лучше они "ложатся" на статистическую гипотезу, тем меньше p-значение в диапазоне от 1 до 0.
Однако, нулевое значение недостижимо и свидетельствует о принципиальной проблеме: величина не случайна, ошибки в расчетах и т.п.
Аналогично с p-value ≥ 0.5, причём 1 можно трактовать как "полный туман/неизвестность", включая факт наличия самого p-значения.
Уж поправьте меня, если ошибаюсь. Но ведь все "много-раундовые" алгоритмы (примерно априори) принципиально уязвимы/нестойки к diff-атакам при возможности считывать/контролировать/искажать состояние между итерациями/раундами.
Соответственно, тут дело не в "консерватории" (AES), а в "пианисте" (программно-аппаратной реализации), и выстраивание подобной атаки (с начала и/или с конца раундов в зависимости от каналов утечки и/или влияния = дело техники и навыков).
Если (вдруг, всё бывает) проектировщики подобных систем (SoC и т.д) "не в курсе", то будем рады принять результат их работы к нам на аудит в ptsecurity.
На всякий, "в обнимку с ASAN" — это шутка на 50% ;)
C tsan у меня отношения не сложились, примерно как с drd и helgrind — либо не требуется, либо прилично фалсит (много false-positives) и приходиться разгребать руками:
Свой код уже автопилотно получается с минимизацией contention и кол-ва примитивов синхронизации, либо lock/wait-free если нужно.
Для чужого запутанного (особенно legacy) кода эти инструменты могут прилично фалсить. И вот после ReOpenLDAP в 2015 мне что-либо по-крупному чинить не приходилось (тьфу-тьфу).
Стандартом гарантируется совместимость только при неизменности определений (проще говоря при семантической неизменяемости заголовочных файлов) и использовании одного компилятора (включая его опции и т.п.).
В остальных случаях могут быть нюансы, т.е. нужно знать как внесенные изменения отражаются на уровне ABI.
У вас несколько неверное представление, поэтому вы пару раз перемешали мух с котлетами:
В контексте удобно рассказать о знатной бага-фиче с
[[gnu::pure]]в C++ и__attribute((pure))__в C:на злодля совместимости с gcc поддерживается фронтендом и обрабатывается бэкендом, а также честно виден через__has_attribute(pure).[[gnu::pure]]clang насильно включаетnoexcept(true), т.е. задним числом меняет тип функции (начиная с C++17).noexcept(false).Теперь представьте, что у вас проект с использованием десятка продвинутых C++ библиотек, в одной из которых есть трех-этажные шаблонны с абсолютно обоснованным использованием
[[gnu::pure]]в паре-тройке функций, т.е. с втихую добавленнымиnoexcept(true).Этот
noexcept(true)неплохо "протекает" через инлайнинг и IPO. При этом clang много чего оптимизирует/совмещает кадры стека и т.д. Соответственно, в каких-то случаях появление исключения приведет к вызовуstd::terminate(), а в других нет.При каких-нибудь жалких 10-20К строк кода отлаживать сплошное удовольствие. Я провозился несколько часов, пока не дошел до "поштучного" анализа unwind-таблиц. Что характерно, эта бага-фича гуглится элементарно, как только понимаешь связь между
[[pure]]и проблемами с исключениями. Но никак не раньше ;)Ну что сказать, реклама LLVM удалась ;)
Доступность санитайзеров и их дружба друг-с-другом зависит от платформы, версии софта и т.п. Например, если не ошибаюсь, в gcc 10.x на x86_64 можно включить UndefinedBehaviorSanitizer (ubsan) одновременно с AddressSanitizer (asan) или с MemorySanitizer. А при выключенном asan можно всегда включить отдельно LeakSanitizer c любым другим санитайзером. Но лучше смотреть https://github.com/google/sanitizers и доку по конкретному компилятору.
Но в целом, это RTFM.
Roaring Bitmaps не совсем то что вам нужно (не считая проблем шарповой реализации). А вот с CSharpFastPFOR померятся вполне уместно. Собственно этого достаточно чтобы соотнести результат вашего VLQ с остальными competitors в score-таблицах у TurboPFor и т.п.
Кроме этого, это поможет вам самим сориентироваться и решить куда двигаться дальше. Ну и конечно было-бы любопытно увидеть статью-продолжение с разбором полетов.
P.S.
На всякий — про качество кода CSharpFastPFOR мне ничего не известно, т.е. там тоже могут быть какие-то перлы.
Ждем наглядного процесса национализации TSMC в течение года?
Нет, совсем не так.
Вне зависимости от ученой степени ваша работа может представлять интерес (не быть дилетантской и наивной), если хотя-бы одно из двух:
А пока вы просто не понимаете как смешно выглядите, уж извините за прямоту.
Да, давайте еще раз:
Соответственно, замечательно что вы пытаетесь самостоятельно разобраться и придумать что-то новое. Однако, без ознакомления с наработанным опытом из первого пункта (совершенно вне зависимости от остальных) результат вашей работы (включая статью) рискует быть излишне дилетантским и наивным.
Пардон, ну так вы для начала просто прочитайте публикации Daniel Lemire по ссылкам.
Причем если Дэниеля внятно спросить что-то beyond RTFM (тем более по-французски), то он очень хорошо отвечает.
Daniel Lemire с коллегами занимался этой темой (Integer Compression) более 6 лет. Собрал, наработал и опробовал массу идей, опубликовал около десятка работ и довел до ума несколько реализаций. А в https://github.com/lemire/FastPFor/blob/master/README.md пожалуй лучший набор ссылок по теме, как на научные работы (т.е. идеи с глубокой проработкой и выкладками), так и на реализации (с оптимизацией и т.д.).
С одной стороны, здорово что вы пытаетесь самостоятельно разобраться в теме и что-то придумать. Однако, не стоит делать публикаций без минимального ознакомления с примерно общеизвестной (хотя и в узких кругах) информацией по теме. Уж извините, вовсе не хочу обидеть, но это достаточно вредный дилетантизм.
s/Berkley/Berkeley/g
т.е. основная ошибка с пропуском "e" осталась.
Советую ознакомиться с работами Daniel Lemire, Leonid Boytsov, Nathan Kurz и т.д. по данной теме.
Соответственно, недостает сравнения с https://www.roaringbitmap.org/ и https://github.com/lemire/FastPFor.
Без этого плюсануть статью совесть не позволяет.
На скриншотах снизу видна небольшая неточность — вместо "Berkley" лучше писать "Berkeley DB".
Ох, пожалуй я "за википедию":
Чем больше "замеров" и чем лучше они "ложатся" на статистическую гипотезу, тем меньше p-значение в диапазоне от
1до0.Однако, нулевое значение недостижимо и свидетельствует о принципиальной проблеме: величина не случайна, ошибки в расчетах и т.п.
Аналогично с
p-value ≥ 0.5, причём1можно трактовать как "полный туман/неизвестность", включая факт наличия самого p-значения.Уж поправьте меня, если ошибаюсь. Но ведь все "много-раундовые" алгоритмы (примерно априори) принципиально уязвимы/нестойки к diff-атакам при возможности считывать/контролировать/искажать состояние между итерациями/раундами.
Соответственно, тут дело не в "консерватории" (AES), а в "пианисте" (программно-аппаратной реализации), и выстраивание подобной атаки (с начала и/или с конца раундов в зависимости от каналов утечки и/или влияния = дело техники и навыков).
Если (вдруг, всё бывает) проектировщики подобных систем (SoC и т.д) "не в курсе", то будем рады принять результат их работы к нам на аудит в ptsecurity.
На всякий, "в обнимку с ASAN" — это шутка на 50% ;)
C tsan у меня отношения не сложились, примерно как с drd и helgrind — либо не требуется, либо прилично фалсит (много false-positives) и приходиться разгребать руками:
Просто остался на C/C++ в обнимку с ASAN ;)
Стандартом гарантируется совместимость только при неизменности определений (проще говоря при семантической неизменяемости заголовочных файлов) и использовании одного компилятора (включая его опции и т.п.).
В остальных случаях могут быть нюансы, т.е. нужно знать как внесенные изменения отражаются на уровне ABI.
Там действительно неплохая подборка, но не вопросов, а скорее советов. Причем жаль что без должного описания причин (например, отсылки к этому багу).
На всякий, поясню почему вас "минусуют" (и, видимо, с заносом в карму):