Привет хакеры, сегодня мы с вами отправимся в путешествие в мир индустриального C++ и Webassembly. Недавно мне довелось поучаствовать в портировании такой сложной и большой кодовой базы на C/C++ как SpiderMonkey на WASI платформу и я хочу поделиться с вами этим опытом.
Вас задрало, что node_modules соревнуются по количеству используемого места с вашей коллекцией музыки?
Вы перечитали инструкцию к Redux в шестидесятый раз и поняли две вещи: "До меня кажется доходит..." и "Думаю, мне стоит перечитать это ещё раз!"
Вы в очередной раз узнали, что 1 + "1" == "11", а [] - {} == NaN?
Билд скрипт в webpack занимает больше места чем ваша библиотека на javascript?
Тогда заходите под кат, я покажу вам, как можно перевести ваш фронтэнд на го.
Приветствую. Хочу донести гениальную и простейшую идею о том, как можно бесплатно хостить несложные бессерверные веб-приложения на Blazor WASM на github pages.
Это особенно полезная инструкция для тех, кто хотел бы сделать элементарнейшие утилиты, но не хочет/не может для этого поднимать сервер или использовать js для всех вычислений.
Прошу под кат!
Grain стремится взять лучшее от функциональных и императивных языков программирования и донести это до широкой аудитории. Во многих языках реализованы замечательные идеи, но в конечном итоге эти языки не получили широкого распространения. Всё потому, что они слишком странные или чересчур сложные для изучения. И, следовательно, их попытки сплотить вокруг себя большое сообщество провалились. Grain должен вдохнуть новую жизнь в эти идеи и представить их в доступной форме, оставаясь простым в использовании.
17 марта 2021 был опубликован релиз девятой версии движка V8. Этот пост - краткое описание того что вошло в список изменений релиза.
В .NET 6 запланирована поддержка AOT компиляции для Blazor WebAssembly приложений. Давайте попробуем запустить в Preview 2 версии.
Анонса и инструкций пока что нету. Поэтому и решено написать этот пост.
WebGL 2.0 вышел в далёком 2017ом году, принёс графический стек OpenGL ES 3.0 (2012го года), и, казалось бы, все современные браузеры давно должны были его поддерживать. Однако, среди лидеров затесались отстающие, и пользователи Safari до сих пор (начало 2021го) вынуждены ограничиваться возможностями WebGL 1.0, опубликованным в 2011ом году на основе OpenGL ES 2.0.
PBR освещение достаточно требовательно к вычислительным ресурсам графического процессора и обычно реализуется средствами WebGL 2.0. Возможно ли адаптировать PBR рендерер графического движка для работы в условиях ограничений WebGL 1.0 на iPad? В этой статье описывается опыт такой адаптации для графического движка открытого C++ фреймворка Open CASCADE Technology.
В предыдущей статье мы остановились на варианте, который с помощью SWAR-хинта превращает 8 последовательных цифр в одно числовое 32bit-значение. Но что если мы предположим, что все значения у нас, в основном, невелики - до 3 цифр? Тогда нам вполне достаточно использовать всего лишь 32bit-инструкции, а SWAR будет выполнен за 2 операции вместо 3 - сплошной выигрыш!
Давайте перепишем наш код так, чтобы первый блок из 4 символов обрабатывался 32bit-инструкциями, а второй блок из 8 символов, если понадобится - уже 64bit-инструкциями.
И... вместо 29ms получаем 31ms! Значит, наше предположение относительно длины чисел не оправдалось, и в первом блоке выгоднее обрабатывать сразу побольше символов.
То есть больше размерность регистра - лучше? И такие регистры есть - это 128-битные SSE-регистры XMM - в WebAssembly они доступны нам как переменные с типом v128 и суперскалярные операции над ними.
В первой части статьи мы исследовали скорость различных вариантов обмена информацией между JavaScript и WASM-кодом. В этом продолжении - наконец-то займемся написанием прикладного кода нашего парсера.
Мы ведь теперь пишем "прямо на ассемблере" - значит, все будет супербыстро! Правда ведь?
ASP.NET Core Blazor — это разработанная Microsoft веб-платформа, предназначенная для запуска на стороне клиента в браузере на основе WebAssembly (Blazor WebAssembly) или на стороне сервера в ASP.NET Core (Blazor Server), но две эти модели нельзя использовать одновременно. Подробнее о моделях размещения написано в документации.
В статье я расскажу о том, как
TL;DR:
В прошлой статье, посвященной выяснению победителя в состязании JS-парсеров строки buffers-атрибута узла плана PostgreSQL, мы дошли до факта, что самый эффективный вариант - реализовать примитивный конечный автомат и никогда не трогать регулярные выражения и любые операции над строками сложнее .charCodeAt.
Такой код на тестовом нормализованном наборе показывает время порядка 48ms на 6.3MB или около 130MB/s, что примерно в 11 раз быстрее наивного варианта со .split.
Но всегда остается вопрос: "А еще быстрее - можно?"
Чтобы приблизиться к возможностям "железа", но по-прежнему остаться в инфраструктуре JavaScript, сегодня мы научимся решать эту задачу с использованием WebAssembly и SIMD-инструкций, постаравшись по пути споткнуться обо все подводные камни.
Пока одни обсуждают что не так с WebAssembly, я думаю как его можно использовать вне браузера. Например написание wasm фильтров для Envoy. AssemblyScript был взят потому, что это не C++ и не Rust, т.е. ожидается более низкий порог вхождения. Под катом будет дико примитивный код и пару бенчмарков. Картинка взята из бенчмарка.
Моя предыдущая статья про rust вызвала положительную реакцию и большое количество обсуждений о том что да как с rust. Мне исключительно приятно видеть что вам понравился этот материал.
В комментариях я встретил много вопросов типа «А можно ли использовать rust для WEB?» Лаконичный ответ таков: «Можно». Можно и brainfuck использовать, если хочется. Нужно ли? Скажем так, brainfuck для WEB использовать категорически не стоит. А вот rust – тут надо понимать что именно делает rust и каковы его цели. Для того чтобы это понять мы должны погрузиться в компилятор и разобраться в устройстве процессоров. Под катом вы найдёте глубокий заныр в историю того как появился rust и поймёте что это такое и когда его нужно использовать а когда можно и на «ноде запилить».
В рамках одного из моих SDK-проектов нам понадобилось добавить скриптование, которое бы оказало наименьший эффект на размер конечного бинарного файла, но при этом предоставляло хорошую фунциональность. Это дало старт проекту, который описан в этой статье. Прошу заметить, что т.к. в SDK у нас есть определенные требования, они частично перенеслись на язык скриптования, поэтому в проекте не участвовали некоторые достаточно известные встраиваемые ЯП (но Lua включен для сравнения).
Сайт проекта доступен по ссылке. Скажу сразу, что на данный момент для меня лично победителями являются Chibi-Scheme и Wasm3. Подробности для заинтересовавшихся под катом.
В этой статье я хотел бы пройтись и показать основные моменты того, как настроить IDE CLion для компиляции CMake проекта средствами Emscripten. Когда я занимался этим скрещиванием мне пришлось потратить день или два на эксперименты. И в этой заметке я собираюсь собрать некое "how to", которое в итоге сработало.
