Что вошло в релиз движка V8 версии 9.0
- Перевод
17 марта 2021 был опубликован релиз девятой версии движка V8. Этот пост - краткое описание того что вошло в список изменений релиза.
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", которое в итоге сработало.
Здравствуйте, меня зовут Дмитрий Карловский и я… рассекаю на велосипедах… по бездорожью… против ветра… в гору… на лыжах. И сегодня я приглашаю вас прокатиться со мной вдоль и поперёк текстовых форматов данных и вместе спроектировать идеальный формат.
Я уже рассказывал о нём 5 лет назад, что привело к жарким дебатам, повлёкшим за собой небольшие изменения синтаксиса. Поэтому позвольте рассказать с чистого листа что он представляет из себя на текущий момент.
Спикер \Дмитрий Карловский
Место \PiterJS #47
Время 2020-05-20
Это — расширенная текстовая версия одноимённого выступления на PiterJS#47. Вы можете читать её как статью, либо открыть в интерфейсе проведения презентаций, либо посмотреть видео.