> Я рассматриваю генерацию кода именно для увеличения производительности как альтернатива интерпретации.

Таким способом ты только угробишь производительность. И потом допустим память и таблицы вызовов ты можешь расшарить для этих модулей, а вот датасекцию и глобальные переменные уже будет проблиматично - придется это каждый раз прокидывать в каждый модуль и обновлять. Ну и по памяти. Каждлый модуль потребляет некоторое колличестко памяти для того же сендбокса, секций и т д. А так же тебе же нужно будет пройтись по всем этим модулям и вызвать их, верно? Ты это будешь делать на стороне хоста скорее всего и вот тут неожиданность - интероп зачастую очень медленный

> Если там на каждый модуль отдельный тяжёлый инстанс ВМ создаётся, то конечно лучше уж тогда JS генерить.

Инстансы (по крайней мере в браузере) довольно тяжелые да. А еще в том же хроме они текут по памяти

Допустим у меня будет в маленьком модуле будет тупо самодостаточный цикл, которому не нужны никакие функции, глобальные переменные и так далее. В эту функцию просто будут передаваться указатели на данные, которые надо обработать.
Мне по идее надо будет вызвать функцию один, может пару раз, чтобы сразу обработать большой массив данных, так что может это покроет оверхед.
Но идея генерить JS мне больше нравится. Какой там оверхед с вызовом JS из wasm?

Оверхед сильно зависит от рантайма (браузера) а так же от того какой тип данных ты гоняешь, например функции с нативными типами i32, i64, f32, f64 будут относительно быстро вызываться, если там будут строки, объекты, массивы, которые нужно уже через линейную память гонять - до тут ситуацию совершенно другая

Если пару раз, то тут JIT не нужен. JIT имеет смысл только когда ты сотни и тысячи раз вызываешь

Рантайм дотнета не очень большой (судя по Blazor - единицы мегабайт) и в него вложено на порядки больше человеко-часов, чем энтузиаст может вложить в свой проект, поэтому насчет того, что в конечном итоге получится "оптимальнее" для общего случая я сильно сомневаюсь

Я рассматриваю только нативные типы. То есть если код будет работать со строками, то только в виде байтов в памяти Wasm-модуля. По сути на ARM/x86 будет генерироваться машинный код, а под браузер - низкоуровневый JS.

Ну и для JIT-а тебе нужен будет все равно интерпретатор, Иначе как ты собираешься профиль составлять?

Нужен, потому что сама функция будет делать много. В ней будет цикл на тысячи-миллионы итераций.

Я свой язык делаю, естественно первым делом там будет интерпретатор. А сейчас я просто заранее продумываю, как я буду всё оптимизировать через JIT под разные платформы.

Это могло бы выглядеть так:
1) Сначала работает интерпретатор скомпилированный в wasm, который составляет статистический профиль что как должно инлайниться, девиртуализироваться и т д,
2) Дальше по всем этм данным собирается в фоне wasm модуль
3) Который потом инстанциируется и в режиме hot-spot заменяет интерпретатор

Естественно без деоптимизаций, только однонаправленная 2-х этапная архитектура

Я делаю свой интерпретируемый язык со своей VM и не имеющий ничего общего с .NET. Можно только некоторые отдельные операции оптимизировать через JIT. Так что Blazor тут вообще ни при чём.

Не очень большой это пару килобайт, а пару мегабайт - это весьма здоровый рантайм я бы сказал

Сомневаюсь что реально утолкать в пару килобайт JIT, GC и стандартную библиотеку

Ну вот в AssemblyScript и TinyGo как то умудрились ;)

А этот wasm модуль отдельный? То есть его интеропом дёргать придётся? Или можно как-то в основной модуль добавить скомпилированные функции?

Это отдельный единственный модуль да. Просто он генериться динамически исходя из информации полученной от интерпретаптора. Такой себе PGO

В таком виде это еще может существовать

эээ, я почему-то думал, что JIT и стандартная библиотека в AssemblyScript предоставляются рантаймом WASM, а GC там вообще нет - или я не прав?

Абсолютно не верно) Во первых я не раз уже выкладывал сюда пейпер по которому мы делали GC. Точнее там гибрид ARC и GC