" стройки, склады, промзоны" - это очевидно не нормальная среда обитания людей. А опасные зоны, предназначенные для специализированного персонала, который обычно должен заходить туда только после инструктажа по безопасности и одевания средств индивидуальной защиты. И да, возможно как раз там роботы даже больше нужны, чем в нормальной жизни. И возможно там действительно будут более полезны двуногие (хотя вот для склада сильно сомневаюсь, там всё же колёса явно полезнее). Только вот не надо называть это роботами для обычной жизни или для широкого круга задача. Это наоборот будут специализированные роботы для узкой ниши.
Про ширину я имел в виду не то, что она не влияет на экономику, а то что нет никакого увеличения ширины. Ну если конечно ставится такое пожелание и инженер не совсем криворукий.
"major players (Tesla, Boston Dynamics, Figure, Agility) " - ха, это вообще кто такие? Какие у них доли рынка робототехники? Я видел анализы рынка за последний год и не припомню таких имён даже в первой двадцатке...
О какой человеческой инфраструктуре речь? Если мы говорим о современной комфортной для человека среде, то там вообще будет минимизировано всё то, чего не любят колёсные устройства. Даже лестницы и пороги минимизируют сейчас, не говоря уже о более пересечённой местности. Вы вообще в курсе какова проходимость женщины на красивых каблуках? ))) Я уже молчу про инвалидов и современный тренд по приведению окружающей среды в приемлемую для них.
Так что если говорить именно о среде для жизни людей, то наиболее эффективным тут решением будет не двуног и даже не гибрид с колёсами (про которого я писал в предыдущем сообщение), а банальная тележка на роликах. И не удивительно что все современные роботы-гиды, а так же роботы-пылесосы и т.п. делаются по такой схеме. Им просто большей проходимости и не надо, а эффективность при этом максимальная.
Вот если мы захотим большей проходимости, чтобы робот мог и по дороге и по лестнице и по склону и через какие-то препятствия, то тут уже надо отходить от просто колёс. И на мой взгляд тут как раз оптимален гибрид ног с колёсами, типа того, что на видео в предыдущем сообщение.
А вот если роботу нужно будет передвигаться исключительно по препятствиям (типа напарник по альпинизму или по подводной лодке или что-то индустриальное в таком стиле), то тут соглашусь, что лидером будет двуног (не даром эволюция его выбрала).
Очевидно что у каждого подхода есть своя область, где он может лидировать. Однако на мой взгляд у двунога она наиболее узкая (хотя и важная, скажем каким-нибудь спасателям точно такой больше всего подходит), что прямо противоречит посылу статьи.
P.S. Что касается "экономических" аргументов, то поводу числа модулей соглашусь (хотя это просто цена за большую универсальность), а вот по поводу увеличения ширины - это просто смешно и может быть аргументом только какого-то инженера-недоучки.
В целом статья весьма интересная (много интересных цифр из биологии, которых я раньше не видел). Если бы только не провокационный (потому что не верный) заголовок и отсутствие реального доказательства этого нагло выдвинутого тезиса в самом тексте. Потому что доказательством тезиса о лучшем не может быть сравнение с ещё каким-то одним решением, а может быть только сравнение со всеми возможными.
Как банальный контр-пример просто возьмём любого четырёхногого робота и приделаем ему снизу маленькие мотор-колёса. И мгновенно получим решение с такой же эффективность на пересечённой местности как у обычного четырёхнога и при этом превосходящую на порядок всех безколёсных (включая двухнога) на ровной поверхности.
Не буду тут показывать наши решения, так что просто оставлю тут это видео как пример подобного решения (на которое сейчас кстати смотрят многие ведущие разработчики в данной области):
P.S. Так что на мой взгляд двухногость является венцом эволюции только потому, что природа не смогла создать концепцию колеса.
В статье же чётко описано, что это не совпадение, а однозначно следствие того, как была выбрана международная единица измерения длины (в каких-нибудь футах/секунда^2 или аршинах/секунда^2 цифры уже не сходятся).
Более того, такое же численное значение (но в местных единицах измерения) будет и на других планетах, на которых развитие науки двигалось точно таким же путём.
Если уж говорить о g, как о константе, то надо апеллировать скорее к каким-то инженерным наукам, а не к физике. Вот в них частенько используют g как внесистемную единицу измерения ускорения. Скажем при расчёте допустимых перегрузок и т.п. А вот в физике это точно не является одной из фундаментальных констант. Хотя бы потому что для физиков это как минимум функция, а по хорошему вообще тензорное поле 2-го ранга. )))
Потому что согласно истории считать надо не от меридиана, а от маятника. А меридиан потом подогнали просто.
Соответственно для Марса один местный метр будет где-то 0,4 нашего (с учётом разницы в секундах). Ну и можно потом подогнать, что он равен 1/53 000 000 их меридиана.
И тогда местное g будет как раз в районе 9,88 в местных единицах.
Константы легко вычислить просто по размерности. Но смысл статьи как раз в том, что в случае g ничего вычислять не надо - оно будет таким же (в районе пи квадрат в местных единицах), если развитие науки (а точнее метрологии) у них двигалось бы так же как и у нас...
Если автор «дорос» до такой «инновационной» технологии, как make и при этом параллельно активно использует различные скрипты на Python, то возможно ему стоило бы сделать следующий шаг в развитие и открыть для себя такие слова как Scons, Waf или вообще Bazel. С ними получился бы один простенький и логичный скрипт сборки, а не запутанный монстр, как в статье.
Зачем было использовать ESP32, главной фичей которого является интегрированный wifi (не используемый в данном проекте)? Можно было взять любой приличный МК со встроенным bluetooth (например те же популярные STM32) и избежать половины проблем из статьи.
Никаких особых оптимизаций в C++ мы не делали. Мы согласны с тем, что если покрутить правильные ручки у компилятора, то можно выжать совсем другие цифры.
Делать тесты производительности с C++ без хотя бы опции "-O3" — это уже довольно странная трата времени…
Лично я ожидал, что нативный код будет выполняться значительно быстрее Wasm. Но первые полученные результаты показали, что это не так. И это меня довольно сильно удивило. Планирую вернуться к этому бенчмарку позже.
И правильно что удивило — там точно что-то не так. )
Что касается нашего продукта, то все замеры производительности значат мало что, т.к. на сетевых задержках мы потеряем гораздо больше времени.
Ну я говорил только про обсуждаемый в статье тест — для него очевидно и тесты производительности актуальны и SIMD и т.д. Про продукт в контексте производительности вроде речи не было, так что мои замечания относились не к нему.
Мы честно пытались найти хоть какой-то мало-мальски вычислительный код в продукте. Взяли например обработчик плейлистов. Но на реальных данных код выполняется микросекунды, поэтому бенчмаркать там нечего. К тому же, это совсем не критический участок кода.
Если у вас там видео воспроизводится, то можно посмотреть различные латентности, особенно в 4K и со сложными кодеками. )
Гарантий нет, но ведь всегда есть достаточно безопасные и предсказуемые кусочки программы, про которые что-то можно доказать.
Проблема в том, что на уровне машинных кодов невозможно получить гарантии. Потому как JIT компилятору неоткуда знать, что к данной ячейки памяти нет доступа у какого-то другого кода. Т.е. тот же C++ компилятор ещё может делать подобные выводы например по отсутствию ссылок (или операций взятия адреса) на данную переменную. А при просто потоке машинных кодов, обращающихся к каким-то произвольным участкам памяти, как гарантированно понять, что какой-то посторонний код (в худшем случае вообще в параллельном потоке — этого сейчас в WASM нет, но планируется в ближайшее время) не поправит данную ячейку памяти (которая потом используется как указатель)?
А браузеру вовсе не нужно с данной памятью работать. Учитывая, что в WebAssembly пока размер кучи ограничен 2^32, а процессоры у нас 64-битные, можно тупо нарезервировать страниц как раз на 2^32, но на реальные физические отобразить ровно столько, сколько заявлено в дескрипторе wasm-модуля (ну и по мере вызова grow_memory отображать дополнительные).
Ээээ что? Что значит браузеру не нужно с данной памятью работать? Ему не нужна вообще никакая память для своей личной работы или как? А если хоть какая-то нужна, то как её защитить от доступа из WASM модуля с помощью защиты страниц виртуальной памяти?
Вы хотите сказать, что clang берёт и сам генерит векторные инструкции? Мне казалось, что они всё-таки получаются в процессе работы самого LLVM. Учитывая, что с точки зрения меня, как разработчика приложений, формат wasm является всего лишь форматом обмена данными, мне всё равно, в какой там IR браузер разворачивает мой wasm-модуль и как его оптимизировать.
Ни в какой IR модули WASM в браузере не разворачивается. Формат wasm — это по сути и есть IR, представляющее собой ассемблерные инструкции некого виртуального процессора. Причём этот формат является чуть изменённой (упрощённой и с большей безопасностью) версией IR из LLVM. К сожалению векторные типы LLVM не вошли в первую версию WASM.
Или разработчики WebAssembly не хотят, чтобы браузер делал векторизацию и хотят переложить эту заботу на компилятор? Ну тогда я всё равно не вижу практической невозможности позволить генерацию быстрого кода, я вижу только невозможность сочетать это с быстрым запуском кода.
Вот уж не знаю как. Я точно помню, как общался с сотрудниками Мозиллы и они мне говорили про багу в range analysis ещё в альфа-версии WebAssembly. Как минимум, нижняя граница определена в compile-time (в WebAssembly-модуле для heap необходимо указывать минимальный и максимальный размер хипа), а то, что указатель известен только в рантайме, ещё не значит, что его диапазон нельзя оценить с помощью статического анализа. Такое, например, реализовано в JVM для устранения проверки на выход за границу массива.
Так нужны гарантии, что эти значения не меняются. Именно в этом проблема, а не в определение самих значений. Собственно единственная оптимизация, которую реально делают все подобные инструменты, это убирание повторных проверок (ну типа если мы дважды обращаемся по одному указателю внутри одной итерации цикла).
mprotect в POSIX. В Windows тоже был системный вызов, но я с ходу не вспомнил название.
VirtualProtect это в Винде. Только ничем эти функции не помогут для решения данной проблемы. Если закрыть с помощью них доступ к какой-то области памяти, то каким образом сам браузер будет работать с этой областью памяти?
Там есть всё необходимое. Вот как-то C-компиляторы делают это. А они, заметьте, никогда не оптимизируют непосредственно AST C. Т.е. они строят IR (промежуточное представление), которое как раз очень похоже на портабельный ассемблер, а потом уже находят в нём циклы, которые можно векторизовать. Для этого есть куча способов, есть много специализорованной литературы, которая рассказывает про это (вот даже последние редакции Dragon Book рассказывают про векторизацию), и есть ещё большая куча всяческих статей от авторов тех или иных компиляторов.
С учётом того, что в LLVM IR имеются векторные типы, это конечно очень большая загадка, как это делается. ))) Кстати, ещё забавный вопрос: интересно, как укладывается в это ваше видение факт работы OpenMP SIMD (у уже молчу про intrinsics)?
Полагаю, что статья автора как раз не про драйвера и ядра ОС.
Речь о том, что отказ от исключений уж точно не ведёт к потере производительности. )
Само собой. Например, хотя у нас в имеются специалисты с экспертным знанием C++, но для бэкенда наших сайтов используется вообще дико медленный Питон, потому как C++ нам тут просто не нужен — мы не Гугл или Яндекс. Однако все эти размышления не имеют никакого отношения к моему изначальному замечанию — там речь шла совсем о другом:
если у ребят получилась одинаковая производительность подобного алгоритма на JS, WASM (C++) и нативном C++, то практически гарантированно у них что-то очень не так в варианте нативного C++.
Мне кажется, что проверка на выход за границы heap-а в ряде случаев может убираться оптимизатором.
Каким это образом, если и значение указателя и значения границ определены только в рантайме?
Кроме того, часть работы по отлову выходов за границу хипа можно сделать через защиту памяти.
Каким образом можно в рамках одного процесса закрыть некому коду доступ к какой-то области выделенной памяти?
Что касается SIMD, опять же, браузер может сам анализировать WASM и автоматом векторизовать его (для этого в WASM есть всё необходимое).
Нет там ничего необходимого. В будущем появится (соответствующие инструкции), но пока нет.
А если бы можно было делать автовекторизацию напрямую из машинных кодов, то такой алгоритм давным давно внедрили бы непосредственно в конвейер CPU.
По крайней мере, LLVM ровно так и делает.
Ээээ что? Где это он так делает?
Нет возможности получить указатель на переменную в стеке. Если такой указатель где-то берётся, то приходится размещать переменную в shadow-стеке, со всеми накладными расходами на поддержание shadow-стека.
Хм, да это интересный момент. Я его не смотрел. Причём с учётом того, что итоговая машина всё же стековая, у WASM JIT'a в теории есть большое поле для оптимизации. А вот делается ли там сейчас что-то для этого или нет — не знаю. Хотя это не сложно посмотреть, т.к. исходники открыты.
Нет возможности вообще как-то погулять по стеку, чтобы, например, сгенерировать исключение. Да и нативную поддержку исключений пока не завезли. Так что единственная возможность — это вставлять всюду проверки.
С учётом того, что в наиболее требовательных к ресурсам приложениях (программирование различных МК, ядра ОС, дравейров и т.п.) как раз применяется режим C++ с отключёнными исключениями, то данная особенность если и влияет на производительность, то только положительно. )))
Все приложения разные, а JIT в браузерах творит чудеса.
Нет там никаких чудес. Каждый раз, когда я видел утверждения о равенстве быстродействия с C++, всё сводилось к кривому использованию последнего (собственно иначе и быть не может, т.к. тогда бы уже давно писали бы браузеры на js). Для схожего с использованным в статье для тестов алгоритмом у меня были следующие результаты (это усреднённое время в мс):
JS 15,6
C# 15,1
ASM.JS (из C++) 12,5
WASM из ASM.JS 11,4
Java 10,1
C# unsafe 8,9
WASM 8,6
D 7,2
C++ nosimd 4,4
C++ 1,5
Хорошая статья по WebAssembly. Единственное, чтобы я добавил, это что для сборки C++ кода в WASM не требуется обязательно Emscripten. Для собственно компиляции достаточно просто компилятора LLVM (естественно собранным с поддержкой WASM и Clang'ом). И именно его использует Emscripten внутри себя. А смысл проекта Emscripten не в генерации WASM (или даже asm.js, с чего всё начиналось), а в генерации JS обёрток, реализующих функциональность стандартных библиотек C++ через браузерное API. Т.е. без Emscripten (с чистым LLVM) не будет возможности даже для вызова функции типа printf (но при этом будет базовая возможность вызвать произвольную JS функцию из страницы, в которую загружен wasm модуль).
Да, ну и вот эта цитата:
Но когда включается оптимизация (зеленый столбик), мы получаем время, практически совпадающее с JS. И, забегая вперед, мы получаем аналогичные результаты в нативном коде, если скомпилируем С++, как нативное приложение.
означает, что у вас есть какие-то фундаментальные проблемы в вашем нативном C++ приложение. Т.е. мои тесты вполне подтверждают ваш результат, что WASM в данное время сравним по производительности с JS. Но при этом тот же C++ код скомпилированный в машинные коды всегда получается в разы быстрее. И на это есть две фундаментальные причины:
1. WASM с одной стороны предоставляет полный доступ к работе с указателями, а с другой должен гарантировать безопасное выполнение подобного кода внутри песочницы (у модуля не должно быть способа залезть в данные браузера или других модулей). Как следствие этого, IR код работы с памятью компилируется (при загрузке модуля в браузере) не в прямую инструкцию x86, а с дополнительной проверкой выхода за границы выделенной памяти. На активно работающем с памятью коде, это может давать просадку производительности х2 раза.
2. SIMD. В будущем в WASМ планируют завести поддержку SIMD инструкций, но пока этого нет. В JS этого нет тем более. А в любом приличном компиляторе C++ уже много лет как поддерживается автовекторизация циклов, которая может давать увеличение быстродействие вплоть до х7 раз (для самых подходящих циклов, но в коде графических фильтров изображений должно быть полно таких).
В общем не знаю где у вас там конкретные косяки с C++, но если у вас скомпилированное в машинные коды приложение исполняется столько же, сколько WASM и JS варианты, то эти косяки у вас однозначно есть.
Да, я вспомнил что в десятки раз — это касалось не openocd, а родной утилиты от STМ (называется ST-LINK Utility), которой я пользовался для прошивки до j-link.
Насколько софт JLink быстрее? Полагаю, что главным фактором, определяющим время прошивки, является всё же скорость соединения дебагера.
В десятки раз. На том же железе (но с другой прошивкой программатора).
Qt Creator поддерживает только openocd и st-util
Это не так. Qt Creator изначально поддерживает ровно один универсальный режим отладки — удалённый gdb. Плюс к этому там есть две дополнительные предустановки для st-link и openocd. Однако это всего лишь для удобства — можно без проблем настроить тот же openocd (который естественно реализуют gdb сервер) через общий универсальный режим (он в настройках Qt Creator называется «по умолчанию»).
Так что отладка через j-link (ПО, а в качестве железа служит обычный st-link, перепрошитый под j-link их официальной утилитой) у меня отлично работает из Qt Creator.
работа под линуксом — это два (хотя мб софт jlink тут тоже работает)
Есть и под винду и под линух и под мак.
openocd это универсальный комбайн, поддерживающий хоть stm32, stm8, отечественные кортексы — это три
Так j-link аналогично. И более того, там получается одно универсальное решение не только со стороны ПО, но и одно аппаратное решение для всех МК.
целый зоопарк отладчиков помимо jlink и stlink — это четыре
В данном сравнение это получается уже скорее минус, чем плюс. )))
ну и возможность лазить в сходники и делать любые фиксы — это пять.
А вот это да, я бы тоже предпочёл иметь открытые исходники ПО от Segger. Но боюсь в таком случае у них не вышло бы нормально зарабатывать… ))) Так что уж лучше качественное закрытoe ПО.
Из всего семейства Сortex-M вывода SWO нет лишь у M0/M0+ — поэтому решение прокатывает в большинстве случаев.
Ну вот например у нас из МК используются исключительно STM32F0, так что для нас это «лишь» является наоборот «всем». )))
Раньше вот даже не знал, что RTT уже c openocd скрестили, а теперь руки чешутся всё это дело проверить.
А зачем обязательно openocd использовать? Почему не попробовать более мощный j-link? Оно же даже без логирования и отладки намного удобнее, например хотя бы временем прошивки…
Своё личное мнения я уже изложил в комментариях выше. А здесь хочу поделиться свежим и весьма интересным (и во многом совпадающим с моим) мнением довольно авторитетного человека: https://rodneybrooks.com/why-todays-humanoids-wont-learn-dexterity/
" стройки, склады, промзоны" - это очевидно не нормальная среда обитания людей. А опасные зоны, предназначенные для специализированного персонала, который обычно должен заходить туда только после инструктажа по безопасности и одевания средств индивидуальной защиты. И да, возможно как раз там роботы даже больше нужны, чем в нормальной жизни. И возможно там действительно будут более полезны двуногие (хотя вот для склада сильно сомневаюсь, там всё же колёса явно полезнее). Только вот не надо называть это роботами для обычной жизни или для широкого круга задача. Это наоборот будут специализированные роботы для узкой ниши.
Про ширину я имел в виду не то, что она не влияет на экономику, а то что нет никакого увеличения ширины. Ну если конечно ставится такое пожелание и инженер не совсем криворукий.
"major players (Tesla, Boston Dynamics, Figure, Agility) " - ха, это вообще кто такие? Какие у них доли рынка робототехники? Я видел анализы рынка за последний год и не припомню таких имён даже в первой двадцатке...
О какой человеческой инфраструктуре речь? Если мы говорим о современной комфортной для человека среде, то там вообще будет минимизировано всё то, чего не любят колёсные устройства. Даже лестницы и пороги минимизируют сейчас, не говоря уже о более пересечённой местности. Вы вообще в курсе какова проходимость женщины на красивых каблуках? ))) Я уже молчу про инвалидов и современный тренд по приведению окружающей среды в приемлемую для них.
Так что если говорить именно о среде для жизни людей, то наиболее эффективным тут решением будет не двуног и даже не гибрид с колёсами (про которого я писал в предыдущем сообщение), а банальная тележка на роликах. И не удивительно что все современные роботы-гиды, а так же роботы-пылесосы и т.п. делаются по такой схеме. Им просто большей проходимости и не надо, а эффективность при этом максимальная.
Вот если мы захотим большей проходимости, чтобы робот мог и по дороге и по лестнице и по склону и через какие-то препятствия, то тут уже надо отходить от просто колёс. И на мой взгляд тут как раз оптимален гибрид ног с колёсами, типа того, что на видео в предыдущем сообщение.
А вот если роботу нужно будет передвигаться исключительно по препятствиям (типа напарник по альпинизму или по подводной лодке или что-то индустриальное в таком стиле), то тут соглашусь, что лидером будет двуног (не даром эволюция его выбрала).
Очевидно что у каждого подхода есть своя область, где он может лидировать. Однако на мой взгляд у двунога она наиболее узкая (хотя и важная, скажем каким-нибудь спасателям точно такой больше всего подходит), что прямо противоречит посылу статьи.
P.S. Что касается "экономических" аргументов, то поводу числа модулей соглашусь (хотя это просто цена за большую универсальность), а вот по поводу увеличения ширины - это просто смешно и может быть аргументом только какого-то инженера-недоучки.
В целом статья весьма интересная (много интересных цифр из биологии, которых я раньше не видел). Если бы только не провокационный (потому что не верный) заголовок и отсутствие реального доказательства этого нагло выдвинутого тезиса в самом тексте. Потому что доказательством тезиса о лучшем не может быть сравнение с ещё каким-то одним решением, а может быть только сравнение со всеми возможными.
Как банальный контр-пример просто возьмём любого четырёхногого робота и приделаем ему снизу маленькие мотор-колёса. И мгновенно получим решение с такой же эффективность на пересечённой местности как у обычного четырёхнога и при этом превосходящую на порядок всех безколёсных (включая двухнога) на ровной поверхности.
Не буду тут показывать наши решения, так что просто оставлю тут это видео как пример подобного решения (на которое сейчас кстати смотрят многие ведущие разработчики в данной области):
P.S. Так что на мой взгляд двухногость является венцом эволюции только потому, что природа не смогла создать концепцию колеса.
В статье же чётко описано, что это не совпадение, а однозначно следствие того, как была выбрана международная единица измерения длины (в каких-нибудь футах/секунда^2 или аршинах/секунда^2 цифры уже не сходятся).
Более того, такое же численное значение (но в местных единицах измерения) будет и на других планетах, на которых развитие науки двигалось точно таким же путём.
Если уж говорить о g, как о константе, то надо апеллировать скорее к каким-то инженерным наукам, а не к физике. Вот в них частенько используют g как внесистемную единицу измерения ускорения. Скажем при расчёте допустимых перегрузок и т.п. А вот в физике это точно не является одной из фундаментальных констант. Хотя бы потому что для физиков это как минимум функция, а по хорошему вообще тензорное поле 2-го ранга. )))
Потому что согласно истории считать надо не от меридиана, а от маятника. А меридиан потом подогнали просто.
Соответственно для Марса один местный метр будет где-то 0,4 нашего (с учётом разницы в секундах). Ну и можно потом подогнать, что он равен 1/53 000 000 их меридиана.
И тогда местное g будет как раз в районе 9,88 в местных единицах.
Константы легко вычислить просто по размерности. Но смысл статьи как раз в том, что в случае g ничего вычислять не надо - оно будет таким же (в районе пи квадрат в местных единицах), если развитие науки (а точнее метрологии) у них двигалось бы так же как и у нас...
Делать тесты производительности с C++ без хотя бы опции "-O3" — это уже довольно странная трата времени…
И правильно что удивило — там точно что-то не так. )
Ну я говорил только про обсуждаемый в статье тест — для него очевидно и тесты производительности актуальны и SIMD и т.д. Про продукт в контексте производительности вроде речи не было, так что мои замечания относились не к нему.
Если у вас там видео воспроизводится, то можно посмотреть различные латентности, особенно в 4K и со сложными кодеками. )
Проблема в том, что на уровне машинных кодов невозможно получить гарантии. Потому как JIT компилятору неоткуда знать, что к данной ячейки памяти нет доступа у какого-то другого кода. Т.е. тот же C++ компилятор ещё может делать подобные выводы например по отсутствию ссылок (или операций взятия адреса) на данную переменную. А при просто потоке машинных кодов, обращающихся к каким-то произвольным участкам памяти, как гарантированно понять, что какой-то посторонний код (в худшем случае вообще в параллельном потоке — этого сейчас в WASM нет, но планируется в ближайшее время) не поправит данную ячейку памяти (которая потом используется как указатель)?
Ээээ что? Что значит браузеру не нужно с данной памятью работать? Ему не нужна вообще никакая память для своей личной работы или как? А если хоть какая-то нужна, то как её защитить от доступа из WASM модуля с помощью защиты страниц виртуальной памяти?
Ни в какой IR модули WASM в браузере не разворачивается. Формат wasm — это по сути и есть IR, представляющее собой ассемблерные инструкции некого виртуального процессора. Причём этот формат является чуть изменённой (упрощённой и с большей безопасностью) версией IR из LLVM. К сожалению векторные типы LLVM не вошли в первую версию WASM.
Не нехотят, а это единственное разумное решение. И собственно говоря уже все материалы (типы, инструкции) для реализации подготовлены: github.com/WebAssembly/simd/blob/master/proposals/simd/SIMD.md. Но в текущий «стандарт» WASM это пока не входит.
Так нужны гарантии, что эти значения не меняются. Именно в этом проблема, а не в определение самих значений. Собственно единственная оптимизация, которую реально делают все подобные инструменты, это убирание повторных проверок (ну типа если мы дважды обращаемся по одному указателю внутри одной итерации цикла).
VirtualProtect это в Винде. Только ничем эти функции не помогут для решения данной проблемы. Если закрыть с помощью них доступ к какой-то области памяти, то каким образом сам браузер будет работать с этой областью памяти?
С учётом того, что в LLVM IR имеются векторные типы, это конечно очень большая загадка, как это делается. ))) Кстати, ещё забавный вопрос: интересно, как укладывается в это ваше видение факт работы OpenMP SIMD (у уже молчу про intrinsics)?
Речь о том, что отказ от исключений уж точно не ведёт к потере производительности. )
если у ребят получилась одинаковая производительность подобного алгоритма на JS, WASM (C++) и нативном C++, то практически гарантированно у них что-то очень не так в варианте нативного C++.
Каким это образом, если и значение указателя и значения границ определены только в рантайме?
Каким образом можно в рамках одного процесса закрыть некому коду доступ к какой-то области выделенной памяти?
Нет там ничего необходимого. В будущем появится (соответствующие инструкции), но пока нет.
А если бы можно было делать автовекторизацию напрямую из машинных кодов, то такой алгоритм давным давно внедрили бы непосредственно в конвейер CPU.
Ээээ что? Где это он так делает?
Хм, да это интересный момент. Я его не смотрел. Причём с учётом того, что итоговая машина всё же стековая, у WASM JIT'a в теории есть большое поле для оптимизации. А вот делается ли там сейчас что-то для этого или нет — не знаю. Хотя это не сложно посмотреть, т.к. исходники открыты.
С учётом того, что в наиболее требовательных к ресурсам приложениях (программирование различных МК, ядра ОС, дравейров и т.п.) как раз применяется режим C++ с отключёнными исключениями, то данная особенность если и влияет на производительность, то только положительно. )))
Нет там никаких чудес. Каждый раз, когда я видел утверждения о равенстве быстродействия с C++, всё сводилось к кривому использованию последнего (собственно иначе и быть не может, т.к. тогда бы уже давно писали бы браузеры на js). Для схожего с использованным в статье для тестов алгоритмом у меня были следующие результаты (это усреднённое время в мс):
JS 15,6
C# 15,1
ASM.JS (из C++) 12,5
WASM из ASM.JS 11,4
Java 10,1
C# unsafe 8,9
WASM 8,6
D 7,2
C++ nosimd 4,4
C++ 1,5
Да, ну и вот эта цитата:
означает, что у вас есть какие-то фундаментальные проблемы в вашем нативном C++ приложение. Т.е. мои тесты вполне подтверждают ваш результат, что WASM в данное время сравним по производительности с JS. Но при этом тот же C++ код скомпилированный в машинные коды всегда получается в разы быстрее. И на это есть две фундаментальные причины:
1. WASM с одной стороны предоставляет полный доступ к работе с указателями, а с другой должен гарантировать безопасное выполнение подобного кода внутри песочницы (у модуля не должно быть способа залезть в данные браузера или других модулей). Как следствие этого, IR код работы с памятью компилируется (при загрузке модуля в браузере) не в прямую инструкцию x86, а с дополнительной проверкой выхода за границы выделенной памяти. На активно работающем с памятью коде, это может давать просадку производительности х2 раза.
2. SIMD. В будущем в WASМ планируют завести поддержку SIMD инструкций, но пока этого нет. В JS этого нет тем более. А в любом приличном компиляторе C++ уже много лет как поддерживается автовекторизация циклов, которая может давать увеличение быстродействие вплоть до х7 раз (для самых подходящих циклов, но в коде графических фильтров изображений должно быть полно таких).
В общем не знаю где у вас там конкретные косяки с C++, но если у вас скомпилированное в машинные коды приложение исполняется столько же, сколько WASM и JS варианты, то эти косяки у вас однозначно есть.
В десятки раз. На том же железе (но с другой прошивкой программатора).
Это не так. Qt Creator изначально поддерживает ровно один универсальный режим отладки — удалённый gdb. Плюс к этому там есть две дополнительные предустановки для st-link и openocd. Однако это всего лишь для удобства — можно без проблем настроить тот же openocd (который естественно реализуют gdb сервер) через общий универсальный режим (он в настройках Qt Creator называется «по умолчанию»).
Так что отладка через j-link (ПО, а в качестве железа служит обычный st-link, перепрошитый под j-link их официальной утилитой) у меня отлично работает из Qt Creator.
Есть и под винду и под линух и под мак.
Так j-link аналогично. И более того, там получается одно универсальное решение не только со стороны ПО, но и одно аппаратное решение для всех МК.
В данном сравнение это получается уже скорее минус, чем плюс. )))
А вот это да, я бы тоже предпочёл иметь открытые исходники ПО от Segger. Но боюсь в таком случае у них не вышло бы нормально зарабатывать… ))) Так что уж лучше качественное закрытoe ПО.
Ну вот например у нас из МК используются исключительно STM32F0, так что для нас это «лишь» является наоборот «всем». )))
А зачем обязательно openocd использовать? Почему не попробовать более мощный j-link? Оно же даже без логирования и отладки намного удобнее, например хотя бы временем прошивки…