Здравствуйте, Константин Б., Вы писали:

НС>>Это не костыль, это реальность. И попытка на нее натянуть очередную leaky abstraction ни к чему хорошему не приводит.

КБ>Практикой не подверждается. От кучи целых типов на практике проблем больше.

Продемонстрируйте свою практику, пожалуйста.

S>Что скажете?
LEB128 тогда уже. Чтоб наверняка.

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

N>Я про gmp уже упоминал. mpn/x86_64/gmp_mparam.h :

N>

N>#define GMP_LIMB_BITS 64
N>#define MUL_TOOM22_THRESHOLD                27
N>

N>27*64 == 1728

А как давно эта строка менялась? Ибо с развитием железа скорость выполнения алгоритмов от обрабатываемого объёма данных весьма даже плавает.

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

M>Я по Фиюреру делал, и ускорение начинается сразу же
У тебя просто обычное умножение похоже уж очень медленное получилось.
У меня на текущем железе карацуба умножение становится быстрее арифметического только после 1024 бит, а Sqr и вовсе после 4192х
Заодно обновил константы

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

N>Здравствуйте, Константин Б., Вы писали:

НС>>>Это не костыль, это реальность. И попытка на нее натянуть очередную leaky abstraction ни к чему хорошему не приводит.

КБ>>Практикой не подверждается. От кучи целых типов на практике проблем больше.

N>Продемонстрируйте свою практику, пожалуйста.

Не нулевое количество проблем с неправильным выбором целого типа больше чем ноль проблем от "leaky abstraction" 🤷🏿

Здравствуйте, Константин Б., Вы писали:

НС>>>>Это не костыль, это реальность. И попытка на нее натянуть очередную leaky abstraction ни к чему хорошему не приводит.

КБ>>>Практикой не подверждается. От кучи целых типов на практике проблем больше.

N>>Продемонстрируйте свою практику, пожалуйста.

КБ>Не нулевое количество проблем с неправильным выбором целого типа больше чем ноль проблем от "leaky abstraction" 🤷🏿

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

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

N>>Я про gmp уже упоминал. mpn/x86_64/gmp_mparam.h :

N>>

N>>#define GMP_LIMB_BITS 64
N>>#define MUL_TOOM22_THRESHOLD                27
N>>

N>>27*64 == 1728

CC>А как давно эта строка менялась?

Репа публичная, hg log напустить ты очевидно в состоянии.
https://gmplib.org/repo/gmp/

CC> Ибо с развитием железа скорость выполнения алгоритмов от обрабатываемого объёма данных весьма даже плавает.

Конкретно этот файл — общий для x86-64 всего целиком — менялся в 2011.
Но там есть ещё по каждой ходовой архитектуре свой файлик.
Например, самая последняя добавка mpn/x86_64/alderlake/gmp-mparam.h, там 13 (то есть 832 бита).
Перед этим zen3, там 20 (1280 бит).
Перед этим bd2, там 16 (1024 бита).
Перед этим bt1, там 24 (1536 бит).

У skylake почему-то 26, хотя не древность. У zen3 больше чем у bd2, хотя она на десяток лет новее. Стабильности не наблюдается.

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

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

НС>>>>>Это не костыль, это реальность. И попытка на нее натянуть очередную leaky abstraction ни к чему хорошему не приводит.
КБ>>>>Практикой не подверждается. От кучи целых типов на практике проблем больше.
N>>>Продемонстрируйте свою практику, пожалуйста.
КБ>>Не нулевое количество проблем с неправильным выбором целого типа больше чем ноль проблем от "leaky abstraction" 🤷🏿
N>Как минимум на вторую половину вашей фразы отсутствует подтверждение

Серъезно? "Вы не привели доказательств что проблем нет"? Ну так может наконец сформулируете с какими проблемами вы сталкивались?

Здравствуйте, Константин Б., Вы писали:

НС>>>>>>Это не костыль, это реальность. И попытка на нее натянуть очередную leaky abstraction ни к чему хорошему не приводит.
КБ>>>>>Практикой не подверждается. От кучи целых типов на практике проблем больше.
N>>>>Продемонстрируйте свою практику, пожалуйста.
КБ>>>Не нулевое количество проблем с неправильным выбором целого типа больше чем ноль проблем от "leaky abstraction" 🤷🏿
N>>Как минимум на вторую половину вашей фразы отсутствует подтверждение

КБ>Серъезно? "Вы не привели доказательств что проблем нет"?

Да.

КБ> Ну так может наконец сформулируете

У вас однозначно проблемы с чтением.

КБ> с какими проблемами вы сталкивались?

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

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

КБ>>Серъезно? "Вы не привели доказательств что проблем нет"?

N>Да.

Потрясающе.

КБ>> с какими проблемами вы сталкивались?

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

Не будем обращать внимания что в этой ветке (и топике) обсуждается другое.
Использование языка с несколькими целыми типами (например C) решит эту проблему? Не решит?
А если проблема не зависит от наличия/отсутсвия набора целых типов — то причем этот пример здесь вообще?

Здравствуйте, Константин Б., Вы писали:

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

КБ>Не будем обращать внимания что в этой ветке (и топике) обсуждается другое.

А я вижу прямое отношение ко всему в топике.
Все эти int8_t сейчас это костыли для сужения множества значений (тем более не работающие толком в условиях навязанного integral promotion).

КБ>Использование языка с несколькими целыми типами (например C) решит эту проблему? Не решит?

Почему сразу "например C"?
Решит — наличие типов с произвольно задаваемыми множествами значений. Среди которых все эти int16_t будут просто важными частными случаями для типового домена железо/ОС/etc.

КБ>А если проблема не зависит от наличия/отсутсвия набора целых типов — то причем этот пример здесь вообще?

Условие в "если" не выполняется.

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

N>А я вижу прямое отношение ко всему в топике.
N>Все эти int8_t сейчас это костыли для сужения множества значений (тем более не работающие толком в условиях навязанного integral promotion).

А этому утверждению есть подтверждение?

КБ>>Использование языка с несколькими целыми типами (например C) решит эту проблему? Не решит?

N>Почему сразу "например C"?

А почему нет? В C относительно стандартный набор целых типов.

N>Решит — наличие типов с произвольно задаваемыми множествами значений. Среди которых все эти int16_t будут просто важными частными случаями для типового домена железо/ОС/etc.

А этому утверждению есть подтверждение?

Здравствуйте, Константин Б., Вы писали:

N>>А я вижу прямое отношение ко всему в топике.
N>>Все эти int8_t сейчас это костыли для сужения множества значений (тем более не работающие толком в условиях навязанного integral promotion).

КБ>А этому утверждению есть подтверждение?

Которому из? Тут у меня три утверждения

КБ>>>Использование языка с несколькими целыми типами (например C) решит эту проблему? Не решит?
N>>Почему сразу "например C"?
КБ>А почему нет? В C относительно стандартный набор целых типов.

char/short/int/long, или что?

N>>Решит — наличие типов с произвольно задаваемыми множествами значений. Среди которых все эти int16_t будут просто важными частными случаями для типового домена железо/ОС/etc.
КБ>А этому утверждению есть подтверждение?

И опять же — которому из?

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

N>Репа публичная, hg log напустить ты очевидно в состоянии.
N>https://gmplib.org/repo/gmp/
Для этого надо его на винду поставить, а он мне там нафиг не нужен.

N>Конкретно этот файл — общий для x86-64 всего целиком — менялся в 2011.
Значит уже устарел. В районе 2011го у меня тоже другая константа была.

N>Согласен, методически более верно было бы взять среднее между относительно последними Intel и AMD.
Идеально было бы мерять на конкретной машине во время старта, но это будет уже малость перебор

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

A>>>> Хотя с виртуальной машиной там и ошибок-то таких не бывает, как в сях.
N>>>Ну да, там другие ошибки:

N>>>[--url=https://cs9.pikabu.ru/post_img/2016/09/14/8/1473858812151073022.jpg]Image: 1473858812151073022.jpg[/url]

A>>Насколько я помню, ты достаточно низкоуровневый разработчик с большим опытом. И ты при этом не понимаешь, что это *на самом деле* другая ошибка? Что-то тут не сходится. Знаешь, что такое неделю искать, где у тебя память испортилась?

N>Знаю. Где-то и несколько месяцев (не подряд).
N>Да, другая ошибка. И думаешь, она всегда легко ищется?

"Легко" это понятие относительное. Я написал, что "там и ошибок-то таких не бывает", имея в виду два принципиально разных класса этих самых ошибок.

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

А ошибка того типа, что на картинке, ловится автотестами. Если она прошла через автотесты, значит они не покрывали какой-то важный кейс. Значит, надо дописать. Это в принципе МОЖНО сделать. В отличие от.

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

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

A>>Есть языки, где ты можешь САМ сделать синтаксис вида a : int 1..100 (или более интуитивный) с генерацией алиаса на тип с чекерами, даже если bounds на уровне языка никак не представлены.

S>Простите, что вмешиваюсь, а можно список этих языков?

Когда я это писал, я держал в голове Nemerle, про который тут много рассказывали в своё время. Язык, где даже if это макрос, и макросами же сделана возможность инлайнить XML в код. Сразу скажу, что сам я эти макросы не писал, но был глубоко впечатлён возможностями языка по расширению базового синтаксиса.

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

N>>>Тьюринг-полнота ни при чём.

A>>Да неужели. Когда сравнивают два языка, один из которых хорошо подходит для некоторой фичи, а второй — плохо, а потом кто-то говорит, что оба они, В ПРИНЦИПЕ, одно и то же, то этот "принцип" есть принцип Тьюринга и ничто другое.

N>CreatorCray сказал, что можно самому построить такой шаблон. Про Тьюринг-полноту ты сам зачем-то ввернул в эту ветку обсуждения, там этого не было. Вот я и не понимаю, почему.

Зачем и почему? Затем, что Тьюринг-полнота автоматически гарантирует принципиальную возможность запрограммировать что угодно. И потому нет смысла акцентировать эту самую принципиальную возможность ("на выходе получается ровно код проверки при укладке в переменную"). Важно, КАК мы это программируем. "Как" называется "выразительность". Между прочим, CreatorCray позже сказал, что из-за выразительности в таком малозначительном вопросе менять язык нет смысла. Из чего следует, что мы с ним друг друга поняли.

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

N>>Да, другая ошибка. И думаешь, она всегда легко ищется?

A>"Легко" это понятие относительное. Я написал, что "там и ошибок-то таких не бывает", имея в виду два принципиально разных класса этих самых ошибок.

A>Принципиальная разница тут в следующем. Порчу памяти ты автотестами не поймаешь. Она же может оказаться плавающая.

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

Подавляющее большинство случаев порчи памяти ловится даже без изменения кода (или с минимальными изменениями) несколькими простыми приёмами. Самый дорогой из них это однократная аллокация любого адреса, память не переиспользуется. Второй — защитные блоки вокруг каждой переменной с проверяемым заполнением. Разная инициализация некоторыми случайными шаблонами самой памяти. Лишь бы хватило ресурсов.

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

A> Поэтому и приходится полагаться на косвенные свидетельства отсутствия ошибок, например, соответствие грамматике (то, что проверяет компилятор).

В языке без усиленного контроля (как Rust с его borrow checker) хрен там чем грамматики с компилятором помогут. Все семантические проблемы лежат сильно выше.

A>А ошибка того типа, что на картинке, ловится автотестами.

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

Или ситуацией типа — послали API запрос к серверу, тот сказал что-то типа "402 хреново мне от вашей чрезмерной нагрузки", а клиентской стороне пофиг, что переменные не инициализированы и содержат undefined.

Я даже уверен, что вариант с API многократно воспроизводился в реале с примерно такими же последствиями.

Или ты хочешь сказать, что автотесты должны были быть сделаны и на случай отказа базы или сервера? Вот я не думаю, что кто-то всерьёз будет тестить, что select из базы на недавно добавленные и вроде бы закоммиченные данные куда-то уплыли — пока его носом не ткнут в эту ситуацию. На сбойнувший GET ещё хоть как-то можно предположить, но не на это.

A> Если она прошла через автотесты, значит они не покрывали какой-то важный кейс. Значит, надо дописать. Это в принципе МОЖНО сделать. В отличие от.

Не "в отличие от", см. выше. Меняется специфика и стиль, может резко отличаться цена, но нет принципиальной разницы в самой возможности.

A>Поэтому в системах с виртуальной машиной (и автоматическим управлением памятью и полноценной диагностикой, что я явно не обозначил, но подразумевал) роль компилятора при подготовке как можно более стабильного продукта падает, а роль автотестов — растёт. Это, как бы, исторический факт. В масс-кодинге тесты выстрелили с приходом Джавы.

Потому что сам масс-кодинг с платформой, в которой тебе даже самые тупые ошибки обычно не приводят к потере управляемости, выстрелил с Java. JavaScript и C# догнали через несколько лет.

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

N>Здравствуйте, Константин Б., Вы писали:

N>>>А я вижу прямое отношение ко всему в топике.
N>>>Все эти int8_t сейчас это костыли для сужения множества значений (тем более не работающие толком в условиях навязанного integral promotion).

КБ>>А этому утверждению есть подтверждение?

N>Которому из? Тут у меня три утверждения

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

КБ>>>>Использование языка с несколькими целыми типами (например C) решит эту проблему? Не решит?
N>>>Почему сразу "например C"?
КБ>>А почему нет? В C относительно стандартный набор целых типов.

N>char/short/int/long, или что?

Эти и их unsigned варианты.

N>>>Решит — наличие типов с произвольно задаваемыми множествами значений. Среди которых все эти int16_t будут просто важными частными случаями для типового домена железо/ОС/etc.
КБ>>А этому утверждению есть подтверждение?

N>И опять же — которому из?

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

Здравствуйте, Константин Б., Вы писали:

КБ>>>А этому утверждению есть подтверждение?
N>>Которому из? Тут у меня три утверждения
КБ>"Все эти int8_t сейчас это костыли для сужения множества значений". Есть мнение что это костыли или для экономии памяти или средство для обеспечения определенного бинарного представления.
КБ>Какой смысл сужать множество если ни компилятор ни рантайм не проверяют выход за границы.

Компилятор не проверяет, но мы-то можем проверять. После присвоения — сконвертировать обратно в исходный более широкий тип и сравнить на равенство.
Если компилятор уверен в том, что диапазон значений был до того достаточно узким, он может выкинуть эту проверку с конверсией.
А если ещё GCC/Clang стиль с __builtin_add_overflow(src, 0, &dst), то можно сразу и результат проверки получить.

Конечно, есть ещё тот фактор, что, например, запись по int16_t* запишет 2 байта, а не 4. Но то, что intN_t типы необязательны (в отличие от int_leastN_t и int_fastN_t), чётко показывает, чего именно хотели стандартизаторы в первую очередь.
Вы про эту прикольную тонкость стандартов были в курсе?

КБ>>>>>Использование языка с несколькими целыми типами (например C) решит эту проблему? Не решит?
N>>>>Почему сразу "например C"?
КБ>>>А почему нет? В C относительно стандартный набор целых типов.
N>>char/short/int/long, или что?
КБ>Эти и их unsigned варианты.

Тогда — не очень-то решит. Этот набор ограничен и непереносим в общем случае. Можно, конечно, опереться на то, что char везде вокруг 8 бит, short — 16, а int — минимум 32, но тогда надо честно говорить себе, что мы пишем не на C, а на некоем "усреднённом C современного железа достаточной мощности".
С другой стороны, у меня в работе одновременно проекты для железяк на ARM/32 и ARM/64. Так что на размер long я уже не могу заложиться.

N>>>>Решит — наличие типов с произвольно задаваемыми множествами значений. Среди которых все эти int16_t будут просто важными частными случаями для типового домена железо/ОС/etc.
КБ>>>А этому утверждению есть подтверждение?
N>>И опять же — которому из?
КБ>"Решит". Не очень понятно как оно там что решит. Согласно вводной на проекте бардак и заставить разработчиков проверять данные нельзя, но почему-то можно заставить их использовать наш волшебный тип.

Мы переваливаем на компилятор проверку валидности значений. Где-то он ещё при компиляции пожалуется — пусть это 1% мест, но уже будет хорошая зацепка. Дальше начнёт взрываться на тестах. Это уже хороший метод заставить разработчиков закопаться, что они не так делают. Дальше... ну передавать с этой опцией кастомерам или нет — зависит, где-то лучше чтобы работало даже на кривых данных, но как минимум в бета-тестировании или что вместо него — лучше с полной защитой.
А дальше — психология. Это тот же случай, как в TDD: чтобы заставить себя написать код для задачи, а не пялиться на котиков — пишем тест, и его непрохождение служит стимулом для написания целевого кода.