Спасибо за видео, очень познавательно. Но не понял почему в куче только 1 строка? У нас же 2 раза строка используется, а она вроде как не ссылочная или это часть оптимизации?
3:51 Браузерный V8 (не серверный Node.js) за smi принимает 31 битные числа (30 бит на число, 1 число на знак), то есть максимальное положительное smi число в браузерном V8 это (2**30)-1 и минимальное (-2**30), не включая отрицательный ноль -0. Переход на 31 бит, вместо 32 произошел после разработки и внедрения технологии v8 pointer compression. Убедиться в этом можно создав данные числа и посмотрев на их тип в байткодовом представлении.
Технология pointer compression, о которой вы говорите, действительно, оптимизирует хранение ссылок и чисел, но ее рассмотрение выходит за рамки схематичного устройства памяти, о котором я рассказываю в видео, взяв в расчет оригинальное устройство движка. Для 64-х битной архитектуры, которую я рассматриваю в этом видео, в оригинальном V8 есть возможность хранить 32 бита числа, соответственно, их значения находятся в промежутке от -2**31 до 2**31 - 1. Более того, даже, если учесть сжатие с помощью pointer compression, это не отменяет того, что в памяти число займет тоже 32 бита (идентификатор числа + бит знака + 30 бит под его значение).
@@ВасилийНовиков-ъ7э Вы не поняли того, что Вам сказал @user-te4zh2dz9r и предоставили свое собственное своеобразное представление происходящего 1) обозначать диапазоны чисел как это делаете вы, -2**31 до 2**31 - 1 не является нормой. Принято говорить: Если речь идет о 64 битах - то число представляется 64 битами. Знаковое оно или нет - значение имеет только для представления его в самом JS. И только для частных случаев. В общем случае, программист понимает, что если он работает с целыми знаковыми - то это колличество бит на представление минус 1 на знак. И при этом понимает что это - НЕ ИМЕЕТ НИКАКОГО значения, поскольку разделение чисел на целые знаковые и беззнаковые - условно. Так как любое знаковое представляется таким же беззнаковым. 2) Автор комментария на который Вы отвечали, абсолютно правильно указал Вам на вашу особенность. Потому, что в рамках V8 то, чем является SMI зависит от трех вещей - это архитектура (x32 / x64) и наличием оптимизаций Pointer Compression и/или представления числа в пределах указателя. Если архитекутра x32 - то SMI в V8 будет занимать 31 бит. Если учесть знак - то 30 бит. Еще один бит используется для того, чтобы различать где у нас указатель а где SMI Если архитектура x64 - то SMI будет зависеть от того, включена или нет оптимизация Pointer Compression. То есть сжатие указателя. Который в 64 битной системе, должен быть 64 бита. Однако с включенной оптимизацией он становится 32 битным. И мы откатываемся к условиям 32 битной архитектуры для SMI. Если же оптимизация отключена(как например в Node) то SMI будет 63 бита. 1 бит опять потрачено на что, чтобы различать где у нас число а где указатель. Одновременно с этим, может быть отключена оптимизация, которая позволяет хранить сами по себе числа вместо указателя. И тогда SMI будет составлять в V8 точно столько же бит сколько и у архитектуры: 32 и 64 соотвественно. Попробуйте разобраться еще глубже, чтобы точнее описывать людям то что хотите сказать
Когда Вы рассказываете про хранение строк в памяти Вы утверждаете, что с помощью 1 байта можно закодировать символы с 0 по 256 позицию. Т.е. всего 257 позиций с помощью 8 бит? Как так у Вас получается? Наверное Вы хотели сказать до 256, но даже так не лишним будет напомнить, что не включительно. Просто на следующем слайде про SeqOneByteString есть фраза "символы, которые выходят за 256 кодовую точку" которая опять же вносит больше путаницы. С одной стороны всё правильно, но с другой стороны для новичков это может быть не столь очевидным.
Спасибо за валидное замечание и респект за внимательность! Действительно, стоило было указать, что символ на 256 позиции не может быть закодирован с помощью 1 байта.
Вводящий в заблуждение и ничем не помогающий набор утверждений. Мне вот так и не стало ясно, почему стек должен работать быстрее кучи, если учесть, что они расположены в одной и той же памяти.
Короче. Ютуб сожрал мой длинный коммент с пояснением того почему stack может быть лучшим выбором. В 3 раза я писать его уже не буду. Кратко: Вы правы. Автор видео наговорил глупостей.
![JavaScript[5] - Путь самурая. Переменные, память, данные. НОВЫЙ БЕСПЛАТНЫЙ КУРС IT-KAMASUTRA](http://i.ytimg.com/vi/bmHZ-YQBWNA/mqdefault.jpg)
Если smi не создают в куче объект smallball как другие примитивы, то при сравнение двух одинаковых по значению чисел почему будет true?
Спасибо за видео, очень познавательно.
Но не понял почему в куче только 1 строка? У нас же 2 раза строка используется, а она вроде как не ссылочная или это часть оптимизации?
3:51 Браузерный V8 (не серверный Node.js) за smi принимает 31 битные числа (30 бит на число, 1 число на знак), то есть максимальное положительное smi число в браузерном V8 это (2**30)-1 и минимальное (-2**30), не включая отрицательный ноль -0. Переход на 31 бит, вместо 32 произошел после разработки и внедрения технологии v8 pointer compression. Убедиться в этом можно создав данные числа и посмотрев на их тип в байткодовом представлении.
Технология pointer compression, о которой вы говорите, действительно, оптимизирует хранение ссылок и чисел, но ее рассмотрение выходит за рамки схематичного устройства памяти, о котором я рассказываю в видео, взяв в расчет оригинальное устройство движка. Для 64-х битной архитектуры, которую я рассматриваю в этом видео, в оригинальном V8 есть возможность хранить 32 бита числа, соответственно, их значения находятся в промежутке от -2**31 до 2**31 - 1. Более того, даже, если учесть сжатие с помощью pointer compression, это не отменяет того, что в памяти число займет тоже 32 бита (идентификатор числа + бит знака + 30 бит под его значение).
@@ВасилийНовиков-ъ7э Вы не поняли того, что Вам сказал
@user-te4zh2dz9r и предоставили свое собственное своеобразное представление происходящего
1) обозначать диапазоны чисел как это делаете вы,
-2**31 до 2**31 - 1
не является нормой.
Принято говорить:
Если речь идет о 64 битах - то число представляется 64 битами. Знаковое оно или нет - значение имеет только для представления его в самом JS. И только для частных случаев. В общем случае, программист понимает, что если он работает с целыми знаковыми - то это колличество бит на представление минус 1 на знак. И при этом понимает что это - НЕ ИМЕЕТ НИКАКОГО значения, поскольку разделение чисел на целые знаковые и беззнаковые - условно. Так как любое знаковое представляется таким же беззнаковым.
2) Автор комментария на который Вы отвечали, абсолютно правильно указал Вам на вашу особенность. Потому, что в рамках V8 то, чем является SMI зависит от трех вещей - это архитектура (x32 / x64) и наличием оптимизаций Pointer Compression и/или представления числа в пределах указателя.
Если архитекутра x32 - то SMI в V8 будет занимать 31 бит. Если учесть знак - то 30 бит. Еще один бит используется для того, чтобы различать где у нас указатель а где SMI
Если архитектура x64 - то SMI будет зависеть от того, включена или нет оптимизация Pointer Compression. То есть сжатие указателя. Который в 64 битной системе, должен быть 64 бита. Однако с включенной оптимизацией он становится 32 битным. И мы откатываемся к условиям 32 битной архитектуры для SMI.
Если же оптимизация отключена(как например в Node) то SMI будет 63 бита. 1 бит опять потрачено на что, чтобы различать где у нас число а где указатель.
Одновременно с этим, может быть отключена оптимизация, которая позволяет хранить сами по себе числа вместо указателя. И тогда SMI будет составлять в V8 точно столько же бит сколько и у архитектуры: 32 и 64 соотвественно.
Попробуйте разобраться еще глубже, чтобы точнее описывать людям то что хотите сказать
Когда Вы рассказываете про хранение строк в памяти Вы утверждаете, что с помощью 1 байта можно закодировать символы с 0 по 256 позицию. Т.е. всего 257 позиций с помощью 8 бит? Как так у Вас получается? Наверное Вы хотели сказать до 256, но даже так не лишним будет напомнить, что не включительно. Просто на следующем слайде про SeqOneByteString есть фраза "символы, которые выходят за 256 кодовую точку" которая опять же вносит больше путаницы. С одной стороны всё правильно, но с другой стороны для новичков это может быть не столь очевидным.
Спасибо за валидное замечание и респект за внимательность!
Действительно, стоило было указать, что символ на 256 позиции не может быть закодирован с помощью 1 байта.
Спасибо)
11:23 неправильно, снова стоит обратиться к v8 pointer compression
Вводящий в заблуждение и ничем не помогающий набор утверждений. Мне вот так и не стало ясно, почему стек должен работать быстрее кучи, если учесть, что они расположены в одной и той же памяти.
Короче. Ютуб сожрал мой длинный коммент с пояснением того почему stack может быть лучшим выбором. В 3 раза я писать его уже не буду.
Кратко: Вы правы. Автор видео наговорил глупостей.