Какое по счету выступление?
Ну я не считал как бы ну... нулей два, нулей два.
В одной из каких-то сотен.
Ой господи, тайм таймер он тикает.
Якобы у меня есть 40 минут, я в них не уложусь.
Я расскажу вам сегодня все про то неприятное
события, когда тормозит память, но на самом деле практически нет.
Это конечно же кликбейтный заголовок, более интересный кликбейтный заголовок и более корректный.
Это парсим гигабайт в секунду, а доклад конечно же будет вообще не про то, но гигабайта в секунду мы парсить будем.
Память у нас немножечко потормозит, поэтому я надеюсь, что
В целом, обещание сдержу.
Работаю я в авитушке, авита это такой, если вдруг кто не знает, классифайт на Святой Руси.
У нас там 200 миллионов активных объявлений, которые постоянно доступны и постоянно обновляются в основном поиске.
И еще немного побольше во всяких вторичных поисках, в личном кабинете, в админке, вот эти все дела.
Поэтому для кого-то Ван Биллион Роу Челлендж, который вышел 1 января, мы такие хм, блин.
И очень интересно, но к несчастью, те датасеты, с которыми нам надо работать каждый день, они в принципе таков уже порядка.
Так что Ван Биллион Роу Челлендж у нас на 1 января уже был.
И что забавно, вот эта вот задачка с партиком ТСВ, которая выросла, ну и которая тоже Ван Биллион Роу Челлендж некоторым образом.
Она у нас началась ещё в том году, в конце того года.
Поэтому Ван Биллион Роу Челлендж поучаствовать, конечно, не удалось.
что конкретно за простецкая задачка и тем не менее задачка прикладная, которую мы занимались и немного
Задачка – выгнать ибезид гевекторов, которые у нас частично всё ещё хранятся в посгрессе, хотя вроде бы, могу путать, вроде бы уже недавно выгнали их совсем.
Чего такое вектор на имбеддинге?
Зачем они нужны в эпоху победившего хайпа ЛЛМа и аяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяя
Расскажу, если интересно.
Зачем мы их туда вообще клали?
Мы начинали с того, что их, я не знаю, миллиона, а закончили и они маленькие.
А закончили тем, что их 200 миллионов, они большие, и они плохо вылезают в Позгельс.
Вот, соответственно, сейчас люди должны орать, но, видимо, люди спокойные пришли или просто в субботу
расслабленные, о чем тут вообще рассказывать?
Это же совершенно тривиальная задача.
Тебе надо попарсить долбаную ЦСВХу.
Наверное, все способны попарсить долбаную ЦСВХу.
Кстати, это ЦСВХа, а ТСВХа.
То есть даже кавычки обрабатывать не надо.
Да, правильно, верно, все верно.
Действительно, простое решение можно написать за полчаса, и потом его чуть-чуть заполировать, скажем так.
И в момент, когда оно такие начнет неизбежно тормозить на том или ином масштабе,
занести трэды, разложить его на несколько трэдов и, в общем-то, это для любых нормальных людей хватает.
И на этом натурально кончаются любые бизнес-потребности.
Про все это я не буду рассказывать, буду рассказывать про упортое решение и, дескать, упортое тормоза и упортое трюки, которые появляются, если выйти за рамки этих самых долбанных бизнес-потребностей, когда ты ускоряешь от простой решения и делаешь из него решение,
батарейки сел, у меня еще нет, у микрофона возможно
И снова седая ночью, то я ей доверяю, я. Раз, два, три, четыре, пять, шесть, семь, восемь, девять, девять, девять, девять, девять, девять, девять, девять, девять, девять, девять, девять, девять, девять, девять, девять, девять, девять, девять, девять, девять, девять, девять, девять, девять, девять, девять, девять, девять, девять, девять, девять, девять, девять, девять, девять, девять, девять, девять, девять, девять, девять, девять, девять, девять, девять, девять, девять, девять, девять, девять, девять, девять, девять, девять, девять, девять, девять, девять, девять, девять, девять,
Просто не было той вещи, которая не затормозила бы.
Ну, собственно, на мой взгляд, это как раз интересно.
О, предлагают переключиться на полку.
Тогда надо другое выключить.
С полкой мне, конечно, привычнее.
Итак, простая задача, более привычная ее формулировка.
У нас есть тот самый тсв-файл, то есть файли, в котором разделители банально Байтик №9.
Даже там ковычек нет, эскейпинга нет, ничего нет.
Просто дочитай долбанную строку, найди в нее Байтик со значением 9, все, ты нашел следующее поле.
Иногда это число, это и деха.
Иногда это число это еще что-нибудь.
В общем случае, этот механизм он у нас поддерживает все подряд, но в конкретном случае, в котором мы во всякой упираемся, он тупой, как палка, в нем две колонки, один ID документа, 64-битное число, и один какой-то вектор.
Виктора в свою очередь бывают разные, они бывают там, размера, не знаю, 37 флотов или 128 маленьких int 8.
Это все тоже надо поддерживать.
Взять такой файлик и подготовить его к индексации, скажем так.
Чтобы его джойнить с несколькими индексами, которые мы потом будем строить, мы его вот дески хэшируем и результат хэширования в бинарном виде сохраняем в файл.
Очень простая задача, и вот Эпик-шер из worth a thousand words, и вот она, это a thousand numbers, и значит задача выглядит буквально вот так.
Вот такой примерный файлик, там циферки, циферки, ничего не понятно.
И да, в этом конкретном файлике вот эти конкретные вектора каких-то фичей это вектор размерностью 47.
Как вот у дата сатанистов получился вектор размерностью 47, не спрашивайте.
Мне, как программист уносит, что угодно, что не является степенью двойки, не нравится.
Что я могу с этим поделать?
65 миллионов строк, неожиданно, несмотря на эти душераздирающие цифры, это не так много данных.
Это всего на всю 16 гигабайт, то есть у приличного мобильного телефона в оперативку вылезет.
Тем не менее, появляются какие-то гигабайты и миллиарды.
И, естественно, первое же, во что упрется ваш первый парсер, носишечки или C++.
И это, скорее всего, в СТР ТОД.
Банально, так как его придется три миллиарда раз вызвать.
Решение, в целом, подчеркиваю очевидно.
Распарсить, прохешировать, хешить, построить, сохранить на диск, все.
Что может быть проще времени?
Простое решение делается примерно вот так.
Все знают, что сишечка пытается из себя изображать питоны и получается у нее плохо.
Я имею в виду си плюс плюсик.
Всякие и стримы, отстримы, стринги, все это запредельно тормозит.
И, конечно же, перформящий парсер так писать нельзя.
Все понимают, что надо сделать дебютный проход в МАП, запустить указатель, вынимать циферки.
когда у тебя хэш тоже затормозит, конец, кстати, наступит как раз через 15 минут, но придется написать свой собственный хэш с какой-нибудь ареной, чтобы не было 4 миллиарда локаций.
И заодно на сдачу это еще и будет приятнее реализовать.
Это нормальное решение, так называемое.
Вот они совсем простое с истремами.
Спаси Господи, про него мы как раз ничего рассказывать не будем, я предполагаю, что все это вы и так знаете.
Если на дай Бог кто-нибудь не знает, то кулары подходите все вот эти дела.
А мы, то есть я, блин, во рту переслухал, переходим к букве Т. Т, я не знаю, что значит Т. Точнее, я догадываюсь, что значит Т, Т одновременно значит тормос, Т одновременно значит трюк, вот Т может значить что угодно еще, но кажется неважно.
Местами это будет тормос, а местами это будет трюк.
Местами это будет и то и другое, и тормос, и трюк для борьбы с этим тормозом.
Тормоз номер один для разминки под названием знают все.
Ну, сарян, надо с чего-то начинать и разминаться.
Хотя уже не время разминаться, пора доклад заканчивать.
На что заменить STR2F и STR2D в момент, когда они начали тормозить?
Предполагаю, что все знают, что можно его заменить на STD FromChars, или что интересно, можно заменить этот самый тормозящий STR2F и STR2D на одну из двух библиотек, которые, по-моему, базы для современных реализаций FromChars-то и являются.
за авторством по большому счету одного и того же товарища профессора канадского лимира и под названием FastFloat и FastDouble.
Я специально опускаю здесь бенчмарки, так как скорее всего бенчмарки на ваших данных и на ваших железь будут чуть другие, чем у меня.
У меня вот каждый раз, как я не упираюсь в подобный масштабный парсинг, и начинаю это обмерять, какого-то черта получается одна и та же история.
Для того, чтобы распарсить флот, быстрее всего работает штука под названием Fast Double.
Вот как несой, как неворочий.
Вот на моем железе, на моих данных почему-то именно вот так.
Ни стандартный FromChars, ни FastFloat, который, казалось бы, по названию должен быть быстрее всех.
Фаст-дабл, но есть дюанс.
Начинаю немного копать, потому что становится интересно и выясняется, что они тоже тормозят, типа чего, как может идеальное решение с оптимизированными веками в 2024 году тоже тормозить.
Ну, тормозит оно, конечно, в кабычках, и это упортный момент.
Но я залез туда внутрь, потому что мне стало интересно посмотреть, что находится внутри котика,
И у меня возникла мысль, а вдруг я туда залезу, повыкидываю, что не нужно, и оно у меня начнет работать еще быстрее.
Честно говоря, это уже не критично нужно, но очень-очень интересно.
И еще меня очень интересовал момент, до какого уж черта партсинг, который флот к W приводит, это оказывается быстрее, чем, значит, какая-то библиотека, которая якобы заточена именно под партсинг флотов.
И внезапно в этом месте я узнал две интересные штуки.
Performance поднял в итоге где-то раза в два тоже.
Интересная штука номер один.
Годный парсер почти всех флотов пишется сегодня в 24 году, оказывается буквально в 50 строк, из которых первые две, точнее не первые две, а ключевые две выглядят вот так.
Здесь я на слайде перенес, чтобы строк нагнать, и получилось целых четыре, но по факту их тут две.
Трюк, которым можно распарсить 99% целых чисел... О, это ставить целых чисел.
Трюк, которым в реальной жизни парсятся 99% потока, которым эти библиотеки пользуются, выглядит вот так.
Мы просто смотрим в строчку, смотрим, где там точка находится.
Видим строчку 1.234.56, накапливаем число 1.234.56, степень минус 2, а дальше банально делаем высокоточное дабл деления или, соответственно, высокоточное дабл умножения.
Потому что у дабл это точно большая, существенно больше, чем у флота, туда можно запихать в 53 бита манки с довольно много разрядов, и этого натурально хватает, блин, для того, чтобы распарсить флот в 99,9% случаев.
И, честно говоря, для того, чтобы распарсить достаточно маленький дабл, который типично вам все равно и будет встречаться.
Этого тоже хватает, и это можно распарсить.
В большом проценте случаев оно сработает.
Вот неожиданно, оказывается, я всю жизнь думал, что парсер флота написать, это разорвать все свои органы на британский флаг, но нет.
Оказывается, это очень просто, и ядро этого парсера – это реально две строки.
в такой вот интересной подлой трюку.
Правда, если его, значит, неаккуратно применять, то оно начинает промахиваться на границе точно представимого значения флота и иногда в трех случаях на 5 миллиардов округлять блин не в ту сторону.
Но вот есть небольшие спецэффекты, мне кажется, ими зачастую можно пренебречь.
А еще что я узнал, я не понимаю, по какой причине, но когда я просто взял вот этот фаст паз и буквально его скопировал к себе в код, какого-то черта он начал у меня работать двой быстрее.
Вот просто взял и начал работать двое быстрее.
Я ничего не делал, по сравнению с умной реализацией, я просто стырил её к себе к опипасту и вот быстрее.
Но внутри этого парстера я подсмотрел ещё одну ключевую идею, которую знал раньше, но обязан вынести на слайд.
И эта ключевая идея и ключевая фича заключается в том, что STD from Charsatenta тоже оказывается тормозит.
Возможно, некоторые хорошие реализации STD from Chars не тормозят, но в целом тормозят.
Так вот, инты мы, наверное, все умеем парсить, даже не с первого курса в УЗА, а с первого класса детсада.
И парсер весь выглядит примерно вот так вот в две строки.
Берем, идем по строке, умножаем на 10, вычитаем 0, все дела.
Что же тут можно сделать такого интересного и какого черта я вот эту чушь выношу на слайд?
Делать этого, если что, на всякий случай, именно делать в продакшене, скорее всего не надо за отдельно взятыми упоротыми случаями, дисклеймер такой.
Иногда надо, когда у вас там, не знаю, 100 гигабайт этих самых ТСВ или, скорее, терабайт в ближайшем будущем.
Но техника сама по себе очень красивая, и я считаю полезное право её упомянуть.
Это свар, сим-двизина-регистор.
Вот код, который простой, который ты пишешь первую версию талонную, который у тебя как-то парстинт.
Очень простенько, считаемый, всё хорошо.
Потом, значит, свежевыший джиджум такой заходит в эталонную production-ведку твоего метода MySTDfromCharts, видит там вот такое вот, им мгновенно увольняется.
Но, на самом деле, я считаю, что это хороший тест.
Если уволился, то, значит, сразу был ненужен нам с ним не попутись таким джуном, который такой простенький, снипет на 10 строк, разобрать, не способен размотать, особенно с учетом того, что он весь хорошо закомментирован.
Мне было бы очень интересно полезть, значит, в детали и по строчкам его разобрать.
Если кому-то еще интересно, куары, все дела, времени не так не хватит, что важно.
Вот этот код, это та же самая штука, что на предыдущем слайде, это тот же самый пар сербонального инта, просто по упору тому написанный использующий двор ды, как будто это сим-дрегистр, внутри которого лежит четыре маленьких числа.
Его абсолютно тривиально можно переписать, очевидно, на уинт 64 будет та же самая история, но будем обрабатывать по 8 байт за раз, а не по 4 байта за раз.
Забегая немного вперед на SSG2 и на VX2, код этот переписывать совершенно бесполезно, так как настолько длинные
целые числа вам будут встречаться в жизни примерно никогда.
И неожиданно именно вот этот вот дурной вариант именно с двордами или 8-байтными интами, он именно будет работать быстрее всего.
Почеркиваю, если детали кому-то интересны, вот там контакты, кулары, все дела.
Единственная правильная реакция на этот код, конечно же, вот такая типа «Матерь Божья, что происходит?» Но вот так.
И я неожиданно советую всем желающим и интересующимся при случае в порядке упражнения переписать парсерента или написать с нуля парсерента вот именно в этом упоротом стиля, а потом выкинуть его нахрен.
Он достаточно маленький, он скорее всего вам не потребуется.
И тем не менее это очень интересное упражнение, которое в частности, я считаю, поможет, например, ворваться в написание всяких симдов и всяких оптимизированных значит относительно штук такой относительно малой кровью.
потому что мозг у вас уже начнет переламываться на медаль мышления у нас в одном регистре лежит 27 чисел или там 13 до не степень двойки но все еще пока вместо хотя бы обычных хотя бы обычные битвы операции будут работать там обычные издвиги и так далее без дополнительного мусора в виде интринзиков типа ммн или там мм 512 и повторюсь это маленькое упражнение его не тяжело сделать значит советую продолжаем
что ещё подкинет нам реальность.
Следующий пункт — распарсить, прохэшировать, сохранить.
Распарсить, прохэшировать, сохранить.
Конечно же, хэш тормозит.
Ну, конечно же, хэш тормозит.
Но любая тема, любого доклада, но любой... Я считаю, что C++-конференция, на которой не тормозил хэш, не имеет права на существование.
Вот как бы... Но это невозможно.
Хотя бы один раз, хотя бы в одном докладе, неважно про что там, про статическую ренковку, про программин на перпокатах для Apollo 11 этот факт должен всплыть.
Конечно, упортое люди пишут свои крафтовые хэши.
Конечно же, они тоже тормозят.
Конечно же, у нас есть свой крафтовый хэш, конечно же, и он тормозит.
И тут у любого вменяемого слушателя, и у меня самого, когда я писал этот доклад, возникает вопрос.
Да что ж ты сволочь делаешь?
И этот стандартный хэш тебе плохой, и он тормозит.
Крафтовый, который ты руками заботливого выписывал, он плохой, и он тормозит.
Все, которые ты с интернетов взял, они тоже тормозят.
Ответ, я считаю, заключается в изобразительном искусстве.
Как правильно рисовать, товарищ?
за которую я топлю, она бывает штука кажущейся.
Вот так вот рисовать очень-очень долго.
Это просто довольно кажущаяся.
Да, выглядит просто скандинавский минимализм.
Но рисовать в таком стиле ты замучаешься.
Или вот так рисовать ты замучаешься.
Но вот этот вот бык образца 2020, образца гиперреалистов Бельгийских, если я не ошибаюсь, гиперреалистов 2020 года плавно переводят к нам к давно известным послевоенным концепциям, которые человечество в лице художников прохавало и переварило и продало на аукционах уже достаточно давно.
В данном случае я топлю за то, чтобы делать...
И один, значит, малоизвестный Павел давным-давно еще в 45-м нарисовал вот такого БК.
Но Павлу это не понравилось, и он решил его упростить.
Но Павлу этой степени непрощения не понравилось, и он решил его упростить.
Но даже ей эта степень упрощения недостаточно схематично до эксподина Пикасо.
Плюс, понятное дело, если ты нарисуешь 20 слайдов, то ты продашь 20 картину не одну.
Поэтому предельная степень деконструкции, на которой дошел Паша, выглядела примерно вот так.
Ну или по меньшей мере это предельная степень деконструкции, которую я сумел найти в интернетах.
Предельная деконструкция.
И в отдельно взятых местах кода именно она собакой нужна.
Вот весь хэш, который не тормозит.
А, вру, это половина его.
Но мы будем, наверное, не зачитывать эту половину, да, не зачитывать.
Мы просто считаем, сколько нам надо элементов, считаем степень двойки, считаем маску для того, чтобы это степень двойки, а локацию делаем не все тот самый тормозящий, все вот эти вот глупости.
А хэш – реализация хэша, вся реализация хэширования, которая работает ещё, грубо говоря, в полтора раза быстрее.
Крафтовый хэш таблицы, которая в свою очередь работает и так далее до бесконечности, он выглядит вот так.
вот это весь код, который у нас в продакшене, если что, делает хэширование.
Не трудно догадаться, что я скопипастил его полностью и не менял ни одного байта.
Потому что, конечно же, для целей доклада я должен был бы понтануться и ку заменить на pn, чтобы нормально читалось.
Но к несчастью там в контексте есть p, поэтому понятно, что p и q это начало иконец альфа и омега.
Ну, для эстетов можно, конечно, с именами
Переменных поиграть, но хэш выглядит вот так.
Вот это вот нехитрое хэширование.
Я, естественно, ни в коем случае не призываю никуда копировать.
Не считаю, что оно является предельным быстрым.
Мне сложно ускорить предыдущий код, но я тем не менее верую, что его можно ускорить.
И тезис тут у меня довольно прост.
Не про то, что вот этот вот код, это, дескать, некое искрагение, и надо весь код всегда так писать.
Но в редких, особых местах, в редких особых местах натурально в одном проценте, может быть, одной десятой процента случаев, надо не бояться деконструировать натурально то, что вам надо.
до предельной простоты, натурально до каких-то костей, тут мясо уже не осталось, и не боятся писать вот такой кот в тех местах, где он реально нужен и реально помогает.
И хэш — это вот этот хэш в этом месте — это одно из таких речайших мест.
В принципе, на этом теоретически можно было бы прекращать, значит, что-то, сказки тысяч одной ночи, но, конечно же, это была только разминка, а вот настоящие хардкоры и по-настоящему, на мой взгляд, интересные штуки, а самое главное, полезные начнутся только сейчас.
Слава богу, мне кажется, накинули времени.
Итак, теперь по-настоящему.
Следующий трюк, он же тормоз или что-то типа того.
Помним, помним, вот этот вот рефрен распларстить, сохранить, ля-ля-ля, трэдов накинуть и после этого любому бизнесу нормально будет.
Трэды, конечно же, тормозят.
В момент, когда ты их накидываешь, трэды, конечно же, тормозят.
Но тормозить не по трэд-креи, это не по трэд-дистрой, и не СТД-трэд.
Конечно же, как может ошибочно показаться, а технология, так сказать,
обкатанная годами и миллионами зря с вас жённых CPU часов, за носа этих самых тредов в production code.
Ну вот, смотрите, есть у нас задачка.
Надо попасть в 16 гигов ТСВ.
Да, очевидно, как решать.
Режем на 20 кусков, запускаем 20 тредов, пусть там считают.
Ну да, у нас будет какая-то стерилизованная часть фикстей, она относительно небольшая, зря мы что ли хэш упрощали.
Просто сделаем 20 тредов и там всё будет хорошо, но достаточно прилично ускорится.
И действительно достаточно прилично ускоряется.
Люди на этом, короче, успокаиваются и делают это, естественно, абсолютно зря, потому что вот это вот, верните мне мой, 2009, вы абсолютно в жопу неправильный метод за носа трэдов и раскидывание по воркерам нашей даже нехитрой и абсолютно примитивной задачки.
На трэды раскидывать вашу задачу, даже примитивную, как ТСВ, а не дай бог более сложную, в которой может оказаться более
Сложный счёт, который несколько ещё зависит от структуры данных, над, блин, совсем не так.
Ответ статический пул-задач, именно пул, а не очередь, потому что очередью это назвать невозможно.
Это натуральный вектор и это натуральный одинотомик счётчик.
Нельзя ни в коем случае в современной мультитредной среде, то есть в последние 20 лет,
Резать данные и один к одному биндить их на воркер 3D, надо их нарезать в маленький фарш и класть в пул.
Почему это охрененно важный?
Почему я считаю вот это, наверное, самый важный кусок доклада, самый важный, практически полезный?
Если вам абсолютно пофигу все остальное, вам, возможно, скорее всего, может быть, не сегодня, а на следующей работе или на предыдущей пригодится вот это вот сакральное знание.
Мне оно последние 15 лет позволяет поднять где-то 20-50 производительности многопоточной спола просто блин всегда, просто по нормальному раскидав задачи на трыды.
Удивлен, что, дескать, это еще не внесены в соответствующие методички, но вот не внесено.
Посмотрим код и посмотрим, чем он отличается от традиционного подхода.
Весь код выглядит вот так.
Я, правда, только сегодня утром понял, что комментарии про магию у меня не там.
Он должен быть либо на одну строчку выше, либо в обоих строках.
Эт весь код, я, естественно, проверял, он компилируется и работает.
Там еще 40 строк окружающего нет, но ключевой код выглядит вот так.
У нас есть какой-то вектор, он может быть глобальный, может быть спрятан в какой-то воркер-класс-хелпер.
Важно то, что у нас есть некий вектор с задач, некий фронт работ, который нам надо проесть, и мы поэтому вектору бежим.
Сколько тредов с токой джобов в воркере?
Немного более необычный ицикл, соответственно, в функции threadfunk нет.
Подход, за который я дико бежно топлю, я считаю его очень важным.
Один долбанный атомик-счетчик, один долбанный цикл, который при помощи этого атомика-счетчика из статического, больше не меняющегося, на момент запуска даже первого трыда вегтора, выгребает задачи.
И естественно, задачи нужно нарезать в мелкий фарш.
Их должно быть 20, их должно быть скорее 200, а лучше 2000.
Ну, иногда, возможно, даже 2 миллиона.
Весь вся магия происходит во-первых за счетатомик счетчика и за счет того, что у нас каждый свободившийся воркер, каждая очередная свободная касса выбирает следующую задачу и начинает ее обрабатывать.
Но, извините, если мы сделаем банальный вектор из 20 задач и намапим его на 20 ядер, как в модельном бенчмарке, у нас ровно обычный подход и получится.
Фарш надо нарезать сильно более
При этом предельно мелко его нарезать нельзя.
В самом деле мы не можем себе позволить парсить 16 гигабайт кусочками по 1 килобайту.
Это будет какая-то дурь и скорее всего это хорошо не взлетит.
Хотя, честно говоря, с атомиком может даже и 1 килобайт взлетит, но вообще, говоря, это такой себе подход.
Крупно нарезать тоже нельзя.
Получится, значит, обычный тот самый вариант.
В данном примере и в целом я ориентируюсь на то, чтобы
получался такой достаточно увесистый по размеру и главное по времени исполнения, чтобы он грубо говоря там был больше кванта скетчуэллера операционной системы, а это типично там миллисекунд 5.
Вот я обычно целюсь в миллисекунд 10-50,
Это сильно недогма и в отдельно взятых задачах выгоднее другие размеры или есть какие-то требования про другие размеры, потому что даже 50 мс для вас может оказаться слишком большой квант.
Тут к несчастью необходимы определенные искусства.
В данном конкретном примере у меня кванты и...
Размер джаба получались 4,5-4 мегабайта, чтобы попарсить.
И примерно за 5 мс и эти 4 мегабайта в конечном итоге в финальной версии уже со всеми остальными оптимизациями, собственно, парсятся.
И ускорение это даёт до двух блин раз.
То есть, реклама, которую я давал раньше, она оказывается ещё и в коей веке врёт.
Здесь небольшое лирическое отступление на тем того, какого черта так происходит.
Это лирическое отступление я вынужден сократить в 10 раз.
Я рассказывать про него могу в 10 раз больше, но краткая версия такова.
Последние 20 лет с момента выхода процессора Pentium D, у которого наконец-то стало два ядра, а не одно и одно с тех пор ядро обязательно немного ниже другого.
Вот с тех самых пор код у нас чуть менее чем всегда исполняется в многопоточной среде.
И всегда эта многопоточная среда чудовищна, неравномерна и никак не гарантирована.
Куда угодно ваш тред может перебросить скетчу или он может перебросить его с ядра на ядро.
Он может внутри одного CPU, он может перебросить его с одного CPU на другой CPU.
Он может тем самым соответственно засрать весь кеш этому труду.
Более того, даже если никого никуда не будут перебрасывать и афинити будет прибит к гвоздями, просто значит из-за эффектов неравномерности.
Исполнение проедания кыша и кэш-трешинга у вас эти 3D даже в идеальном мире без прерываний, без Affinity, без ничего, все равно скоты такие будут исполняться за сильно разное время.
Более того, последние лет 10-15, поскольку людям надоело, когда у них в 2007 году неудачно смонтированный процессор
А МД буквально плавился и прожигал материнку, с тех пор человечество быстро изобрело термальный тротлинг, то есть небольшой термодатчик внутри процессора, который такой, э, чё-то я сильно разогнался.
Давайте снизим накал и снизим частоты в десятера, чтобы не дай бог натурально не расплавиться.
И этот термальный тротлинг ты, извините, не отключишь вообще никак.
Если процессор решил, что ему слишком жарко, он себя охладит.
Кроме того, чипы физически разные, а внутри чипов есть неравномерности физические, которые приводят к тому, что абсолютно один и тот же самый код, исполняющийся на абсолютно, казалось бы, логически одинаковых ядрах, просто физически в разных кусках кристалла исполняется по-разному.
Типа на ядре номер 1 он исполняется на определенной спорости в 5,0 ГГц в режиме ван-кор-турбо на другом ядре просто перепиниваешь его на другое ядро и все мандец больше чем 4,8 с тем же термальным пакетом и так далее ты значит не увидишь
Кроме того, последние, значит, десктопные проции, последние три поколения, они оснащены еще ээфишенциядрами, которые специально тормозны по сравнению с перформансиями.
Кроме того, на сервере, а, да, ну, извините, я что-то увлекся и всего в пять раз сократил аумментацию.
Трыды, которые из-за всех этих дурацких эффектов, с точки зрения программиста, блин, эффекта один.
Ты вот запускаешь трет, а какое время он будет исполняться, тебе не дают гарантий, ну вообще никаких.
И довольно чудовищно, насколько тебе этих гарантий не дают.
Четыре мегабайта в секунду, пять миллисекунд, ну сколько мы ожидаем, что будет исполняться вот этот вот джоб.
Ну не знаю, там сей в полтора раза.
Это довольно сильно тормознули.
Сейчас кто-нибудь из зала может быть выкройки 20.
Кто-нибудь выкройкинуть что-нибудь из зала?
Я как померил, как бы ушанку выжимал, вот до момента прилета в Ереван с понедельника выжимаю, 110 и я такой, ну это, я, короче, может, дурак и неправильно что-то сделал, там запустил браузер с порнхабом, пока бенчмарка обчитывался, чтобы я тоже обчитывался.
Я всё переделал, я всё выключил на компьютере, я, дескотета, открыл окно, чтобы он получше охлаждался, окно, в смысле, в компьютере, и на улице жарко, и прибил всё к ядру и сделал 10 прогонов.
И в каждом прогоне, с приемпиненным, блин, ядром, в один долбанный трет с идеальным охлаждением и с предельной частотой на ван-кор-турбо,
И что интересно, вот эти 110 миллисекунд, я не знаю почему, и мне, честно говоря, не охота настолько хорошо разбираться.
Потому что это какая-то чудовищная сумма натуральна.
Она не объясняется тем, что Ох, операционка перебросила трет туда-сюда.
Она не объясняется кишом, потому что весь файл у меня уже давно в кише лежит, он отлично помещается в память.
У меня нет разумного объяснения, тем не менее у меня есть вот эти наблюдения.
И обратите внимание, что, естественно, когда у нас 20 трыдов, то у нас вместо 5 мс тоже получается 7.
Потому что, как известно, хорошо всем все же знают, что процессора не умеют работать с одинаковой частотой на всех ядрах достаточно хорошо.
И что в 1-кварт-дурбу даже на те уровнях процессорах существенно меньше, чем у 1-кварт-дурбы.
Ну вот мы это, конечно, все знаем.
Разлет вот такой чудовищный и нормальными методами ему не помогает ничего.
ровно поэтому нарезка джабов по всем вот этим спецэффектам спецэффектов много а решение супер простое нарезка фарш и эффект от него термоядерный вот значит нехитрая табличка которая сравнивает обычный подход с нарезкой как раз там на 20 кусков или 8 кусков и так далее и подход с нарезкой
моего тестового файла в мелкий фарш по 4 мегабайта.
В пределе два и четыре десятых, блин, раза ускорения.
И минимальное ускорение, которое я в принципе вижу на глупых двух трыдах уже полтора раза.
То есть те самые 50 процентов, которые я и обещал.
То есть плюс 20-50% вы получите вообще всегда, плюс 20% в том случае, когда у вас сразу были джабы, которые относительно неравномерны, но относительно маленькие, может быть, вы их уже как-то начинали проедать, но недостаточно допилили.
В данном примере, извините, я споло поднял тупым циклом и тупым атомик щетчиком.
лишних 2,5 раза производительности.
Возможно, самый главный слайд доклада, так как, в отличие от всего остального, холокоста вот это дело хотя бы практически применимо и подчеркиваю с момента пенсиум D применимо для всех.
Фух, слава богу, можно меня выгонять со сцены, потому что с важным я закончил, ну вот и с метафизическим про хэши и пикасо тоже, но
Тогда мы не узнаем самое интересное.
Самое на мой взгляд интересное, то есть те самые упоратые техники, которые я обозначал буквой U в начале.
SSD, конечно же, тормозит.
Здесь я все свои элементации срежу насчет того, что я пробовал, а, поверьте, я кое-чего пробовал.
Единственное, что я не пробовал, это, дескать, абсолютно синхронную
запись, чтение, разрезать все на блоки, запустить достаточно тредов, чтобы один блок что-нибудь считал, быстро-быстро пихал в какую-нибудь МПМЦ очередь, которая через юринг перекладывала куда-нибудь еще.
Я решил, что это будет довольно неинтересно, но кое-какие трюки с мегапоточной записью и так далее, я все-таки попробовал.
Кроме как апгрейдам железа, кажется, что стербозящим ССД сделать ничего чуть менее, чем невозможно.
Но мы же умные, как бы, программист бывает сильный, а бывает умный.
Вот сильные носят все, а умные носят только люмение, а чугунья стараются не носить.
Если ССД тормозит, то, может быть, надо им не пользоваться.
Если у меня тормозит операция записи 13 гигабайт на ССД, то, может быть, не надо писать 13 гигабайт на ССД.
Пожите, но мне надо записать 13 гигабайт на ССД.
Пожите, а вдруг они жмутся?
Что если я их к зипам пожму?
Ни в коем случае не пользуйтесь гзипом, гзип тормозная параша, которая должна умереть еще 15 лет назад.
С момента изобретения божественных ZSTD и LZ4.
Не пользуйтесь ничем, кроме LZ4 вообще ничем.
Только LZ4 в ситуациях, когда вам нужна приличная скорость.
А приличная скорость в данном контексте это хотя бы от одного жалкого гигабайта в секунду.
Все остальное не даст вам такой скорости сжатия, LZ4 не тормозит.
Но для этой задачи он тормозит.
Несмотря на то, что эти вот бинарные вектора фичей, LZ4 жмет достаточно недурно, обеспечивает приличное сжатие 35-40% от оригинальных данных, 13 с чем-то гигабайт превращается в 6.
Плохие новости заключаются в том, что даже супер-быстрые лз4, которых их жмёт на очень-очень хороших полутора гигабайтах, блин, в секунду, не разжимает.
Упирается он при этом естественные в CPU и в память.
Я, честно говоря, не мерял во что больше.
подозреваю, что, как обычно, на современных процессорах там не настолько много счета, насколько много елозения по памяти, когда LZ4 свою хэштабричку, значит, обновляет.
Вот, возможно, это можно разложить на n-потоков, перекрасировать записью как раз на SSD, сделать блочную запись, чтобы и маленькую внутреннюю виртуальную файл-систему.
Вот, но, к несчастью, эти эксперименты мне
Мне оказался другой эксперимент, как обычно, разрезать котёнкой и посмотреть, что там внутри собаки внутри.
Дальше небольшой интродакт рекурс за две минуты в данных любой алгоритм.
Любое сжатие, это очень просто, сейчас объясню.
Короче, нормально делаем, нормально будет.
то, что часто, короче, кодирую малым числом бит, а то, что никогда не встречается, кодирую, короче, большим числом бит.
Вот весь курс, значит, теория информации и сжатия.
Все остальное — это вот база такая, самый фундамент.
Все остальное — это примерно 723 техники, которые человечество придумало на предмет того, а как конкретно детектить, что частое, а что редкое, и как конкретно кодировать в большее или меньшее количество бит.
Про свои данные я все хорошо знаю.
Внутри у них флаты и их дата сатанисты вручили в своих долбанных СТСВ файлах.
В тех местах, когда они вручают их нам в виде бинарных файлов, у нас волосы мягкие и шелковистые.
Мы с этими бинарными файлами в этот момент напрямую работаем.
Но вот иногда вручать такие тексты мы приходим приседать.
Что там может повторяться внутри этих векторов?
Если большая вероятность у нас в 128-мерном пространстве маленьких имбеддингов из нашего прода или большом пространстве в 1536 измерения имбеддингов из чат GPT, у нас будут повторяться большие группы координат.
Прям вот подряд типа первая, вторая, третья, четвертое, пятая вот в этом векторе одинаковые.
Конечно же нет, нету такой вероятности.
Ну, дальше очевидное изображение, блин.
А раз там отдельные компоненты повторяются, то, может, посмотрим, как они повторяются, и может быть, можно жать сильно проще?
Оказывается, в том датасете, конкретном датасете, который у меня был действительно довольно много фичей, которые банально занулины, в каких-то других датасетах и в каких-то других коллекциях фичах статистика будет другая, там вместо 0 в топчике будет там какое-нибудь странное значение типа 91 и 0,
которое я даже в этом своем татасете тоже увидел на позиции топ-7.
И дальше нехитрый расчет на салфетке, вот проведенный в последней строчке показывает, что если мы топ-3 значения будем кодировать в два бита, оставив один бит на то, чтобы кодировать out of band значения, про которые мы не знаем, что с ним делать.
Если мы топ-3 значения будем кодировать в 2 бита, а все остальные в 33, использовав один этот самый бит для того, чтобы передать сигнал, что сейчас поедет число, которое нам раньше, ну, не то что не встречалось, но которое в топ-3 не входит, то у нас получится коэффициент сжатия 0.376, который, честно говоря, там был сильно похож на коэффициент сжатия LZ4, который был в свою очередь тип там 0.369.
Дальше примерно за 10 минут ты видишь вот такой вот энкодер.
Это весь энкодер, который просто банально сравнивает на равенство с тремя топовыми значениями, которые ты заботливо посчитал заранее и, естественно, заботливо посчитать заранее на тонь и топ значения, что их можно посчитать, блин, по первым 2 мегабайтам.
Если они ультимативно топовые, они будут ультимативно топовой везде.
Если они не ультимативно топовой, твоя нехитрая идея отставить, моя нехитрая идея оказалась, как ей полагается, тупой и в продакшн поэтому не пойдет.
А дальше самое интересное.
Как ни странно, вот я же говорю, важное я уже рассказал, а теперь самое интересное.
Вот этот вот прототип естественно работает.
Он, естественно, и декодер для него написать не тяжело.
И что очень важно, очень вот важно в сжатии данных, написать декодер, который данный все-таки разожмет и проверить, что ваш гениальный алгоритм не сжал всю вселенную в ноль бит.
Потому что много таких гениальных алгоритмов, но для них сложно написать декомпрессор.
Для этого кода, слава богу, потому что его 10 строк, где компрессор мне написать, удалось.
И он действительно побительно восстановил нужный мне файл.
Потом, как обычно, вы уже догадываетесь, что сейчас будет, уже вот очки вот эти вот, на готове должны быть.
Ну, конечно, но тут всего 20 строк макарон.
И опять первые 20 строк макарон,
Это вот чистая копипаста, которая делает то же самое, но на AVX два регистрах.
Все, что делают вот эти вот 10 строк, это всего на всего сравнение с ТОП-1, ТОП-2 и ТОП-3, только по, извините, 256 бит за раз.
Ну и дальше вот дополнительная копипаста, весь вот этот кодек в 20 строк.
Предыдущая версия, естественно, была скалярная, скажем так, медленнее, чем LZ-4, как ни странно, незапредельной.
Медленнее, как ни странно, она тоже уже или даже чуть-чуть быстрее, не важно.
А теперь самое на мой взгляд интересное и вот крыша сорвательная до сих пор значит приятно удивляюсь.
Как вы думаете, с какой скоростью вот это вот дело работает с учетом того, что LZ4 супер быстрый годами оптимизированный, которому ты в зависимости от того, какую ты ему степень сжатия выставил, он сильно разную скорость показывает.
Если самую запредельную, которую по-моему даже с командной строки выкрутить нельзя, приходится немного в C++-ном коде, но может быть и можно с командной строки, просто мне было ли не выизучать командную строку.
с какой скоростью работает вот этот вот код, если приличный работает на скорости 1,5 гига в секунду.
4, 5, там, может быть, 6, 7, 19.
Вот я откровенно признаюсь, я этого не ожидал абсолютно.
Но дальше меня посетило слава Богу.
Иначе бы этот доклад еще на два часа растянулся, меня посетило гениальное озарение.
И я сумелось с 19 сделать 25.
И сейчас я вам покажу магию, как из кодера уже безумного, которая работает на скорости 19 гигов в секунду для конкретных датасетов, для нормальных данных он не работает.
Но, блин, 19 гигов в секунду.
LZ4 тормозит нам где-то хвосте.
Из этого, оказывается, можно сделать 25.
Это был единственный метод сделать из этого 25 гигабайт в секунду, потому что дальнейшее приседание с дальнейшим анролингом, попытками завести, а вы x512 и тдтп за разумное время не давали ничего.
И по ходу, в этот момент этот ходер, несмотря на то, что он там совсем мало счета делает, вот видимо в этот момент он достаточно уже упирается и в счет, и в память, и вот
Дальше его ускорять приходится только методом в кавычках переписывания на MEM-CPI.
Ну, MEM-CPI, естественно, не делает ничего.
Но на этой же тестовой машинке работает на 25 гига в секунду.
Почему не, значит, впрод не пошло, расскажу отдельно.
Вот, спойлер, потому что больно сложно, а выигрыша все-таки никакого с этого к несчастью.
И это для меня самое большое открытие, которое я в доклад занес.
Я не ожидал вообще, что удастся делать нетривиально работу, прилично сжимать данные на таком безумном темпе.
Для меня это было личное открытие, а для меня личное открытие к несчастью происходит редко, не каждый год.
Вот в продакшн не пошло, зато границы доступного
Зато теперь я знаю, что если я в подобную опрусь, то оказывается иногда нечто, что казалось ранее невозможным, таки возможным.
Ну и вот оно оказывается возможным.
Это уже был трюк slash-tormus номер 9.
И поэтому их, конечно же, осталось два.
Естественно, заявлено, это было 10.
Когда тормозит память, то, собственно, частично память тормозит уже вот в этих местах, в LZ4, в кодрах, это DATP.
Но если обставить таймерами вообще-вообще все-все в своей программе, и иногда для этого приходится обставить таймерами момент выхода из программы, и, там, затаймить снаружи, то внезапно выясняется, что еще пара неожиданных мест тормозит.
Memset тормозит, который я цинично спрятал между T4 и T6, у меня сменилась номерация, и я вот ее возвращаю.
который выражается в MnMap.
И, естественно, Free у меня тормозит.
Не потому, что у меня 4 миллиарда локаций, а локаций в одном из экспериментов у меня была одна.
Я сделал пол, на все нужные мне 16 гигабайт, и пытался с этим полом работать.
И даже оно тормозило, и это понятное дело.
Странички по 4 килобайта анмапаются, и это понятное дело.
внутри ядра перестраиваются структуры, которые делают буккипи на maintenance этих самых страничек отмапленного, достаточно большого адресного пространства иными словами.
В момент, когда вы делаете достаточно большой фри, просто банально трогая достаточно большой по количеству объемов данных, вот будет неожиданно тормозить даже фри.
Он же в конечном итоге и в MUNMAP уйдет.
Единственное, если вы действительно все-таки делаете фри, и память в операционку возвращаете.
Да, скорее всего, здесь можно поиграться с huge pages и вот этим всем.
Я попробовал, скажем так, за 15 минут не взлетело, возможно, я пробовал криво.
Если кто-нибудь знает как правильно, то пожалуйста пишите и обязательно в следующий доклад вставлю, что вот фрит тормозит, но разогнать его удалось.
Возникает резонный вопрос.
Ты там совсем умом поехал, на кой хрен это делать?
Значит любой нормальный темлит, и я в том числе, по голове вот настучит вот этим микрофоном, который работает и поэтому тяжелый, а не легким, который не работает.
Ну короче, и тут мы ответим решительно и гневно.
Пацаны, посмотрите на профайл.
Медледолбные мемсеты Free в этом профиле, ну да, они не 60% времени, которые, что так, что это, что с компрессией, что без компрессии, в итоге пожирает запись на ССД, с которой ничего сделать не удается.
Ну, за разумное срок, я имею в виду.
Если мы за две минуты и за две строки кода,
Сумеем саптибизировать 8%, то мы за две минуты и за две строки кода сумеем споло поднять 4% производительность.
Ну давайте конечно попробуем, но с условием больше двух строк кода мы на этот тратить не будем.
Оказывается, значит, большим количеством строк кода MEMSET можно DATSAL переписать руками, написать ELIENT AVX2 или AVX512 версию и она кроха туличку, на там процент, но все-таки быстрее работает, чем абсолютно такая же реализация в GALIPC, но с махненьким количеством ивчиков внутри.
Ну вот, но это конечно копейки и имени заниматься мы не будем.
Если раскидать банально вот эту работу на несколько трыдов, и если в том месте, где мы делаем мемсед для хиша, примерно всего-навсего на гигабайт, там где-то гигабайт данных иногда даже меньше, если в этом месте раскидать этот мемсед на 2-4-3-да,
Мы натурально уверенно и гневно замечаем, как там полсекунды мы скроили, грубо говоря, там или 200 мс.
Безумие, конечно, но вот так.
Предполагаю, хотя не успел попробовать, что в натурально в одну строчку это можно сделать, написав программу ОМП паралл, и там четыре кусочка, четыре мемсета, чтобы они как раз автоматом раскидались на четыре 3D.
Вот Хьюдж Мало, моя идея, мои деньги на Хьюдж Пейджес, но не срабатывать.
Вот, время давно кончилось, я, очевидно, работаю на заемном.
Оно и сейчас кончилось, оно и тогда кончилось, потому что, естественно, это значит, вся развлекуха была на первые майские, потому что, естественно, любой темлит сам себе, в первую очередь, стучит микрофоном по голове, что нельзя такой херней заниматься в рабочее время.
Вот, на вторых майских я занимался чем-то еще, о чем я расскажу, наверное, когда-нибудь в будущем.
Но сегодня то, что мы узнали, в ходе хаотичного доклада и пробега по всяким странным местам и темным углам, не то чтобы даже если плюс-плюс, а библиотеки, процессора и всего вот этого вот.
Если сводку подвести, она довольно большая.
Честно говоря, она у меня в памяти не отложится, но тем не менее она вот.
В программке, которую никто не читает и обещали, 10 пунктов вот они, получите распишитесь.
Некоторые из них ни вам, ни мне в продакшене нахрен не нужны.
Например, в божественной кодке HZ3, которая очень хорошо себя проявляет на некоторых данных, а на других совершенно отвратительно не нужен совсем, он у меня в продакшен не пошел, так как ну больно блин сложно.
Но некоторые из них вы можете применить мгновенно, если вдруг у кого-то в проекте str2f в конце концов и если вдруг он хоть немного проявляется на профайлере, но кажется, ничего не стоит в одну строчку заменить на фромчарс и так далее.
А в некоторых местах я, значит, топлю за то, чтобы вы не боялись применять те или иные запретные техники типа написания hash таблицы в 5 строк, потому что вот, дескать, тимлит, значит, запретил, но вот на конференции разрешили.
Если запомните что-нибудь одно, как я, я зачастую даже одно не запоминаю, а только половинку, то прошу запомнить вот это вот.
Самое главное, если у вас есть два трыда, а обычно у вас есть два трыда в современную эпохню, то, пожалуйста, ни в коем случае не делайте два джаба на эти два трыда, если у вас джабы, ну,
Блин, не знаю, минимально больше одного мегабайта исполняются там длиннее одной миллисекунды.
Это вам обязательно убивает производительность, и если вы нарежете свою работу на фарш достаточно мелкий и раскидаете ее по воркерам, через банальный атомик счетчик, блин, и через неизменный, не мутабельный вектор, то будет невероятно лучше.
Я практически гарантирую, что процентов 10-20 в таких
в ситуациях будет всегда.
Здесь мы вот видели, аж два раза это к несчастью не нагнанной бенчмарке.
Ну и лично для себя я еще втыкаю сладь, что оказывается, даже если супер-быстрый LZ-4 или что-нибудь такое тормозит, это еще не конец.
Оказывается, в некоторых ситуациях можно выкрутиться.
Я вот этого раньше не знал, теперь знаю.
Про списанию я стою перед обедом, так что, наверное, пора поесть, но есть альтернативный вариант позадавать вопросы.
Я не очень понимаю вопрос, что означает не тормозит, если это про ХЗ-3, который не тормозит.
Сложно будет перебить 19 гигов в секунду, в момент, когда ММСПР работает на 25.
В этот момент я готов пожертвовать вот этими 20% и сказать, что все быстрее не то, чтобы невозможно, но дальнейшие усилия они абсолютно не стоят свечи.
Вот это я означает не тормозит.
По большому счету это единственная важная метрика и есть.
Не тормозит это когда дальнейшее усилие по оптимизации уже не выгодны.
Уже дальше ни геморрой не стоит свечи.
Это занимает примерно 50, наверное, миллисекунд в самом начале, на той самой SSD-хе, по за счет того, что сикет у нее быстрый, берешь, запускаешь указатель, грубо говоря, им-мапом или просто банально рядами, идешь по файлу, кусками не менее 4 мегабайт, вычитываешь чуть-чуть данных и дочитываешь до конца строки.
После этого у тебя получаются нифига неровные блоки, там, 4 мегабайта плюс 120 байт, 4 мегабайта плюс 247 байт.
Но, извините, на общем фоне они достаточно ровные и достаточно мелкие.
Так что там никакой магии нет.
Спойлер, оно на профайле на самом деле тоже есть, просто из этого профайла я его скрыл, оно занимает около 50 мсн.
Я ожидал, что будет больше и придется играть размером блока.
Оказалось, прям достаточно хорошо, даже на тормозном серверном ССД.
Будет конечно же хуже, потому что в этот момент у тебя длина кода для топ 523 будет 10 бит и для топ 511 будет 9 бит.
И вот этого большого количества бит, которое ты потратишь на номер, его скорее всего не хватит, чтобы покрыть 100%.
И наоборот, в тех местах, когда у тебя частотное распределение значений такое, что натурально 99,9% укладываются в топ-500, скорее всего, в этом случае окажется действительно выгодно использовать 9 бит.
Вот с алгоритмами сжатия всегда вот такая адаптивная магия, ты всегда должен либо статически заранее, посмотрев на свои данные, либо динамически проанализировав эти данные онлайн, понять, какое у тебя частотное распределение и какое количество бит на вот этот нехитрый маркерный код даст тебе оптимум.
В данном примере 3 на другом Dota Set будет 7, на другом Dota Set будет 31 и так далее.
Это можно и запрограммировать в принципе тоже там математика в одну строчку.
Так, значит, правильно ли я понимаю, что другое?
Настя, размер под задачу играет в эфире 4, как в этом конце даже реза.
С одной стороны, имперически, а с другой стороны, на всех довольно разнообразных задачах, на которых этот трюк приходилось проделывать, оно как сформулировать-то бы корректно, оно неожиданно примерно к одним и тем же значениям приходит.
То есть ты хочешь уложить это дело в несколько миллисекунт во-первых, чтобы там сравним с квантом для трыда было, и ты хочешь успеть полопатить какое-то разумное количество данных.
И как несу и как не ворочей, что-то СВ хупарсить, что там, я не знаю, обратный индекс обыскивать, что еще чего-нибудь, это несколько мегабайт.
Соответственно, у меня прямо уже рулов там определенно есть, что я начинаю, там группу говорят с одного, там мегабайта, двух мегабайт, а дальше вот ворочую действительно размер блока, если у меня слишком медленно или слишком быстро исчет.
Вот это как раз та самая часть под названием, как бы нам обустроить запись 13 гигавт на диск, она длинная, нудная, но у нее натурально просто не было времени.
И у меня интуитивно плохие ожидания от того, что я могу наэкономить.
Просто банально потому, что вот 500 мегов в секунду, и вот эта физика будет с нами обязательно на саташном ССД и там 1,5 гигавт в секунду, вот с этой физикой ничего особо не поделать, и с ней бороться сложно.
Попробовали ли по 4 мегабайта по джабу?
Я все необходимые настройки покрутил, может быть, ошибся.
Может быть, какая-то тупая ошибка там в короласе.
Действительно, если просто поставить huge pages в среде и там какую-нибудь, не знаю, забыл дёрнуть какую-нибудь функцию из ГлебЦ, которая тоже изоторическую сильно, которую надо было дёрнуть.
Может быть, есть такой риск.
Так, здесь есть вопрос, который, я плохо понимаю, KV-SZD от Samsung.
Интеловский SPDK, чтобы писать на диск?
Интеловский SPDK, чтобы писать на диск?
Интеловский SPDK, чтобы писать на диск?
Интеловский SPDK, чтобы писать на диск?
Интеловский SPDK, чтобы писать на диск?
Интеловский SPDK, чтобы писать на диск?
Интеловский SPDK, чтобы писать на диск?
верую, что он может быть, верую, что... Я верую, что с диском что-то можно еще сделать.
И, например, хотя бы сделать так, чтобы относительно разумными усилиями вот это вот комбас сжатия и аккуратно зашедуленной физической записи, чтобы хотя бы она не сериализовано шла, не подряд, как, собственно, у меня на простых бенчмарках, и от чего, значит, простыми мерами эффекта нет.
Но это уже сильно выходило за рамки развлечения в субботу вечером на первых майских.
Да, верую, что можно поковаряться и там упороться в запись, аккуратно ее раскидать.
Мне показалось, возможно, ошибочно, что это долго слишком.
Есть интересный вопрос, что если не кнавертировать строку в число работать со строкой?
Это будет довольно медленно, если мы начнём инференс там какой-нибудь катбустовой модельки гонять в строках, кроме того, это потребует от нас переписать весь катбуст и затормозить его прикидочный раз в 100.
Поэтому, извините, но опции со строками там нет.
Потому что конечный получатель этих данных, если чё, это в конечном итоге один хрен какие-то ML-модели.
Это входные данные, сыры для них, имбединги и прочие, возможно, не имбединги, а какие-то сыры в кавычках фичи, которые, в свою очередь, насчитаны другими моделями.
Потребитель — не человек.
Потребитель — ML-библиотекотель и иная.
У нас вроде бы в этих местах кат-буст, но я могу ошибаться.
В большем количестве мест кат-буст может где-то еще какой-то инферензовился.
Окей, ну и последний завершающий вопрос, если ядер не 2,16, а, например, 2000, как у ГПУ, насколько мелкий фарш-задачью должен быть?
Или после какого-то значения это не зависит от количества ядер?
О, с ГПУ, с ГПУ-хой вроде бы давно я не программил ничего под ГПУ-ху, но теоретически там та же самая история может быть.
Другое дело, что ГПУ-ха, насколько я ее помню по годам древним, она
как ни странно, сильно более предсказуемо, если у тебя там, грубо говоря, в колычках шейдер или как это там называется, куда программа в определенное количество инструкции укладывается, то она, в отличие вот от этой чудовищной дрожи, когда один и тот же мелкий джоп, то 5 миллисекунд исполняется, то 10, то 110, вот настолько чудовищного дрожания на ГПУ я не наблюдал.
Но у меня, правда, к несчастью, данные устаревшие на много лет.
Поэтому, возможно, на ГПУ с этим попроще.
И возможно, что на GPU более-менее вровень нарезать, и менее жестко раскидывать на 3D, да, свой эффект.
Ну, там действительно и компьютер-шейдеров обычно сильно больше.
Поэтому, думаю, за счет этого в этом месте должно быть проще, типа как раз просто статически разрезало, сильно более быстро досчитывающиеся джабы и относительно все хорошо.
Но об этом что-то, если узнаю, то расскажу в каком-нибудь светлом будущем.
Для этого надо GPU опять попрограммировать.