Disclaimer | Дисклеймер


V8
Часть 2.

Если рассматривать JIT-компилятор в качестве "мозга" V8, то скрытые классы и профилирование — его глаза и память.

Не секрет, что в JavaScript объекты могут менять свою структуру на лету:

const obj = {};
obj.x = 10; // Добавили свойство
obj.y = 20; // Добавили ещё одно свойство

Как мы уже поняли из первой части, для оптимизации V8 нужно предсказывать структуру объектов. Для этого он создаёт скрытые классы. Простыми словами - это некоторые внутренние метаданные, которые описывают "форму" объекта (а именно, какие у него есть свойства и их типы).

Чтобы стало понятнее:
При создании объекта, V8 назначает ему скрытый класс (например, C0). После этого, при добавлении свойства x, движок создает новый класс (например, C1) на основе C0, и на основе известной информации о x. Соответственно, при добавлении y, создается следующий класс, унаследованный от C1. При этом, есть важная особенность. Если у двух объектов одинаковая структура (свойства добавлялись в одном порядке), они получат один скрытый класс. Это позволяет TurboFan генерировать более оптимизированный код для каждой конкретной "формы" объектов.

Если со скрытыми классами логически все просто, то профилирование устроено несколько сложнее для понимания, так как "растянуто" на все этапы работы.

Подробнее: ещё одна особенность TurboFan, заключается в том, что он не оптимизирует код сразу. Сначала V8 профилирует его.
В учет идет информация о функциях, о том, как часто они вызываются, какие типы данных в них передаются. О том, как именно ведут себя объекты.

Описанный выше процесс выглядит, примерно, следующим образом:

В момент интерпретации (Ignition), V8 выполняет код и записывает частоту вызовов функций, учитывая типы переменных. (например: x - всегда число)

После этого в дело вступает базовый компилятор (он же SparkPlug). Происходит процесс генерирования неоптимизированного машинного кода на основе ранних данных.

Следующий этап - оптимизация (TurboFan), о котором мы говорили раннее. Тут, на основе собранных данных, и происходит вся магия. Из основного - если функция вызывается много раз, TurboFan проводит анализ истории её выполнения и созданных скрытых классов объектов.

По итогам, компилируется специализированный код.

Эти знания, важны на много больше, чем может показаться на первый взгляд.
Почему и как это проверить? В следующей, финальной, части поговорим как раз про это.



// Поставь реакцию!

t.me/aif_sn

Disclaimer | Дисклеймер


Уметь писать код - хорошо.
Уметь писать код хорошо - отлично.

Но чтобы писать код хорошо, по-мимо прочего, очень важным фактором является факт понимания, как работают инструменты и технологии, с которыми мы взаимодействуем.

V8
Часть 1.

Рано или поздно каждый сталкивался с высказываниями, что язык JavaScript - язык медленный.

Однако, в том же Chrome или, например, Node.js, все происходит достаточно быстро. Почему?
Почти всё, благодаря JIT-компилятору, который встроен в движок V8.

Магия?
Чтобы лучше понять что происходит, стоит немного рассмотреть, глобально, архитектуру, систему, того, что происходит с кодом. Как дело доходит, непосредственно, до его выполнения.

Существуют 2 основных пути - компилирование кода, и интерпретирование кода.
Если не вдаваться в подробности (тема, действительно, невообразимо обширна), можно представить, что JavaScript - это ноты.

Интерпретатор - пианист, который видит эти ноты впервые. Он читает их, и играет мелодию прямо по нотам, не зная того, что будет дальше (это не совсем так, но принцип именно такой)
Способен начать играть мелодию сразу, но каждый раз, играя ее, он будет заново обрабатывать каждую ноту.

Компилятор - это пианист, который сначала учит ноты, наизусть. Простраивает в голове модели того, как должна звучать мелодия, где должын быть акценты, а уже после - играет мелодию по памяти.
Необходима долгая подготовка, но после - моментальное исполнение.

Движок V8, использует два уровня (и еще огромную массу оптимизаций, которые подробно затрагивать, мы сейчас не будем)

На первом этапе, работает Ignition - сверхлегкий интерпретатор.
Быстрый старт: V8 сначала прогоняет код через Ignition.
После, генерирует байткод (это что-то среднее между JavaScript и машинным кодом). И в конце, cобирает данные о том, какие функции вызываются чаще всего.
Зачем? Чтобы не тратить время на компиляцию всего кода сразу.

На втором этапе, работает TurboFan — оптимизирующий компилятор.
Когда функция вызывается много раз, V8 передаёт её в TurboFan. Тут и начинается, та самая магия:
Во-первых, проводится анализ типов: V8 смотрит, какие типы данных ты используешь (числа, строки, объекты).
Во-вторых, проводится специализация кода - если функция 100 раз вызвана с числами — TurboFan генерирует машинный код только для чисел.
По-мимо описанных выше процессов, производится инлайн-подстановка: маленькие функции (вроде x + y) вставляются прямо в вызывающий код, без лишних вызовов.
И наконец, производится удаление мёртвого кода: Если условие if (false) { ... } — TurboFan вырежет его.

В результате - код выполняется ПОЧТИ как нативый С++

Это почти все. Существует 3-ий этап - деоптимизация
Происходит это в том случае, если, например: функция стабильно работала с числами, а в какой-то момент получила - строку.
V8 откатывает оптимизацию и возвращается к Ignition. Процесс - медленный. Именно поэтому, стабильные типы = быстрый код.

В следующих частях углубимся в тему, и разберем профилирования и скрытые классы



// Поставь реакцию!

t.me/aif_sn

Disclaimer | Дисклеймер


В прошлом сообщении коснулся темы собеседований.

В эту же кучу, можно свалить различные матрицы компетенций, асессменты, скрининги, пирамиды навыков и прочие, прочие, прочие процессы, созданные для настоящего контроля развития сотрудников, и здравой оценки их навыков, но зачастую, в текущей реальности, выполняющие роль, полностью противоположную задуманной.

К сожалению, компаниями, с недостаточным уровнем планирования бюджета, сотрудниками, с далеко не благими, и уж точно не дальновидными намерениями, все было извращено на столько, что сейчас, редко где можно увидеть, действительно, рабочие с административной, верные с технической, точки зрения, проработанные системы.

Для корректного функционирования, помимо глубокой проработки технической базы знаний, говорим мы о различных этапах собеседований или этапах повышения квалификации сотрудников, очень важна идейно-направленная, структурированая, проработка внешних и смежных процессов. То, как и на что именно, будут влиять итоги, метрики, которые будут собраны. То, какие, действительно, возможности, права и обязанности будут иметь участники с обоих сторон в процессе и после.

Конечно, это актуально только, если говорить в ключе прозрачности. Если целью любых из вышеперечисленных процессов является что-то связанное с ограничением, недопущением, и уж тем более, разными формами обмана, тогда, по-настоящему, корректные модели - будут только мешать плану :)

Увидеть "уход от", или правильнее сказать "искажение" ранее, замечательно работавших схем, можно почти в любой, нынешней, крупной корпорации. Зачастую, очень сильно грешат подобными поступками крупнейшие банки и их дочерние организации (к сожалению, почти полностью бесконтрольные), а так же компании, занимающиеся, не побоюсь использовать в данном контексте слово, субарендой человеческих ресурсов, работающие по конвейеру.

Грустно признавать, но очень не малую роль в этом, сыграл человеческий фактор, проявляющийся, действительно, в попытке сотрудниками играть не по правилам. Впрочем, с этим можно, и конечно, нужно, бороться менее деструктивными подходами. Но зачастую, выбирают более простой, хоть и на много менее эффективный, несущий в себе достаточно много подводных камней, вариант.



// Поставь реакцию!

t.me/aif_sn

Disclaimer | Дисклеймер


- Big O
Нотация позволяет описать "сложность" алгоритма.

Глупо было бы предполагать, что не существует других. А ведь они, действительно, есть! И мало того что они существуют, некоторые из них, могут быть, информативнее для конкретных ситуаций.

Вашему вниманию 2 не менее важные нотации:

- Ω-нотация (Омега-нотация)
Используется для описания лучшего случая сложности алгоритма (При оптимальных входных данных). Другими словами - минимальной возможной сложности алгоритма.

Например: Если говорить про полностью отсортированный массив данных, к которому применяется алгоритм сортировки Insertion Sort, сложность, в лучшем случае (минимально-возможная) можно обозначить Ω(n)

- Θ-нотация (Тета-нотация)
Используется для указания на точную сложность алгоритма. Θ-нотация представляет собой оценку как для худшего, так и для лучшего случая.

Например: Алгоритм Merge Sort всегда работает со слозжностью Θ(n log n), независимо от порядка данных. Значит, его сложность будет как минимум, так и максимум O(n log n) в любом случае

По-мимо описанных выше, существуют и другие нотации, например: o-нотация (малая о-нотация) или ω-нотация (малая омега-нотация), но используются на много реже, как правило, когда необходимо проводить более глубокую и точную аналитику и сравнения.

Удивить своими знаниями на собеседовании? Легко. По личным наблюдениям, где-то 7 из 10 интервьюеров, к сожалению, знают только о существовании (без подробностей) или вовсе не слышали о существовании других нотаций для описания сложности алгоритмов.



// Поставь реакцию!

t.me/aif_sn

Disclaimer | Дисклеймер


Из любой ситуации всегда есть выход
ESC -> :wq

© vi 1976 - 2025



// Поставь реакцию!

t.me/aif_sn

Disclaimer | Дисклеймер


Ситуация #000001

- А какой ты тогда предлагаешь выбрать статус для задачи, которую нельзя вливать в master, до определенной даты?
- Ready to merge
- ...

К сожалению, в сферу IT всё больше и больше прокрадываются отвратительнейшие проявления социальной жизнедеятельности, такие как кумовство, различные расслоения по субъективным причинам и прочие, не менее тошнотворные понятия.

Конечно, это не значит, что IT - это только про технические знания, написание кода, и любые другие hard - скиллы. Тем не менее, наша сфера всегда была "нитакой" и, как следствие, описанные выше проявления - считались несколько постыдными. Они были всегда, да, и в целом, это нормально. Но точно не в таком явном виде, в каком все чаще и чаще встречаются, особенно в крупных компаниях.

Безусловно, как и в любой другой сфере, основываясь, хотя бы, на банальной потребности человека в общении, базовой социализации, на том, что человек, любой, всегда так или иначе тянется к человеку, очень важными остаются коммуникативные навыки, выстраивание определенного уровня отношений с коллегами, начальством. Но никогда, никогда и нигде, "отношения/е" опирающиеся, исключительно, на личностные, субъективные ощущения, не должны быть выше чем реальность.

Как показала практика, такая обстановка дел, почти всегда (без внешнего вмешательства) приводит к остановке любых рабочих процессов в команде, отделе, компании, корпорации. Это не быстрый процесс, но неизбежный. Именно поэтому, со стороны руководства компании, со стороны людей, на любых управляющих должностях, необходим четкий и системный подход, к решению проблем, связанных с чрезмерным субьективизмом в командах.



// Поставь реакцию!

t.me/aif_sn

Disclaimer | Дисклеймер


Информация носит исключительно развлекательный характер и содержит авторский материал, являющийся выдумкой, созданный без цели оскорбить чьи-либо чувства. Авторы не призывают к каким-либо действиям и ничего не утверждают.

Любые совпадения с местами, предметами, личностями, событиями и любой сущностью, из реального мира - случайны.

Возможно использование ненормативной лексики.

Возрастное ограничение 18+


t.me/aif_sn