MV
в общем, имхо, нет причин использовать life
Size: a a a
2021 January 18
MV
особенно, учитывая то, что он уже не поддерживается
M
Не то что не стоит, а вообще никому бы не рекомендовал
MV
если нужен именно интерпретатор, то wasmi - хороший вариант
К
Для этого есть gas metering
Где читануть что это вообще такое в алгоритмах.
А то чет гуглится только счётчики газа
А то чет гуглится только счётчики газа
M
Где читануть что это вообще такое в алгоритмах.
А то чет гуглится только счётчики газа
А то чет гуглится только счётчики газа
это обычная практика для блокченов
К
Ну блокчейны понятно.
Но тут же не блокчейны, а лимит на вызов блока. Что конечно тоже самое
Но тут же не блокчейны, а лимит на вызов блока. Что конечно тоже самое
M
Ну блокчейны понятно.
Но тут же не блокчейны, а лимит на вызов блока. Что конечно тоже самое
Но тут же не блокчейны, а лимит на вызов блока. Что конечно тоже самое
Не совсем. Просто лимит - это лишь подсчет колличесва операций и завершение при определенном пороге, gas metering - это уже подсчет суммы весов для каждой операции. Естественно делается это обычно для базового блока только, потому что инкрементировать сумму весов после каждой операции слишком накладно
MV
если хочется прям совсем подробностей, то можно найти доки на pin или валгринд, там прям неплохо описано
К
Да мне в принципе как это реализовать, чтобы хлопать Инфинити лупы внутри блоков в нашей машине.
Ща я тупо ограничиваю количество прыжков без расчета стоимости, так как там проблемы вызова - некоторые операции сами по себе дорогие, и те же 10 операций могу быть 100ms, или 0.01ms
А пару операции так вообще локают на 2 секунды. Ток я не могу знать их кост сразу, чтобы веса расставить
Ща я тупо ограничиваю количество прыжков без расчета стоимости, так как там проблемы вызова - некоторые операции сами по себе дорогие, и те же 10 операций могу быть 100ms, или 0.01ms
А пару операции так вообще локают на 2 секунды. Ток я не могу знать их кост сразу, чтобы веса расставить
MV
Да мне в принципе как это реализовать, чтобы хлопать Инфинити лупы внутри блоков в нашей машине.
Ща я тупо ограничиваю количество прыжков без расчета стоимости, так как там проблемы вызова - некоторые операции сами по себе дорогие, и те же 10 операций могу быть 100ms, или 0.01ms
А пару операции так вообще локают на 2 секунды. Ток я не могу знать их кост сразу, чтобы веса расставить
Ща я тупо ограничиваю количество прыжков без расчета стоимости, так как там проблемы вызова - некоторые операции сами по себе дорогие, и те же 10 операций могу быть 100ms, или 0.01ms
А пару операции так вообще локают на 2 секунды. Ток я не могу знать их кост сразу, чтобы веса расставить
ну в общем случае ничего лучше gas/instruction metering не придумать
M
Кстати turbofan даже не разматывает циклы для Wasm как это делается для JS 🤦♂️
https://bugs.chromium.org/p/v8/issues/detail?id=11298
Добавляем сюда еще это (в FF и Safari это тоже отсутствует)
https://bugs.chromium.org/p/v8/issues/detail?id=11085&q=component%3AWebAssembly&can=2
И получаем, что Wasm в браузерах даже и близко не подобрался к своей потенцеальной производительности
https://bugs.chromium.org/p/v8/issues/detail?id=11298
Добавляем сюда еще это (в FF и Safari это тоже отсутствует)
https://bugs.chromium.org/p/v8/issues/detail?id=11085&q=component%3AWebAssembly&can=2
И получаем, что Wasm в браузерах даже и близко не подобрался к своей потенцеальной производительности
A
Анрол лупов в JS. Ничоси. Я думал такое только в шейдерах делают.
M
Анрол лупов в JS. Ничоси. Я думал такое только в шейдерах делают.
в шейдераз делается это для пайплайнов не поддерживающих ветвления и соответственно для циклов постоянной длины
PG
Кстати turbofan даже не разматывает циклы для Wasm как это делается для JS 🤦♂️
https://bugs.chromium.org/p/v8/issues/detail?id=11298
Добавляем сюда еще это (в FF и Safari это тоже отсутствует)
https://bugs.chromium.org/p/v8/issues/detail?id=11085&q=component%3AWebAssembly&can=2
И получаем, что Wasm в браузерах даже и близко не подобрался к своей потенцеальной производительности
https://bugs.chromium.org/p/v8/issues/detail?id=11298
Добавляем сюда еще это (в FF и Safari это тоже отсутствует)
https://bugs.chromium.org/p/v8/issues/detail?id=11085&q=component%3AWebAssembly&can=2
И получаем, что Wasm в браузерах даже и близко не подобрался к своей потенцеальной производительности
Я наивно думала что они разматываются на этапе сборки в wasm, а не turbofanом :)
M
в шейдераз делается это для пайплайнов не поддерживающих ветвления и соответственно для циклов постоянной длины
А так любой компилятор делает loop unrolling даже если потом не требуется векторизация. для Wasm байткода это не делается так как всегда ожидается, что это будет сделано на хостовом рантайме
M
Я наивно думала что они разматываются на этапе сборки в wasm, а не turbofanом :)
Нет конечно, одна из основных целей Wasm это компактность. А ввобще ни одно байткодовое представление не делает разматывние на уровне байткода (кроме пожалуй LLVM IR и то не всегда)
A
в шейдераз делается это для пайплайнов не поддерживающих ветвления и соответственно для циклов постоянной длины
Ага, фиксил баги с реймарчингом. Было больно.
M
Ага, фиксил баги с реймарчингом. Было больно.
В общем, разматывание «фиксированного» цикла и не фиксированного цикла немного отличаются. Последний разматывается с некоторых фактором (4 или 8, 16) в зависимости от характеристик cache locality (для этого же еще и делается loop peeling и loop fusion)