Да, WSL и правда работает через трансляции вызовов, прям как Docker. Но, покупать RDP с GPU на Linux ради статьи - это сильно жирно... А использование ВМ - бессмысленно, т.к. там задержки ещё выше. Ну и накатывать Linux ради одной статьи тоже такое себе~
В замен этого я попытался организовать максимально равные условия тестирования для каждой итерации бенчмарка.
Если вы про это, то таблица была создана с флагом UNLOGGED и AUTOVACUUM_ENABLED = FALSE (В спойлере с тест кодом под Postgres ниже приведен SQL запрос инициирующий таблицу).
Оно вообще не должно было ничего читать/писать на диск. При кешировании так и подразумевается, что при любом сбое - данные пропадают.
Postgres в статье используется именно как система для хранения и доступа к кешу, а не как база данных.
А то, такой подход иногда позволяет находить простые решения к сложным задачам. Работу с GPU и правда можно было бы организовать по другому, но опять же пока писал эту статью так вышло, что привычные рамки использования GPU также были проигнорированы.
Получив в качестве результата прирост скорости у Postgres по сравнению с Redis - логичным следующим шагом будет сравнить хотя бы 2 СУБД, которые предназначены для работы на GPU. Только вот с такими задачами я ранее не сталкивался и не могу с уверенностью сказать, что такое моё сравнение (если я его организую) - будет технически грамотным.
Ну а с кешированием работаю постоянно.
По итогу при переходе на VRAM удалось получить относительно небольшой выйгрыш в производительности, что может сбить с толку, но тут стоит обратить внимание на то, что I9-11900K и RAM были настроены на околопредельные частоты для стабильной работы (при повышение по памяти ещё хотя бы на 100МГц я получал неминуемый BSOD в моем случае).
Возможно следовало бы включить в тест кейсы ещё ряд прогонов бенчмарка, но при этом намеренно занизив частоты CPU и RAM, для получения более явного отрыва при переходе на GPU.
Возможно не самая актуальная, но почему бы не сравнить эту производительность?
Просто я не нашел нормальных подобных сравнений в интернете, а вопрос этот меня мучал.
PG_Strom входит в комплект PostGis например - надстройка на Postgres, для работы с геоданными, когда этих самых данных реально много. Вот там как раз таки и идет прирост с 100... 200... 300 раз.
Какой именно я не знаю, но раз они запилили эту надстройку, значит причина у них была весомая.
Да и в целом статья не агитирует всех бросать свои дела и бежать переводить кеш у в проектах на GPU.
Я просто предложил рассмотреть кеширование на GPU, как один из возможных вариантов реализации кеширования впринципе.
В конце статьи так и написано даже, что такая реализация может быть необходима исключительно каким то супер сложным и требовательным проектам.
Ну а что, есть же компании, которые кластеры серверов с большим объемом ОЗУ ставят, чтобы данные чисто в ней хранить.
Думаете нет компаний, которые все все на GPU считают?) А как же тот же OpenAI? Не знаю, как у них там обстоят дела с кешем, но GPU у них точно в достатке.
Ядро редиса однопоточно и об этом в статье не раз сказано. Но... Существует вот просто форк редиса, который использует видеопамять (про потоки не сказано) и вот видеопамять в отличии от обычной работает же сильно шустрее. Вот и был смысл взять 2 этих редиса и сравнить. А результат получился неожиданным, потому что версия на GPU проиграла версии на CPU.
Что касается опроса и наличия dict/HashMap в нем... А про пункт с матрасом например почему не спросили?)
Понятно же что часть пунктов там лишние и dict/hashmap в их числе... Я такие шуточные опросы вообще в каждую последнюю статью пихаю...
По умолчанию профиль выставлен в режим производительности, карточка тоже слегка разогнана. Если честно не обратил внимание на изменение режима питания с P8 на другие. На тестах GPU нагрузилась по итогу максимум до ~20-25%, а проблемы с троттлингом, о которых вы наверное подразумеваете на 20-25% нагрузке точно никак не вылезут.
Тесты относительно простенькие, продолжительностью не более полутора минут. На них и вольтаж особо не вырос и даже вентиляторы вроде не загудели)
RTX 3080 TI как-никак околофлагманская GPU на момент выхода. Я с неё 4к на 120фпс вытягиваю в ААА проектах и то на полную загрузить не могу, то ли дело какой то там Postgres)
Но почему порт именно 3128? Данный tcp порт создан именно под функцию прокси.
Забавно, впервые слышу чтоб под прокси это был именноопределенный порт. Вешать прокси можно на любой а таки на 443 - наоборот более интересный выбор...
Так и есть, тока сравниваем не только чем забивать, а ещё самое главное - куда забивать? :)
Я понимаю, что реляционные бд в целом не заточены под работу с таблицами ключ-значение, но такая возможность у них есть, а сравниваем мы все таки кеширование и именно бд vs redis.
И про тонкую настройку postgres тоже в курсе. Но это уже не совсем объективное сравнение получится, т.к. на разном железе и ос можно получить совсем разные результаты производительности. Получится что у бенчмарка от настройки к настройке будут совершенно разные результаты.
С MySQL довольно мало доводилось работать, т.к. в основном работаю с Postgres.
К тому же для MySQL насколько я понял нет готового решения для её развертывания на GPU, а главная идея статьи то была в том, чтобы рассмотреть саму возможность работы с кешем на GPU.
Тоже были такие мысли, чтобы их развеять я также запускал чистые контейнера postgres и redis в докере и проводил эти тесты между докер контейнерами.
Также запускал redis и postgres напрямую на WSL без docker - результаты в целом сошлись с инстансами в docker, так что в моих тестах я думаю возможным замедлением такого рода можно пренебречь.
Тсс... Где то в мире опять загрустил Хуанг от этих слов... А разве есть рациональное объяснение тому, что AI хотят засунуть абсолютно везде? Хотя многие задачи можно было бы решить нехитрым SQL запросом или алгоритмом.
Типы данных под капотом ВМ:
null
unsigned int — 4 байта (для счетчиков)
int — 8 байт
double — 8 байт (5.0E-324… 1.7E308, значащих цифр: 15-16)
string — динамическая длина, 1 символ = 1 байт
array — массив указателей, длина фиксированная, размер зависит от разрядности ос, но её можно изменять через SetLen()
Для работы с битовыми операциями или же с байтами по-отдельности предусмотрены языковые операторы и ряд классов по типу stream, в будущем этот функционал языка будет расширен.
Т.к. Mash с динамической типизацией и относительно других современных языков производительностью не выделяется, то писать какие-либо низкоуровневые вещи, кодеки и т.п. требующие производительности разумно на нативных языках и в дальнейшем возможно использовать это все из Mash, если это необходимо.
Ну а так, в Mash будет все это поддерживаться на уровне "работает медленно, но корректно".
:)
Да, WSL и правда работает через трансляции вызовов, прям как Docker. Но, покупать RDP с GPU на Linux ради статьи - это сильно жирно... А использование ВМ - бессмысленно, т.к. там задержки ещё выше. Ну и накатывать Linux ради одной статьи тоже такое себе~
В замен этого я попытался организовать максимально равные условия тестирования для каждой итерации бенчмарка.
Если вы про это, то таблица была создана с флагом UNLOGGED и AUTOVACUUM_ENABLED = FALSE (В спойлере с тест кодом под Postgres ниже приведен SQL запрос инициирующий таблицу).
Оно вообще не должно было ничего читать/писать на диск.
При кешировании так и подразумевается, что при любом сбое - данные пропадают.
Postgres в статье используется именно как система для хранения и доступа к кешу, а не как база данных.
Ну и опять же, раз уж взялся сравнивать Redis & Postgres - то БД должна была быть загнана в довольно таки не оптимальные рамки работы "как Redis".
А то, такой подход иногда позволяет находить простые решения к сложным задачам.
Работу с GPU и правда можно было бы организовать по другому, но опять же пока писал эту статью так вышло, что привычные рамки использования GPU также были проигнорированы.
Получив в качестве результата прирост скорости у Postgres по сравнению с Redis - логичным следующим шагом будет сравнить хотя бы 2 СУБД, которые предназначены для работы на GPU. Только вот с такими задачами я ранее не сталкивался и не могу с уверенностью сказать, что такое моё сравнение (если я его организую) - будет технически грамотным.
Ну а с кешированием работаю постоянно.
По итогу при переходе на VRAM удалось получить относительно небольшой выйгрыш в производительности, что может сбить с толку, но тут стоит обратить внимание на то, что I9-11900K и RAM были настроены на околопредельные частоты для стабильной работы (при повышение по памяти ещё хотя бы на 100МГц я получал неминуемый BSOD в моем случае).
Возможно следовало бы включить в тест кейсы ещё ряд прогонов бенчмарка, но при этом намеренно занизив частоты CPU и RAM, для получения более явного отрыва при переходе на GPU.
Ну так, ресурсов - не жалеем!
Точнее сказать - памяти не жалеем, я её даже не замерял.
Главное в этой статье только одно - perfomance!
Возможно не самая актуальная, но почему бы не сравнить эту производительность?
Просто я не нашел нормальных подобных сравнений в интернете, а вопрос этот меня мучал.
PG_Strom входит в комплект PostGis например - надстройка на Postgres, для работы с геоданными, когда этих самых данных реально много. Вот там как раз таки и идет прирост с 100... 200... 300 раз.
Какой именно я не знаю, но раз они запилили эту надстройку, значит причина у них была весомая.
Боюсь, что у меня нет ответа на ваше ЗАЧЕМ 😔...
Да и в целом статья не агитирует всех бросать свои дела и бежать переводить кеш у в проектах на GPU.
Я просто предложил рассмотреть кеширование на GPU, как один из возможных вариантов реализации кеширования впринципе.
В конце статьи так и написано даже, что такая реализация может быть необходима исключительно каким то супер сложным и требовательным проектам.
Ну а что, есть же компании, которые кластеры серверов с большим объемом ОЗУ ставят, чтобы данные чисто в ней хранить.
Думаете нет компаний, которые все все на GPU считают?) А как же тот же OpenAI? Не знаю, как у них там обстоят дела с кешем, но GPU у них точно в достатке.
Ядро редиса однопоточно и об этом в статье не раз сказано. Но... Существует вот просто форк редиса, который использует видеопамять (про потоки не сказано) и вот видеопамять в отличии от обычной работает же сильно шустрее. Вот и был смысл взять 2 этих редиса и сравнить. А результат получился неожиданным, потому что версия на GPU проиграла версии на CPU.
Что касается опроса и наличия dict/HashMap в нем... А про пункт с матрасом например почему не спросили?)
Понятно же что часть пунктов там лишние и dict/hashmap в их числе... Я такие шуточные опросы вообще в каждую последнюю статью пихаю...
По умолчанию профиль выставлен в режим производительности, карточка тоже слегка разогнана.
Если честно не обратил внимание на изменение режима питания с P8 на другие.
На тестах GPU нагрузилась по итогу максимум до ~20-25%, а проблемы с троттлингом, о которых вы наверное подразумеваете на 20-25% нагрузке точно никак не вылезут.
Тесты относительно простенькие, продолжительностью не более полутора минут. На них и вольтаж особо не вырос и даже вентиляторы вроде не загудели)
RTX 3080 TI как-никак околофлагманская GPU на момент выхода.
Я с неё 4к на 120фпс вытягиваю в ААА проектах и то на полную загрузить не могу, то ли дело какой то там Postgres)
Забавно, впервые слышу чтоб под прокси это был именно определенный порт. Вешать прокси можно на любой а таки на 443 - наоборот более интересный выбор...
Так и есть, тока сравниваем не только чем забивать, а ещё самое главное - куда забивать? :)
Я понимаю, что реляционные бд в целом не заточены под работу с таблицами ключ-значение, но такая возможность у них есть, а сравниваем мы все таки кеширование и именно бд vs redis.
И про тонкую настройку postgres тоже в курсе. Но это уже не совсем объективное сравнение получится, т.к. на разном железе и ос можно получить совсем разные результаты производительности. Получится что у бенчмарка от настройки к настройке будут совершенно разные результаты.
С MySQL довольно мало доводилось работать, т.к. в основном работаю с Postgres.
К тому же для MySQL насколько я понял нет готового решения для её развертывания на GPU, а главная идея статьи то была в том, чтобы рассмотреть саму возможность работы с кешем на GPU.
Тоже были такие мысли, чтобы их развеять я также запускал чистые контейнера postgres и redis в докере и проводил эти тесты между докер контейнерами.
Также запускал redis и postgres напрямую на WSL без docker - результаты в целом сошлись с инстансами в docker, так что в моих тестах я думаю возможным замедлением такого рода можно пренебречь.
Что то юмор, что это, так и так на том и сошлись 🤝
"Жажда наживы" - это слишком грубо и может отпугнуть наших потенциальных клиентов.
Мы руководствуемся исключительно желанием наживы.
Тсс... Где то в мире опять загрустил Хуанг от этих слов...
А разве есть рациональное объяснение тому, что AI хотят засунуть абсолютно везде?
Хотя многие задачи можно было бы решить нехитрым SQL запросом или алгоритмом.
«и раз в 15 минут закатно смеяться в офисе без причины»
Хитрый ход headhunter. Коварный хитрый ход... :)
null
unsigned int — 4 байта (для счетчиков)
int — 8 байт
double — 8 байт (5.0E-324… 1.7E308, значащих цифр: 15-16)
string — динамическая длина, 1 символ = 1 байт
array — массив указателей, длина фиксированная, размер зависит от разрядности ос, но её можно изменять через SetLen()
Для работы с битовыми операциями или же с байтами по-отдельности предусмотрены языковые операторы и ряд классов по типу stream, в будущем этот функционал языка будет расширен.
Т.к. Mash с динамической типизацией и относительно других современных языков производительностью не выделяется, то писать какие-либо низкоуровневые вещи, кодеки и т.п. требующие производительности разумно на нативных языках и в дальнейшем возможно использовать это все из Mash, если это необходимо.
Ну а так, в Mash будет все это поддерживаться на уровне "работает медленно, но корректно".
:)
Тайпхинты в Python нужны чтоб код был более выразительным. Если нужно больше производительности, то на помощь придут декораторы @njit :)