Коротенькая статья по хранению векторов для #LLM (в статье для Ollama)
🔥2
Я тут ковырял MSSQL в одном проекте, а там использовалось page data compression для разного второстепенного барахла, что здорово сжимало данные и уменьшало IO. И надо сказать page data compression отлично подходит если данные меняются редко, а жмутся хорошо. И вспомнил, что в Postgres есть аналог, ну как аналог... штука, которую тоже можно использовать для сжатия данных - TOAST. И нашёл статью, где неплохо описывается в т.ч. структура (как оно лежит внутри) - и да, это полезно для понимания процессов и применения - где/когда можно, а где не стоит. #postgres
👍6🔥1
В .net 9 завезли поддержку OAuth 2.0 Pushed Authorization Requests и вот статья с примерами реализации (да, на примере Duende IdentityServer) #dotnet
🔥6🤯1
Чятики принесли интересную штуку - какой-то новый профайлер для дотнета. Опенсурс, но по фичам надо сравнивать с dotProfiler и dotMemory конечно. #dotnet
👍2
Ещё один закат солнца вручную - message queue поверх Postgres - pgmq.
Зачем? Не знаю.
Почему? Потому что могут!
Пытаюсь придумать кейс для использования, но что-то пока не выходит. Вроде и версия 1.45, хоть щас в прод! :))) #postgres
Зачем? Не знаю.
Почему? Потому что могут!
Пытаюсь придумать кейс для использования, но что-то пока не выходит. Вроде и версия 1.45, хоть щас в прод! :))) #postgres
🤔3🔥1
Интересная книга "The Internals of PostgreSQL" с картинками! По краткому прочтению - must have для разработчиков. #postgres
👍7
Тут на соседнем канале зашла речь про ускорение некоторых алгоритмов с помощью SIMD и я побыстрому накидал реализацию двух - косинусное сходство и корреляцию Пирсона (на скриншоте бенчи для него, для косинусного сходства - в камментах в gist). Алгоритмы как будто прямо таки созданы для Single Instruction/Multiple Data :)
Первый блок на скриншоте - просто мап на Vector<double> и дальнейшие операции, ничо сложного, но даже это даёт 6-кратный буст. Второй блок с float, тут ещё побыстрее, просто потому что элемент в 2 раза тоньше и за один чпок забирается в два раза больше элементов по сравнению с double.
Но вот дальше там был ещё один кейс, когда входные данные короче И double И float - например short. И вот тут становица всё ещё интереснее: отмапленый в Vector256<short> забирает сразу 16 элементов входного массива. Напрямую в Vector256<float> такое не смапиш конечно, поэтому операция двухэтапная - сначала GetLower/GetUpper по 8 элементов экспандяца до int (32 бита = 256 бит), а потом кастяца до float (тоже 256 бит).
Вроде выглядит некоторыми костылями, но это даёт 14-кратный буст даже на длинных массивах, которые гарантированно не влезают в L2 кэш. Если кастить в 32-битный float конечно, с double ситуация пожиже - там буст ровно в два раза хуже (~x7), что вполне логичо :))
Судя по всему выполнение SIMD инструкций тут отлично сочетается с асинхронностью L1/L2-кэша - пока локальные данные кастяца, множаца и складываюца - в кэш подтягиваются следующие порции данных и к моменту следующей итерации они уже там. #simd
Первый блок на скриншоте - просто мап на Vector<double> и дальнейшие операции, ничо сложного, но даже это даёт 6-кратный буст. Второй блок с float, тут ещё побыстрее, просто потому что элемент в 2 раза тоньше и за один чпок забирается в два раза больше элементов по сравнению с double.
Но вот дальше там был ещё один кейс, когда входные данные короче И double И float - например short. И вот тут становица всё ещё интереснее: отмапленый в Vector256<short> забирает сразу 16 элементов входного массива. Напрямую в Vector256<float> такое не смапиш конечно, поэтому операция двухэтапная - сначала GetLower/GetUpper по 8 элементов экспандяца до int (32 бита = 256 бит), а потом кастяца до float (тоже 256 бит).
Вроде выглядит некоторыми костылями, но это даёт 14-кратный буст даже на длинных массивах, которые гарантированно не влезают в L2 кэш. Если кастить в 32-битный float конечно, с double ситуация пожиже - там буст ровно в два раза хуже (~x7), что вполне логичо :))
Судя по всему выполнение SIMD инструкций тут отлично сочетается с асинхронностью L1/L2-кэша - пока локальные данные кастяца, множаца и складываюца - в кэш подтягиваются следующие порции данных и к моменту следующей итерации они уже там. #simd
👍11🤯5🔥4
В продолжение поста, теперь на столе коэффициент детерминации R² (gist). Тут что-то пошло не совсем так: если использовать прямой подход с мапом в Vector256<T> - то буст всего х4 на double и x6 на float (причем повторяемость практически не зависит от размера массива, а значит дело не в кэше который всё успевает и никак не влияет на перф, а в вычислениях).
Однако, если сделать финт ушами (второй скриншот) - и смапить в Vector512<T> - то всё становица чуточку лучше. И тут неважно, что процессор не умеет нативно AVX512, Vector512<T> здесь просто как контейнер для двух Vector256<T>. Здесь получается.... классический loop unrolling, когда за одну итерацию забирается два Vector256<T> (lower/upper) и дальше они ровно также как в ручном loop unrolling складываюца/умножаются в цикле в по прежнему в Vector256<T>.
Это помогает больше чем в 1.5 раза к обычному способу с Vector256 - буст с х4 до ~х5.5 (на double) и с х7.6 до ~x12.5 (на float). Причем на массивах больших, которые не помещаются в L1 кэш - разрыв в перфе больше. Подозреваю, что по причине как в предыдущем посте. #simd
Однако, если сделать финт ушами (второй скриншот) - и смапить в Vector512<T> - то всё становица чуточку лучше. И тут неважно, что процессор не умеет нативно AVX512, Vector512<T> здесь просто как контейнер для двух Vector256<T>. Здесь получается.... классический loop unrolling, когда за одну итерацию забирается два Vector256<T> (lower/upper) и дальше они ровно также как в ручном loop unrolling складываюца/умножаются в цикле в по прежнему в Vector256<T>.
Это помогает больше чем в 1.5 раза к обычному способу с Vector256 - буст с х4 до ~х5.5 (на double) и с х7.6 до ~x12.5 (на float). Причем на массивах больших, которые не помещаются в L1 кэш - разрыв в перфе больше. Подозреваю, что по причине как в предыдущем посте. #simd
🔥3👍1
Тут пишут что GitHub Copilot стал бесплатным... https://x.com/satyanadella/status/1869445091213095140
🔥8
Ещё один no code AI web design generator - на удивление генерит приличные странички (на мой непрофессиональный дизайнерский взгляд). И отметил бы что очень грамотно построенный маркетинг с точки зрения перевода в платность :))) бесплатных кредитов хватает на 2-3 страницы, а дальше за деньги :))
UI чем-то похож на фигмовский и генеряца именно макеты, а не странички. Но с другой стороны можно очень быстро слепить лендинг для чего-нибудь типа пет-проекта.
#ai
UI чем-то похож на фигмовский и генеряца именно макеты, а не странички. Но с другой стороны можно очень быстро слепить лендинг для чего-нибудь типа пет-проекта.
#ai
👍3
О вот ещё посты по перфу с соседнего канала, я что-то упустил что SkipLocalsInit даёт в некоторых местах приличный буст. Надо не забывать это поюзать при случае в бенчах при оптимизации.
Ещё один пост оттуда же про SkipLocalsInit и структуры
в рамках кросс-поста рекомендуется к подписке :))
Ещё один пост оттуда же про SkipLocalsInit и структуры
в рамках кросс-поста рекомендуется к подписке :))
Telegram
C# Heppard
Структура как Span #решение #память #скорость
Разобравшись с InlineArray и SkipLocalsInit мы можем пойти дальше. Например, мы можем представить любую структуру как Span. Напомню, что Span это простой указатель на адрес в памяти + отступ, умноженный на размер…
Разобравшись с InlineArray и SkipLocalsInit мы можем пойти дальше. Например, мы можем представить любую структуру как Span. Напомню, что Span это простой указатель на адрес в памяти + отступ, умноженный на размер…
👍6
Проект с забавным названием Picoc и не очень забавной сутью - интерпретатор Си. И что особенно интересно: It was originally written as a script language for a UAV on-board flight system 😮
Да, проект не оч живой (последний коммит 7 лет назад).
Да, проект не оч живой (последний коммит 7 лет назад).
Storing currency values: data types, caveats, best practices - то что надо знать, когда хранишь деньги в базе :) #howto
🔥9👍1
Тут nVidia релизнула несколько моделей на гитхабе Text to visual world generation (картинка / video). Должно быть это прекрасные модели, но... ресурсы...
Ну и initialization time на Single H100 CPU 14B модели 590 секунд... Вобщем копите бабки :) #llm
Ну и initialization time на Single H100 CPU 14B модели 590 секунд... Вобщем копите бабки :) #llm
👍2
В интернетах пишут, что 512-битные DKIM ключи уже небезопасны. Да, подобранная подпись работает не со всеми почтовыми серверами, но на достаточно крупных типа Yahoo Mail - работает.
👍2