Cranelift 👍

Heap2local (aka Scalar Replacment) для GC, Dead Store Ellimination для GC полей, глобальных переменных, и store операций. Оптимизации для memory.copy, memory.fill и много чего еще. Binaryen имеет довольно разного уровня оптимизации. Более того много оптимизаций не поддерживается в LLVM так как они очень специфичны для WebAssembly

Если у вашего смеха есть причина, то неплохо бы её озвучить, чтобы вас не воспринимали сами знаете кем.

В мутабельных даже не часть, а все дерево целиком «переиспользуется» :)

Есть риск что более высокоуровневые оптимизации часто будут специфичными для конкретного языка.

Не всегда. Это надо по месту смотреть, не копируют ли дерево целиком.

Это всё низкоуровневые же. Как он поймёт, например, что функция идемпотентна, а значит несколько её вызовов можно схлопнуть в один?

а там есть что попилить навскидку?

я хочу

Воббще для этого в LLVM делают MLIR, а во всех языках есть middle IR. В Rust это MIR

Конечно! Я там ниже привел. Могу еще подкинуть issues если перечисленные не очень заинтересовали

Разве дерево, которое копируют целиком, не иммутабельное?

👍

Нет. Скорее наоборот: мутабельное дерево приходится копировать целиком, потому что мало ли кто его мутирует, а иммутабельное можно просто по ссылке передавать кругом.

огонь, то, что надо

только бы начало патча wasm simd для jsc еще хотя бы до готовности к ревью довести сперва 😅

Представьте себе макрос, который применяется в разных местах. Если он везде вставит ссылки на один мутабельный узел, то при обработке одного места применения макроса будут наводки на все остальные. В лучшем случае тут используется копирование при записи. В худшем - копируют сразу на всякий случай.

Мне кажется, мы немного о разных вещах говорим. В моем понимании, если дерево "мутабельное", значит его имеет право кто угодно менять in-place по своему усмотрению, все наблюдатели работают с единой копией и видят все изменения. И я вполне могу представить кейсы, когда это нужно - ради простоты в маленьких проектах, или ради производительности в крупных. А вот если оно должно меняться, но у кого-то должна оставаться старая копия - тогда это, по сути, "иммутабельное" дерево. Которое при этом может быть реализовано более или менее эффективно - копированием только частей или всего дерева сразу

> если дерево "мутабельное", значит его имеет право кто угодно менять in-place по своему усмотрению

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

Видимо, так и оказывается, что все структуры данных — "иммутабельные" в Вашем понимании. Наверное поэтому ФП потихоньку "захватывает мейнстрим".

Видимо, вы рассматриваете ситуацию сразу в контексте промышленных проектов - поэтому и инварианты, и многопоток, и т.д. - я полностью согласен, что иммутабельные структуры там подойдут гораздо лучше. Однако изначально разговор шел о сравнении эффективности использования ресурсов мутабельных и иммутабельных структур как таковых