Очень интересный формат. Гораздо более экономный чем IEEE-754.
Все кто пользуется числами с плавающей точкой, подмены не заметят. Налететь могут только сериализаторы.
А если расчеты были нормализованы (использовались величины порядка 1), то точноть вычислений возрастёт, т.к. будет больше значащих разрядов.
Но пока можно только на FPGA поиграться.
Вряд ли. Грубо, пользователи хотят "смотреть котиков", а петабайты "котиков" на ютьюбе закодированы с использованием старого формата. И перетестировать кучу существующего ПО для просмотра "котиков" на совместимость и отсутствие "багоюзерства" никто не будет. Плюс 100% не будут работать без дополнительных танцев с бубном экспорт/импорт данных во внешние системы, ещё не поддерживающие новый формат (та же сериализация/десериализация).
В теории возможен вариант с появлением принципиально новой архитектуры, которую будет продвигать какая-нибудь крупная компания, причём, помимо прочего, эта компания сможет создать и развивать собственную экосистему с "просмотром котиков", одновременно поддерживая конвертацию стрых данных.
В общем, для существующего пласта ПО и "ближайшей" (лет 10 минимум) перспективы — точно нет.
Так что формат, скорее всего, ждёт довольно узкая область применения, например, в некоторых суперкомпьютерах (если они именно "с нуля" строятся), или при хранении/передаче огромных массивов данных, ну, или если канал сильно ограничен (станции дальнего космоса, например).
Ещё интересный вариант может быть при проектировании видеокарт. На вход идут данные в IEEE-754, а внутренняя обработка уже в posits — обсчётов куча, затраты памяти колоссальные, конвертация входных данных вполне может стать оправданной, при этом результат идёт только на выход монитора, на котором любые а любые мелкие несоответствия обсчёта в двух разных системах заведомо не будут заметны. А там, глядишь, и производители игр подтянутся, а за ними и какие-нибудь производители игровых платформ.
"Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живете". (с) Макконнелл, "Совершенный код".
LVV>>Грядет замена стандарта IEEE-754? P>Не грядет.
Ну, почему?
Лет через 35...
Сначала в каких-нибудь специальных машинах для специальных расчетов.
В графических процессорах...
В суперкомпьютерах...
Но, согласен, массовое производство могут поменять только по 1 причине: смена формата сулит хорошую прибыль.
-
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>Ну, почему? LVV>Лет через 35... LVV>Сначала в каких-нибудь специальных машинах для специальных расчетов. LVV>В графических процессорах... LVV>В суперкомпьютерах... LVV>Но, согласен, массовое производство могут поменять только по 1 причине: смена формата сулит хорошую прибыль.
А тут не грозит потому как потребитель платящий деньги разницы не заметит. Возможная экономия на нескольких битах приведет к усложнению схемотехники и снижению быстродействия. Для конечного потребителя это пофиг. А вот для разработчика оценка потери точности стала бы еще сложнее. Для чего несколько лишних бит в мантиссе, если оценка того не потеряются ли они при дальнейших расчетах становится очень нетривиальной задачей?
Здравствуйте, pagid, Вы писали:
P>Здравствуйте, LaptevVV, Вы писали:
LVV>>Ну, почему? LVV>>Лет через 35... LVV>>Сначала в каких-нибудь специальных машинах для специальных расчетов. LVV>>В графических процессорах... LVV>>В суперкомпьютерах... LVV>>Но, согласен, массовое производство могут поменять только по 1 причине: смена формата сулит хорошую прибыль.
Просто сделают доп набор векторных команд и назовут PackedFloat extension вместо posit и понесётся маркетинг.
— P>А тут не грозит потому как потребитель платящий деньги разницы не заметит. Возможная экономия на нескольких битах приведет к усложнению схемотехники и снижению быстродействия. Для конечного потребителя это пофиг. А вот для разработчика оценка потери точности стала бы еще сложнее. Для чего несколько лишних бит в мантиссе, если оценка того не потеряются ли они при дальнейших расчетах становится очень нетривиальной задачей?
Тут как раз все проще и вместо double64 предлагается переходить на posit32 что в два раза быстрее по памяти и гораздо точнее чем float.
Здравствуйте, kov_serg, Вы писали:
_>Тут как раз все проще и вместо double64 предлагается переходить на posit32 что в два раза быстрее по памяти и гораздо точнее чем float.
Чуть-чуть точнее, и стоит немного ошибиться в оценке порядка результатов, в том числе промежуточных каждой операции, так эти небольшие преимущества обернуться полным провалом.
Здравствуйте, kov_serg, Вы писали:
_>Все кто пользуется числами с плавающей точкой, подмены не заметят.
"Отучаемся говорить за всех" (c)
Физики всех видов точно пошлют как минимум куда Макар телят не гонял. Почему они должны терять точность вычислений из-за смены порядка? Постоянно вылазят константы с большими показателями, типа 6.67e-11, 6.02e23 и т.п. — на них будет падать точность расчётов?
_>А если расчеты были нормализованы (использовались величины порядка 1), то точноть вычислений возрастёт, т.к. будет больше значащих разрядов.
И кто будет так "нормализовывать" расчёты на практике?
Здравствуйте, netch80, Вы писали:
N>Физики всех видов точно пошлют как минимум куда Макар телят не гонял. Почему они должны терять точность вычислений из-за смены порядка? Постоянно вылазят константы с большими показателями, типа 6.67e-11, 6.02e23 и т.п. — на них будет падать точность расчётов?
Ничего не вылазит.
_>>А если расчеты были нормализованы (использовались величины порядка 1), то точноть вычислений возрастёт, т.к. будет больше значащих разрядов.
N>И кто будет так "нормализовывать" расчёты на практике?
Никто в здравом уме и не производит вычисления с не нормализированными величинами.
Вы же не вычисляете расстояние между атомами в парсеках и не измеряете площадь поля для гольфа в барнах. Даже вместо штук зачем-то используют моли.
Здравствуйте, kov_serg, Вы писали:
N>>И кто будет так "нормализовывать" расчёты на практике? _>Вы же не вычисляете расстояние между атомами в парсеках и не измеряете площадь поля для гольфа в барнах. Даже вместо штук зачем-то используют моли.
Зато мерять космические расстояния в метрах, километрах, астрономических единицах — норма. Потому что стандарты.
_>Никто в здравом уме и не производит вычисления с не нормализированными величинами.
Сплошь и рядом вижу такое — потому, что никому из практиков в здравом уме таки не приходит, что подложка будет терять точность на минимальных отклонениях от диапазона, грубо говоря, от 1/100 до 100.
Вы продолжаете расписываться за всех с, мягко говоря, сомнительными основаниями.
Здравствуйте, netch80, Вы писали:
N>Зато мерять космические расстояния в метрах, километрах, астрономических единицах — норма. Потому что стандарты.
Нет дело не в стандартах.
_>>Никто в здравом уме и не производит вычисления с не нормализированными величинами. N>Сплошь и рядом вижу такое — потому, что никому из практиков в здравом уме таки не приходит, что подложка будет терять точность на минимальных отклонениях от диапазона, грубо говоря, от 1/100 до 100.
Это видимо по тому что они не внимательно изучали численные методы. Или вообще далеки от вычислительной математики.
И потом вы сильно преувеличиваете потерю точности. Посмотрите внимательно какие погрешности в космических расстояниях.
posit32 vs float32
режим 1 - до 4 8.4 значащих цифр у float 7.2
режим 2 - до 16 7.8 значащих цифр у float 7.2
режим 3 - до 256 7.2 значащих цифр у float 7.2
режим 4 - до 65536 6.6 значащих цифр у float 7.2
режим 5 - до 4.3e+09 6.0 значащих цифр у float 7.2
режим 6 - до 1.84e+19 5.4 значащих цифр у float 7.2
режим 7 - до 3.40e+38 4.8 значащих цифр у float 7.2
режим 8 - до 1.16e+77 4.2 значащих цифр во float не представима
режим 9 - до 1.34e+154 3.6 значащих цифр во float не представима
режим 13 - до 1e+2466 1.2 значащая цифра во float не представима
...
max=2^(+2^31) ~ 1.76e+646456993 - максимальное представимое число
2^(-2^31) - наименьше по модулю представимое не нулевое число
Так что в диапазоне 1/256 до 256 точность не хуже чем у float32
N>Вы продолжаете расписываться за всех с, мягко говоря, сомнительными основаниями.
Я излагаю свое мнение. Для обычных инженерных расчетов достаточно 4 значащих цифр. Для более точных моделей ничто не мешает использовать большую точность.
Более того есть методы позволяющие уточнять результат имея ограниченную точность вычислений.
И потом тут как всегда компромис: вам надо точно или быстро.
Здравствуйте, kov_serg, Вы писали:
_>И потом вы сильно преувеличиваете потерю точности. Посмотрите внимательно какие погрешности в космических расстояниях. _>
_>posit32 vs float32
_>режим 1 - до 4 8.4 значащих цифр у float 7.2
_>режим 2 - до 16 7.8 значащих цифр у float 7.2
_>режим 3 - до 256 7.2 значащих цифр у float 7.2
_>режим 4 - до 65536 6.6 значащих цифр у float 7.2
_>режим 5 - до 4.3e+09 6.0 значащих цифр у float 7.2
_>режим 6 - до 1.84e+19 5.4 значащих цифр у float 7.2
_>режим 7 - до 3.40e+38 4.8 значащих цифр у float 7.2
_>режим 8 - до 1.16e+77 4.2 значащих цифр во float не представима
_>режим 9 - до 1.34e+154 3.6 значащих цифр во float не представима
_>режим 13 - до 1e+2466 1.2 значащая цифра во float не представима
_>...
_>max=2^(+2^31) ~ 1.76e+646456993 - максимальное представимое число
_>2^(-2^31) - наименьше по модулю представимое не нулевое число
_>
_>Так что в диапазоне 1/256 до 256 точность не хуже чем у float32
Следует ли из этой таблички, что, те хвалы обещающие рай на земле, что написаны в статье на хабре — ложь? (Про то, что один 32-битный посит заменяет float64?)
IEEE-754, конечно, уродство ещё то, но я не вижу чем новый формат лучше. Один только отдельный бит знака сводит на нет преимущества нового формата. И как при наличии этого бита он может избежать такой странности, как несовпадающие значения 0 и -0? Not-a-number (NaN), так же как и бесконечности (причём разных знаков) — тоже полезны как результат выполнения функций в которые передаётся недопустимый аргумент. А разная длина мантиссы у разных порядков даже вредна, при этом теряется сам смысл плавающей точки.
Я отвечаю за свои слова, а не за то как вы их интерпретируете!
Здравствуйте, Mystic Artifact, Вы писали:
_>>И потом вы сильно преувеличиваете потерю точности. Посмотрите внимательно какие погрешности в космических расстояниях. _>>
_>>posit32 vs float32
_>>режим 1 - до 4 8.4 значащих цифр у float 7.2
_>>режим 2 - до 16 7.8 значащих цифр у float 7.2
_>>режим 3 - до 256 7.2 значащих цифр у float 7.2
_>>режим 4 - до 65536 6.6 значащих цифр у float 7.2
_>>режим 5 - до 4.3e+09 6.0 значащих цифр у float 7.2
_>>режим 6 - до 1.84e+19 5.4 значащих цифр у float 7.2
_>>режим 7 - до 3.40e+38 4.8 значащих цифр у float 7.2
_>>режим 8 - до 1.16e+77 4.2 значащих цифр во float не представима
_>>режим 9 - до 1.34e+154 3.6 значащих цифр во float не представима
_>>режим 13 - до 1e+2466 1.2 значащая цифра во float не представима
_>>...
_>>max=2^(+2^31) ~ 1.76e+646456993 - максимальное представимое число
_>>2^(-2^31) - наименьше по модулю представимое не нулевое число
_>>
_>>Так что в диапазоне 1/256 до 256 точность не хуже чем у float32
MA>Следует ли из этой таблички, что, те хвалы обещающие рай на земле, что написаны в статье на хабре — ложь? (Про то, что один 32-битный посит заменяет float64?)
Нет это не ложь это лукавство. Ибо оно может заменить double по динамическому диапазону, но не по точности. У double мантиса 52бита, а у посита32 28 и меньше.
Но double способен представлять числа до 1.8e308 посит32 тоже способен работать с этими числами, но с меньшей точностью. Но как я уже писал раньше у инженеров только интерферометры способны выдавать очень точные значения, бытовая точность это 1-10%. 10ppm это 5 знаков уже часы. Меньше 1ppm это уже прецизионные измерения. А когда вы оцениваете по порядку величины тут нафиг не нужна великая точность.
Здравствуйте, kov_serg, Вы писали:
_>Но double способен представлять числа до 1.8e308 посит32 тоже способен работать с этими числами, но с меньшей точностью. Но как я уже писал раньше у инженеров только интерферометры способны выдавать очень точные значения, бытовая точность это 1-10%. 10ppm это 5 знаков уже часы. Меньше 1ppm это уже прецизионные измерения. А когда вы оцениваете по порядку величины тут нафиг не нужна великая точность.
Вот, не знаю... Сдается мне, что даже графика в виде "точность то не очень нам и важна, там пару пикселов туда-сюда" на самом деле довольно быстро становится проблемой (хотя я серьезно графикой не занимался). С учетом того, что кардинальных улучшений в точности нет — затея, имхо, сомнительная.
Там меня в статье на хабре на самом деле не только это зацепило. Там написано, что битовые сравнения вдруг работают (с нулем? — с чего бы? А +/-0 вроде и не особо то проблема). Быстро прочитав наискось осталось ощущение, что много восторга, но сложностей работы с FP не уменьшает вообще, а качаственные характеристики не осознал.
Здравствуйте, kov_serg, Вы писали:
_>Это видимо по тому что они не внимательно изучали численные методы. Или вообще далеки от вычислительной математики.
Это знатный аргумент. Сразу выводит в дамки.
_>И потом вы сильно преувеличиваете потерю точности. Посмотрите внимательно какие погрешности в космических расстояниях.
Для начала стоило бы поговорить насколько операции с 64-разрядным IEEE-754 дороже операций с 32-разрядным IEEE-754. По быстродействию, количество транзисторов вряд ли стоит обсуждения. А уж потом говорить о том насколько интересен предлагаемый вариант.
_>[code] _>posit32 vs float32 _>режим 1 — до 4 8.4 значащих цифр у float 7.2
...
... _>режим 9 — до 1.34e+154 3.6 значащих цифр во float не представима _>режим 13 — до 1e+2466 1.2 значащая цифра во float не представима _>...
О какая красота! Процессор должен поддерживать этот зверинец, а программист обдуманно и с чувством выбирать какой именно вариант ему нужен для текущей задачи?
_>Я излагаю свое мнение. Для обычных инженерных расчетов достаточно 4 значащих цифр.
То есть для инженерных расчетов 32-разрядного IEEE-754 хватит с большим запасом. Неожиданный вывод, делающий предыдущие рассуждения и предложения бессмысленными, во всяком случае для обычных инженерных расчетов.
_>Для более точных моделей ничто не мешает использовать большую точность.
64-разрядный IEEE-754
Но ради чего пыжились придумывая как скрестить ужа с ежом?
_>И потом тут как всегда компромис: вам надо точно или быстро.
Так все же насколько быстрее?
Здравствуйте, LaptevVV, Вы писали:
LVV>Наши могут себе позволить. LVV>В специальных разработках для государственных структур. LVV>Ну, или для вооружений.
Ага, могут, только все это засекретят, и никто не узнает дают ли они реально улучшение или с ними проблем будет еще больше чем с обычными флоатами...
Вообще текущий стандарт чисел с плавающей точной просто ужасен, там грабли на каждом шагу. Было бы здорово если бы его заменили на что-то более вменяемое.
Но с другой стороны грабли текущего стандарта известны и хорошо описаны, а какие там новые грабли окажутся в новом стандарте пока не понятно, вполне возможно, что их будет еще больше, и понятно это станет только после массового внедрения. А массовое внедрение вещь дорогая, сложная и очень не быстрая...
Здравствуйте, pagid, Вы писали:
_>>И потом вы сильно преувеличиваете потерю точности. Посмотрите внимательно какие погрешности в космических расстояниях. P>Для начала стоило бы поговорить насколько операции с 64-разрядным IEEE-754 дороже операций с 32-разрядным IEEE-754. По быстродействию, количество транзисторов вряд ли стоит обсуждения. А уж потом говорить о том насколько интересен предлагаемый вариант.
Основной посыл не в скорости вычислений, а в скорости пересылки данных. Сжатие — основной посыл и гамма коды тут очень хорошо вписались.
P>О какая красота! Процессор должен поддерживать этот зверинец, а программист обдуманно и с чувством выбирать какой именно вариант ему нужен для текущей задачи?
Нет программист просто лёгким движением должен поменять один тип на другой, для того что бы можно было легко сравнить результаты.
Процессор поддерживает эпический зоопарк технологий, так-то какой-то мелкий зверинец не помешает. Еще в поситах нет +inf, -inf, +0, -0, qNAN, sNAN, режима округления и правил работы с этими особенными значениями только 0 и inf и округление к ближайшему.
_>>Я излагаю свое мнение. Для обычных инженерных расчетов достаточно 4 значащих цифр. P>То есть для инженерных расчетов 32-разрядного IEEE-754 хватит с большим запасом. Неожиданный вывод, делающий предыдущие рассуждения и предложения бессмысленными, во всяком случае для обычных инженерных расчетов.
_>>Для более точных моделей ничто не мешает использовать большую точность. P>64-разрядный IEEE-754
Не 64бит, а значительно больше. P>Но ради чего пыжились придумывая как скрестить ужа с ежом?
Очень просто расширили динамический диапазон при этом не сильно потеряв в точности в типовом диапазоне.
_>>И потом тут как всегда компромис: вам надо точно или быстро. P>Так все же насколько быстрее?
В 2 раза быстрее по памяти если использовать вместо double.
Зачем по вашему float16 используют?
В некоторых задачах снижают точность ниже плинтуса https://www.sysml.cc/doc/2019/168.pdf и работает
Здравствуйте, qwertyuiop, Вы писали:
Q>Здравствуйте, LaptevVV, Вы писали:
Q>IEEE-754, конечно, уродство ещё то, но я не вижу чем новый формат лучше. Один только отдельный бит знака сводит на нет преимущества нового формата. И как при наличии этого бита он может избежать такой странности, как несовпадающие значения 0 и -0? Not-a-number (NaN), так же как и бесконечности (причём разных знаков) — тоже полезны как результат выполнения функций в которые передаётся недопустимый аргумент. А разная длина мантиссы у разных порядков даже вредна, при этом теряется сам смысл плавающей точки.
Нет там +0 и -0 и +inf и -inf там есть только 0 и ComplexInfinity
Здравствуйте, kov_serg, Вы писали:
_>Основной посыл не в скорости вычислений, а в скорости пересылки данных.
Зачем она? Скорость вычислений понятно. И да скорость вычислений это интегральный показатель, необходимое время для пересылки память-кэш и кэш-процессор она разумеется тоже должа учитывать. Или о какой пересылке речь, по каким-то каналам связи что ли?
_>Сжатие — основной посыл и гамма коды тут очень хорошо вписались.
Как хорошо? Есть какие-то оценки?
Хотя стоп-стоп, я же для начала попросил сравнить скорость работы существующих реализаций float и double (в С-шной терминологии), это позволило бы для начала понять, а нужно ли вообще задумываться над желанием запихнуть в 32-разряда что-то большее, чем сейчас чуток приближающее к double.
_>Нет программист просто лёгким движением должен поменять один тип на другой, для того что бы можно было легко сравнить результаты.
То есть подогнать тип "впритирочку". А потом при чуть других данных окажется, что из этой притирочки результат, более вероятно промежуточный, выходит. И кто тогда и сразу ли, и по какой причине поймет, что в результате получилась лажа?
_>Процессор поддерживает эпический зоопарк технологий, так-то какой-то мелкий зверинец не помешает.
Но сначала нужен ответ на вопрос — с какой целью?
_>Еще в поситах нет +inf, -inf, +0, -0, qNAN, sNAN, режима округления и правил работы с этими особенными значениями только 0 и inf и округление к ближайшему.
И какие реальные проблемы решит? Иррациональный страх недоучек-хипстеров от недопонимаемого ими формата с плавающей точкой? Нет, не решит, пока это именно плавающая точка никаких реальных проблем и необходимости понимать её особенности подобная перестановка кроватей не разрешит.
_>>>Я излагаю свое мнение. Для обычных инженерных расчетов достаточно 4 значащих цифр. P>>То есть для инженерных расчетов 32-разрядного IEEE-754 хватит с большим запасом.
Так хватит или не хватит?
_>Не 64бит, а значительно больше.
Зачем и для чего больше?
_>Очень просто расширили динамический диапазон при этом не сильно потеряв в точности в типовом диапазоне.
Если сравнивать posit32 и double, то потеряв очень много значащих цифр. Но если ты готов вести инженерные расчеты с четырьмя значащими цифрами, то чем плох сегодняшний float? там там их больше.
_>В 2 раза быстрее по памяти если использовать вместо double.
При чем тут память? И не заменяют эти posit32 double, по этой причине говорить даже о двукратной экономии памяти (таки с какой целью? ) это лукавство.
Здравствуйте, pagid, Вы писали: _>>Основной посыл не в скорости вычислений, а в скорости пересылки данных. P>Зачем она? Скорость вычислений понятно. И да скорость вычислений это интегральный показатель, необходимое время для пересылки память-кэш и кэш-процессор она разумеется тоже должа учитывать. Или о какой пересылке речь, по каким-то каналам связи что ли?
Очень просто передача между CPU и GPU _>>Сжатие — основной посыл и гамма коды тут очень хорошо вписались. P>Как хорошо? Есть какие-то оценки? P>Хотя стоп-стоп, я же для начала попросил сравнить скорость работы существующих реализаций float и double (в С-шной терминологии), это позволило бы для начала понять, а нужно ли вообще задумываться над желанием запихнуть в 32-разряда что-то большее, чем сейчас чуток приближающее к double.
Скороть работы можно сравнить только на конкретных задачах. Так как тут всё сильно зависит от реализации.
_>>Нет программист просто лёгким движением должен поменять один тип на другой, для того что бы можно было легко сравнить результаты. P>То есть подогнать тип "впритирочку". А потом при чуть других данных окажется, что из этой притирочки результат, более вероятно промежуточный, выходит. И кто тогда и сразу ли, и по какой причине поймет, что в результате получилась лажа?
Если модель лажа, то никакие типы данных не помогут. _>>Процессор поддерживает эпический зоопарк технологий, так-то какой-то мелкий зверинец не помешает. P>Но сначала нужен ответ на вопрос — с какой целью? _>>Еще в поситах нет +inf, -inf, +0, -0, qNAN, sNAN, режима округления и правил работы с этими особенными значениями только 0 и inf и округление к ближайшему. P>И какие реальные проблемы решит?
Это позволяет иметь более простую реализацию. P>Иррациональный страх недоучек-хипстеров от недопонимаемого ими формата с плавающей точкой? Нет, не решит, пока это именно плавающая точка никаких реальных проблем и необходимости понимать её особенности подобная перестановка кроватей не разрешит.
o_O? Использование сжатия данных это один из путей которыми придётся увеличивать произвоительность. Т.к. ныче память это медленно. P>>>То есть для инженерных расчетов 32-разрядного IEEE-754 хватит с большим запасом. P>Так хватит или не хватит?
В многих задачах вполне приемлемо. Но если не критично люди не заморачиваются и используют double. Т.к. в обычных вычислениях кэш процессора нивилирует отличия по времени доступа в ram. _>>Не 64бит, а значительно больше. P>Зачем и для чего больше?
Орбиты небесных тел считать или жесткие системы уравнений. _>>Очень просто расширили динамический диапазон при этом не сильно потеряв в точности в типовом диапазоне. P>Если сравнивать posit32 и double, то потеряв очень много значащих цифр. Но если ты готов вести инженерные расчеты с четырьмя значащими цифрами, то чем плох сегодняшний float? там там их больше.
Он не плох для определённого круга задач вполне приемлем.
Сценарий такой ведёте расчеты в double в double80 (fpu) или в double128, а результаты вычислений для передачи упаковываете в posit. _>>В 2 раза быстрее по памяти если использовать вместо double. P>При чем тут память? И не заменяют эти posit32 double, по этой причине говорить даже о двукратной экономии памяти (таки с какой целью? ) это лукавство.
Для расчетов можно и fixed32 использовать, но у него динамический диапазон очень маленький и надо за ним очень внимательно следить. В posit32 в overflow и underflow будет тяжелее уйти.
Здравствуйте, kov_serg, Вы писали:
_>Здравствуйте, pagid, Вы писали:
_>Очень просто передача между CPU и GPU
Совсем не в теме про расчете на GPU. С какой точностью там принято считать с плавающей точкой?
_>Скороть работы можно сравнить только на конкретных задачах. Так как тут всё сильно зависит от реализации. _>например _>!! Люто синтетический подгоночный тест: _>[cpp]
...
...
... _>g++ test.cpp -O3 && ./a.out _>dt=2.30sec data_size= 38.1Mb data_rate=1655.5Mb/s compute_rate=413.9M/s _>dt=4.80sec data_size= 76.3Mb data_rate=1589.5Mb/s compute_rate=198.7M/s _>float/double=2.08
Намного лучше, чем я предполагал. Считал, что как раз около двух раз это как раз вполне реально.
_>Если модель лажа, то никакие типы данных не помогут.
Не, так не пойдет. Это слишком общая сентенция. Потеря же точности при недостаточной длине в представлении числа объективная реальность. Разумеется от алгоритма и его реализации зависит, при уменьшении количества значащих цифр оно неизбежно. _>Для расчетов можно и fixed32 использовать, но у него динамический диапазон очень маленький и надо за ним очень внимательно следить. В posit32 в overflow и underflow будет тяжелее уйти.
Не, это тоже из какого-то другого разговора.
Здравствуйте, pagid, Вы писали:
P>float/double=1.39 P>Намного лучше, чем я предполагал. Считал, что как раз около двух раз это как раз вполне реально.
Занятно. У меня на i7-4770/DDR3 стабильно получается 1.8-1.9. А на i5-7300HQ/DDR4 получается тоже в районе 1.45 (с похожими абсолютными цифрами). Один раз вышло 1.3, но это обновления в фоне ставились.
MA> Занятно. У меня на i7-4770/DDR3 стабильно получается 1.8-1.9. А на i5-7300HQ/DDR4 получается тоже в районе 1.45 (с похожими абсолютными цифрами). MA>Один раз вышло 1.3, но это обновления в фоне ставились.
i5-6400 память Х.З. какая
Повторяется. Если тест 64-разрядный от 1.38 до 1.55, если 32-разрядный 1.32 — 1.34 при этом абсолютные цифры немного лучше.
На стареньком AMD процессоре абсолютные цифры в несколько раз больше, но соотношение примерно такое же. Там память DDR3
Здравствуйте, kov_serg, Вы писали:
N>>Зато мерять космические расстояния в метрах, километрах, астрономических единицах — норма. Потому что стандарты. _>Нет дело не в стандартах.
Очень аргументированное утверждение
_>И потом вы сильно преувеличиваете потерю точности. Посмотрите внимательно какие погрешности в космических расстояниях.
Нормальные там погрешности, многие вещи меряют с точностью до 5-6 десятичного знака, а то и точнее. Это не XIX век.
_>posit32 vs float32 _>режим 1 — до 4 8.4 значащих цифр у float 7.2 _>режим 2 — до 16 7.8 значащих цифр у float 7.2 _>режим 3 — до 256 7.2 значащих цифр у float 7.2 _>режим 4 — до 65536 6.6 значащих цифр у float 7.2 _>режим 5 — до 4.3e+09 6.0 значащих цифр у float 7.2 _>режим 6 — до 1.84e+19 5.4 значащих цифр у float 7.2 _>режим 7 — до 3.40e+38 4.8 значащих цифр у float 7.2 _>режим 8 — до 1.16e+77 4.2 значащих цифр во float не представима _>режим 9 — до 1.34e+154 3.6 значащих цифр во float не представима _>режим 13 — до 1e+2466 1.2 значащая цифра во float не представима _>... _>max=2^(+2^31) ~ 1.76e+646456993 — максимальное представимое число _>2^(-2^31) — наименьше по модулю представимое не нулевое число
Я не смог однозначно понять, что эти "режимы" значат. В оригинальной pdfʼке автор разве что качучу вприсядку не танцует — стиль такой, что туда вставить пару десятков одесских анекдотов вообще ничего не изменит; но понять оттуда, чему равно в его предложениях, например, es для 32-битного числа — я тупо ниасилил. Если вы осилили, чему там предлагается сделать равным это es? И значит ли "режим N" в вашей таблице, что в числе ровно N так называемых regime bits?
Если "да" на последнее, то в диапазоне порядков до 3.4e+38 — то, что позволяет float32 — точность уже в разы хуже.
_>[/code] _>Так что в диапазоне 1/256 до 256 точность не хуже чем у float32
N>>Вы продолжаете расписываться за всех с, мягко говоря, сомнительными основаниями. _>Я излагаю свое мнение. Для обычных инженерных расчетов достаточно 4 значащих цифр.
"Обычные инженерные" это то, для чего использовались таблицы Брадиса? (У меня других ассоциаций на 4 значащих цифры нет, поэтому предполагаю источник отсюда.) А чего вдруг такая подмена контекста? Разве float32 предполагался для "обычных инженерных расчётов" образца 1921 года?
_> Для более точных моделей ничто не мешает использовать большую точность. _>Более того есть методы позволяющие уточнять результат имея ограниченную точность вычислений. _>И потом тут как всегда компромис: вам надо точно или быстро.
У меня такой же компромисс есть с IEEE754, причём там нужно следить за сильно меньшим набором факторов.
Например, там есть явный контроль переполнений и недополнений.
А тут — будет, например, параметр режима вычислений "поднимать флаг, если точность стала менее 16 бит"?
И так для каждого значения с шагом хотя бы 4 бита?
Здравствуйте, pagid, Вы писали:
P>Для начала стоило бы поговорить насколько операции с 64-разрядным IEEE-754 дороже операций с 32-разрядным IEEE-754. По быстродействию, количество транзисторов вряд ли стоит обсуждения. А уж потом говорить о том насколько интересен предлагаемый вариант.
Если реализация не явно урезана (по историческим причинам или от недостатка ресурсов), то:
— Сложение, вычитание, сравнение — времена равны (основные сложности всё равно идут не по длине).
— Умножение — ну процентов 10-20 разницы.
— Деление, квадратный корень — тут уже начинает сильно зависеть от алгоритма, но в общем в полтора раза.
Трансцедентные функции могут разниться сильно больше — например, на float32 хватит 3 членов ряда, а на 64 нужно уже 7, и все вычислять большей длиной... — может быть в 3-5 раз.
_>>режим 9 — до 1.34e+154 3.6 значащих цифр во float не представима _>>режим 13 — до 1e+2466 1.2 значащая цифра во float не представима _>>...
P>О какая красота! Процессор должен поддерживать этот зверинец, а программист обдуманно и с чувством выбирать какой именно вариант ему нужен для текущей задачи?
Я там спросил, но предполагаю, что речь идёт о длине поля regime bits (что задаёт смещение порядка и длину мантиссы). Тогда выбирать ничего не надо. Но кто знает... читать "спеку" от автора сложно — смешуёчков и дифирамбов больше, чем сути. Боюсь, одно это отвратит толковых читателей.
_>>Я излагаю свое мнение. Для обычных инженерных расчетов достаточно 4 значащих цифр. P>То есть для инженерных расчетов 32-разрядного IEEE-754 хватит с большим запасом. Неожиданный вывод, делающий предыдущие рассуждения и предложения бессмысленными, во всяком случае для обычных инженерных расчетов. _>>Для более точных моделей ничто не мешает использовать большую точность. P>64-разрядный IEEE-754 P>Но ради чего пыжились придумывая как скрестить ужа с ежом?
+1.
_>>И потом тут как всегда компромис: вам надо точно или быстро. P>Так все же насколько быстрее?
Для этого надо подождать и затем измерить образцовую софтовую реализацию в стиле berkeley-softfloat.
Я однако предполагаю, что с таким стилем мы этого не дождёмся...
Здравствуйте, pagid, Вы писали:
P>Здравствуйте, kov_serg, Вы писали:
_>>Здравствуйте, pagid, Вы писали:
_>>Очень просто передача между CPU и GPU P>Совсем не в теме про расчете на GPU. С какой точностью там принято считать с плавающей точкой?
Долго было только 32 бита. Сейчас массово добавлены 64 и местами 16.
Здравствуйте, netch80, Вы писали:
N>Я не смог однозначно понять, что эти "режимы" значат. В оригинальной pdfʼке автор разве что качучу вприсядку не танцует — стиль такой, что туда вставить пару десятков одесских анекдотов вообще ничего не изменит; но понять оттуда, чему равно в его предложениях, например, es для 32-битного числа — я тупо ниасилил. Если вы осилили, чему там предлагается сделать равным это es? И значит ли "режим N" в вашей таблице, что в числе ровно N так называемых regime bits?
Я взял es=2 для определенности.
У поситов есть еще интересное свойство
int32 px=posit32(x), py=posit32(y)
если px<py => x<y
если px==-px то это или 0 или inf
если px==0 => x=0
если px==0x80000000 => x=inf
Здравствуйте, LaptevVV, Вы писали:
MD>>C++ астрологи объявят неделю тайпдефов и макросов, не иначе LVV>А КТО ТАКИЕ с++ АСТРОЛОГИ? LVV>Кого ты к ним относишь?
Это мемчик из Героев Меча и Магии. Там в некоторые дни выскакивало сообщение "Астрологи объявили неделю X, количество Y увеличено вдвое"
