Говорят *int64_t не нужен. float64_t хватит всем

intptr_t например (что если адресное пространство больше 53 бит?)
Циклические счётчики, когда тебе важна разность между моментами 2 событий, а не абсолютное значение. тут конечно и 32 бита обычно хватает, но гибридный тип с float'ом не пойдёт.
Да и вообще иногда нужны именно целочисленные операции, плавающая точка может внезапно потерять где-нибудь точнось, особенно при оптимизации. с целыми работать проще.

Даже в указателях только 48 используется (хаха, а вы что, думали 64? Щас).

Здравствуйте, вы из какого года пишете?

Нужны инструкции которые экспоненту всегда в 0 держат. И традиционный carry флаг

Нужны инструкции которые экспоненту всегда в 0 держат

Тогда для умножения нужно промежуток хранить в float128.

Тебе 1 бита карри флага не хватает? Зачем float128?

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

Я оперирую и 512-битными словами и 256 и 1024, а тут пишут что мне больше 48 не надо

Пусть он обоснует что (a + b) + c != a + (b + c) – это правильный подход и так и должно быть. А то, понимаешь ли, привыкли тут что сложение ассоциативно!

Python 3.11.6 (main, Oct  2 2023, 13:45:54) [GCC 12.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> a = float(2**64)
>>> b = -a
>>> a
1.8446744073709552e+19
>>> b
-1.8446744073709552e+19
>>> c = 1
>>> (a + b) + c
1.0
>>> a + (b + c)
0.0

Странно иметь настолько мало опыта в программировании чтобы не знать миллиона применений для 64-битных интов, и при этом иметь наглость диктовать какие типы для чего применимы и кто под кого должен подстаиваться.

Почему же тогда подход JS не нравится «настоящим программистам»? Да потому что все остальные наловчились в 64 бита рассовывать разное

ровно наоборот. Это в JS целые 53 бита, потому что они наловчились рассовывать разное в 64 бита (в double).

Это сайд эффект от NaN-packed/NaN-boxing

Who are you quoting?

Ну а иметь один числовой тип вместо двух как будто тоже гениально? Все в выигрыше, никто не пострадал.

В JavaScript два числовых типа:

> 1 === 1n
< false

Что за срань я только что прочитал? 🤦‍♂️

Те, кто говорят – не знают матчасть. Что тут обсуждать?

На бинарном уровне double (aka float64) все равно является числом с плавающей точкой, только из-за того что оно имеет достаточно разрядов оно не теряет точность при обратном преобразовании из double -> long.

На wiki:

0 01111111111 00000..0   = 1
0 10000000000 00000..0   = 2
0 10000000000 10000..0   = 3   # math.pow(2,1)*(1 + 0.5) 
0 10000000001 00000..0   = 4   # math.pow(2,2)*(1 + 0.0)
0 10000000011 01110..0   = 23  # math.pow(2,4)*(1 + 0.25 + 0.125 + 0.0625)

Если кто не поняли или не знает как кодируются числа с плавающей запятой то поясню:

2^{экспонента} * 1.{мантисса}

А если экспонента 0 (магическое число) то просто:

0.{мантисса} 

где каждый бит в мантиссе обозначает доли 0.5 0.25 0.125 0.0625 и т.д. их сумма будет приближаться к 1 (чем больше разрядов в мантиссе тем ближе к единице).

Короче, FP это жесть, преобразование int-> float не очевидно, на бинарном уровне с ними работать это стрелять себе в ногу. Обязательно найдутся double значения отличающиеся на бинарном уровне но преобразующиеся в единственное целое.

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

Мнение имбецила тянущего идиотский язык во все щели.

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

На каких бл. байтах? Тип данных какой использовать по мнению автора сего убожества?

А если какой нибудь алгоритм хэширования/шифрования где 64 бита еще и мало?

Откуда взято это дерьмо?

Пишу в том числе на JS (TS). Отсутствие int - жопная боль.

JavaScript

тормозное говнище

man canonical address

А если экспонента 0 (магическое число) то просто: 0.{мантисса}

Немножко не так. Если экспонента 0, то это либо 0, когда мантисса = 0, либо денормализованные числа порядка 2^-1022 и меньше, то есть очень маленькие - чтобы увеличить точность операций вокруг нуля.

Денормализованные числе часто округляют до 0, при оптимизациях. Кроме того, не все архитектуры в принципе их поддерживают.

https://en.wikipedia.org/wiki/Subnormal_number

преобразование int-> float не очевидно

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

Смешно то, что буквально на днях тр**ся с тем, что ёб**ый js не умеет в uint64.

в какой жизненной ситуации вам нужны целые больше 53-х бит? Это 9*10^15, девять ебучих квадриллионов, девять тыщ триллионов то есть. Чтобы представлять что? Вокруг нас просто нет предметов в таком количестве

Эм, а по эллиптическим кривым как гулять? Например, в secp256k1 (используется в bitcoin и некоторых алгоритмах шифрования) нужно 10^78. Ваши 9*10^15 вообще ни туда ни сюда.

man canonical address

Раз мануалы не открываешь, то хоть Википедию полистай.

https://en.m.wikipedia.org/wiki/Intel_5-level_paging

Полностью согласен. В JS всё сделано идеально в этом плане. Битовые операции там тоже нормально работают.

плавающая точка может внезапно потерять где-нибудь точнось

Используй ECC память и у тебя ничего внезапно не будет теряться.

одновременно и целое до 53-х бит, и с плавающей точкой если больше.

Неявное преобразование типов с потерей данных, да ещё и в рантайме? Великолепно!

Даже в указателях только 48 используется (хаха, а вы что, думали 64? Щас).

Откуда дровишки? Разницу между физическими и виртуальными адресами мы точно понимаем?

Давайте всё таки будем честны: 64 бита действительно часто используется, как 8 байт в памяти, в которые удобно распиханы данные, не имеющие отношения к тому числу, которое там должно было быть.

Snowflake id, tagged pointer, что-то ещё. Это всё примеры структур, спрятанных под 64 бита и действительно для большинства практических целей хватит и 53 бит, и 48 бит.

Мы когда делали себе в софтине самопальную timeseries db, то сократили числа до 12 бит, а в оставшиеся 2 бита клали разряд. Очень удобно, потому что на графике точность выше 12 бит не нужна никак.

Но бесит то нас не то, что кто-то указывает на то, что мы «неправильно» пользуемся 64 битами, а то, что приводит в пример яваскрипт с его больными умолчаниями.

018 == "018"
017 != "017"

Люди, которые породили такое, не могут быть примером для остальных.

В том же руби есть автобоксинг интов: дошли до 62 бит и потом число само превращается в BigNumber объект с соответствующим пенальти. А вместо этого в яваскрипте нет возможности распарсить длинный интеджер, который встречается на практике

Т.е. яваскрипт и в теории плохой и на практике плохой. И бесит то, что это предлагают как пример только потому, что видите ли мы абъюзим эти 8 байт.

Да абъюзим, потому что мы абъюзеры и будем такими. И петушня позорная нам не указ.

Даже в указателях только 48 используется (хаха, а вы что, думали 64? Щас).

Откуда дровишки? Разницу между физическими и виртуальными адресами мы точно понимаем?

Мы – да. Ты – не факт.

~ cat /proc/cpuinfo|grep address\ sizes|uniq
address sizes   : 43 bits physical, 48 bits virtual

Виртуальные адреса, конечно, 64 бита на бумаге, но в середине там нули, поэтому они укладываются в 48 бит. Это для x86_64. Другие архитектуры умеют в том числе полноценное 64-битное виртуальное пространство.

grep -m1 address\ sizes /proc/cpuinfo

64 бита на бумаге, но в середине там нули

там не нули :-) там значение равное старшему значащему биту адреса (тому самому 47-му).

64 бита на бумаге, но в середине там нули

там не нули :-) там значение равное старшему значащему биту адреса (тому самому 47-му).

Да, ты прав. Мой косяк.

The x86-64 architecture divides canonical addresses into two groups, low and high. Low canonical addresses range from 0x0000'0000'0000'0000 to 0x0000'7FFF’FFFF’FFFF. High canonical addresses range from 0xFFFF'8000'0000'0000 to 0xFFFF’FFFF’FFFF’FFFF. Considered as signed 64-bit numbers, all canonical addresses range between -2^47 and 2^47-1.

1) Производительность. Некоторые операции физически так устроены, что работают только с целыми. Помимо битовых операций очевидное индексирование массивов. Конверсия будет добавлять время. Плюс я не уверен, что даже на современных процессорах вещественные операции не медленнее целых. Особенно если помимо десктопов думать о мобильных процессорах. И я уж молчу про микроконтроллеры, где часто вообще soft float.

2) Защита от ошибок. Где-то вещественное не имеет смысла. И сами типы тебя защищают от них. А с float у тебя получится полтора землекопа, а ты и не заметишь. Math.floor постоянно вызывать геморно.

3) 64 бита таки бывают нужны. Например, таймстемпы высокой точности, хеши, криптография. И битовые операции там тоже нужны, не как хак для производительности, а как официальная часть алгоритма. Если ты не дорос до таких задач, это не значит, что их нет.

BigInt не подойдёт?

Я бы понял если допустим над единым форматом можно было бы и битовые операции и флоат и целые проводить. Естественно после битовых в флоатах хз что.

Ещё 53 бита это как то не кругло. 48 + 16 в угоду скорости и меньше точности. + чёткая адресация сейчас. Имхо

Виртуальные адреса, конечно, 64 бита на бумаге

Таки да - для меня было немножко сюрпризом что виртуальные адреса на x86-64 тоже ограничены. Вообще - логично конечно.

А теперь, внимание - вопрос на миллион: так что, получается старшие 16 бит в поинтерах на x86-64 можно абъюзить (по крайней мере на нынешнем железе)?

AMD specification requires that the most significant 16 bits of any virtual address, bits 48 through 63, must be copies of bit 47 (in a manner akin to sign extension). If this requirement is not met, the processor will raise an exception

AMD specification requires

Это всё здОрово. Я имел в виду что я их могу выставить как AMD этого хочет перед использованием, но как storage - они доступны. Так ведь?

На достаточно свежих процах. На интел есть «Linear Address Masking», на амд есть «upper address ignore».

Не знаю. В TLB - навряд ли. Если хочешь углубиться в вопрос и выяснить, возможно ли заюзать «неиспользуемые битики» на уровне ядра и page table, то вот тебе пара ссылок для начала:

https://docs.kernel.org/mm/page_tables.html

https://www.kernel.org/doc/gorman/html/understand/understand006.html

На уровне юзерспейса это точно не работает.

Вообще-то Lua придумал «правильные» (с т.з. топикстартера) числа ещё до того, как появился «JavaScript» (который правильнее называть ECMAScript).

Ещё ссылка с картинкой как выглядит page table entry: https://en.wikipedia.org/wiki/X86-64#Page_table_structure

JavaScript единственный язык, который сделал правильные числа.

JavaScript единственный язык, который сделал правильные

JavaScript единственный язык

А чего мелочится?! Даешь JS единственным ЯП с обязательным нативным исполнением на любом железе!

То есть JS достаточно каждому. Даже в embedded используется (хаха, а вы что, думали только Сишечка и Асм? Щас). Почему же тогда JS не нравится «настоящим программистам»? Да потому что все остальные наловчились в синтаксис рассовывать разное, нужно им это или не нужно. То есть по сути единственная причина, почему JS не единственный, это другие языки, которые пришли раньше и у которых конвенция другая. Они может все возможности синтаксиса и не используют, но потенциально могут, и в итоге приходится под них подстраиваться. А нужно наоборот, чтобы все подстраивались под JavaScript. Но как же адресная арифметика, скажете вы? Как мне всякие там офсеты считать? Ну чувак, адресная арифметика на указателях это страшный хак, раз уж мы о типах заговорили. Она должна на массивах делаться, а не на указателях. А всякие Сишечки, Java, Rust, Asm, PHP, Python это от лукавого. Должен быть только JavaScript.

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

Тормознутое говнище по производительности находится где-то между жабкой и lua с пистоном. Обнови мантры.

Что ты там пытался такое сделать с uint64?

эскобар.жпг. Чтобы считать деньги не подходят оба.