Я продолжаю думать о том, как Dusk использует нативные host-функции для дорогих по вычислениям операций.
На бумаге всё выглядит просто. Вынести тяжёлые вычисления из WebAssembly, выполнять их эффективнее в среде хоста и заодно снизить часть накладных расходов.
Но то, что одна часть пути выполнения становится быстрее, не означает автоматически, что вся нагрузка ускорится на ту же величину. Это важно, поскольку Dusk продвигается к тому, чтобы вывести финансовые рынки onchain с институциями, лицензированными в ЕС; в итоге архитектуре придётся работать с реальными нагрузками, а не просто выглядеть эффективной на бумаге. Я пока не знаю, убирает ли дизайн host-функций у Dusk узкое место, которое действительно доминирует в реальных нагрузках, или же в основном ускоряет работу, которая в общей картине оказывается лишь меньшей долей всего времени выполнения.
Детали, за которыми стоит следить: какие операции выносятся из WASM, насколько они ускоряются и какую долю в репрезентативной нагрузке Dusk составляют эти операции.
Архитектура даёт вескую причину ожидать улучшение. Это менее убедительные доказательства, чем наблюдать, как та же самая нагрузка на практике даёт ощутимый, воспроизводимый выигрыш.
Мне было бы менее важно теоретическое ускорение одной примитивной операции — гораздо важнее, насколько это меняет производительность той нагрузки, которую Dusk действительно запускает.
Вопрос в том, убрал ли Dusk реальное системное узкое место или просто ускорил одну часть пути, не сильно сдвинув общую производительность.
Я слежу за бенчмарками, специфичными для Dusk: такими, которые изолируют выигрыш от host-функций и показывают, насколько он важен на уровне реальной нагрузки.
#dusk $DUSK @Dusk
На бумаге всё выглядит просто. Вынести тяжёлые вычисления из WebAssembly, выполнять их эффективнее в среде хоста и заодно снизить часть накладных расходов.
Но то, что одна часть пути выполнения становится быстрее, не означает автоматически, что вся нагрузка ускорится на ту же величину. Это важно, поскольку Dusk продвигается к тому, чтобы вывести финансовые рынки onchain с институциями, лицензированными в ЕС; в итоге архитектуре придётся работать с реальными нагрузками, а не просто выглядеть эффективной на бумаге. Я пока не знаю, убирает ли дизайн host-функций у Dusk узкое место, которое действительно доминирует в реальных нагрузках, или же в основном ускоряет работу, которая в общей картине оказывается лишь меньшей долей всего времени выполнения.
Детали, за которыми стоит следить: какие операции выносятся из WASM, насколько они ускоряются и какую долю в репрезентативной нагрузке Dusk составляют эти операции.
Архитектура даёт вескую причину ожидать улучшение. Это менее убедительные доказательства, чем наблюдать, как та же самая нагрузка на практике даёт ощутимый, воспроизводимый выигрыш.
Мне было бы менее важно теоретическое ускорение одной примитивной операции — гораздо важнее, насколько это меняет производительность той нагрузки, которую Dusk действительно запускает.
Вопрос в том, убрал ли Dusk реальное системное узкое место или просто ускорил одну часть пути, не сильно сдвинув общую производительность.
Я слежу за бенчмарками, специфичными для Dusk: такими, которые изолируют выигрыш от host-функций и показывают, насколько он важен на уровне реальной нагрузки.
#dusk $DUSK @Dusk