А временами выдает дикую дичь. Особенно забавно, когда сигнатура функции определяется неверно и из-за этого в функции вызывающей оную пропадают целые блоки вычислений (декомпилятор считает, что они не используются и отбрасывает, как не нужные)
Все правильно делаете. А в статье — «почти» ошибка.
Дело в том, что когда 4-х компонентный вектор, представляющий вершину треугольника, умножается на матрицу, предполагается в что в w сидит 1 или 0. 1 — если нужно применять транспонирование из последнего столбца матрицы, 0 — когда нет.
Понятно зачем. Как я писал выше, у JS есть поддержка только чисел до 2^53. Поэтому некоторые программы, которые используют int64_t, переносятся на js, но с костылями. А в WebAssembly — честная поддержка численных типов. Отсюда и выгода.
Кроме того, современный v8 постоянно делает сбор статистики по входным параметрам в функцию, на их основании компилирует js код в байткод процессора. Если какой-то параметр изменил тип — запускается неоптимизированная версия функции и статистика начинает собираться по новой.
А для WebAssembly этот функционал не нужен в принципе. Все статически скомпилировано и связано, как в обычном MZP\ELF исполняемом файле
Вот еще мое поделие. Просмотрщик моделей для WoW. bnet.marlam.in/mv
Требует поддержи WebGL2.0 Управление для моделей M2 — мышкой + колесико мышки. Для моделей WMO — wasd + мышка.
Сначала программа разрабатывалась на C++ + OpenGL 3.3. А потом, как возникла идея — все с достаточно малыми усилиями было скомпилировано в WebAssembly. В основном благодаря тому, что использовались только те команды OpenGL 3.3, которые присутствовали и в WebGL 2.0
PS: Работает лучше всего в Chrome'е. У Safari сейчас вообще нет поддержки WebGL 2.0, поэтому Mac в пролете
Ну тащем-то сейчас WebAssembly дает три преимущества перед js:
1) Нативная поддержка int64
2) Более быстрое выполнение кода
На этом все. Сейчас WebAssembly стоит воспринимать просто как байткод, который содержит типы, за счет чего может более быстро выдавать результат по сравнению с JS. На данном этапе WebAssembly не может делать напрямую вызовы браузерного API(делается через прослойки в виде js функций). Поэтому полезность минимальна.
С другой стороны, я имел опыт, когда программа скомпилированная в asm.js из С++ не работала, где-то внутри неправильно срабатывала математика и программа отказывалась правильно работать. При этом в таргете WebAssembly все работало как часы.
>что он сначала задаёт некие очень сильные требования к квантовым компьютерам, а потом торжественно делает вывод, что эти требования невыполнимы
Справедливости ради, нужно сказать, что нечто похожее происходит и во всей теории QC и QM. Т.е. теорией задается нерушимость некоторых принципов ( как пример — принцип неопределённости Гейзенберга) и любые попытки натянуть результаты экспериментов полученных в рамках QM на принципы классической физики — отсекаются за счет упоминания этих принципов. Получается система замкнутая сама на себя.
Кроме того, само по себе признание того, что QC — это не совсем то, чего все ожидают — создает парадоксальную ситуацию. С одной стороны на исследования выделяются огромные деньги благодаря сильным ожиданиям от пользы QC. С другой стороны, если говорят что вы ожидаете от QC слишком многого, то появляется логичный вопрос: для чего тогда на QC выделяется такое огромное финансирование?
Интересная ситуация с этими вашими квантовыми компьютерами.
Впервые о них я узнал еще в начале 00-х. Прошло 18 лет, а воз и ныне там. Более того, со скрипом въехав в теорию, заложенную как теоретическую базу для них, стало понятно, что в их случае нет гарантированной точности результата.
В игрострое очень часто играются с приближенными формулами расчета физических процессов. Для приближенного моделирования поведения воды, нагрузки на колеса машины и т.д.
Ну я примерно это и имел ввиду. Просто само слово ассемблер некоторых людей вгоняет в ступор. И не низкоуровневые программисты привыкли мыслить переменными. То, что происходит под капотом — вгоняет в ступор.
Сложность SIMD в том, что нужно думать и руками делать:
1) загрузку переменных в регистры
2) манипуляции над регистрами
3) выгрузку результата из регистра в общую память
А развитие языков программирования всегда было направлено на то, чтобы программист забыл об этих низкоуровневых манипуляциях, и как следствие — как можно больше людей могли писать код. js, php, python, VM based languages — вот это все.
Да, я это и имел ввиду. Те же MEMFS, IDBFS и WORKERFS можно использовать и для wasm варианта. Разницы нету никакой.
Из wasm кода можно делать прозрачные вызовы js функций. Благодаря этому факту, glue код для wasm'а ничем не отличается и все эти прелести можно использовать из коробки
Как минимум — это позволяет более эффективно исполнять математику в браузере. JS не сильно дружит с системами типов и виртуальной машине JS приходится постоянно проверять, не изменился ли тип. Если тип изменился — вызывается неоптимизированная версия и чуть позже происходит возможная перекомпиляция JS в тот же машинный код. А это потеря производительности.
А с wasm — типы известны еще до исполнения программы.
Еще один минус JS — нету нативной поддержки Int64. Все числа в JS — double, под значащую часть выделяется только 56 битов и 8 бит под мантису. Из-за этого большие int64 округляются до 2^56 и теряется точность. А wasm поддерживает int64 из коробки
Ну и что? Emscripten может компилировать как в asm.js так и в wasm.
Фишка emscripten'а в том, что сам инстанциирует нужный код и с точки зрения программиста — нету разницы, что именно под капотом. И при asm.js и при wasm вызов функции происходит совершенно одинаково.
Еще одно преимущество — emscripten сделал реализацию системных вызовов платформы linux(syscalls). Это дает возможность прямо переносить программы, которые обращаются к файлам в web. Обращение будет происходить к виртуальной файловой системе, в emscripten есть несколько имплементаций таких — используй какая больше тебе подходит
Наверняка Servo опирается на вызовы системные функции, которые недоступны в браузере.
Поэтому чтобы запустить Servo в браузере — придется имплементировать abstraction layer на API, доступном в браузере. Нечто подобное происходит, когда вендор портирует Android на свой девайс(делается имплементация HAL)
Вирусов не будет. Если бы была возможность они существовали бы уже сейчас. Суть в том, что нужно смотреть на то, какие API браузер предоставляет для JS окружения. То же самое API будет доступно со временем и для WebAssembly. Т.е. ничего нового не добавят
В 2011-м году браузеры добавили поддержку для произвольного доступа к папкам и файлам на HDD без участия юзера. Но потом это выпилили, по всей видимости из соображений безопасности.
Дело в том, что когда 4-х компонентный вектор, представляющий вершину треугольника, умножается на матрицу, предполагается в что в w сидит 1 или 0. 1 — если нужно применять транспонирование из последнего столбца матрицы, 0 — когда нет.
Ты просто идешь и трудоустраиваешься.
Кроме того, современный v8 постоянно делает сбор статистики по входным параметрам в функцию, на их основании компилирует js код в байткод процессора. Если какой-то параметр изменил тип — запускается неоптимизированная версия функции и статистика начинает собираться по новой.
А для WebAssembly этот функционал не нужен в принципе. Все статически скомпилировано и связано, как в обычном MZP\ELF исполняемом файле
bnet.marlam.in/mv
Требует поддержи WebGL2.0 Управление для моделей M2 — мышкой + колесико мышки. Для моделей WMO — wasd + мышка.
Сначала программа разрабатывалась на C++ + OpenGL 3.3. А потом, как возникла идея — все с достаточно малыми усилиями было скомпилировано в WebAssembly. В основном благодаря тому, что использовались только те команды OpenGL 3.3, которые присутствовали и в WebGL 2.0
PS: Работает лучше всего в Chrome'е. У Safari сейчас вообще нет поддержки WebGL 2.0, поэтому Mac в пролете
1) Нативная поддержка int64
2) Более быстрое выполнение кода
На этом все. Сейчас WebAssembly стоит воспринимать просто как байткод, который содержит типы, за счет чего может более быстро выдавать результат по сравнению с JS. На данном этапе WebAssembly не может делать напрямую вызовы браузерного API(делается через прослойки в виде js функций). Поэтому полезность минимальна.
С другой стороны, я имел опыт, когда программа скомпилированная в asm.js из С++ не работала, где-то внутри неправильно срабатывала математика и программа отказывалась правильно работать. При этом в таргете WebAssembly все работало как часы.
PS: с нетерпением жду когда сделают SIMD.JS в WebAssembly. Linked issue здесь: github.com/WebAssembly/proposals/issues/1
Справедливости ради, нужно сказать, что нечто похожее происходит и во всей теории QC и QM. Т.е. теорией задается нерушимость некоторых принципов ( как пример — принцип неопределённости Гейзенберга) и любые попытки натянуть результаты экспериментов полученных в рамках QM на принципы классической физики — отсекаются за счет упоминания этих принципов. Получается система замкнутая сама на себя.
Кроме того, само по себе признание того, что QC — это не совсем то, чего все ожидают — создает парадоксальную ситуацию. С одной стороны на исследования выделяются огромные деньги благодаря сильным ожиданиям от пользы QC. С другой стороны, если говорят что вы ожидаете от QC слишком многого, то появляется логичный вопрос: для чего тогда на QC выделяется такое огромное финансирование?
Впервые о них я узнал еще в начале 00-х. Прошло 18 лет, а воз и ныне там. Более того, со скрипом въехав в теорию, заложенную как теоретическую базу для них, стало понятно, что в их случае нет гарантированной точности результата.
Ну не знаю. Я могу предположить, что это самодеятельность разработчиков компилятора, но как минимум gcc 6 съедает такой код и не давится.
Использование этой конструкции помогло мне очень эффективно портировать код с JS на C++.
Вот это сейчас совершенно легальный код в С++. Привет JS?
Никаких методов. Никаких конструкторов.
И стиль из ООП превращается в процедурное программирование
1) загрузку переменных в регистры
2) манипуляции над регистрами
3) выгрузку результата из регистра в общую память
А развитие языков программирования всегда было направлено на то, чтобы программист забыл об этих низкоуровневых манипуляциях, и как следствие — как можно больше людей могли писать код. js, php, python, VM based languages — вот это все.
Из wasm кода можно делать прозрачные вызовы js функций. Благодаря этому факту, glue код для wasm'а ничем не отличается и все эти прелести можно использовать из коробки
А с wasm — типы известны еще до исполнения программы.
Еще один минус JS — нету нативной поддержки Int64. Все числа в JS — double, под значащую часть выделяется только 56 битов и 8 бит под мантису. Из-за этого большие int64 округляются до 2^56 и теряется точность. А wasm поддерживает int64 из коробки
Фишка emscripten'а в том, что сам инстанциирует нужный код и с точки зрения программиста — нету разницы, что именно под капотом. И при asm.js и при wasm вызов функции происходит совершенно одинаково.
Еще одно преимущество — emscripten сделал реализацию системных вызовов платформы linux(syscalls). Это дает возможность прямо переносить программы, которые обращаются к файлам в web. Обращение будет происходить к виртуальной файловой системе, в emscripten есть несколько имплементаций таких — используй какая больше тебе подходит
Поэтому чтобы запустить Servo в браузере — придется имплементировать abstraction layer на API, доступном в браузере. Нечто подобное происходит, когда вендор портирует Android на свой девайс(делается имплементация HAL)
Вирусов не будет. Если бы была возможность они существовали бы уже сейчас. Суть в том, что нужно смотреть на то, какие API браузер предоставляет для JS окружения. То же самое API будет доступно со временем и для WebAssembly. Т.е. ничего нового не добавят
В 2011-м году браузеры добавили поддержку для произвольного доступа к папкам и файлам на HDD без участия юзера. Но потом это выпилили, по всей видимости из соображений безопасности.
Так что боятся нечего, живем!