Хм. Идея-то неплоха, но вбухивать тонны человеко-часов в еще одну VM — overkill по мне. И все из-за гипотетической патентной угрозы со стороны владельцев Java или .NET? Или есть другие веские причины?
Здравствуйте, wildwind, Вы писали:
W>Здравствуйте, D. Mon, Вы писали:
W>Хм. Идея-то неплоха, но вбухивать тонны человеко-часов в еще одну VM — overkill по мне. И все из-за гипотетической патентной угрозы со стороны владельцев Java или .NET? Или есть другие веские причины?
Java/.NET — слишком высокий уровень (ГЦ, классы). Это скорее ближе к LLVM. Чем им LLVM не подошел, я .
Здравствуйте, WolfHound, Вы писали:
WH>Почему вот это опкоды?
Потому что они потом хотят это в asm\машинный код превращать. С функциями сложнее. Ну и оптимизация ложится на компилятор, а не на рантайм.
WH>Это всё должно быть обычными функциями.
Кому должно?
Здравствуйте, gandjustas, Вы писали:
G>Потому что они потом хотят это в asm\машинный код превращать. С функциями сложнее. Ну и оптимизация ложится на компилятор, а не на рантайм.
1)Компилятор может провести ровно те же оптимизации.
2)Рантайму (который на самом деле тоже компилятор) всё равно, что знать в лицо. Опкод или функцию из стандартной библиотеки. Разница в несколько машинных тактов при парсинге кода.
WH>>Это всё должно быть обычными функциями. G>Кому должно?
Здравому смыслу.
Вон мелкософты захардкодили те же опкоды в MSIL, а когда потом начали делать генерики, случился большой ой.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, gandjustas, Вы писали:
G>>Потому что они потом хотят это в asm\машинный код превращать. С функциями сложнее. Ну и оптимизация ложится на компилятор, а не на рантайм. WH>1)Компилятор может провести ровно те же оптимизации. WH>2)Рантайму (который на самом деле тоже компилятор) всё равно, что знать в лицо. Опкод или функцию из стандартной библиотеки. Разница в несколько машинных тактов при парсинге кода.
WH>>>Это всё должно быть обычными функциями. G>>Кому должно? WH>Здравому смыслу. WH>Вон мелкософты захардкодили те же опкоды в MSIL, а когда потом начали делать генерики, случился большой ой.
Тут не будет дженерков.
Дженерики поддержваются языком, а тут уровень машинного кода без возможности декомпиляции.
Избаловало вас НЕТ возможность посмотреть исходник скомпилированного кода.....
Здравствуйте, s22, Вы писали:
s22>Тут не будет дженерков. s22>Дженерики поддержваются языком, а тут уровень машинного кода без возможности декомпиляции. s22>Избаловало вас НЕТ возможность посмотреть исходник скомпилированного кода.....
Не пори чушь. Ей больно.
Они АСТ сериализуют. Сделать для этого дела декомпилятор проще чем для .НЕТ.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Break and continue statements can only target blocks or loops in which they are nested. This guarantees that all resulting control flow graphs are reducible, which leads to the following advantages:
1)Simple and size-efficient binary encoding and compilation.
Грамотная стековая машина как минимум не хуже.
При этом гораздо гибче.
2)Any control flow—even irreducible—can be transformed into structured control flow with the Relooper algorithm, with guaranteed low code size overhead, and typically minimal throughput overhead (except for pathological cases of irreducible control flow). Alternative approaches can generate reducible control flow via node splitting, which can reduce throughput overhead, at the cost of increasing code size (potentially very significantly in pathological cases).
3)The signature-restricted proper tail-call feature would allow efficient compilation of arbitrary irreducible control flow.
Они эти пляски с бубном записали в преимущества?
Почему разработчики компиляторов должны выпиливать для своего кода всякие релуперы?
При том, что такая модель поможет только при начальной реализации, которая транслирует этот кода в жабаскрипт, а когда у них будет нормальный компилятор на клиенте, всё это будет не нужно. На все разработчики компиляторов до скончания веков будут вынуждены тратить уйму времени для того чтобы запихнуть свой код в эту модель.
По ссылке на signature-restricted proper tail-call таких слов нет. Хотя я, конечно, понял, что они пытаются этим сказать.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Интересно, как это скажется на приватности, рекламе и безопасности вообще.
Сейчас получить JS-подмес в http без s не просто, а очень просто. В метро хоть проехаться, а есть еще и провайдеры, отмороженность которых только растет. Подмесы находят обычные люди путем несложного анализа. Что будет, когда все это дело начнет байткодиться?
Кроме того, типичная страница в интернете сейчас содержит десяток трекеров, благодаря чему вся история вашего браузинга идет прямиков в закрома ФСБуку, Яндексу, Гуглу и далее по списку. Есть Ghostery, который выкусывает все трекеры по базе, во что эта база превратится с байткодом?
Короче, сдается мне, вся эта история закончится левой рекламой, от которой не избавиться, и окончательной потерей приватности. Рад буду ошибиться.
Здравствуйте, WolfHound, Вы писали:
WH>При том, что такая модель поможет только при начальной реализации, которая транслирует этот кода в жабаскрипт, а когда у них будет нормальный компилятор на клиенте, всё это будет не нужно. На все разработчики компиляторов до скончания веков будут вынуждены тратить уйму времени для того чтобы запихнуть свой код в эту модель.
"когда у них будет нормальный компилятор на клиенте" — сейчас на джаваскрипте написаны вагоны кода, больше, чем на любом другом ЯП. Т.е. технология взлетит/невзлетит в зависимости от того, какой профит будет на JS.
Просто прийти и сказать, вот, можно писать на С++ — это так себе. Те, кто может и умеет UI, уже давно пишут на чем то другом. А те, кто пишут на С++, уже давно ушли в дрова и числодробилки.
Здравствуйте, Ikemefula, Вы писали:
I>"когда у них будет нормальный компилятор на клиенте" — сейчас на джаваскрипте написаны вагоны кода, больше, чем на любом другом ЯП. Т.е. технология взлетит/невзлетит в зависимости от того, какой профит будет на JS. I>Просто прийти и сказать, вот, можно писать на С++ — это так себе. Те, кто может и умеет UI, уже давно пишут на чем то другом. А те, кто пишут на С++, уже давно ушли в дрова и числодробилки.
Ты не понял ни что ни зачем делают разработчики WebAssembly.
Ни моих претензий к ним.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, WolfHound, Вы писали:
WH>Loads convert Memory types to Local types according to the following rules: WH>Тут явно торчат уши текущей реализации. WH>Когда реализация протекает в модель пиши пропало.
WH>Если хочется проводить эти конвертации нужно делать это на этапе загрузки байткода. WH>В самом же байткоде должны быть совершенно конкретные типы.
тут совершенно конкретные типы, возможно ты не понял
фактически тут сказано, что регистр может быть int32 или int64, а данные в памяти 8,16,32,64 соответственно знаковые и беззнаковые....
вообщем прямо ложиться на команды ассемблера x86
WH>2)Control flow structures WH>https://github.com/WebAssembly/design/blob/master/AstSemantics.md#control-flow-structures WH>Опять протечка реализации в модель. WH>Только в значительно более тяжёлой форме. WH>Данные извращения нужны исключительно для компиляции в жабаскрипт. И только по тому, что жабаскрипт не умеет goto.
No action, while and switch combined with jump-threading are enough.
Just add goto (direct and indirect).
Add new control-flow primitives that address common patterns.
Add signature-restricted Proper Tail Calls.
Add proper tail call, expanding upon signature-restricted proper tail calls, and making it easier to support other languages, especially functional programming languages.
WH>3)The signature-restricted proper tail-call feature would allow efficient compilation of arbitrary irreducible control flow. WH>[/q] WH>Они эти пляски с бубном записали в преимущества? WH>Почему разработчики компиляторов должны выпиливать для своего кода всякие релуперы? WH>При том, что такая модель поможет только при начальной реализации, которая транслирует этот кода в жабаскрипт, а когда у них будет нормальный компилятор на клиенте, всё это будет не нужно. На все разработчики компиляторов до скончания веков будут вынуждены тратить уйму времени для того чтобы запихнуть свой код в эту модель.
Здравствуйте, s22, Вы писали:
s22>тут совершенно конкретные типы, возможно ты не понял s22>фактически тут сказано, что регистр может быть int32 или int64, а данные в памяти 8,16,32,64 соответственно знаковые и беззнаковые....
Я всё понял. И то, что они делают не правильно.
s22>вообщем прямо ложиться на команды ассемблера x86
Это вообще к делу не относится. Ну и 8 и 16 битные регистры в x86 тоже есть.
s22>No action, while and switch combined with jump-threading are enough. s22>Just add goto (direct and indirect). s22>Add new control-flow primitives that address common patterns. s22>Add signature-restricted Proper Tail Calls. s22>Add proper tail call, expanding upon signature-restricted proper tail calls, and making it easier to support other languages, especially functional programming languages.
У тебя есть ужасная привычка давать цитаты без ссылок.
Исправляйся. Ибо очень раздражает.
s22>не понял, что тут....
Ну, вот есть у тебя конечный автомат, реализованный при помощи goto.
Теперь попробуй скомпилировать его в предложенный формат.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
s22>>не понял, что тут.... WH>Ну, вот есть у тебя конечный автомат, реализованный при помощи goto. WH>Теперь попробуй скомпилировать его в предложенный формат.
Да скомпилить-то можно, только... Это будет либо релупер, которой поддерживает неприводимые графы потока управления (irreducible flowgraphs), либо алгоритм наподобие тех, что используются в декомпиляторах. Во втором случае неприводимые графы можно скомпилить только если предварительно конвертнуть их приводимые методом копирования целых кусков автомата. Это при том, что до сих пор неизвестен алгоритм, который порождает минимальное количество копий. А существующие эвристические подходы ещё и не слишком шустро работают. На выходе JIT всё равно генерит машинный код, на который никаких подобных ограничений не накладывается, поэтому странно, что нельзя просто так взять и скомпилить конечный автомат. Это при том, что компиляция конечного автомата напрямую в x86, ну или хотя бы в LLVM — это час работы.
Здравствуйте, konsoletyper, Вы писали:
K>Да скомпилить-то можно, только...
Я знаю что можно. Просто предлагаю s22 на своей шкуре почувствовать, чего это стоит.
K>поэтому странно, что нельзя просто так взять и скомпилить конечный автомат.
Судя по всему они тупо решили срезать углы при начальной реализации, а на то что из-за этого потом будут страдать разработчики компиляторов им пофигу.
K>Это при том, что компиляция конечного автомата напрямую в x86, ну или хотя бы в LLVM — это час работы.
Да во что угодно, где goto есть.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
всетаки они делают IR а не VM.
и транслировать будут тибо в asm.js, либо сразу в нативный асм.
WH>Почему вот это опкоды? > Int32Add WH>Это всё должно быть обычными функциями.
да, может показаться что дженерики, где типы подставляется в рантайме,
эффективнее шаблонов, где может создаваться много копий одного кода с разными типами.
однако,
во-первых размер бинарника с "push arg1/push arg2/call add" больше "add32 arg1 arg2".
у шаблона может быть всего одна инстанциация.
с шаблоном компилятор может сделать больше оптимизаций и выкинуть/свернуть много кода, в итоге размер бинарника будет меньше чем с дженериком.
во-вторых на компиляцию дженериков уходит больше ресурсов, это важно — если клиент это мобильник с батарейкой.
Здравствуйте, Abyx, Вы писали:
A>всетаки они делают IR а не VM.
Один чёрт.
A>и транслировать будут тибо в asm.js, либо сразу в нативный асм.
Незначительные детали реализации.
A>да, может показаться что дженерики, где типы подставляется в рантайме, A>эффективнее шаблонов, где может создаваться много копий одного кода с разными типами.
Причём тут шаблоны? Я про них вообще ничего не говорил.
A>во-первых размер бинарника с "push arg1/push arg2/call add" больше "add32 arg1 arg2".
Не правда.
Стековое представление самое компактное.
В прочем у них тут тоже практически стековое представление. Так что будет паритет.
Только с кучей не нужных ограничений.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Сейчас мы находимся в благословенный период, когда все основные вендоры НАКОНЕЦ-то нормально научились договариваться друг с другом о фичах. Так что все может получиться.
Главные но:
— в списке разработчиков нет Apple'а. Думаю, они подтянутся. Скорее всего где-то в рамках https://trac.webkit.org/wiki/FTLJIT
— Путь лежит через первоначальную обратную совместимость с asm.js. Это, имхо, может народить в проекте ужасных костылей.
Здравствуйте, Mamut, Вы писали:
M>Сейчас мы находимся в благословенный период, когда все основные вендоры НАКОНЕЦ-то нормально научились договариваться друг с другом о фичах. Так что все может получиться.
Люди, следившие за их рассылкой, говорят, что те пока только договорились, что надо договориться, но дальше этого — о фичах — пока не очень еще договорились.
.
