Что там с 128 бит?

AVX?

Ну или какие-то другие специфические SIMD инструкции

Там 256/512 бит это вектор, а не точность вычислений.

POWER9 купи себе. Там есть.

Мне вчера Густафсон рассказывал, что 128 бит float не нужно, нужно 754й формат выбросить, и тогда всем хватит 32х(или 64х, детали забываются).

для некоторых задач численного интегрирования диффуров, где даже в double постепенно копится заметная ошибка

Деды™ придумали XSC Languages ©.

Мне вчера Густафсон рассказывал

Это про Unum? Ну да, было бы круто. Осталось в процессоры это запилить.

А как поможет XSC, если аппаратного 128 бит нет? Имитировать то float 128 бит и фортран умеет. Только скорость страдает

Есть отличная библиотека QD (https://github.com/scibuilder/QD) для 128 и 256-ти битной точности. Внутри использует обычные даблы из-за чего потеря в скорости всего двух-трех кратная.

ну на фортране то я просто указать могу -fdefault-real-16 (для gfortran). Но это, естественно, даст проигрыш в скорости. Ну а для расчетов все-таки есть разница, ждать полчаса или полтора

Неплохо бы конечно еще на GPU это все запустить дополнительно

на GPU float’ы хреновые

на x86(-64) это 80 битные регистры FPU

А разве не в 32-битных инструкциях 80 бит максимум? Потому что даже на армах x64 long double - 128 бит

Проигрыш по скорости от перехода 64->128 даже в случае аппаратной реализации будет, хоть и меньший. Очевидно, что верторизация будет короче, меньше чисел будет влезать в кэш и т.д. Насчёт GPU - было бы отлично, но портировать qd на это дело будет не очень просто. Как я понимаю, там есть учёт неточностей и округлений для double, которые есть в CPU. Для GPU потребуется перенастройка.

даже на армах x64 long double - 128 бит

Про ARM не скажу, но если я не ошибаюсь, на x86-64 банально не на чем аппаратно 128 битные float считать

существует вот такая пепяка https://www.nextplatform.com/2018/05/24/a-peek-inside-that-intel-xeon-fpga-hybrid-chip/ на ней же можно запилить нужные тебе операции для 128-битных флоатов?

Подозреваю, что fpga будет тормозно. Но штука прикольная)

Ну в общем похоже, что пока что искомого решения пока что нет, видимо надо будет подумать как лучше использовать то, что есть

у меня на райзене 16 байт пишет, а не 10

#include <iostream>

int main() {
	std::cout << sizeof( long double ) << std::endl;

	return 0;
}

Писаться оно может что угодно, а вычисляются они как?

Хз, для моих вычислений даже точности обычного float (4 байта) хватает

ну как получить 128 байтные программным путем - это не вопрос. Но это будет гораздо медленнее аппратных 128 бит.

Есть разница - ждать полтора часа или полчаса

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

К сожалению такой подход невозможен для численных задач

В обшем да, 80бит:

DB 2D 6A 0E 00 00                             fld     cs:tbyte_2020

А по поводу того, что 16 выводит - там вообще видимо константа взятая с потолка это из-за выравнивания:

BE 10 00 00 00                                mov     esi, 16
48 8D 3D BB 2E 00 00                          lea     rdi, _ZSt4cout@@GLIBCXX_3_4
E8 66 FE FF FF                                call    __ZNSolsEm

А вот в армах и правда 128 бит: https://en.wikipedia.org/wiki/Long_double

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

А что-нибудь для более точного есть или планируется?

Реализация высокоточных вычислений в базисе модулярно-интервальной арифметики (PDF) ©.

Можно попытаться реализовать вычисления в системе остаточных классов на ARM системах, или специализированных СБИС ПЛ ©.

P.S. Ещё глянь The GNU Multiple Precision Arithmetic Library (GMP) ©.

Ну да, тред не читай. Речь то идет именно про аппаратную поддержжку. программная то понятно что есть

Речь то идет именно про аппаратную поддержжку.

Дык ссылка на ПЛИСины намекает на аппаратную поддержку, которую сам спаяй и прошей на модулярную арифметику :)

Если не нравяться готовые библиотеки, технически, что мешает замутить самодельный float тип любой произвольной точности? Будет медленно, но зато точно. Все алгоритмы работы с floating point давно известны, так что учебник в зубы и вперед…

где даже в double постепенно копится заметная ошибка

Чёт с трудом верится. Сколько точных знаков после запятой тебе надо?

даже в double постепенно копится заметная ошибка

Ну так ошибка будет копиться, будь там хоть 128000 бит. Для решения этой проблемы предназначены совершенно иные методы.

А что лучше использовать для этого? У меня тмм сейчас рунге кутта-4 обычная

Ты прямо упираешься в накопление ошибки?

Мне нужно чтобы величина угла (0-360 градусов) считалась с точностью не хуже 1 секунды дуги. У меня же в примере, где должен получаться строгий 0, т.к. в этом случае должна интегрироваться производная от 1 (т.е. 0), а получается 64 секунды дуги, причем ошибка получается именно из за погрешностей double

Да, у меня копится ошибка вычислений в double

У меня есть функция заданная на сетке, а между узлами провожу интерполяцию. И даже если я на всей сетке я задам 1, то интерполяция дает не строго 1. И эта ошибка копится

А задача на GPU вообще ложится? Если да, то я бы всё-таки покопал в сторону GPU с ручной реализацией арфиметики достаточной точности, ибо замедление из-за софтовой арифметики может уравновеситься параллельностью GPU.

Мне нужно чтобы величина угла (0-360 градусов) считалась с точностью не хуже 1 секунды дуги

Т.е. порядка 10^-6. Остаётся запаc порядка 10^9. У тебя столько операций?

У меня тмм сейчас рунге кутта-4 обычная

Так может у тебя просто шаг недостаточно мелкий?

Ошибки самого рунге кутты это другая тема.

Суммарно шагов порядка 10^5 - 10^6

Это про Unum?

Это что?

https://en.m.wikipedia.org/wiki/Unum_(number_format)

Потому что даже на армах x64 long double - 128 бит

Удивил, полез гуглить.

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

«Floating point: 32 × 128-bit registers[1] for scalar 32- and 64-bit FP or SIMD FP»

Т.е. там тупо нет аппаратных скалярных 80-бит => поэтому приходится long double делать софтверно => разницы перформанса между софтовым 80 бит и 128 бит наверняка нет => ну тогда пусть будет 128 бит.

Вообщем, не засчитывается.

И обломаться на интегралах

en.m.wikipedia.org

За такое нужно банить безжалостно. Ну в чём проблема убрать эту «m» когда копируешь ссылку?

а теперь вспоминаем, что большая часть действительных чисел транстцендентные и обламываемся

почему «обломаться»?
вычисление определённого интеграла будет такой же функцией (по заданной точности вычисляет первые биты результата)

большая часть действительных чисел транстцендентные и обламываемся

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

по заданной точности вычисляет первые биты результата

вот поэтому - всё равно приходим к необходимости получить результат в численном виде с некоторой точностью

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