У Xilinx есть одно такое бооольшущее преимущество — его можно/нужно использовать в оборонке. По этому развитие решений на Xilinx'e ещё и стимулируется внешними факторами: доступность химикатов / патентов, государственное лоббирование.
В датацентрах Xilinx используют как решения для SDN, а не для ускорения каких-либо вычислений. Даже у того же Mellanox'a Сonnect-X серия 40Gbit/s интерфейс ни что другое как Xilinx Virtex 6+. Причём используют не саму ПЛИСку/DevBoard Xilinx'a/Alter'ы, а именно вендорную карточку с соответствующей прошивкой, так как нужны гарантии долгосрочной поддержки. Выбор производителя FPGA производителем карты в основном связан больше с экономическими и политическими факторами, доступностью ресурсов, нежели с какими-то реальными показателями производительности. "Выбрали Xilinx — потому что вот Юра шарит в нём, а Альтерку как-то не переваривает, ибо туго у него заводится". Сейчас очень слабо развита экосистема для высокопроизводительных решений на основе FPGA — есть ровно два проекта: DPDK и SPDK.
Altera стоит дешевле, но поддержка никакая: тех процессы — проще, объёмы FPGA — меньше, количество "мёртвого кремния" — больше. Не то что бы для этого не было целевого рынка сбыта. После покупки интелом ситуация немного изменилась в лучшую сторону, но если сравнивать с тем же Xilinx'ом (2.8Ghz 0.7V HBM память 16нм процесс) и Achronix'ом (BRAM LRAM DSP в каждом блоке ячеек), то Alter'e особо то и нечего предложить кроме как классических, дешёвых, решений.
Касательно "Проигрывает ASIC", дык это вброс… ASIC по определению означает любую специализированную микросхему вытравленную в кремнии. Просто для малосерийки нет смысла травить что-то сложное и энергоэффективное, по этому и тех процесс начинается с 45нм.
Касательно "FPGA ускорителей" тоже вброс — сейчас нет нормальных верифицируемых языков программирования что бы таргетить VHDL/Verilog для целевых платформ, a формат бинарников и прошивка целевых FPGA дело сугубо проприетарное.
Раньше у Xilinx'a можно было спокойно взять контракт на партию в 5-10 тысяч кастомных Virtex 6 "порезаных" под нужды конкретного проекта, ну и опционально заказать "соответствие военным требованиям" целевой, дефолтной, страны.
Понятное дело, Спасибо за доброе слово.
Могу смело утверждать что ситуацию очень сильно усугубляет нестабильность существующих прошивок и неразвитые механизмы их обновления.
Планирую как нить сесть и переписать сам DPDK с нуля, но это будет не скоро.
Может быть напишу статейку про свой язык на хабр, правда аудитория тут довольно колоритная.
Даже в Unsafe с Offheap'ом overhead будет пропускную способность сильно прогинать.
JVM в афинном окружении очень странно работает: если просто писать с аффинных потоков в буфер и обрабатывать банальным Poll'ом — там бывают всякие странные артефакты (livelock'и например) из-за отсутствия нормальной синхронизации.
Unsafe+Offheap может выжать где-то 400-500К RPS, и то на захват с 10Gbit'ного интерфейса, вангую что реально там будет где-то 5-6Gbit со всеми мучениями, потом будут "глюки и радости".
Нет, конкретно это не видел: подход понятен, но морально устарело.
Грубо говоря там есть очень большие проблемы в стоимости interop'a в FFI, и очень сильно не хватает как оптимизаций JIT'a так и просто оптимизаций объектной модели — слишком много overhead'a от legacy хлама.
Ну как бэ уже успел написать свой функциональный язык (каппа-числение со стрелками и лямбдами, каппа — это лямбда без HoF'a, но с делегатами), с компилятором и native/llvm/jvm/js/wasm таргетами, в свободное время пишу стандартную либу.
Там отдельным таргетом будет DPDK \o/
Также планирую портировать как-нить сам DPDK и poll-mode драйвера, правда нету денег на железки и тесты.
Мои страдания с попытками интегрировать DPDK куда-попало увенчались ничем.
Надеялся что в Java9 допилят Project Panama и старые глюки уйдут — ниповезло.
По этому дальше публиковать статьи особо нету смысла...
Есть lock-free и есть wait-free подходы, а в системах реального времени используется временное разделение…
По CAP теореме можем пожертвовать либо консистентностью либо доступностью, а в случае с высоконагрузом это значит задержка vs пропускная способность.
На DPDK, к примеру, решения работают напрямую с железом — там нет распространённых накладных расходов на коммуникацию и трансляцию вызовов, высоконагрузы уже начинаются с 1М RPS.
В приложениях на golang'e с использованием fasthttp тот же nginx или haproxy уже является бутылочным горлышком при RPS 80K+. Сторонние кэши типа redis/memcached тоже не вписываются из-за больших накладных расходов на коммуникацию. C fasthttp и тюнингом настроек ядра можно выжать 300К rps… опять же, тут никто не даст поправить sysctl или ядро пересобрать с rt патчами.
Было бы лучше смотреть на flame-graph'ы под нагрузкой и метрики сложности CFG, чем проводить эстимации в RPS'e — это была бы более точная эстимация при совместном использовании распространённых производительных решений.
Это не "мой привычный подход", просто есть user-space решения которые позволяют обрабатывать больше одного миллиона запросов в секунду. Существующие kernel-space решения имеют довольно много ограничений: лишних копирований буферов с kernel-space в user-space, смен контекстов выполнения, избыточного менеджмента памяти etc
Меня кумарит немного факт что highload рассматривается только в рамках общепринятых прикладных решений которые не работают с железом напрямую — там уже задача ставится как "давайте обработаем запрос клиента за 800 процессорных тактов с когерентностью кэша и использованием cache streaming подходов".
Можно реализовать нормальную Keyset паджинацию и докрутить нормальное API к react-virtualized. Сейчас есть довольно много нерешённых проблем с реализацией API'шек, пушами и синхронизацией… например вот.
Если в двух словах: можно прикрутить непрерывную прокрутку ко всему, с помощью Keyset паджинации.
Мог бы написать поболее, но NDA не позволяет.
Перепробовал все llvm'ые языки — имеет место быть проблема: "как обработать пользовательский запрос за 600 тактов процессора", по этому сполз на строковые инструкции с SSE2 SSE4.2 AVX2 AVX512, в зависимости от размера строк выполняю динамическую кодогенерацию… и надо использовать Cache Streaming подходы.
Пока нет нормальных программных реализаций которые могли бы нагрузить нормально сетевые интерфейсы до максимальной пропускной способности — нужно over 48 ядер на 10ти гигабитный интерфейс.
У Xilinx есть одно такое бооольшущее преимущество — его можно/нужно использовать в оборонке. По этому развитие решений на Xilinx'e ещё и стимулируется внешними факторами: доступность химикатов / патентов, государственное лоббирование.
В датацентрах Xilinx используют как решения для SDN, а не для ускорения каких-либо вычислений. Даже у того же Mellanox'a Сonnect-X серия 40Gbit/s интерфейс ни что другое как Xilinx Virtex 6+. Причём используют не саму ПЛИСку/DevBoard Xilinx'a/Alter'ы, а именно вендорную карточку с соответствующей прошивкой, так как нужны гарантии долгосрочной поддержки. Выбор производителя FPGA производителем карты в основном связан больше с экономическими и политическими факторами, доступностью ресурсов, нежели с какими-то реальными показателями производительности. "Выбрали Xilinx — потому что вот Юра шарит в нём, а Альтерку как-то не переваривает, ибо туго у него заводится". Сейчас очень слабо развита экосистема для высокопроизводительных решений на основе FPGA — есть ровно два проекта: DPDK и SPDK.
Altera стоит дешевле, но поддержка никакая: тех процессы — проще, объёмы FPGA — меньше, количество "мёртвого кремния" — больше. Не то что бы для этого не было целевого рынка сбыта. После покупки интелом ситуация немного изменилась в лучшую сторону, но если сравнивать с тем же Xilinx'ом (2.8Ghz 0.7V HBM память 16нм процесс) и Achronix'ом (BRAM LRAM DSP в каждом блоке ячеек), то Alter'e особо то и нечего предложить кроме как классических, дешёвых, решений.
Касательно "Проигрывает ASIC", дык это вброс… ASIC по определению означает любую специализированную микросхему вытравленную в кремнии. Просто для малосерийки нет смысла травить что-то сложное и энергоэффективное, по этому и тех процесс начинается с 45нм.
Касательно "FPGA ускорителей" тоже вброс — сейчас нет нормальных верифицируемых языков программирования что бы таргетить VHDL/Verilog для целевых платформ, a формат бинарников и прошивка целевых FPGA дело сугубо проприетарное.
Раньше у Xilinx'a можно было спокойно взять контракт на партию в 5-10 тысяч кастомных Virtex 6 "порезаных" под нужды конкретного проекта, ну и опционально заказать "соответствие военным требованиям" целевой, дефолтной, страны.
Понятное дело, Спасибо за доброе слово.
Могу смело утверждать что ситуацию очень сильно усугубляет нестабильность существующих прошивок и неразвитые механизмы их обновления.
Планирую как нить сесть и переписать сам DPDK с нуля, но это будет не скоро.
Может быть напишу статейку про свой язык на хабр, правда аудитория тут довольно колоритная.
Даже в Unsafe с Offheap'ом overhead будет пропускную способность сильно прогинать.
JVM в афинном окружении очень странно работает: если просто писать с аффинных потоков в буфер и обрабатывать банальным Poll'ом — там бывают всякие странные артефакты (livelock'и например) из-за отсутствия нормальной синхронизации.
Unsafe+Offheap может выжать где-то 400-500К RPS, и то на захват с 10Gbit'ного интерфейса, вангую что реально там будет где-то 5-6Gbit со всеми мучениями, потом будут "глюки и радости".
Нет, конкретно это не видел: подход понятен, но морально устарело.
Грубо говоря там есть очень большие проблемы в стоимости interop'a в FFI, и очень сильно не хватает как оптимизаций JIT'a так и просто оптимизаций объектной модели — слишком много overhead'a от legacy хлама.
Не, они тренили конвуляционку распознавать полки с шоколадом Рошен...
Cпасибо за длиннопост.
Хабр снова торт.
Я имел ввиду полноценный http rest :p
Ну как бэ уже успел написать свой функциональный язык (каппа-числение со стрелками и лямбдами, каппа — это лямбда без HoF'a, но с делегатами), с компилятором и native/llvm/jvm/js/wasm таргетами, в свободное время пишу стандартную либу.
Там отдельным таргетом будет DPDK \o/
Также планирую портировать как-нить сам DPDK и poll-mode драйвера, правда нету денег на железки и тесты.
Мои страдания с попытками интегрировать DPDK куда-попало увенчались ничем.
Надеялся что в Java9 допилят Project Panama и старые глюки уйдут — ниповезло.
По этому дальше публиковать статьи особо нету смысла...
Я думаю также стоит рассмотреть гибридные branch and bound алгоритмы дискретной оптимизации применяемые для подобных задач.
Есть lock-free и есть wait-free подходы, а в системах реального времени используется временное разделение…
По CAP теореме можем пожертвовать либо консистентностью либо доступностью, а в случае с высоконагрузом это значит задержка vs пропускная способность.
На DPDK, к примеру, решения работают напрямую с железом — там нет распространённых накладных расходов на коммуникацию и трансляцию вызовов, высоконагрузы уже начинаются с 1М RPS.
В приложениях на golang'e с использованием fasthttp тот же nginx или haproxy уже является бутылочным горлышком при RPS 80K+. Сторонние кэши типа redis/memcached тоже не вписываются из-за больших накладных расходов на коммуникацию. C fasthttp и тюнингом настроек ядра можно выжать 300К rps… опять же, тут никто не даст поправить sysctl или ядро пересобрать с rt патчами.
Было бы лучше смотреть на flame-graph'ы под нагрузкой и метрики сложности CFG, чем проводить эстимации в RPS'e — это была бы более точная эстимация при совместном использовании распространённых производительных решений.
Спасибо, предположил "понятные причины".
Понял что можно особо не распыляться — всё равно никто не поймёт "масштабов бедствия".
Это не "мой привычный подход", просто есть user-space решения которые позволяют обрабатывать больше одного миллиона запросов в секунду. Существующие kernel-space решения имеют довольно много ограничений: лишних копирований буферов с kernel-space в user-space, смен контекстов выполнения, избыточного менеджмента памяти etc
Меня кумарит немного факт что highload рассматривается только в рамках общепринятых прикладных решений которые не работают с железом напрямую — там уже задача ставится как "давайте обработаем запрос клиента за 800 процессорных тактов с когерентностью кэша и использованием cache streaming подходов".
Эм… докер уже сам по себе большое бутылочное горлышко.
Ок
Вы уже поставили довольно много палок в колёса участникам используя посредственное окружение и очень субъективную оценку.
\o/
Прикольно когда организаторы чемпионата по highload'у не знают какой нынче highload бывает.
У меня малость пригорает.
Можно реализовать нормальную Keyset паджинацию и докрутить нормальное API к react-virtualized. Сейчас есть довольно много нерешённых проблем с реализацией API'шек, пушами и синхронизацией… например вот.
Если в двух словах: можно прикрутить непрерывную прокрутку ко всему, с помощью Keyset паджинации.
use-the-index-luke.com/no-offset
Я думаю сначала нужно разобраться в offset и keyset паджинации что бы можно было утверждать что вот прям действительно "грусть-печалька".
"Чик-чик и в продакшн"…
А QA, a кто поддерживать будет, а ответственность ?
Мог бы написать поболее, но NDA не позволяет.
Перепробовал все llvm'ые языки — имеет место быть проблема: "как обработать пользовательский запрос за 600 тактов процессора", по этому сполз на строковые инструкции с SSE2 SSE4.2 AVX2 AVX512, в зависимости от размера строк выполняю динамическую кодогенерацию… и надо использовать Cache Streaming подходы.
Пока нет нормальных программных реализаций которые могли бы нагрузить нормально сетевые интерфейсы до максимальной пропускной способности — нужно over 48 ядер на 10ти гигабитный интерфейс.
Смотрел, пробовал, пока с ним есть проблемы.
Не знаю, не колупал BESS.
Не уверен что это целесообразно — там есть много подводных камней на подобие влияния ASLR.
Ага, я дальше отписал что это плохой пример.