Loser story

Я конечно все понимаю, не очень популярный инвалидский дистрибутив и все дела. Но у всех зависает wildcard search по контенту пакетов в alpine? https://pkgs.alpinelinux.org/contents и попробовать поискать что-то в духе *symbolizer*

Я конечно все понимаю, не очень популярный инвалидский дистрибутив и все дела.Но у всех зависает wildcard search по контенту пакетов в alpine?https://pkgs.alpinelinux.org/contents и попробовать поискать что-то в духе *symbolizer*

Недавно в userver добавили реализацию счётчика на основе rseq -- restartable sequence.Идея не новая и встречалась как один из юзкейсов, когда это все добавлялось в ядро (4.18).Но в опенсурсе таких реализаций не встречал.Основное преимущество перед per thread счётчиком, то что thread-ов обычно больше cpu-cores, и как следствие чтения получаются быстрее, а записи аналогичны.Вообще впервые я встретил применение rseq в google tcmalloc, как замену per thread спискам блоков.И на мой взгляд это одна из лучших идей, которые я видел в современных аллокаторах. Потому что для очень большого числа программ, это сильно улучшает использование памяти.rseq исторически был сделан как раз для tcmalloc, хотя вероятно в гугле также заюзали и для метрикоподобных счётчиков.Ещё из интересного в glibc 2.35 затащили инициализацию rseq и в целом начали использовать для sched_getcpu.Вроде бы это произошло потому что пришли люди из mysql в redhat и сказали, а у нас медленно с вашим sched_getcpu, если сделать с rseq будет быстрее.Юзкейс аналогичный, шардированный счётчик.

Недавно читал про разные olap query execution engines: velox, photon, etc. Есть интересный момент, о котором я думал раньше, но не встречал на практике. Предлагается для строковых функций (lower, upper, reverse, etc) делать предположение об инпуте, ASCII…

Недавно читал про разные olap query execution engines: velox, photon, etc.Есть интересный момент, о котором я думал раньше, но не встречал на практике.Предлагается для строковых функций (lower, upper, reverse, etc) делать предположение об инпуте, ASCII он или нет.Утверждается, что в среднем это сильно ускоряет их, впрочем, если у вас только китайский текст, то вам такое не поможет, но вероятно и ничего не испортит.velox использует такой подход: Сделаем проверку на ASCII для инпута, если мы о нём ничего не знаем. Как правило эту проверку нужно сделать только один раз для инпут данных, так как большинство строковых функций принимая ASCII вернут так же ASCII.плюсы:* не требует ничего от стораджаминусы:* определяет ASCII или нет каждый раз* значительная часть времени для ASCII строк уходит на проверку, если бы мы знали заранее, что у нас только ASCII, было бы быстрее* незначительно медленнее utf-8 photon менее понятно, так как кода нет, но можно сказать что они так же имеют специализированные варианты функций.И возможно сохраняют некоторую мета информацию о колонке, насколько много в ней ASCII строк и нужно ли делать дополнительные проверки.плюсы:* читай минусы veloxминусы:* дополнительные вычисления на вставке/компактизации данныхВ заключение скажу что мне стало куда более очевидно, что для любой обработки строк стоит хотя бы сделать ASCII специализацию, и проброс ASCII or UTF-8, чтобы не считать это каждый раз.Например в lucene, да и у нас в поисковом движке, этого нет (при вставке текста, он проходит через множество функций токенизации), а сейчас я уверен, что это стоило бы попробовать сделать.Ещё есть прикольный момент, который я подсмотрел в реализации velox: часто специализация строковой функции для ASCII, реализацией совпадает с аналогом для последовательности байт, соответственно код можно переиспользовать.https://vldb.org/pvldb/vol15/p3372-pedreira.pdfhttps://people.eecs.berkeley.edu/~matei/papers/2022/sigmod_photon.pdf