IT в России и мире в реалиях мирового кризиса

Цитата: adolfus от 26.04.2021 00:30:22Кристофари – обычный кластер из слабосвязанных узлов на базе x86_64 с посредственными характеристиками. Узлы не имеют доступа к памяти друг друга. Производительность ограничена производительностью интерлинков. Программировать для такого рода архитектур архисложно. Однако именно эти архитектуры агрессивно продвигаются США в лице аргонской национальной лаборатории, которая разработала mpi – библиотеку, с помощью которой программирование задач для такого рода кластеров упрощается. Однако сама лаборатория использует совершенно другие архитектуры... тадам... IBM Blue Gene.

Что касается нвидии, то деньги на ней и прочую бухгалтерию считать невозможно – у графических ускорителей вся арифметика только с плавающей запятой, даже целочисленная арифметика в полной мере не поддерживается. Это не годится для финансовых расчетов – там вычисления только с фиксированной запятой. Кстати, x86_64 тоже не имеет поддержки вычислений с фиксированной запятой, поэтому, чтобы правильно считать деньги (большие), приходится  эмулировать соответсвующие инструкции через исключение недопустимой операции.Вот, кстати, IBM выдала кобол для x86_64, посмотрим, как они с этим там расправляются.
Нвидию же сбер использует для зарабатывания бабок, продавая машинное время для бигдата-процессинга и тренировки нейросетей – узлы заточены исключительно на это. Собрался рулить цифровым обществом.

   
Вы архитектуру Ненавидии изучали по "Техникемолодёджи" или по "Попмеханике"?

Цитата: dmitriк62 от 26.04.2021 13:56:06Вы архитектуру Ненавидии изучали по "Техникемолодёджи" или по "Попмеханике"?

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

Цитата: adolfus от 17.04.2021 01:12:13Во времена того автокада конструктор с карандашом и парой толстых справочников, набитых закладками, мог рассчитать асферический объектив орбитального телескопа – его этому учили в вузе, откуда он пришел в отдел. Сегодня это реализовано в сапре, но юзер уже не конструктор – он не только расчитать, он вообще не понимает как это работает. Он берет то, что есть в библиотеке сапра, собирает до кучи и просто говрит – ну вот так вот получается. А когда спрашиваешь, почему кома на порядок больше, чем дает теория, делает круглые глаза. Сапр не подберет стекло, но посчитает засветку внутренностей или искажения из-за одностороннего нагрева и прочей никогда не реализуемой в нормальном проекте фигни. Зачем конструкору считать, как там будет, если что-то там криво нагреется или придет блик? Он просто следуя правилам, понятым и заученным в вузе, либо отображенным в руководствах и справочниках, будет не считать это дерьмо, а делать, чтобы этого избежать. Современный сапр сильно заточен на визуализацию и кейсы использования, однако мало кто из тех конструкторов, кого я знаю, этим пользуется – это совершенно бессмысленная вещь.

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

С хабра:
В течение последних 20 лет сотрудники Post Office (почтовая компания из Великобритании) разбирались с программой Horizon, в которой имелась фатальная ошибка: из-за неисправности казалось, что сотрудники воровали десятки тысяч фунтов. Некоторые местные почтмейстеры были осуждены и посажены в тюрьму из-за того, что Post Office упорно настаивал на том, что программному обеспечению можно доверять. После десятилетий баталий приговоры 39 человек, наконец, отменили.
Horizon создан японской компанией Fujitsu. Данные этой программы использовались для судебного преследования 736 сотрудников Post Office в период с 2000 по 2014 год.
https://habr.com/ru/…og/554404/

Цитата: mse от 27.04.2021 12:31:49Сцукко, до слёз... Левая крайняя колонка, это стопка 64-битных РОН. В мире стока денех нет, чтобы обсчитать с дефолтной точностью и фиксированной запятой.

Скрытый текст

... Я даже не знаю как мне на этот Ваш "до слез" отвечать... Вы программируете на ассемблере? На каком? Знаете, как используя базовую целочисленную арифметику считать сложные проценты и прочую экспоненциально-логарифмическую банковскую муйню? Достойно уважения...

Это в графике можно –  "поставил" точку где-то посредине целого, типа вместо метров в миллиметрах (двоичных, разумеется), а то и в микронах работаем, и пиши в целых. С деньгами так не выйдет. Вы в лучшем случае начнете терять, либо генерировать. Опять же проблема с мультипликативными операциями – требуют коррекции, типа как для bcd. А уж как муторно возиться с дробями и рядами, используя целочисленную арифметику, не передать словами. Да и смысла нет, если есть доказанные и десятилетиями оттестированные алгоритмы, опирающиеся на доказанные примитивы и инструкции – бери и повторяй. Работая с деньгами, Вы не можете просто так сменит набор инструкций и типы данных – один и тот же банковский или экономический алргоритм при одних и тех же условиях должен выдавать одни и те же результаты вне зависимости от того, на чем он написан и на чем выполняется. Вы не задумывались, почему не переносят код с кобола, написанный полсотни лет назад и выполняющийся на мейнфреймах, на другие языки и другие платформы?
...
Деньги на x86_64 считаются, да. Но путем эмуляции реальных десятилетиями обкатанных в реальном коде инструкций, которая выполняется через исключение недопустимой операции. Компилятор (или программист) генерирует левую инструкцию, которая вне набора и вызывает исключение #UD. Пишется обработчик, который парсит инструкцию, вызвавшую #UD, и эмулирует требуемую из "кошерного" набора. Потом доказывается, что эмулянты работают так же, как и аппаратные.

Цитата: adolfus от 28.04.2021 01:10:04сложные проценты и прочую экспоненциально-логарифмическую банковскую муйню
...
Опять же проблема с мультипликативными операциями – требуют коррекции, типа как для bcd
...
десятилетиями оттестированные алгоритмы
...
один и тот же банковский или экономический алргоритм при одних и тех же условиях должен выдавать одни и те же результаты
...
написанный полсотни лет назад и выполняющийся на мейнфреймах
...
инструкций, которая выполняется через исключение недопустимой операции
...
доказывается, что эмулянты работают так же, как и аппаратные.

Гм. Как я понял эту увлекательнейшую историю. Иррациональные величины, получающиеся при экспоненциальных расчетах всё равно невозможно выразить в виде целочисленных дробей, поэтому применяются округления (я читал что до сотой доли самой мелкой единицы - копейки, цента - но не суть). В банковском деле стандартом стали округления, автоматически получавшиеся на архитектуре 60-х годов прошлого века, и от всех новых программ требуют совпадения с теми примерами. Но сегодня копировать схемотехнические решения из седой древности. никто не будет, поэтому они эмулируются с помощью отработанных и проверенных временем алгоритмов. Не понял только, зачем это делать через прерывание, а не через вызов подпрограммы. Неужели кому-то настолько не хватает быстродействия?
ЗЫ.
И вообще просто серфясь по интернету через https миллиарды людей ежедневно проводят сотни миллиардов транзакций с длинными целыми, которые ни одна процессорная архитектура не поддерживает и ещё несколько десятилетий поддерживать не будет. И никто из этого трагедии не делает.

Цитата: Senya от 28.04.2021 07:38:43Не понял только, зачем это делать через прерывание, а не через вызов подпрограммы. Неужели кому-то настолько не хватает быстродействия?

Вообще-то аппаратно всё должно работать начиная с 486-х процов. Флаги округления FPU выставить в нужный режим (их 4 режима. Для целочисленых вычислений вроде выбирать положено округление к нулю. Не знаю как с финансами). Ставим фиксированый множитель 10000 (для сотых долей цента) и команды FILD/FIST перекидывают число из плавающей точки в 64-битную фиксированую, в соответствие с выбраным режимом округления без лишних телодвижений. Прекрасно работал с целыми 64-битными числами без потери точности на FPU. Прерывания лишь для случая выхода за границы диапазона. Ассемблер, само-собой. На других языках элементарно может быть заложена такая же поддержка.

Цитата: adolfus от 26.04.2021 00:30:22Кристофари – обычный кластер из слабосвязанных узлов на базе x86_64 с посредственными характеристиками. Узлы не имеют доступа к памяти друг друга. Производительность ограничена производительностью интерлинков. Программировать для такого рода архитектур архисложно. Однако именно эти архитектуры агрессивно продвигаются США в лице аргонской национальной лаборатории, которая разработала mpi – библиотеку, с помощью которой программирование задач для такого рода кластеров упрощается. Однако сама лаборатория использует совершенно другие архитектуры... тадам... IBM Blue Gene.

Что касается нвидии, то деньги на ней и прочую бухгалтерию считать невозможно – у графических ускорителей вся арифметика только с плавающей запятой, даже целочисленная арифметика в полной мере не поддерживается. Это не годится для финансовых расчетов – там вычисления только с фиксированной запятой. Кстати, x86_64 тоже не имеет поддержки вычислений с фиксированной запятой, поэтому, чтобы правильно считать деньги (большие), приходится  эмулировать соответсвующие инструкции через исключение недопустимой операции.Вот, кстати, IBM выдала кобол для x86_64, посмотрим, как они с этим там расправляются.
Нвидию же сбер использует для зарабатывания бабок, продавая машинное время для бигдата-процессинга и тренировки нейросетей – узлы заточены исключительно на это. Собрался рулить цифровым обществом.

Нда.... попробую по тому что понятно.
1. Сбер давно стремится стать IT компанией с банковской лицензией, впрочем почти стал давно, и основной софт ему разрабатывают «Сбербанк-технологии".  Кристофари это для них и понты, и давление на конкурентов, и да это обычный кластер, только один из мощнейших в мире.... 
2. Насколько я знаю, в региональных центрах у них вполне себе работают ЦОД-ы на x86_64, 
3. По поводу так зацепившего вас Nvidia, вот тут как мне кажется поворот интересный и в иную сторону. Делали они этот Кристофари в сколковском муравейнике, притом в момент бешенного интереса к майнингу и криптовалютам, вот есть у меня подозрение, что собирались если не наберётся постоянных заказчиков то майнинг. 
3.1. Есть и ешё момент, Их образовательный проект, для которого как мне кажется представленная архитектура удобнее чем один супермозг, по сути же в рамках единой системы нужно держать о обрабатывать массу цифровых двойников образовательных учреждений, притом каждого со своей непересекающейся ни с кем информацией.
4. И наконец. То что для банков ИТ это основное производство, стало понятно ещё в прошлом веке, но вот превращение банков в ИТ компании в рамках рыночной экономики или госкапитализма который опять же предполагаеи рынок в плане финансовых услуг, это пмсм откровенно нечестная конкуренция, так как крупнейшие банки знают всю подноготную клиентов, их финансовые отношения между собой, и хоть все якобы конфидициально, но блин о какой конфидициальности можно говорить в рамках идеологии "только бизнес и ничего личного" , обвязаной голубой лентой так называемой экосистемы. Плюс прямое посягательство на функции государства и регулируемые государством, как то образование&воспитание&медицина... вне досягаемости регулятора.

Цитата: Senya от 28.04.2021 07:38:43Гм. Как я понял эту увлекательнейшую историю. Иррациональные величины, получающиеся при экспоненциальных расчетах всё равно невозможно выразить в виде целочисленных дробей, поэтому применяются округления (я читал что до сотой доли самой мелкой единицы - копейки, цента - но не суть). В банковском деле стандартом стали округления, автоматически получавшиеся на архитектуре 60-х годов прошлого века, и от всех новых программ требуют совпадения с теми примерами. Но сегодня копировать схемотехнические решения из седой древности. никто не будет, поэтому они эмулируются с помощью отработанных и проверенных временем алгоритмов. Не понял только, зачем это делать через прерывание, а не через вызов подпрограммы. Неужели кому-то настолько не хватает быстродействия?
ЗЫ.
И вообще просто серфясь по интернету через https миллиарды людей ежедневно проводят сотни миллиардов транзакций с длинными целыми, которые ни одна процессорная архитектура не поддерживает и ещё несколько десятилетий поддерживать не будет. И никто из этого трагедии не делает.

Транзакции не люди проводят, а программы, которые работают не у миллиардов людей, а на конкретных серверах, и этим серверам все эти длинные целые, что у людей, которые эти самые транзакции инициируют, до фиолетовой лампочки. Там  свои типы данных, свои операции, алгоритмы и прочее. И никто не собирается в ближайше время это все менять и переделывать. Перманентно возникающие передельщики этой "седой древности" уже более, чем полвека пытаются переплыть на "модную, молодежную современность", натыкаются на проблемы, в том числе и округления, которые почему-то никак не получается нормально решить и сдаются. Если в 80-х и 90-х за эту деятельность хоть как-то платили (таки я даже за это получал), то сегодня предпочитают вкладывать деньги в развитие этой самой "седой древности" и обучение общению с ней. Мало того, "мягкую" компоненту этой "седой древности" даже в граните отлили. Мало кто в такой гранит может. Не только лишь все  И что-то я не вижу за окном корабля на лужайке с гранинтными памятниками ни питона ни джавы. Все как в теме с переносом числодробительного кода с фортрана...

Помимо транзакций есть еще куча алгоритмов, в том числе и те, результатом которых является "округление иррациональных результатов" . Кстати, как вы будете округлять? Например, ссуду денег в рост? Умножаете длинное целое денег на процент и ... получаете дробный результат – деньги плюс "хвост".  B так каждый день. В результате у вас накапливается дробная часть. Допустим, перед умножением было масштабирование на 8 разрядов и после умножения нужно все отмасштабировать на 8 разрядов назад, а у вас в этих самых разрядах не нуль. И как мы с ними поступим? И что получим в приросте в конце года?

Цитата: Longspig от 28.04.2021 10:39:19Вообще-то аппаратно всё должно работать начиная с 486-х процов. Флаги округления FPU выставить в нужный режим (их 4 режима. Для целочисленых вычислений вроде выбирать положено округление к нулю. Не знаю как с финансами).

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

Цитата: adolfus от 28.04.2021 12:22:12С финансами это не работает. Во-первых, FPU дает относительную погрешность представления чисел (IEEE 754 обеспечивает логарифмическую равномерность чисел), а для финансов требуется абсолютная (требуется линейная равномерность). Во-второых, дробная часть двоичного числа, подлежащая округлению, всегда нечетная и в какую сторону младший установленный бит не округляй, либо недосчитаешься впоследствии, либо еще хуже – с тебя же и взыщут. Ошибка округления растет, как корень из числа операций. Правило "добавь полразряда и обрежь" работает только в школе на уроках арифметики.

целочисленные операции ограничиваются сложением ( со знаком ) и умножением. Как только появляется деление целочисленность заканчивается. А деление также необходимая финансовая операция для начисления процентов.

Цитата: adolfus от 28.04.2021 12:03:59Там  свои типы данных, свои операции, алгоритмы и прочее

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

Цитата: adolfus от 28.04.2021 12:03:59Мало того, "мягкую" компоненту этой "седой древности" даже в граните отлили. Мало кто в такой гранит может. Не только лишь все

Не, далеко куцему до зайца, в смысле до BCD формата. Который уже полвека как абсолютно бесполезен, но пихается куда только можно.

Цитата: Поверонов от 28.04.2021 13:45:03целочисленные операции ограничиваются сложением ( со знаком ) и умножением. Как только появляется деление

С остатком, которое так же является целочисленной операцией.

Цитата: adolfus от 28.04.2021 12:22:12С финансами это не работает. Во-первых, FPU дает относительную погрешность представления чисел (IEEE 754 обеспечивает логарифмическую равномерность чисел), а для финансов требуется абсолютная (требуется линейная равномерность). Во-второых, дробная часть двоичного числа, подлежащая округлению, всегда нечетная и в какую сторону младший установленный бит не округляй, либо недосчитаешься впоследствии, либо еще хуже – с тебя же и взыщут. Ошибка округления растет, как корень из числа операций. Правило "добавь полразряда и обрежь" работает только в школе на уроках арифметики.

Пока мантисса не выходит за пределы 64-битной разрядногй сетки, равномерность будет линейной. Даже с множителем 10000 на Земле пока столько денюх нет в 64 разряда не влезть. Другое дело, что после любой операции выводящей результат за пределы целочисленой мантиссы (деления с остатком или трансцедентной) придется делать целочисленые  сохранение/загрузку регистра FPU вызывающие автоматическое округление. А при   целочисленом сохранении регистра FPU  к этому случаю применима, например,  методика "округление к четному" усредняющая накапливаемую ошибку "в обе стороны". При рассчетных задачах типа "численых методов решений диффуров" это во благо. Что требуют финансисты при округлении до 0.01 цента - я не знаю, но явно один из существующих 4-х вариантов должен попадать в их запросы.

Цитата: adolfus от 28.04.2021 01:10:04... Я даже не знаю как мне на этот Ваш "до слез" отвечать... Вы программируете на ассемблере? На каком? Знаете, как используя базовую целочисленную арифметику считать сложные проценты и прочую экспоненциально-логарифмическую банковскую муйню? Достойно уважения...

Вы камерад мешаете в кучу - расчетные программы  - там где деньги деньги со счета - на счеит гоняют... и управленческие программы - всякие там опционы , кривые доходности, прогнозирование потока платежей, VaR  и прочий риск -менеджмент. Для первого достаточного INT64  с переводом все в копейки даже для уровня казаначейства Минфина... Для вторых нужны действительно плавающие числа и даже возможно спецалзированное железо.Но количество пользователей на порядок а то и на 2  меньше у второго класса программ...Так шо считать деньги можно считать и спомощью целочсленной арифметики...  

Цитата
 
Это в графике можно –  "поставил" точку где-то посредине целого, типа вместо метров в миллиметрах (двоичных, разумеется), а то и в микронах работаем, и пиши в целых. С деньгами так не выйдет. Вы в лучшем случае начнете терять, либо генерировать. Опять же проблема с мультипликативными операциями – требуют коррекции, типа как для bcd. А уж как муторно возиться с дробями и рядами, используя целочисленную арифметику, не передать словами.

Ну не знаю- не знаю... Есть у меня родственник ... как-то 3 года назад увлекся роботами ну и начал сам мало-помалу писать проги... в последнее время дорщел до программирования FPGA... Ну звонит месяца три назад и спрашивает а не зная ли я алгоритма деления который бы не использовал плавающие числа - ему нужно скорость движения быстро оценить  по показаниям датчика скорсти вращения, ибо FPGA куда быстрее работает с целыми числами нежели с плавающими. Я ему предложил  разлодение  в ряд тейлора прменить, а потом вспомнил что есть более быстрые алгоритмы деления в вике

Цитата

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

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

Цитата
...
Деньги на x86_64 считаются, да. Но путем эмуляции реальных десятилетиями обкатанных в реальном коде инструкций, которая выполняется через исключение недопустимой операции. Компилятор (или программист) генерирует левую инструкцию, которая вне набора и вызывает исключение #UD. Пишется обработчик, который парсит инструкцию, вызвавшую #UD, и эмулирует требуемую из "кошерного" набора. Потом доказывается, что эмулянты работают так же, как и аппаратные.

Цитата: adolfus от 28.04.2021 12:03:59Транзакции не люди проводят, а программы, которые работают не у миллиардов людей, а на конкретных серверах, и этим серверам все эти длинные целые, что у людей, которые эти самые транзакции инициируют, до фиолетовой лампочки. Там  свои типы данных, свои операции, алгоритмы и прочее. И никто не собирается в ближайше время это все менять и переделывать. Перманентно возникающие передельщики этой "седой древности" уже более, чем полвека пытаются переплыть на "модную, молодежную современность", натыкаются на проблемы, в том числе и округления, которые почему-то никак не получается нормально решить и сдаются. Если в 80-х и 90-х за эту деятельность хоть как-то платили (таки я даже за это получал), то сегодня предпочитают вкладывать деньги в развитие этой самой "седой древности" и обучение общению с ней. Мало того, "мягкую" компоненту этой "седой древности" даже в граните отлили. Мало кто в такой гранит может. Не только лишь все  И что-то я не вижу за окном корабля на лужайке с гранинтными памятниками ни питона ни джавы. Все как в теме с переносом числодробительного кода с фортрана...

Помимо транзакций есть еще куча алгоритмов, в том числе и те, результатом которых является "округление иррациональных результатов" . Кстати, как вы будете округлять? Например, ссуду денег в рост? Умножаете длинное целое денег на процент и ... получаете дробный результат – деньги плюс "хвост".  B так каждый день. В результате у вас накапливается дробная часть. Допустим, перед умножением было масштабирование на 8 разрядов и после умножения нужно все отмасштабировать на 8 разрядов назад, а у вас в этих самых разрядах не нуль. И как мы с ними поступим? И что получим в приросте в конце года?

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

Цитата: Longspig от 28.04.2021 18:38:48Пока мантисса не выходит за пределы 64-битной разрядногй сетки, равномерность будет линейной.

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

Цитата: mse от 28.04.2021 19:50:10Мейнфреймы, кстате, имели примерно такие-же системы команд, что и х86.

Откуда Вы эти глупости черпаете? Какая система команд? Совершенно различная архитектура. Там даже стека не было. Совершенно различное кодирование символов. Совершенно различные системы команд. Если что и совпадало, так только директива using. Правда для x86 это подсказка ассемблеру по сегментному регистру, а для мейнфрейма по базовому. И на том и на другом работал. Совершенно разные isa и методы программирования.

Цитата: GrinF от 28.04.2021 21:50:23Есть у меня родственник ... как-то 3 года назад увлекся роботами ну и начал сам мало-помалу писать проги... в последнее время дорщел до программирования FPGA... Ну звонит месяца три назад и спрашивает а не зная ли я алгоритма деления который бы не использовал плавающие числа - ему нужно скорость движения быстро оценить  по показаниям датчика скорсти вращения, ибо FPGA куда быстрее работает с целыми числами нежели с плавающими. Я ему предложил  разлодение  в ряд тейлора прменить, а потом вспомнил что есть более быстрые алгоритмы деления в вике

Для реализации на ПЛИС (Virtex 5 и 7) есть итерационный алгоритм деления на онове метода Ньютона-Рафсона. Вроде в библиотеке, что зайлинх продает, этим методом делят. Вместо итераций используется конвейер из нескольких арифметических блоков.

Цитата: adolfus от 29.04.2021 02:02:18Нормализованное число с плавающей точкой обеспечивает только относительную точность представления, или другими словами, логарифмическую равномерность. Вблизи нуля числа расположены чаще, вдали – реже.

"Относительной" точность в FPU становится лишь выше значения 2**64-1 (знак забирает разряд из поля порядка и тут не участвует). Но операции целочисленого сохранения всегда знаковые, так что разряд теряем (2**63-1). До этого предела, точность представления любого целого числа в FPU абсолютная.
Прекрасно работал с целыми 64-битными числами через FPU.