Поигрался с примером на js. Вот что интересно, если сравнивать версию с функцией и без функции (for (...) { j += i / 3.1415692 }), то выясняется, что при количестве итераций < 10 000 разница в скорости больше трех раз, однако позже скорость выполнения выравнивается и держится на уровне 1.2 (365 527 293 ns против 336 979 720 ns).
Что-то мне подсказывает, что в такой базовый пример врывается JIT. Если заморочаться дальше, можно запустить ноду с --print-opt-code, в выводе справедливо появится строчка
Отсюда можно смело полагать, что после N (тысячи или типа того) итераций JIT просто заинлайнил функцию, сохранив кучу времени. async функцию заинлайнить он, к сожалению, не может, поэтому такая большая разница, вызов функции не бесплатный. Ближе к реальности — реальные функции, особенно читающие с диска, он заинлайнить не сможет, поэтому результат теста нерепрезентативный.
P.S. Точно до нс в nodejs время померять можно с помощью process.hrtime();
Почему нет? Работает достаточно быстро. Правда таким голым совсем кодом только если прям совсем одну кнопку инлайн нужно добавить. Если чуть сложнее — можно обернуть из серии
Вынести create_element в отдельную библиотеку, позволить ее расширять. Разве что синтаксис получился многословный, но раз мы используем typescript — мы уже используем препроцессинг, поэтому можно сделать DSL чтобы оно выглядело как обычный html и компилировалось в такой код. Oh wait…
Я, будучи реакт разработчиком, следуя ориентированности реакта на функциональное программирование, вообще стараюсь писать в максимально функциональном стиле (включая эффекты из ocaml) и let использую супер редко частично из-за функциональной идеологии. Жалко только в js не так просто объявить переменную вообще иммутабельной, а не только запретить менять ссылку на объект, а в ts readonly прописывать у каждой переменной оверхед лютый
Понимаю, что немного другая категория, но я ещё в 2012 году участвовал в робокроссе, так что в России уже были соревнования беспилотных автомобилей, но не на дорогах общественного пользования, конечно же.
Интересно, что в той же России совершенно не видно на что идут эти налоги (хорошо, на салют и лампочки в городе), когда за рубежом эти налоги возвращаются в инфраструктуре и помощи тебе когда она нужна (временная недееспособность, например). И пенсия ещё.
Global Navigation Satellite System (или Спутниковая Система Навигации)
В России, на удивление, точно такая же как английская аббревиатура, ГНСС, которая в тексте ни разу не встречалась.
GPS необходимо хотя бы три спутника для вычисления 2D-позиции (долгота и широта) и четыре спутника для 3D-позиции (долгота, широта, высота).
Строго говоря, для 3д хватит и трех спутников, как и двух для 2д, но упускается достаточно важная деталь как уход часов. А именно — часы на потребительском устройстве уходят слишком сильно, чтобы выдавать какую-нибудь вменяемую координату. Поэтому в систему уравнений добавляется еще одна переменная — текущее время, а чтобы решить СУ с 4-мя переменными нужно минимум 4 уравнения, поэтому и нужен четвертый спутник. Иначе это выглядит слегка странным зачем нужен 4-й спутник.
И вообще, объяснять принцип работы ГНСС ни разу не упомянув слово "псевдодальность" только вредить.
Почему GPS плохо работает в городских условиях?
Хотел увидеть слово GDOP. Если коротко — переотражение (она же многолучевость) — одна из бед, но далеко не единственная. Например, здания в целом заслоняют спутники, из-за чего приемнику приходится опираться на хотя бы что-то, что он видит, а это может быть далеко не самый оптимальный выбор спутников.
Сам по себе IMU не выдает данные о местоположение (позицию, высоту, скорость), но выдает полезную информацию для вычисления местоположения в местах, где GPS не «ловит» (тоннели, паркинги и пр.);
Можно было и расписать что же он такое выдает, а именно — линейные ускорения по осям и угловые скорости вокруг этих осей. Интегрируя эту информацию и зная начальные точки можно построить маршрут с известным уходом. Засунув в фильтр Калмана с другими датчиками можно получить очень хорошие результаты.
RTK-поправки
Вообще оно называется DGPS (системы дифференциальной коррекции глобальных навигационных спутниковых систем), и опять же нужно уточнить важный момент о том как оно работает. Это устройство обычно установлено стационарно и знает свое положение с геодезической точностью (до пары мм). Зная это, оно решает обратную навигационной задачу: рассчитывает поправки к псеводальностям чтобы уравнение решилось верно. Собственно, эти поправки оно и рассылает на приемники, которые, вдобавок, должны уметь работать с этим каналом связи. И нет, ни через какой интернет оно ничего не рассылает — слишком большая задержка. Обычно эти поправки интегрированы в сам радиотракт приемника.
Впрочем, они бывают сильно разными, часто требуя необходимость видеть то же созвездие, что и потребитель, что в городских условиях достаточно сложно.
В итоге статья похожа на очень поверхностную выжимку копирайтера, лишь бы ссылки добавить.
В статье про комплексирование навигационных систем на техническом ресурсе слово "комплексирование" встречается 0 раз. Как и "фильтр Калмана".
Вот только асинхронные вызовы помещаются в event loop (или его аналоги), а не лежат в стеке. Как результат — отказ эвент лупа, а не проблемы, связанные с глубиной вызовов. Проще говоря — процессор не успевает разгребать события и это понятно, но увеличение глубины стека — меньшее из зол, не имеющее отношение к эвент лупу. Ну понятно, что вызов функции — это сложить 4 (8, 16?) регистров в стек, поменять CP, это все помноженное на косвенную адресацию, что в итоге отъедает процессорное время, я сам лично, заинлайнив один метод в three.js, привел к его (очень незначительному) росту производительности, но речь идет про под-функцию внутри перемножения матриц, которая вызывается миллионы раз на каждый кадр, в остальных случаях в реальных приложениях цена вызова функции крайне мала и скорее будет проседать соединение с базой (я уже молчу про сам неоптимизированный запрос), чем проблемы с вызовом функции.
Лучшее, что я видел, это rxjs ajax. Ну или еще лучше — ангуларовская (2+) обертка $http. Но стримы — то еще зло, поэтому в для небольших проектов, конечно, не подходит.
Во-вторых, а почему в синхронном коде ошибка приводит к выбросу исключения и завершению программы, а в асинхронном — нет?
У вас какое-то свое представление о промисах.
Для начала если никто не сделал .catch, то промис завершится с Uncaught (in promise) в глобальном стеке и никуда ошибка не пропадает и нигде не теряется.
А так же ошибки в промисах ловятся именно там где и должны — тем, кто этот промис вызвал (точнее, кто вызвал функцию, вернувшую промис. Ну или выше по цепочке вызовов).
У промисов, конечно же, есть недостатки, один из главных — их нельзя отменять, а так же они не таскают с собой "контекст" (это создает проблемы как с адекватным, но не репрезетативным стек трейсом, так и, например, в nest.js нельзя в обработчике получить request из контекста, не передавая его напрямую. Хотя это вроде починили с https://nodejs.org/api/async_hooks.html). Часть из этих проблем решают стримы, но это уже прям большой шаг вперед.
Но точно у промисов нет проблем с исключениями, если грамотно проектировать систему.
P.S.
Во-вторых, а почему в синхронном коде ошибка приводит к выбросу исключения и завершению программы, а в асинхронном — нет?
Если вы в синхронном коде успели навесить обработчик на событие, то приложение продолжит реагировать на это событие. И, в свою очередь, если в промисе (асинхронном коде) вылетела ошибка, то прекратится вся дальнейшая обработка этого кода и приложение будет ожидать следующего события. Куда уж логичнее?
Да, все писали обертку в 10 строчек. А потом понадобилось добавить обработку форм, потом картинок, данных, потом пред-обработчики, пост-обработчики, установка хедеров и так далее. В итоге получили свой axios, только хуже оттестированный.
Ловить надо только то, что явно запрошено пользователем, и не перехватывать остальные типы исключений
В js нет разницы между пользовательскими ошибками и программными. С чего механизм отлова ошибок в одном месте должен в таком случае отличаться от других? А ещё, интересно, в каком контексте по-вашему должны сыпаться ошибки вроде обращения к необъявленной переменной если я хочу обернуть ее и показывать пользователю хотя бы что-то вместо белого экрана? А ещё как разделить? Нет доступа к сети к чему относится? А закончилась память? А ublock заблокировал запрос?
PS для fetch никакой статус ответа не является ошибкой и это, в общем случае, правильно. Но не удобно.
Справедливости ради, даже на VPS и Распбери (в том числе небольшом кластере из расбери) микросервисы развернуть легко. Однако все зависит от желания, ведь можно сделать простую конфигурацию с ручным деплоем, а можно сразу завернуть все в кубернетис и разворачивать миникуб какой-нибудь. Второе для MVP слегка оверхед и может съесть кучу времени, за который теорию то и проверить можно было, но не обязательно для этого снимать какие-то невероятные мощности в облаках.
Да и опять же, с чего это AWS будет таким дорогим? Пару простецких сервисов в нем не так дорого обходятся пока нет нагрузки
SVG тоже всегда растрируется (растеризуется?) при рендере. Просто браузер берет на себя обработку зума.
Канвас гораздо более низкоуровневый. Собственно, от сюда и все различия. Нужно сделать что-то быстро и на коленках — svg хорош (но не идеален), но если хочется гибкости и возможности рисовать что вздумается либо быть хоть немного уверенным, что это будет работать быстро (svg с css анимациями может быть очень тормозным, если рисовать чуть больше, чем 5 линий) — брать канвас. Но да, придется ручками делать то, что с свг уже дано.
А почему canvas не подходит для векторной графики? Да, придется от чуть меньше до чуть больше написать ручками, фактически придется найти движок, но на канвасе можно рисовать как угодно, в том числе и векторной графикой. http://processingjs.org/ или http://paperjs.org/ например. Как преимущество — можно смешивать векторную и растровую графику одновременно.
Поигрался с примером на js. Вот что интересно, если сравнивать версию с функцией и без функции (
for (...) { j += i / 3.1415692 }), то выясняется, что при количестве итераций < 10 000 разница в скорости больше трех раз, однако позже скорость выполнения выравнивается и держится на уровне 1.2 (365 527 293 ns против 336 979 720 ns).Что-то мне подсказывает, что в такой базовый пример врывается JIT. Если заморочаться дальше, можно запустить ноду с
--print-opt-code, в выводе справедливо появится строчкаОтсюда можно смело полагать, что после N (тысячи или типа того) итераций JIT просто заинлайнил функцию, сохранив кучу времени. async функцию заинлайнить он, к сожалению, не может, поэтому такая большая разница, вызов функции не бесплатный. Ближе к реальности — реальные функции, особенно читающие с диска, он заинлайнить не сможет, поэтому результат теста нерепрезентативный.
P.S. Точно до нс в nodejs время померять можно с помощью process.hrtime();
Почему нет? Работает достаточно быстро. Правда таким голым совсем кодом только если прям совсем одну кнопку инлайн нужно добавить. Если чуть сложнее — можно обернуть из серии
create_element('li', { className: 'card' }, [ createElement('div', {}, [create_text_node('text')])]);Вынести create_element в отдельную библиотеку, позволить ее расширять. Разве что синтаксис получился многословный, но раз мы используем typescript — мы уже используем препроцессинг, поэтому можно сделать DSL чтобы оно выглядело как обычный html и компилировалось в такой код. Oh wait…
Хм, эту конструкцию я пропустил, спасибо за подсказку!
Я, будучи реакт разработчиком, следуя ориентированности реакта на функциональное программирование, вообще стараюсь писать в максимально функциональном стиле (включая эффекты из ocaml) и let использую супер редко частично из-за функциональной идеологии. Жалко только в js не так просто объявить переменную вообще иммутабельной, а не только запретить менять ссылку на объект, а в ts readonly прописывать у каждой переменной оверхед лютый
Вот только лошадиная тяга загрязняет воздух и вообще создаёт гораздо больше пробоем чем машины (в больших масштабах) https://sustainability.stackexchange.com/questions/4587/impact-on-environment-a-million-horses-vs-a-million-cars
А мне южный парк — «лестница в небо». Интересно, закончится это так же желанием бомбить небо?
Кто использовал амперсанд & и слэш / (их логотипы как компании и поисковика).
Понимаю, что немного другая категория, но я ещё в 2012 году участвовал в робокроссе, так что в России уже были соревнования беспилотных автомобилей, но не на дорогах общественного пользования, конечно же.
Интересно, что в той же России совершенно не видно на что идут эти налоги (хорошо, на салют и лампочки в городе), когда за рубежом эти налоги возвращаются в инфраструктуре и помощи тебе когда она нужна (временная недееспособность, например). И пенсия ещё.
В России, на удивление, точно такая же как английская аббревиатура, ГНСС, которая в тексте ни разу не встречалась.
Строго говоря, для 3д хватит и трех спутников, как и двух для 2д, но упускается достаточно важная деталь как уход часов. А именно — часы на потребительском устройстве уходят слишком сильно, чтобы выдавать какую-нибудь вменяемую координату. Поэтому в систему уравнений добавляется еще одна переменная — текущее время, а чтобы решить СУ с 4-мя переменными нужно минимум 4 уравнения, поэтому и нужен четвертый спутник. Иначе это выглядит слегка странным зачем нужен 4-й спутник.
И вообще, объяснять принцип работы ГНСС ни разу не упомянув слово "псевдодальность" только вредить.
Хотел увидеть слово GDOP. Если коротко — переотражение (она же многолучевость) — одна из бед, но далеко не единственная. Например, здания в целом заслоняют спутники, из-за чего приемнику приходится опираться на хотя бы что-то, что он видит, а это может быть далеко не самый оптимальный выбор спутников.
Можно было и расписать что же он такое выдает, а именно — линейные ускорения по осям и угловые скорости вокруг этих осей. Интегрируя эту информацию и зная начальные точки можно построить маршрут с известным уходом. Засунув в фильтр Калмана с другими датчиками можно получить очень хорошие результаты.
Вообще оно называется DGPS (системы дифференциальной коррекции глобальных навигационных спутниковых систем), и опять же нужно уточнить важный момент о том как оно работает. Это устройство обычно установлено стационарно и знает свое положение с геодезической точностью (до пары мм). Зная это, оно решает обратную навигационной задачу: рассчитывает поправки к псеводальностям чтобы уравнение решилось верно. Собственно, эти поправки оно и рассылает на приемники, которые, вдобавок, должны уметь работать с этим каналом связи. И нет, ни через какой интернет оно ничего не рассылает — слишком большая задержка. Обычно эти поправки интегрированы в сам радиотракт приемника.
Впрочем, они бывают сильно разными, часто требуя необходимость видеть то же созвездие, что и потребитель, что в городских условиях достаточно сложно.
В итоге статья похожа на очень поверхностную выжимку копирайтера, лишь бы ссылки добавить.
В статье про комплексирование навигационных систем на техническом ресурсе слово "комплексирование" встречается 0 раз. Как и "фильтр Калмана".
Вот только асинхронные вызовы помещаются в event loop (или его аналоги), а не лежат в стеке. Как результат — отказ эвент лупа, а не проблемы, связанные с глубиной вызовов. Проще говоря — процессор не успевает разгребать события и это понятно, но увеличение глубины стека — меньшее из зол, не имеющее отношение к эвент лупу. Ну понятно, что вызов функции — это сложить 4 (8, 16?) регистров в стек, поменять CP, это все помноженное на косвенную адресацию, что в итоге отъедает процессорное время, я сам лично, заинлайнив один метод в three.js, привел к его (очень незначительному) росту производительности, но речь идет про под-функцию внутри перемножения матриц, которая вызывается миллионы раз на каждый кадр, в остальных случаях в реальных приложениях цена вызова функции крайне мала и скорее будет проседать соединение с базой (я уже молчу про сам неоптимизированный запрос), чем проблемы с вызовом функции.
Любопытства ради, как глубина стека зависит от нагрузки?
От первого? Просто начиная со второго (который я и имел ввиду), $http завязан на rxjs, а аксиос на промисах работает.
Лучшее, что я видел, это rxjs ajax. Ну или еще лучше — ангуларовская (2+) обертка $http. Но стримы — то еще зло, поэтому в для небольших проектов, конечно, не подходит.
У вас какое-то свое представление о промисах.
Для начала если никто не сделал
.catch, то промис завершится сUncaught (in promise)в глобальном стеке и никуда ошибка не пропадает и нигде не теряется.А так же ошибки в промисах ловятся именно там где и должны — тем, кто этот промис вызвал (точнее, кто вызвал функцию, вернувшую промис. Ну или выше по цепочке вызовов).
У промисов, конечно же, есть недостатки, один из главных — их нельзя отменять, а так же они не таскают с собой "контекст" (это создает проблемы как с адекватным, но не репрезетативным стек трейсом, так и, например, в nest.js нельзя в обработчике получить request из контекста, не передавая его напрямую. Хотя это вроде починили с https://nodejs.org/api/async_hooks.html). Часть из этих проблем решают стримы, но это уже прям большой шаг вперед.
Но точно у промисов нет проблем с исключениями, если грамотно проектировать систему.
P.S.
Если вы в синхронном коде успели навесить обработчик на событие, то приложение продолжит реагировать на это событие. И, в свою очередь, если в промисе (асинхронном коде) вылетела ошибка, то прекратится вся дальнейшая обработка этого кода и приложение будет ожидать следующего события. Куда уж логичнее?
Да, все писали обертку в 10 строчек. А потом понадобилось добавить обработку форм, потом картинок, данных, потом пред-обработчики, пост-обработчики, установка хедеров и так далее. В итоге получили свой axios, только хуже оттестированный.
В js нет разницы между пользовательскими ошибками и программными. С чего механизм отлова ошибок в одном месте должен в таком случае отличаться от других? А ещё, интересно, в каком контексте по-вашему должны сыпаться ошибки вроде обращения к необъявленной переменной если я хочу обернуть ее и показывать пользователю хотя бы что-то вместо белого экрана? А ещё как разделить? Нет доступа к сети к чему относится? А закончилась память? А ublock заблокировал запрос?
PS для fetch никакой статус ответа не является ошибкой и это, в общем случае, правильно. Но не удобно.
Справедливости ради, даже на VPS и Распбери (в том числе небольшом кластере из расбери) микросервисы развернуть легко. Однако все зависит от желания, ведь можно сделать простую конфигурацию с ручным деплоем, а можно сразу завернуть все в кубернетис и разворачивать миникуб какой-нибудь. Второе для MVP слегка оверхед и может съесть кучу времени, за который теорию то и проверить можно было, но не обязательно для этого снимать какие-то невероятные мощности в облаках.
Да и опять же, с чего это AWS будет таким дорогим? Пару простецких сервисов в нем не так дорого обходятся пока нет нагрузки
Только на PDF часто отвечают "а можете отправить word версию, а то я не могу правки внести".
Читать как "так как компания могла пожлобить деньги на офисный пакет".
SVG тоже всегда растрируется (растеризуется?) при рендере. Просто браузер берет на себя обработку зума.
Канвас гораздо более низкоуровневый. Собственно, от сюда и все различия. Нужно сделать что-то быстро и на коленках — svg хорош (но не идеален), но если хочется гибкости и возможности рисовать что вздумается либо быть хоть немного уверенным, что это будет работать быстро (svg с css анимациями может быть очень тормозным, если рисовать чуть больше, чем 5 линий) — брать канвас. Но да, придется ручками делать то, что с свг уже дано.
А почему canvas не подходит для векторной графики? Да, придется от чуть меньше до чуть больше написать ручками, фактически придется найти движок, но на канвасе можно рисовать как угодно, в том числе и векторной графикой. http://processingjs.org/ или http://paperjs.org/ например. Как преимущество — можно смешивать векторную и растровую графику одновременно.
Это почему вдруг к svg нет доступа из JS?