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

M>>У меня один байт — одна десятичная цифра
CC>Ух! Не, ну тогда понятно почему всё так безумно медленно.

А есть варианты сделать long decimal более оптимально, и при этом без особых извращений?

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

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

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

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

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

A>>Ещё можно понять рекомендацию языка с синтаксическими макросами, где генерация типа с любыми проверками (1..100) идёт на лету

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

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

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

CC>Но выразительность современного языка должна быть на уровне, позволяющем перекрытие операторов.

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

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

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

N>Шаблон вида

N>

N>template <int _T_min, int _T_max>
N>RangedInteger& operator=(int new_value) {
N>  if (new_value < _T_min || new_value > _T_max) { throw range_error(); }
N>  mValue = new_value;
N>  return *this;
N>}
N>

И к чему тут этот ужас? Думаешь, никто не знает, как это программировать при помощи сиплюсплюсных шаблонов?

Есть языки, где ты можешь САМ сделать синтаксис вида a : int 1..100 (или более интуитивный) с генерацией алиаса на тип с чекерами, даже если bounds на уровне языка никак не представлены. Я удивился, почему было не предложить открыть для себя именно такой язык. Почему C++, где всё подтыкают шаблонами (за неимением синтаксических макросов). Будем по третьему разу мусолить, или хватит уже, наконец?

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

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

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

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

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

_>>2 Сложность вычисления по операциям сложения увеличиться в 8 раз, умножение столбиком в 64 ,по Карацубы конечно меньше но то же возрастет ощутимо.

SP>этот момент вызывает сомнения. Всё равно данные перед умножением/сложением запихиваются в 64-битный регистр. К тому же выделение н-р 3 байта из 8-байтового куска также будет бить по производительности. Пересылка данных между кешем и процессором ведь также идёт по шине в 64 бита. В общем, держать всё в 64 битах может оказаться даже лучше для производительности.
Я здесь не привязывался к архитектуре процессора а рассматривал с общей точки сложности алгоритмов.И здесь надо рассматривать общую скорость вычисления например запихивание ы шину этих 64 бит данных может занимать одни такт, а само сложение уже несколько тактов.

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

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

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

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

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

A> Как вообще после этого можно сравнивать те ошибки и эту ситуацию, когда тебе русским языком выдана диагностика? Там ещё и в логе наверняка всё есть, вплоть до номеров строк.

Это не диагностика. Это последствия ошибки.
В логе ничего нет, в 99% случаев. Всё надо самому вписывать.
Да, тип интеллектуальной возни другой. Объём работы может быть сходным.

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

M>>>У меня один байт — одна десятичная цифра
CC>>Ух! Не, ну тогда понятно почему всё так безумно медленно.

M>А есть варианты сделать long decimal более оптимально, и при этом без особых извращений?

Загляни в исходники .NET Core.
Там работают группами по 9 цифр на 32-битное хранилище.
Промежуточные операции 64-битные.
Но насколько это "особые извращения", не знаю — код действительно сложнее.

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

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

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

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

A>И к чему тут этот ужас? Думаешь, никто не знает, как это программировать при помощи сиплюсплюсных шаблонов?

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

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

Верю. И это тоже само по себе не тьюринг-полнота.

A> Я удивился, почему было не предложить открыть для себя именно такой язык. Почему C++, где всё подтыкают шаблонами (за неимением синтаксических макросов). Будем по третьему разу мусолить, или хватит уже, наконец?

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

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

Здравствуйте, Ночной Смотрящий, Вы писали:

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

S>>Умно?

НС>Не особо. Язык/рантайм не умеющий в byte[] становится существенно ограниченным.

Это же вообще не связанные вещи. В дарте есть byte[]. В питоне том же один целый тип но поддержка byte[] есть.

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

_>>>2 Сложность вычисления по операциям сложения увеличиться в 8 раз, умножение столбиком в 64 ,по Карацубы конечно меньше но то же возрастет ощутимо.

SP>>этот момент вызывает сомнения. Всё равно данные перед умножением/сложением запихиваются в 64-битный регистр. К тому же выделение н-р 3 байта из 8-байтового куска также будет бить по производительности. Пересылка данных между кешем и процессором ведь также идёт по шине в 64 бита. В общем, держать всё в 64 битах может оказаться даже лучше для производительности.
_> Я здесь не привязывался к архитектуре процессора а рассматривал с общей точки сложности алгоритмов.

Пример тогда был сильно паршивый. Именно на уровне процессора (берём Intel x86 последних лет):
1) Операции короче 32 бит стоят столько же, сколько 32-битные.
2) Только одна операция из базовых четырёх — деление — дорожает при переходе к 64 битам. (Грубо говоря, 90 тактов вместо 25.) Остальные как были 1 такт или меньше, так и остались. Это про throughput. Latency не меняется. Смотрел по 248966-042.pdf.
Ну и учитывать объёмы перегонки памяти, вот там торможение на оперативке может быть серьёзным.

А вот выше одного машинного слова уже можно и учитывать, как вы делали.

_>И здесь надо рассматривать общую скорость вычисления например запихивание ы шину этих 64 бит данных может занимать одни такт, а само сложение уже несколько тактов.

Там всё сложнее. И скорее наоборот, если "запихивание в шину" это промах по всем кэшам, то там 300 тактов можно получить как здрасте.

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

M>>А есть варианты сделать long decimal более оптимально, и при этом без особых извращений?

N>Загляни в исходники .NET Core.
N>Там работают группами по 9 цифр на 32-битное хранилище.
N>Промежуточные операции 64-битные.
N>Но насколько это "особые извращения", не знаю — код действительно сложнее.


А, ну ок, я понял. Да, так можно было, но это усложнило бы код. Я думал на эту тему, решил не связываться. Но суть от этого не меняется — умножение в столбик — это реально очень долго по сравнению с другими методами

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

КБ>Это же вообще не связанные вещи. В дарте есть byte[]. В питоне том же один целый тип но поддержка byte[] есть.

И наличие таких костылей как бэ намекаэ, что очень зря избавились от целых типов разной размерности.

Здравствуйте, Ночной Смотрящий, Вы писали:

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

КБ>>Это же вообще не связанные вещи. В дарте есть byte[]. В питоне том же один целый тип но поддержка byte[] есть.

НС>И наличие таких костылей как бэ намекаэ, что очень зря избавились от целых типов разной размерности.

Или наоборот ворох целых типов — костыль. А это нормальный высокоуровневый способ работать с бинарными данными.

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

M>А есть варианты сделать long decimal более оптимально,
Представление чисел DWORDами, в том же стиле как 64 битное число ими представимо, просто размерность тут плавающая.
Операции делать per-dword, всё это прекрасно ложится на уже имеющиееся процессорные складывалки и умножалки.

Все алгоритмы есть у Donald Knuth, не помню какой уже том.

M>и при этом без особых извращений?
А что считается особым извращением?

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

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

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

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

Я по Фиюреру делал, и ускорение начинается сразу же

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

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

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

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

#define GMP_LIMB_BITS 64
#define MUL_TOOM22_THRESHOLD                27

27*64 == 1728

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

НС>>И наличие таких костылей как бэ намекаэ, что очень зря избавились от целых типов разной размерности.
КБ>Или наоборот ворох целых типов — костыль.

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

Здравствуйте, Ночной Смотрящий, Вы писали:

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

НС>>>И наличие таких костылей как бэ намекаэ, что очень зря избавились от целых типов разной размерности.
КБ>>Или наоборот ворох целых типов — костыль.

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

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