Работать постоянно и исключительно в одной только ОС 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.
Чтобы победить Голиафа - нужно быть хотя-бы Давидом.
Нет. Это общая память, которую делят. HOST сам выбирает и использует для этого наиболее удобную машинерию в зависимости от железки и системы. Например она будет отличаться в windows и linux.
Это легко можно увидеть из под отладчика. Умеешь пользоваться отладчиком?
а еще можно было прочитать спецификацию html5 и узнать из нее, что атрибут lang может и обязан ставиться на каждый фразовый контент в случае если страница мультиязычная.
после чего убедиться что google, строго в соответствии со стандартом интерпретирует подобное поведение стандарта
Автор материала, далеко не всегда перепроверял себя, на соответствие заявленного им, официальному источнику.
Как следствие, почти все о чем идет речь в материале, представляет из себя винегрет из того, что действительно имеет отношение к официальной спецификации языка JavaScript помноженной на заблуждения автора.
Автор материала не знает, что Mozilla Developer Network никогда не являлась официальной документацией. Единственным официальным источником, с 1998 года является сайт спецификации ECMAScript.
Всех нас учили, что в JavaScript есть примитивные и ссылочные типы данных.
Даже если учесть общепринятый жаргон, относительно примитивных типов, то и в его рамках - никаких примитивных типов в языке JavaScript так же не существует. Потому как поведение тех типов, которые по умолчанию возвращают Primitive Value не укладываются в типичный набор критериев распространяемых в общем случае, на примитивные типы.
Главный из которых - строгая детерминированность поведения типа, вне зависимости от особенностей его использования.
То есть примитивный тип - это тип, который должен себя вести везде одинаково. При всех обстоятельствах. Чего в JavaScript нет.
Теория теорией, однако, JS-код исполняется не в теории, а на практике. Точнее, его компилирует и исполняет движок JS. Таких движков существует несколько, разрабатывались они разными людьми и для разных целей. Было бы наивно предполагать, что все они полностью идентичны друг другу.
Сама по себе реализация стандарта, то есть тот самый код который обслуживает спецификацию - безусловно может быть разной. Но верхом глупости будет думать, что подобные реализации не соответствуют заявленной ими спецификации.
Примитивные типы данных,
это иммутабельные (не изменяемые) значения, хранимые в памяти и представленные в структурах языка на низком уровне. Собственно, в JavaScript к примитивным типам относится все, кроме Object, а именно: Null, Undefined, Boolean, Number, BigInt, String, Symbol
То что написал автор - не имеет никакого отношения к официальной спецификации. Согласно которой, никаких примитивных типов в языке JavaScript не существует. Такого термина просто нет в официальной спецификации. Не говоря уже о том, что поведение выше заявленных типов, не отвечает общепринятому определению примитивных типов.
Ссылочные типы данных, они же - объекты, это области памяти неопределенного размера, и доступные по идентификатору (ссылке на эту область памяти). В JavaScript, есть только один такой тип - Object.
Algorithm steps may declare named aliases for any value using the form “Let x be someValue”. These aliases are reference-like in that both x and someValue refer to the same underlying data and modifications to either are visible to both. Algorithm steps that want to avoid this reference-like behaviour should explicitly make a copy of the right-hand side: “Let x be a copy of someValue” creates a shallow copy of someValue.
Это фундаментальная основа языка JavaScript которая закреплена на уровне главы формирующей операции используемый спецификацией.
Все алгоритмы спецификации, если явным образом не указано другого, описывают Expression или Statement в рамках заявленного в главе Algorithm Conventions алгоритма - а именно ссылочного типа.
Если быть максимальным занудой, то в академической среде, где работа с типами определяется как: By Value, By Reference и By Shared, работа со всеми типами в JavaScript отвечает термину By Shared. Что по сути своей является тем же ссылочным типом, и отличается только способом передачи в целевой индентификатор самой ссылки.
Иными словами - любые утверждения со стороны о том, что в языке JavaScript есть якобы типы, которые якобы примитивные противоречат как официальной спецификации, так и общепринятому жаргону.
Исключением являются типы связанные с TypedArray.
Object - единственный мутабельный (изменяемый) тип данных в JavaScript.
Object как тип, ничем не отличается от прочих типов языка JavaScript с точки зрения его описания. Но отличается тем что возвращается по умолчанию при запросе к идентификатору который с ним связан. В случае Object - возвращается структура типа. В случае типов, неправильно названных автором примитивными, по умолчанию возвращается primitive value. Чего не достаточно чтобы считать тип примитивным.
Производя какие-либо манипуляции с объектом, меняется значение непосредственно в области памяти
Ничего подобного не происходит. Это фантазии автора материала. Структура Object ничем не отличается по своему поведению от структуры Record в рамках которой описываются идентификаторы которые связывают с типами вида String, Number etc...
Объект остается в памяти, пока есть активная ссылка на него. Если ссылка удалена или больше не используется в сценарии, такой объект будет вскоре уничтожен сборщиком мусора, но об этом в следующий раз.
Официальная спецификации - никак не управляет тем что будет с обьектом или еще чем-то.
Официальная спецификация никаким образом не заявляет поведение Garbage Collector-а или любой другой машинерии про то же самое.
Это все лежит на плечах, конкретного RunTime, работа которого ВООБЩЕ не зависит от того, будет ли уничтожен какой-то обьект на который нет ссылки или не будет.
Больше того, если уж мы говорим о V8, то в его рамках, Garbage Collector, сто раз подумает прежде чем удалять что -то из памяти даже если на это что-то 100500 раз нет никаких ссылок. По одной простой причине - если память есть и ее достаточно, то последнее что нужно делать, это заниматься чисткой чего-то на что нет ссылок. Особенно в контексте того, что то, что потеряло ссылку, буквально завтра может ее снова обрести. А процесс заведения нового обьекта не в пример дороже чем работа Garbage Collecotr-а.
Нет. Согласно официальной документации, представление типа Number может радикальным образом отличаться в зависимости от выражения в котором числовой литерал используется. И может быть действительно как число с плавающей точкой для выражения деления числа.
И все это, подчеркиваю, в рамках официальной спецификации. (Передаем привет секте примитивных типов в JavaScript)
Посмотрим на это число в V8 в режиме дебага. Для этого воспользуемся системным хелпером движка %DebugPrint
DebugPrint: Smi: 0x1 (1)
Выяглядит вполне ожидаемо. Мы видим простое значение 0x1 с неким типом Smi. Но разве тут не должен быть тип Number, как говорится в спецификации ECMAScript? К сожалению, найти ответы на подобные вопросы в официальной документации движка не представляется возможным,
Еще как представляется.
То, что увидел автор материала, является частью поведения оптимизирующего алгоритма современного RunTime.
Который, вместо того, чтобы создавать дополнительные структуры данных, и ссылки на них, разместит эти данные вместо самого указателя, в ситуации, когда эти данные туда поместятся.
Ну люди добрые, Вы же программисты. Если у Вас ссылка на структуру представляется 32 битами, при этом эта структура должна описать число 1, которое легко помещается в те самые 32 бита, зачем создавать структуру?
Все последующие рассуждения автора про SMI в V8, касаются частного случая применения алгоритма оптимизации Pointer Compression. Который не обязательно будет включен для любой HOST среды. Например в Node, где используется ровно тот-же самый RunTime V8, оптимизация Pointer Compression отключена.
Как следствие, поведение в Node, связанное с обработкой численных литералов, отличается от того же поведения в браузере. Например Node может работать с 64 целыми числами если того позволяет архитектура. Чего не может делать Google Chrome. При этом Google Chrome, благодаря тому самому Pointer Compression становится в полтора раза эффективнее Node в случае обработки массивов данных, где каждый индекс укладывается в 31бит со знаком.
В чем легко убедиться используя тот же самый DebugPrint в Node и в браузере для одного и того же числа в пределах 31 бита.
Вместо ИГОГО:
Автору, как мне кажется, нужно переосмыслить весь написанный им материал и исправить допущенные им неточности. Иначе этот материал представляет из себя больше дезинформацию, нежели попытку просветить необразованное JS комьюнити.
если вы о Яндекс, то он перестал быть сколько-нибудь значимым конкурентом гугл где-то в 13-14 году, когда уже окончательно из Я были изгнаны все кто его создавал.
Задачи семантики в рамках html5 - єто формирование верстки, анализируя которую, любое сторонее программное обеспечение, которое следует тому же стандарту, может используя алгоритмы машинного анализа, зафиксировать однозначным образом, ровно тот же смысл, который был заложен автором оригинальной верстки.
В прямом смысле слова - смысл.
В случае Вашего примера с версткой, которая направлена на оптимизацию формирования отображения никакого "смысла" кроме оптимизации формы отображения - не передается.
Если Вам кажется, что я ошибаюсь, то будте так добры привести пример такого "смысла"
Я еще раз подчеркну, под термином семантика, подразумевается, в прямом смысле єто слова, формирование смысла - такого, как видит его человек.
Пример: Есть секция - черешня. Вложенные секции к ней - єто секция белая и секция красная. Как следствие формируется связь между термином Черешня и двумя связанными с ним качествами равноправными между собой: красная и белая. То есть черешня может быть белой, а может быть красной.
Пример выше, в очень упрощенном виде, иллюстрирует то, что называется семантикой стандарта html5, который разрешает задачи формирования смысла представляемого ей (версткой) контента.
Язык html, в его редакции html5, в первую очередь, направлен на представление семантики (смысла) документа (контента), посредством формирования связей между его секциями. Подавлшющее большинство тегов решают задачи определения тонкостей єтих связей.
То что нарисовали Вы в примере, не может быть принципиально реализовано на языке html, потому как Вы дали пример формирования отображения, а не описания семантики (смысла контента)
а если опыт 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.
Чтобы победить Голиафа - нужно быть хотя-бы Давидом.
Нет. Это общая память, которую делят. HOST сам выбирает и использует для этого наиболее удобную машинерию в зависимости от железки и системы. Например она будет отличаться в windows и linux.
Это легко можно увидеть из под отладчика. Умеешь пользоваться отладчиком?
Worker-ы могут делить одно адресное пространство в JS. Для чего и существует ATOMICS которое регламентирует взаимодействие таких воркеров.
а еще можно было прочитать спецификацию html5 и узнать из нее, что атрибут lang может и обязан ставиться на каждый фразовый контент в случае если страница мультиязычная.
после чего убедиться что google, строго в соответствии со стандартом интерпретирует подобное поведение стандарта
Автор материала, далеко не всегда перепроверял себя, на соответствие заявленного им, официальному источнику.
Как следствие, почти все о чем идет речь в материале, представляет из себя винегрет из того, что действительно имеет отношение к официальной спецификации языка JavaScript помноженной на заблуждения автора.
Судите сами:
Автор материала не знает, что Mozilla Developer Network никогда не являлась официальной документацией. Единственным официальным источником, с 1998 года является сайт спецификации ECMAScript.
Кто Вас и тем более Всех этому учил, должен краснеть на месте. Потому, что согласно официальной спецификации языка JavaScript, никаких примитивных и тем более ссылочных типов - нет.
Даже если учесть общепринятый жаргон, относительно примитивных типов, то и в его рамках - никаких примитивных типов в языке JavaScript так же не существует. Потому как поведение тех типов, которые по умолчанию возвращают Primitive Value не укладываются в типичный набор критериев распространяемых в общем случае, на примитивные типы.
Главный из которых - строгая детерминированность поведения типа, вне зависимости от особенностей его использования.
То есть примитивный тип - это тип, который должен себя вести везде одинаково. При всех обстоятельствах. Чего в JavaScript нет.
Сама по себе реализация стандарта, то есть тот самый код который обслуживает спецификацию - безусловно может быть разной. Но верхом глупости будет думать, что подобные реализации не соответствуют заявленной ими спецификации.
То что написал автор - не имеет никакого отношения к официальной спецификации. Согласно которой, никаких примитивных типов в языке JavaScript не существует. Такого термина просто нет в официальной спецификации. Не говоря уже о том, что поведение выше заявленных типов, не отвечает общепринятому определению примитивных типов.
Согласно официальной спецификации абсолютно все типы в языке JavaScript являются ссылочными:
Это фундаментальная основа языка JavaScript которая закреплена на уровне главы формирующей операции используемый спецификацией.
Все алгоритмы спецификации, если явным образом не указано другого, описывают Expression или Statement в рамках заявленного в главе Algorithm Conventions алгоритма - а именно ссылочного типа.
Если быть максимальным занудой, то в академической среде, где работа с типами определяется как: By Value, By Reference и By Shared, работа со всеми типами в JavaScript отвечает термину By Shared. Что по сути своей является тем же ссылочным типом, и отличается только способом передачи в целевой индентификатор самой ссылки.
Иными словами - любые утверждения со стороны о том, что в языке JavaScript есть якобы типы, которые якобы примитивные противоречат как официальной спецификации, так и общепринятому жаргону.
Исключением являются типы связанные с TypedArray.
Object как тип, ничем не отличается от прочих типов языка JavaScript с точки зрения его описания. Но отличается тем что возвращается по умолчанию при запросе к идентификатору который с ним связан. В случае Object - возвращается структура типа. В случае типов, неправильно названных автором примитивными, по умолчанию возвращается primitive value. Чего не достаточно чтобы считать тип примитивным.
Ничего подобного не происходит. Это фантазии автора материала. Структура Object ничем не отличается по своему поведению от структуры Record в рамках которой описываются идентификаторы которые связывают с типами вида String, Number etc...
Как в первом так и во втором случае, работа происходит абсолютно идентичным образом, что зафиксировано официальной спецификацией.
Официальная спецификации - никак не управляет тем что будет с обьектом или еще чем-то.
Официальная спецификация никаким образом не заявляет поведение Garbage Collector-а или любой другой машинерии про то же самое.
Это все лежит на плечах, конкретного RunTime, работа которого ВООБЩЕ не зависит от того, будет ли уничтожен какой-то обьект на который нет ссылки или не будет.
Больше того, если уж мы говорим о V8, то в его рамках, Garbage Collector, сто раз подумает прежде чем удалять что -то из памяти даже если на это что-то 100500 раз нет никаких ссылок. По одной простой причине - если память есть и ее достаточно, то последнее что нужно делать, это заниматься чисткой чего-то на что нет ссылок. Особенно в контексте того, что то, что потеряло ссылку, буквально завтра может ее снова обрести. А процесс заведения нового обьекта не в пример дороже чем работа Garbage Collecotr-а.
Нет. Согласно официальной документации, представление типа Number может радикальным образом отличаться в зависимости от выражения в котором числовой литерал используется. И может быть действительно как число с плавающей точкой для выражения деления числа.
Одновременно с чем, оно может быть 32-битовым целым со знаком в рамках бинарных операций например and. При этом уничтожая всю метаинформацию о том, какая дробная часть (мантисса) было до этого.
Но и это далеко не все. В рамках спецификации, для сдвигов числовой литерал в выражении может становиться 32 битовым целым БЕЗ знака.
И все это, подчеркиваю, в рамках официальной спецификации.
(Передаем привет секте примитивных типов в JavaScript)
Еще как представляется.
То, что увидел автор материала, является частью поведения оптимизирующего алгоритма современного RunTime.
Который, вместо того, чтобы создавать дополнительные структуры данных, и ссылки на них, разместит эти данные вместо самого указателя, в ситуации, когда эти данные туда поместятся.
Ну люди добрые, Вы же программисты. Если у Вас ссылка на структуру представляется 32 битами, при этом эта структура должна описать число 1, которое легко помещается в те самые 32 бита, зачем создавать структуру?
В современном V8 эта оптимизация называется Pointer Compression. Вот ссылка на статью, в официальном блоге инженеров V8, где подробно описывается это поведение.
Все последующие рассуждения автора про SMI в V8, касаются частного случая применения алгоритма оптимизации Pointer Compression. Который не обязательно будет включен для любой HOST среды. Например в Node, где используется ровно тот-же самый RunTime V8, оптимизация Pointer Compression отключена.
Как следствие, поведение в Node, связанное с обработкой численных литералов, отличается от того же поведения в браузере. Например Node может работать с 64 целыми числами если того позволяет архитектура. Чего не может делать Google Chrome. При этом Google Chrome, благодаря тому самому Pointer Compression становится в полтора раза эффективнее Node в случае обработки массивов данных, где каждый индекс укладывается в 31бит со знаком.
В чем легко убедиться используя тот же самый DebugPrint в Node и в браузере для одного и того же числа в пределах 31 бита.
Вместо ИГОГО:
Автору, как мне кажется, нужно переосмыслить весь написанный им материал и исправить допущенные им неточности. Иначе этот материал представляет из себя больше дезинформацию, нежели попытку просветить необразованное JS комьюнити.
если вы о Яндекс, то он перестал быть сколько-нибудь значимым конкурентом гугл где-то в 13-14 году, когда уже окончательно из Я были изгнаны все кто его создавал.
Задачи семантики в рамках html5 - єто формирование верстки, анализируя которую, любое сторонее программное обеспечение, которое следует тому же стандарту, может используя алгоритмы машинного анализа, зафиксировать однозначным образом, ровно тот же смысл, который был заложен автором оригинальной верстки.
В прямом смысле слова - смысл.
В случае Вашего примера с версткой, которая направлена на оптимизацию формирования отображения никакого "смысла" кроме оптимизации формы отображения - не передается.
Если Вам кажется, что я ошибаюсь, то будте так добры привести пример такого "смысла"
Я еще раз подчеркну, под термином семантика, подразумевается, в прямом смысле єто слова, формирование смысла - такого, как видит его человек.
Пример: Есть секция - черешня. Вложенные секции к ней - єто секция белая и секция красная. Как следствие формируется связь между термином Черешня и двумя связанными с ним качествами равноправными между собой: красная и белая. То есть черешня может быть белой, а может быть красной.
Пример выше, в очень упрощенном виде, иллюстрирует то, что называется семантикой стандарта html5, который разрешает задачи формирования смысла представляемого ей (версткой) контента.
Язык html, в его редакции html5, в первую очередь, направлен на представление семантики (смысла) документа (контента), посредством формирования связей между его секциями. Подавлшющее большинство тегов решают задачи определения тонкостей єтих связей.
То что нарисовали Вы в примере, не может быть принципиально реализовано на языке html, потому как Вы дали пример формирования отображения, а не описания семантики (смысла контента)
єто не знак равенства. Єто знак связывания.
Никак. И єто то самое место, где дружит императивная парадигма с функциональной.