64 бита для целого без вариантов - добро или зло?
От: Shmj Ниоткуда  
Дата: 11.07.23 10:14
Оценка:
Вот новые ЯП типа Dart — решили что нехрен делать 100500 разных вариантов целых чисел (со знаком/без знака, 8, 16, 32, 64) — а просто для всего сделать 64 бита со знаком: https://dart.dev/language/built-in-types

Умно?

Кто-то сразу начнет возражать, что, мол, если будет 1 млрд. записей и в каждой записи число, которое можно было бы сохранить в файл в виде 8 бит, а вместо этого вы потратили 64 бит — то потратим много лишних гигабайт. Однако же при сериализации/сохранении можно применять спец. атрибуты — это отдельный вопрос. В самой же проге все-равно проще и удобнее оперировать, когда все целые числа имеют одинаковую битность и знаковость.

Что скажете?
Re: 64 бита для целого без вариантов - добро или зло?
От: Nuzhny Россия https://github.com/Nuzhny007
Дата: 11.07.23 10:19
Оценка:
Здравствуйте, Shmj, Вы писали:

S>Что скажете?


Смотря для какого языка. Так делать нельзя, если:
— язык должен иметь возможность получать доступ к железу;
— язык предполагает парсинг и сериализацию бинарных данных/файлов/протоколов.
Re: 64 бита для целого без вариантов - добро или зло?
От: vsb Казахстан  
Дата: 11.07.23 10:21
Оценка: :))) :))) :)
Мне нравится, как в JS сделали. float64 без вариантов. Не знаю, кому нужны 64-битовые целочисленные значения, мне не нужны.
Re: 64 бита для целого без вариантов - добро или зло?
От: Osaka  
Дата: 11.07.23 11:35
Оценка: +1
S>Умно?
Очередные юные оболтусы изобрели революционную идею что грамотность и ПДД опыт предков устарел и не нужен.
Re: 64 бита для целого без вариантов - добро или зло?
От: swame  
Дата: 11.07.23 11:51
Оценка: +1
Здравствуйте, Shmj, Вы писали:

S>Вот новые ЯП типа Dart — решили что нехрен делать 100500 разных вариантов целых чисел (со знаком/без знака, 8, 16, 32, 64) — а просто для всего сделать 64 бита со знаком: https://dart.dev/language/built-in-types


S>Умно?


S>Кто-то сразу начнет возражать, что, мол, если будет 1 млрд. записей и в каждой записи число, которое можно было бы сохранить в файл в виде 8 бит, а вместо этого вы потратили 64 бит — то потратим много лишних гигабайт. Однако же при сериализации/сохранении можно применять спец. атрибуты — это отдельный вопрос. В самой же проге все-равно проще и удобнее оперировать, когда все целые числа имеют одинаковую битность и знаковость.


S>Что скажете?


Тип меньшего размера чем 64 бит нужны, только если структурв типа record не выравнивают внутреннее представление на 8 байт для 64-разрядного приложения или на 4 байта для 32-разрядного. В противном случае все равно переменная займет 8 байт.
Как без такой возможности писать высокоэффективные приложения с умеренным потребленем памяти, я не понимаю.
Re: 64 бита для целого без вариантов - добро или зло?
От: Zhendos  
Дата: 11.07.23 12:00
Оценка: +1
Здравствуйте, Shmj, Вы писали:


S>Кто-то сразу начнет возражать, что, мол, если будет 1 млрд. записей и в каждой записи число, которое можно было бы сохранить в файл в виде 8 бит, а вместо этого вы потратили 64 бит — то потратим много лишних гигабайт. Однако же при сериализации/сохранении можно применять спец. атрибуты — это отдельный вопрос. В самой же проге все-равно проще и удобнее оперировать, когда все целые числа имеют одинаковую битность и знаковость.


S>Что скажете?


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

2. Кэш процессора на данный момент это один из ключевых факторов производительности,
и невозможность впихнуть туда больше чисел удручает
Re[2]: 64 бита для целого без вариантов - добро или зло?
От: pagid_ Россия  
Дата: 11.07.23 12:31
Оценка: +6
Здравствуйте, swame, Вы писали:

S>Тип меньшего размера чем 64 бит нужны, только если структурв типа record не выравнивают внутреннее представление на 8 байт для 64-разрядного приложения или на 4 байта для 32-разрядного. В противном случае все равно переменная займет 8 байт.

Бывает не только record, но и банальный массив
Re: 64 бита для целого без вариантов - добро или зло?
От: velkin Удмуртия https://kisa.biz
Дата: 11.07.23 12:53
Оценка: +2 -1
Здравствуйте, Shmj, Вы писали:

S>нехрен делать 100500 разных вариантов целых чисел (со знаком/без знака, 8, 16, 32, 64) — а просто для всего сделать 64 бита со знаком

S>Умно?

Скорее очень глупо.

S>Однако же при сериализации/сохранении можно применять спец. атрибуты — это отдельный вопрос.

S>Что скажете?

Ну то есть тебя не волнует, что в худшем случае придётся купить в 8 раз больше оперативки. По процессору тоже непонятно, как такое воспринимают различные архитектуры.

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

Я считаю одним из весомых недостатков C/C++ является то, что разрядность типа int не определена для разных компиляторов. Изначально не нужно было делать такой тип, должен был быть int8, int16, int32, int64, ... , uint8, uint16, uint32, uint64.

Не нужно было делать никаких char, short, long, long long и прочего. Потому в C/C++ каждая вменяемая библиотека извращается создавая свои типы пытаясь скомпенсировать этот недостаток.

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

У меня есть предположение, почему такое произошло. Традиционно есть адресация в оперативной памяти, а есть данные не являющиеся адресами. И на ранних стадиях разработки языков об этом не задумывались смешивая вместе. А потом пошло поехало.
Re[2]: 64 бита для целого без вариантов - добро или зло?
От: Shmj Ниоткуда  
Дата: 11.07.23 14:19
Оценка:
Здравствуйте, velkin, Вы писали:

V>Не нужно было делать никаких char, short, long, long long и прочего. Потому в C/C++ каждая вменяемая библиотека извращается создавая свои типы пытаясь скомпенсировать этот недостаток.


Так добавили ж уже:

int8_t
int16_t
int32_t
int64_t

https://en.cppreference.com/w/cpp/types/integer
Re[2]: 64 бита для целого без вариантов - добро или зло?
От: Философ Ад http://vk.com/id10256428
Дата: 11.07.23 14:25
Оценка: +1
Здравствуйте, vsb, Вы писали:

vsb>Мне нравится, как в JS сделали. float64 без вариантов...

надеюсь это шутка.
Всё сказанное выше — личное мнение, если не указано обратное.
Re[3]: 64 бита для целого без вариантов - добро или зло?
От: Философ Ад http://vk.com/id10256428
Дата: 11.07.23 14:42
Оценка: +2
Здравствуйте, Shmj, Вы писали:

S>Так добавили ж уже:


S>int8_t

S>int16_t
S>int32_t
S>int64_t

Добавили, когда было уже слишком поздно. К моменту когда их добавили, было уже написано дофига кода, который уже работать не будет. Теперь тебе нужно ооочень постараться, чтобы старые бинари прочитать.
Всё сказанное выше — личное мнение, если не указано обратное.
Re[3]: 64 бита для целого без вариантов - добро или зло?
От: Alekzander  
Дата: 11.07.23 14:58
Оценка:
Здравствуйте, Философ, Вы писали:

vsb>>Мне нравится, как в JS сделали. float64 без вариантов...

Ф>надеюсь это шутка.

The JavaScript Number type is a double-precision 64-bit binary format IEEE 754 value, like double in Java or C#.
...
Integers can only be represented without loss of precision in the range -2^53 + 1 to 2^53 — 1, inclusive (obtainable via Number.MIN_SAFE_INTEGER and Number.MAX_SAFE_INTEGER), because the mantissa can only hold 53 bits (including the leading 1).


https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Number

Или шутка, что нравится?
Re[2]: 64 бита для целого без вариантов - добро или зло?
От: T4r4sB Россия  
Дата: 11.07.23 14:58
Оценка:
Здравствуйте, Zhendos, Вы писали:

Z>Здравствуйте, Shmj, Вы писали:



Z>1. Свойство, что все числа данного типа это неотрицательные довольно часто нужно,


Это где же? Для индексов и размеров оно вредит. Для битовых операций?
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Re[3]: 64 бита для целого без вариантов - добро или зло?
От: Alekzander  
Дата: 11.07.23 15:06
Оценка: +1
Здравствуйте, Shmj, Вы писали:

S>Так добавили ж уже:


S>int8_t

S>int16_t
S>int32_t
S>int64_t

S>https://en.cppreference.com/w/cpp/types/integer


Это не встроенные фундаментальные типы, а алиасы. Разница, хотя бы, в том, что для встроенных типов не надо тащить #include <cstdint>. Что подходит под определение "в C/C++ каждая вменяемая библиотека извращается создавая свои типы пытаясь скомпенсировать этот недостаток".
Re[3]: 64 бита для целого без вариантов - добро или зло?
От: Alekzander  
Дата: 11.07.23 15:10
Оценка:
Здравствуйте, T4r4sB, Вы писали:

Z>>1. Свойство, что все числа данного типа это неотрицательные довольно часто нужно,


TB>Это где же? Для индексов и размеров оно вредит. Для битовых операций?


Как и включенные поворотники, тип uint не предсказывает, куда повернёт машина, и даже не говорит, что в голове у человека на самом деле. Он показывает, что человек хотел сказать окружающим. Тем и ценен.

А InvalidValue надо явно задавать, через тот же 0xf..f. Или пользоваться исключениями/кодами возврата. Или типами с ? на конце.
Отредактировано 11.07.2023 15:18 Alekzander . Предыдущая версия . Еще …
Отредактировано 11.07.2023 15:17 Alekzander . Предыдущая версия .
Re: 64 бита для целого без вариантов - добро или зло?
От: Stanislav V. Zudin Россия  
Дата: 11.07.23 15:14
Оценка: 4 (2) :))) :)
Здравствуйте, Shmj, Вы писали:

S>Вот новые ЯП типа Dart — решили что нехрен делать 100500 разных вариантов целых чисел (со знаком/без знака, 8, 16, 32, 64) — а просто для всего сделать 64 бита со знаком: https://dart.dev/language/built-in-types


S>Умно?


Так себе.
Выше умные люди уже привели аргументы.

S>Кто-то сразу начнет возражать, что, мол, если будет 1 млрд. записей и в каждой записи число, которое можно было бы сохранить в файл в виде 8 бит, а вместо этого вы потратили 64 бит — то потратим много лишних гигабайт.


Я возражу. Помимо сериализации ещё есть и оперативная память. Нафига создавать семикратный оверхед на ровном месте?

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


S>Что скажете?


В одном из проектов мы использовали трюк с разным размером типа данных для ограничения бесплатной демо-версии программы.
В демо-версии максимальное число объектов было ограничено 125 — однобайтный знаковый тип (127 с учётом спецзначений). А в полнофункциональной версии этот тип был 4-байтным.
Было очень увлекательно читать на профильных форумах, как народ пытается отломать ограничения
_____________________
С уважением,
Stanislav V. Zudin
Re[4]: 64 бита для целого без вариантов - добро или зло?
От: T4r4sB Россия  
Дата: 11.07.23 15:30
Оценка: +1 :)
Здравствуйте, Alekzander, Вы писали:

A>Здравствуйте, T4r4sB, Вы писали:


Z>>>1. Свойство, что все числа данного типа это неотрицательные довольно часто нужно,


TB>>Это где же? Для индексов и размеров оно вредит. Для битовых операций?


A>Как и включенные поворотники, тип uint не предсказывает, куда повернёт машина, и даже не говорит, что в голове у человека на самом деле. Он показывает, что человек хотел сказать окружающим. Тем и ценен.


А еще он создает кучу гемора, не отлавливаемого компилятором со всеми варнингами, когда размер или индекс участвует в формуле где есть такая казалось бы невинная операция вычитания. Нафиг. Показывать ограничения на результат надо другими способами.
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Re: 64 бита для целого без вариантов - добро или зло?
От: CRT  
Дата: 11.07.23 15:34
Оценка:
Здравствуйте, Shmj, Вы писали:

S>Вот новые ЯП типа Dart — решили что нехрен делать 100500 разных вариантов целых чисел (со знаком/без знака, 8, 16, 32, 64) — а просто для всего сделать 64 бита со знаком


то что все целые 64 бита — это неправильно. С обработкой двоичных протоколов передачи данных будет неудобно (хотя может Dart на это не рассчитан).

Насчет того что все целые — знаковые... лично мне это нравится. И в джаве мне эта идея сразу понравилась, пока я не узнал что оказывается оператор >>> нормально работает только с int :(

например в джаве после такого:
 byte b=(byte)0xff;
 b>>>=1;
переменная b всё равно будет равна 0xff.

Получается смысл в >>> теряется для всех кроме int и возникают неудобства при обработки байтов в некоторых двоичных протоколах.
Почему они не сделали >>> для byte и short не понимаю
Отредактировано 11.07.2023 16:02 CRT . Предыдущая версия . Еще …
Отредактировано 11.07.2023 16:02 CRT . Предыдущая версия .
Отредактировано 11.07.2023 15:59 CRT . Предыдущая версия .
Отредактировано 11.07.2023 15:36 CRT . Предыдущая версия .
Отредактировано 11.07.2023 15:34 CRT . Предыдущая версия .
Re[5]: 64 бита для целого без вариантов - добро или зло?
От: Alekzander  
Дата: 11.07.23 15:46
Оценка:
Здравствуйте, T4r4sB, Вы писали:

Z>>>>1. Свойство, что все числа данного типа это неотрицательные довольно часто нужно,


TB>>>Это где же? Для индексов и размеров оно вредит. Для битовых операций?


A>>Как и включенные поворотники, тип uint не предсказывает, куда повернёт машина, и даже не говорит, что в голове у человека на самом деле. Он показывает, что человек хотел сказать окружающим. Тем и ценен.


TB>А еще он создает кучу гемора, не отлавливаемого компилятором со всеми варнингами, когда размер или индекс участвует в формуле где есть такая казалось бы невинная операция вычитания. Нафиг. Показывать ограничения на результат надо другими способами.


Это надо смотреть на конкретном примере. Правильно ли был выбран uint в данном случае? Правильно ли были записано присваивание? И т.д.
Re[6]: 64 бита для целого без вариантов - добро или зло?
От: T4r4sB Россия  
Дата: 11.07.23 16:04
Оценка:
Здравствуйте, Alekzander, Вы писали:

A>Это надо смотреть на конкретном примере. Правильно ли был выбран uint в данном случае? Правильно ли были записано присваивание? И т.д.


Уинт был выбран неправильно но не мной, он вшит в язык намертво.
Присваивание конечно неправильно. Пишу тупо a=b вместо a=b as isize.
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.