Статья не имеет никакого отношения к внутреннему устройству языка JavaScript. Статья описывает одну из возможностей его реализации.
Например, для работы JavaScript согласно его спецификации не нужен call stack. Он там вообще никаким образом не описывается. Работа и вызов функций происходит без необходимости что-то класть в стек.
Или цикл событий, который является одним ИЗ способов реализации работы с агентом выполняющим JavaScript код. Опять же спецификации языка глубоко плевать на то, каким образом вы будете помещать в Job Queue задачи на выполнения.
Представьте на секунду, что Agent исполняющий JS код, автоматически научился распределять нагрузку на все доступные потоки.
Код Мартина будет оптимизирован автоматически. Менять ничего не нужно будет. Вычисление простого числа воспользуется всеми доступными ресурсами многопроцессорной архитектуры.
Код на 16 строк, все так же будет работать в одном потоке. И оптимизировать его сможет только человек.
Если бы я попросил кандидата решить подобную задачу и в ответ получил бы такие шестьдесят строк, то кандидат не прошёл бы собеседование.
Если бы Вы проходили у меня собеседование, то Ваш код на 16 строчек, был бы завернут на первой же строке. const primes: number[] = [];
Сравните эту же строку с кодом Мартина. И попробуйте пояснить почему Вас бы сразу завернули.
Потому, что он говорит о Вашем не знании того как работает JS изнутри. В то же время код Мартина, заставил бы меня задать несколько уточняющих вопросов и продолжить собеседование.
Мне кажется, что Вы не поняли главное о чем писал дядя Боб. Он не давал Вам рецептов. Он прививал культуру мышления. Ваш код в 16 строчек - выполняет свою задачу. Он прекрасно может быть использован для решения на коленке. Но он безобразен. Безобразен хотя бы потому, что не оставляет никаких шансов современным оптимизаторам что-то с этим кодом сделать.
В тоже время код от Мартина такие возможности дает. И если инструмент способен делать подобные оптимизации - он с кодом Мартина может сделать много чего полезного и интересного. А с кодом в 16 строк - почти ничего.
При холодром старте, подготовка js кода может занимать больше 100% времени используемошо на его исполнение. Специфика языка.
Как следствие - кеширование как минимум, а способность управлять тем что и как кешируется/компилируется - как максимум, один из золотых граалей старта приложения.
Мне показалось, что Вы не поняли автора. Автор говорил о том, что программисты JS кода, до конца не понимают как использовать инструмент, которы! они используют.
Инструмент, потенциал которого, в силу общей слабости JS комьюнити, до сих пор не раскрыт и имеет большой потенциал. С чем лично я, более чем согласен.
abortController - никакого отношения к JS не имеет. Єто api которое может предоставить host среда. А может и не предоставить, в отличии от того что она обязана предоставить для исполнения js кода согласно спецификации.
Работать постоянно и исключительно в одной только ОС Linux/*BSD у вас скорее всего не получится (без ухода в религиозный фанатизм) и пусть лишь ради 5% работы, но придется переключаться в Windows или использовать виртуализацию.
Как же 500 самых быстрых компьютеров мира перегружают или виртуализруют виндовз?
Наверное я религиозный фанатик, которому linux более чем достаточно в решении его повседневных задач.
Мне кажется, что перевод требует существенных уточнений.
Например: зачем автор переводит термины на русский язык, в случаях когда нет устоявшейся терминологии? abrupt в спецификации, или в обиходе используется именно как abrupt, но не как внезапный.
Другой пример:
Если argument - внезапный (abrupt), вернуть argument.
формулировка вернуть argument может сбивать столку. Какой аргумент? Куда вернуть? Из complition record?
На самом деле єто следовало бы перевести с акцентом на то, что происходит полноценный return из метода, с пробросом complition record вверх по стеку вызова методов.
Весь тест можно выкинуть в топку по одной простой причине: google выделяет разное колличество ресурсов для индексации того или иного домена. Называется краулинговый бюджет. Который прямо влияет в том числе на обьем работы совершаемой гуглом для индексации контента.
Чтобы тест стал корректным - следовало завести тестовый домен, о котором google ничего не знал ранее, а еще лучше хотябы 100.
И если бы авторы єто сделали, то обнаружили бы что мифы уже не такие и мифы.
Самый простой опыт - єто домен с контентом генерируемым на стороне клиента и такой-же в статике. Внезапно оказывается, что скорость индексации сравниваемых доменов отличается в разы.
Из материала, может сложиться ложное впечатление, будто бы typedArray играют какую-то важную роль в производительности всей задачи. Что может спровоцировать читателя в будущем использовать их вместо типичного ExoticObjectArray.
Вероятно, для информативности, следовало бы добавить, что любые typed array в js только тогда приобретают "мистические" черты супер-производительности, когда такие array можно передавать в неизменном виде в какое либо внешнее API. Например imageData от canvas.
Все же прочее, что делается с темже тайпедАррай, в современных агентах, подобных v8, работает с тойже производительностью. При єтом может быть причиной ее просадки именно в момент формарования отображения тайпед аррай на типичный js код.
То есть условный консоле.лог, примененрый к тайпед аррай, может привести к худшей производительности чем он же к exotic object array.
1) web assembly не может быть быстрее js кода хотябы потому, что абстрактный wasm исполняется ровно тойже виртуальрой машиной что и абстрактный байткод, в который собирается в v8 js код.
wasm может быть более предсказуемым в случае, когда мы сталкиваемся с гарбаж коллектором и типизацией, чего в озвученном выше примере нет от слова совсем. GC задействован минимально. Типизация работает ровно также как в wasm typedArray.
2) простое копирование буфера в канвас, для случаев typedArray на порядок быстрее аналога в webGl. уже хотябы потому, что нет издержек на обслуживание каждого пикселя. webGl дал бы Вам прирост тогда, когда вы бы положили на gpu ваши условрые треугольники позволив gpu их красить самостоятельно. в примере выше обслуживается каждый пиксель отдельно. и тут не может быть ничего быстрее копирования буфера.
xms сам по себе никак не мог повлиять на запуск игр. от слова совсем.
исключение, если он отьедал памяти в первом 1024 сегменте столько, что остатка не хватало для запуска приложения. только тогда єто не проблема xms, а проблема доступной памяти в текущем окружении, крторую можно было решать исключая любые други приложерия.
к слову сказать. xms появился как способ дать временное окно перехода между dos и реал моде к виндовс и протектед моде. Дать апи, которое бы позволило запускать приложения в новой среде с минимальными издержками.
Дело в том, что уже с появления 286 процессора стало известно, как адресовать память выше 1мб без использования прослоек типа himem.sys. Единственным недостатком которого, являлась полная несовместимость реал мод,рс протектед мод. Но полностью прозрачный механизм адресации памяти.
Майкрасовт и прочих игроков рынка єто не сильно устраивало именно потому, что нужно было обеспечить бесшовныи переход с дос на виндовс.
В результате появляются франкинштейны вроде xms которые, по сути спекулируют на томже механизме, но предоставляя уровень абстракции єффектинвно заменяемый в новом окружении.
И пока ты думаешь над тем, как обьяснить что это неправильные пчелы и они делают неправильный мед тебе в догонку сразу второй вопрос.
Что там базовые компьютерные науки говорят о lexical environment? Я уверен ты в курсе. А теперь открывай спецификацию ECMA и читай главу 9.1.1. Environment record type hierarchy.
Базовые знания компьютерных наук тебе тогда нужны, когда у тебя нет иного авторитетного источника. Базовым знаниям компьютерных наук не подчинены программные продукты. Что наглядно видно из истории развития термина Lexical Environment в спецификации JS.
Чтобы победить Голиафа - нужно быть хотя-бы Давидом.
Если код, способен модифицировать /etc то єто означает что у него есть рут.
После монимания єтого момента чтения материала теряет всяческий смысл. Даже если настроен SELinux.
Код описаный в статье - єто детская подделка на коленке, развитость которой на уровне 1998 года.
Статья не имеет никакого отношения к внутреннему устройству языка JavaScript.
Статья описывает одну из возможностей его реализации.
Например, для работы JavaScript согласно его спецификации не нужен call stack. Он там вообще никаким образом не описывается. Работа и вызов функций происходит без необходимости что-то класть в стек.
Или цикл событий, который является одним ИЗ способов реализации работы с агентом выполняющим JavaScript код. Опять же спецификации языка глубоко плевать на то, каким образом вы будете помещать в Job Queue задачи на выполнения.
Представьте на секунду, что Agent исполняющий JS код, автоматически научился распределять нагрузку на все доступные потоки.
Код Мартина будет оптимизирован автоматически. Менять ничего не нужно будет. Вычисление простого числа воспользуется всеми доступными ресурсами многопроцессорной архитектуры.
Код на 16 строк, все так же будет работать в одном потоке. И оптимизировать его сможет только человек.
Это Вам как самый показательный пример.
Если бы Вы проходили у меня собеседование, то Ваш код на 16 строчек, был бы завернут на первой же строке.
const primes: number[] = [];Сравните эту же строку с кодом Мартина. И попробуйте пояснить почему Вас бы сразу завернули.
Потому, что он говорит о Вашем не знании того как работает JS изнутри.
В то же время код Мартина, заставил бы меня задать несколько уточняющих вопросов и продолжить собеседование.
Мне кажется, что Вы не поняли главное о чем писал дядя Боб. Он не давал Вам рецептов. Он прививал культуру мышления. Ваш код в 16 строчек - выполняет свою задачу. Он прекрасно может быть использован для решения на коленке. Но он безобразен. Безобразен хотя бы потому, что не оставляет никаких шансов современным оптимизаторам что-то с этим кодом сделать.
В тоже время код от Мартина такие возможности дает. И если инструмент способен делать подобные оптимизации - он с кодом Мартина может сделать много чего полезного и интересного. А с кодом в 16 строк - почти ничего.
Єто ошибка потому, что выбрав оптимальную архитектуру, вы, как человек который не знает систему, так и не поймете почему она тормозит.
А тормозить она будет из-за невозможности оптимизировать ваш код Агентом, который пришел в восхищение от вашей архитектуры и читаемости кода.
При холодром старте, подготовка js кода может занимать больше 100% времени используемошо на его исполнение. Специфика языка.
Как следствие - кеширование как минимум, а способность управлять тем что и как кешируется/компилируется - как максимум, один из золотых граалей старта приложения.
Мне показалось, что Вы не поняли автора. Автор говорил о том, что программисты JS кода, до конца не понимают как использовать инструмент, которы! они используют.
Инструмент, потенциал которого, в силу общей слабости JS комьюнити, до сих пор не раскрыт и имеет большой потенциал. С чем лично я, более чем согласен.
Лекции Константина Анохина, действующего нейробиолога, о том что мы сейчас знаем про память. Минимум 10 летней давности.
Рассказывают намного подробнее. В том числе утверждается о существовании єксперемнтальных препаратов радикально меняющих процесс запоминания.
abortController - никакого отношения к JS не имеет. Єто api которое может предоставить host среда. А может и не предоставить, в отличии от того что она обязана предоставить для исполнения js кода согласно спецификации.
а если опыт 30 лет, то кто тогда?
а мне нравится. я бы даже специально заплатил чтобы такое сделали. мне кажется сочно.
Как же 500 самых быстрых компьютеров мира перегружают или виртуализруют виндовз?
Наверное я религиозный фанатик, которому linux более чем достаточно в решении его повседневных задач.
Мне кажется, что перевод требует существенных уточнений.
Например: зачем автор переводит термины на русский язык, в случаях когда нет устоявшейся терминологии? abrupt в спецификации, или в обиходе используется именно как abrupt, но не как внезапный.
Другой пример:
формулировка вернуть argument может сбивать столку. Какой аргумент? Куда вернуть? Из complition record?
На самом деле єто следовало бы перевести с акцентом на то, что происходит полноценный return из метода, с пробросом complition record вверх по стеку вызова методов.
И так далее.
А еще можно познакомиться с cache api и использовать его, с 100% гарантией.
Весь тест можно выкинуть в топку по одной простой причине: google выделяет разное колличество ресурсов для индексации того или иного домена. Называется краулинговый бюджет. Который прямо влияет в том числе на обьем работы совершаемой гуглом для индексации контента.
Чтобы тест стал корректным - следовало завести тестовый домен, о котором google ничего не знал ранее, а еще лучше хотябы 100.
И если бы авторы єто сделали, то обнаружили бы что мифы уже не такие и мифы.
Самый простой опыт - єто домен с контентом генерируемым на стороне клиента и такой-же в статике. Внезапно оказывается, что скорость индексации сравниваемых доменов отличается в разы.
Из материала, может сложиться ложное впечатление, будто бы typedArray играют какую-то важную роль в производительности всей задачи. Что может спровоцировать читателя в будущем использовать их вместо типичного ExoticObjectArray.
Вероятно, для информативности, следовало бы добавить, что любые typed array в js только тогда приобретают "мистические" черты супер-производительности, когда такие array можно передавать в неизменном виде в какое либо внешнее API. Например imageData от canvas.
Все же прочее, что делается с темже тайпедАррай, в современных агентах, подобных v8, работает с тойже производительностью. При єтом может быть причиной ее просадки именно в момент формарования отображения тайпед аррай на типичный js код.
То есть условный консоле.лог, примененрый к тайпед аррай, может привести к худшей производительности чем он же к exotic object array.
Вы заблуждаетесь.
1) web assembly не может быть быстрее js кода хотябы потому, что абстрактный wasm исполняется ровно тойже виртуальрой машиной что и абстрактный байткод, в который собирается в v8 js код.
wasm может быть более предсказуемым в случае, когда мы сталкиваемся с гарбаж коллектором и типизацией, чего в озвученном выше примере нет от слова совсем. GC задействован минимально. Типизация работает ровно также как в wasm typedArray.
2) простое копирование буфера в канвас, для случаев typedArray на порядок быстрее аналога в webGl. уже хотябы потому, что нет издержек на обслуживание каждого пикселя. webGl дал бы Вам прирост тогда, когда вы бы положили на gpu ваши условрые треугольники позволив gpu их красить самостоятельно. в примере выше обслуживается каждый пиксель отдельно. и тут не может быть ничего быстрее копирования буфера.
xms сам по себе никак не мог повлиять на запуск игр. от слова совсем.
исключение, если он отьедал памяти в первом 1024 сегменте столько, что остатка не хватало для запуска приложения. только тогда єто не проблема xms, а проблема доступной памяти в текущем окружении, крторую можно было решать исключая любые други приложерия.
к слову сказать. xms появился как способ дать временное окно перехода между dos и реал моде к виндовс и протектед моде. Дать апи, которое бы позволило запускать приложения в новой среде с минимальными издержками.
Дело в том, что уже с появления 286 процессора стало известно, как адресовать память выше 1мб без использования прослоек типа himem.sys. Единственным недостатком которого, являлась полная несовместимость реал мод,рс протектед мод. Но полностью прозрачный механизм адресации памяти.
Майкрасовт и прочих игроков рынка єто не сильно устраивало именно потому, что нужно было обеспечить бесшовныи переход с дос на виндовс.
В результате появляются франкинштейны вроде xms которые, по сути спекулируют на томже механизме, но предоставляя уровень абстракции єффектинвно заменяемый в новом окружении.
Мммм молодой человек с Вами все ясно.
Играйте в пинг понг Гена. Это у Вас получается неплохо.
Вопросов к Вам больше не имею.
Ужас то какой.
Как хорошо что я тебя тут встретил.
Скажи мне, о преисполнившейся в базовых знаниях компьютерных наук - как человеку вот тут:
https://www.youtube.com/live/RrGMG4S0hLQ?si=WYlXi_lee8Z4sdzA&t=10954
удалось создать больше 100 000 системных тредов?
И пока ты думаешь над тем, как обьяснить что это неправильные пчелы и они делают неправильный мед тебе в догонку сразу второй вопрос.
Что там базовые компьютерные науки говорят о lexical environment? Я уверен ты в курсе. А теперь открывай спецификацию ECMA и читай главу 9.1.1. Environment record type hierarchy.
Базовые знания компьютерных наук тебе тогда нужны, когда у тебя нет иного авторитетного источника. Базовым знаниям компьютерных наук не подчинены программные продукты. Что наглядно видно из истории развития термина Lexical Environment в спецификации JS.
Чтобы победить Голиафа - нужно быть хотя-бы Давидом.