Comments 16
Тесты не от создателей формата есть?
А то "в некоторых случаях позволяют безопасно использовать 32-битные числа posit вместо 64-битных float" – явно требует звёздочки и расшифровки "на практике вы не столкнётесь с этими случаями". Про сравнение на 8-битной модели я вообще молчу.
Ну то есть я верю, что формат может быть лучше текущего стандарта, но в текущем не вижу такого уж огромного "запаса прочности" (кроме как для конкретных случаев, где он избыточен – и порой может быть заменён просто на fixed point). И интересно знать, стоит ли овчинка выделки (впрочем, пока с этим не определятся производители процессоров – это не так уж важно)
Here are a few extreme examples of inexact multiplications by2 or 0.5 in Posit8 (similar example can be found in Posit16 andPosit32):
1.03125 * 2.0 returns 2.0
10.0 * 2.0 returns 16.0
64.0 * 2.0 returns 64.0
0.015625 * 0.5 returns 0.015625
0.984375 * 0.5 returns 0.5
На самом деле легко понять, что у posit есть ощутимое преимущество из-за того, что огромная площадь (на квадрате декартова произведения области определения бинарной операции) отдана nan'ам. Т.е. в общем случае, бинарная плотность posit выше. Дальше, там очевидно, уже чуть-чуть вкусовщины на тему "что более важно представлять", но снижение числа потерянных значений — это безусловный и резкий плюс.
Плавная кривая нарастания погрешности мне тоже кажется разумной идеей.
Это у 8-битных float, которых нет в IEEE 754, много NaN. Доля NaN — очевидно, 1/2число бит порядка, т.к. у NaN все биты порядка единичные.
Плавная кривая нарастания погрешности — ужасно. Хотите умножить ~106 на ~10-6 — пожалуйста, ответ даже будет иметь много бит в мантиссе. Только младшие биты будут мусором, т.к. в сомножителях нет столько бит мантиссы.
Вы не по области определения сравнивайте, а по напрасно израсходованным битам (ну или по логарифму от числа "плохих" значений). Разница сразу окажется не такой большой.
Тезисно в двух словах некто Марк Рейнольдс написал:
WARNING: All of the following statements about posits are false:
- You can just treat them like reals and they will give good results.
- They are drop-in-replacements for IEEE.
- All tried-and-true methods will work just as well or better.
Let’s do some of that (roughly) define stuff shit:
- A well-conditioned problem is one where small changes in input result in small changes in output.
- an ill-conditioned problem is one where small changes in input result in large changes in output.
Что кажется и наблюдается в posit. Я так понял, что применять его можно, например в машинном обучении, но в основном, для измерений и точной науки вообще никак, так как можно напороться на ошибку, которая никак себя не проявит на этапе разработки… и ясно будет только когда ракета уже полетит не туда.
Теоретически, можно сделать так, что выход результата операции за определенный диапазон будет генерировать аппаратное исключение, и обработчик будет выводить необходимую диагностику.
Да нет, обусловленность — это свойство задачи, и устойчивость — это свойство задачи и алгоритма её решения. Густафсон подобрал несколько плохо обусловленных задач и предлагает их решать не очень устойчивыми методами. Но входные данные подобраны так, чтобы там появлялась разность двух близких чисел около 1, где у позитов на 3-4 бита больше.
Одна из проблем позитов в том, что любой из этих примеров умножить на что-то порядка 105 (или 10-5) — и точность позитов посыплется. А у IEEE, если не выходить в переполнение, сколько было значащих бит до масштабирования, столько и останется.
Для научных расчётов, в зависимости от задачи, позиты могут оказаться и лучше, и хуже. Были доклады, где на 16-битных позитах прогноз погоды считали, и даже более-менее адекватно.
Но меня неинвариантность по масштабу напрягает. Это означает, что для каждой решаемой задачи нужно будет подбирать свой масштаб, чтобы там появлялись цифры только около 1. А для сопряжения двух частей задачи нужно будет ещё как-то манипулировать с этими конвертирующими множителями, что у меня сразу в памяти поднимает Mars Climate Orbiter.
Кроме того, будет увлекательная конвертация между физическими единицами. Если, например, мне нужно перевести гигагерцы частоты в сантиметры длины волны для обсчёта какой-нибудь дифракции на препятствиях и в электронвольты энергии для обсчёта поглощения веществом — мне нельзя уже пользоваться фундаментальными константами, они слишком большие/маленькие и потому теряют точность. Мне каждый фактор нужно аккуратно выписать руками. Или иметь отдельные наборы арифметических операторов для флоатов и позитов, чтобы произведение постоянной Планка на скорость света до 8 десятичного знака считать на компьютере, а не на бумажке.
А так же есть ли готовые либы чтоб можно было быстро сравнить RTL дизайн FPGA просимулировав (обсчитав) его хтябы со скоростью операций умножений с накоплением миллиарда в секунду?
А то находится совсем мало инфы и то что сделано пока что выглядит очень монструозно:
repository.tudelft.nl/islandora/object/uuid:943f302f-7667-4d88-b225-3cd0cd7cf37c/datastream/OBJ/download
на Accumulator (Product) posit<32,2> потребление LUT & REG порядка 2.4к (догадываюсь что это единичный dot product вида «acc+=x*w»)
(взято из Table 4.1)
в другом источнике:
www.eee.hku.hk/~hso/Publications/jaiswal_date_2018.pdf
fig.2 — числа аналогичного порядка, около 2.4к
у FPGA среднего ценового диапазона есть внутри порядка 1-2к классических DSP блоков
и около одного миллиона REG&LUT при этом 100% использоваться нельзя, приближаясь к 100% скорость (Fmax) ОЧЕНЬ сильно проседает, поэтому для примера возьмём 750к,
т.е. это 300 эквивалентных DSP. И они работают на скоростях 100-125МГц.
Более того если даже у бюджетных старых FPGA типа Cyclone V есть варианты под 600 дсп блоков с частотой в 250мгц. А дсп блоки из fpga статей вообще реально запустить на 300 (хотя официально 480 и выше, но у меня столько терпения не хватало да и дедлайн он обычно существует).
Вывод: для FPGA они существенно дороже по ресурсам, скорости в разы ниже уже имеющихся DSP блоков.
В случае ASIC: для posit чисел нужен очень комплексный и многоуровневый barrel-shifter и/или мультиплексор, есть подозрения что они и в этом случае тоже будут существенно дороже floatpoint классических. А по скорости я даже в ASIC флоаты не реализовывал — опыта нет, судить не имею права.
Жаль источников всего несколько и нормальный мета анализ по статьям не провести и поэтому мои выводы трудно назвать качественными и более глубокие выводы бессмыслено делать.
posit имеет очень большой смысл применять для заметного сжатия памяти чтоб вся память используемая сеткой влезла в FPGA целиком и тогда можно получать сотни и тыщи FPS c latency меньше миллисекунды и даже сотен микросекунд (это ключевые и критические требования тз для индустрии и вооружений в нашей компании). Но и тут например если взять 16битную fixedpoint MobileNetv2 которая очень критична к квантизации и сложно ужать до 8 бит. То всё равно многие промежуточные буфера я смог сжать с 16 до 6 бит с потерей всего 0.5% точности простыми способами используемыми уже 30-40 лет в цифровой телефонии и потребляющие десятки LUT но не ТЫЩИ!!! как в случае с posit.
И вообще самая главная проблема не в точности а в скорости и объёме памяти: переход от DDR4 на HBM2 память даёт ускорение с пары сотен FPS до тысячь а в ряде случаев до десятков тысячь FPS потому что ВЕСЬ конвеер нейросети влазит в память и не нужно подгружать ничего динамически ради каждого кадра.
Posit-арифметика: победа над floating point на его собственном поле. Часть 2