Comments 72
Сдаётся мне, главная проблема posit – его евангелисты.
А в следующей статье будет про недостатки 512-битных Quire и двухкратное преимущество 1024-битных Quire+ :)
Вы почти угадали. Не знаю на счет 1024-битных Quire, но 2048-битные Quire существуют как эквивалент 64-битных Posit. Наверное, кому-то может быть нужна даже такая точность.
Хм, а есть формат BigQuire с произвольной точностью? Как BigInteger, только для чисел с плавающей точкой. Применение найдется: теоретическая математика, расчет фундаментальных констант типа PI и подобных.
Формат Posit не накладывает ограничения на размер чисел – можно начинать использовать хоть 2-битные posit (NaN, 0, 1, -1) и расти с масштабе до бесконечности.
И хотя большинство реализаций предполагают фиксированный размер используемого типа, преимуществом Posit как формата является то, что бинарное представление значения более низкой точности всегда является префиксом бинарного представления более точного значения. Так что да, Posit может расти как вектор в куче, произвольно долго накапливая точность одного и того же значения от итерации к итерации.
И хотя большинство реализаций предполагают фиксированный размер используемого типа, преимуществом Posit как формата является то, что бинарное представление значения более низкой точности всегда является префиксом бинарного представления более точного значения. Так что да, Posit может расти как вектор в куче, произвольно долго накапливая точность одного и того же значения от итерации к итерации.
А аппаратно это формат где-то поддерживается?
В массовом производстве пока нигде, и, честно говоря, пока этого не произойдет – нам как разработчикам нет особого смысла их использовать.
Насколько мне известно, пока существуют только наработки в комбинировании RISC-V и Posit. Основное применение – HPC.
Насколько мне известно, пока существуют только наработки в комбинировании RISC-V и Posit. Основное применение – HPC.
Можно посмотреть, есть ли реализации на verilog/vhdl и результаты синтеза/симуляции по ним (благо, сейчас средства разработки позволяют оценить доступную тактовую частоту).
Убедительной реализации Quire на Verilog/VHDL я не видел, но могу сказать что аналогичный подход (Kulisch exact accumulators) ранее уже был реализован и синтезирован для float, давая в 3-6 раз более высокую производительность с гораздо лучшей точностью.
Ждем поста в котором будет описано проектирование процессора для Quire на плис и сравнение в железе c процессором для Float.
В одной из прошлых статей была ссылка. Там пробовали это делать:
In our current implementation targeting FPGAs, summing two products of Posit32 in the hardware quire has more than 10x the area and 8x the latency of summing them using a posit adder and a posit multiplierЕсли еще учесть, что поситы сами по себе медленнее флоатов, то можно заключить, что идея использовать quire никуда не годится. И это не удивительно, ибо в современных ядрах половину площади занимают регистровые файлы, а самый дефицитный ресурс — это порты доступа к этому файлу. Сразу становится понятно, что увеличение разрядности в 16 раз на ровном месте ни к чему хорошему привести не может.
Если еще учесть, что поситы сами по себе медленнее флоатов...
Подождите секунду, какие именно Posit медленнее каких именно Float? Если мы заменяем 64-битные Float на 32-битные Posit, то сравнивать по производительности нужно именно их, и там уже все далеко не так однозначно.
Для реализации арифметики на Quire используются аккумуляторы Kulisch, которые в целом позволяют работать на той же тактовой частоте, что и обычные вычисления. Вы правы, ценой значительного увеличения площади вычислителей. Но для современных процессоров увеличение площади арифметики на фоне всего остального все равно потеряется в долях процентов.
На счет того, что Posit — это формат храниния данных — ОК, уяснили.
Но Quire — серьезно? Правильно ли я понимаю, предлагается завезти в процессоры 512-битные регистры (сейчас в пользовательском сегменте они есть только в ксеонах) и вместо векторных операций выполнять на них скалярные, с очевидно огромными latency потому-что 512 бит. Понимаю, для некоторых специальных ситуаций это имеет смысл, но в повседневных задачах точность float'ов лично меня не настолько беспокоит.
Но Quire — серьезно? Правильно ли я понимаю, предлагается завезти в процессоры 512-битные регистры (сейчас в пользовательском сегменте они есть только в ксеонах) и вместо векторных операций выполнять на них скалярные, с очевидно огромными latency потому-что 512 бит. Понимаю, для некоторых специальных ситуаций это имеет смысл, но в повседневных задачах точность float'ов лично меня не настолько беспокоит.
C latency не все так однозначно. Ключевая операция – a*b+c очень хорошо пайплайнится с помощью аккумулятора Kulisch, позволяя работать на той же тактовой частоте, что и обычные вычисления над float/posit.
Конечно, если сравнивать задержку одиного цикла a*b для Float и Quire, то ситуация будет не в пользу последних, не только из-за 512-битного регистра, но и из-за задержки на преобразование из/в Posit. Но для тех случаев, когда вычисления производятся по цепочке производительность скорее всего будет даже выше.
Таких ситуаций на самом деле множество. Самый типичный пример – сумма большего количества произведений. Используется буквально везде где необходимо умножение матриц – физика, machine learning и т.д.
Конечно, если сравнивать задержку одиного цикла a*b для Float и Quire, то ситуация будет не в пользу последних, не только из-за 512-битного регистра, но и из-за задержки на преобразование из/в Posit. Но для тех случаев, когда вычисления производятся по цепочке производительность скорее всего будет даже выше.
Таких ситуаций на самом деле множество. Самый типичный пример – сумма большего количества произведений. Используется буквально везде где необходимо умножение матриц – физика, machine learning и т.д.
из-за задержки на преобразование из/в PositСтоп, вроде же решили, что posit — это для компактного хранения? Так зачем все время конвертировать туда-сюда, лучше только при сохранении значения в память. Хотя, на фоне 512-битных операций конвертация, скорее всего, будет незаметна.
будет даже вышеЭто как это даже выше? Не вижу никаких предпосылок к тому, что бы 512-битные вычисления были быстрее 32-битных.
Так зачем все время конвертировать туда-сюда, лучше только при сохранении значения в память.Все время не нужно, но если делать бенчмарк с учетом чтения и записи в память и только с одной операцией, то конвертация будет отнимать значимое время.
Не вижу никаких предпосылок к тому, что бы 512-битные вычисления были быстрее 32-битных.А они есть. Обработка сабнормальных чисел и сдвиги при выравнивании экспонент обходятся не бесплатно, да еще и не паралелятся с остальными вычислениями. Вот вам пример из аналогичного подхода, реализованного для float (там даже 640 битные регистры):
The accelerator successfully saturates the SoC’s memory system, achieving the same per-element efficiency (1 cycle-per-element) as Intel MKL running on an x86 machine with a similar cache configuration.Такие регистры как правило делятся на слова, которые вычисляются отдельно, и благодаря этому хорошо пайплайнятся.
Новизна подхода в том, что используется два различных формата представления, один для хранения и передачи чисел – Posit, и другой для вычислений и их промежуточных значений – Quire.
Так вроде еще 8087 имел внутренние регистры по 80 бит. Так понимаю вся новизна в том что вместо 80бит расширяется аж до 512, ну да, свежо, современно :))
Дадада, то же самое хотел написать. ФПУ-стек 8087 состоит из восьми 80-битных регистров, которые потом ужимаются до 32/64. Так что по сути речь про ещё большее расширение (причем сразу так радикально, без потери точности) и другой формат упаковки. И вот в первом пункте есть проблема....
Вспомнил как программировал для 8087, само собой на ассемблере, ибо ни один компилятор тогда не мог нормально использовать все возможности сопроцессора. Собственно говоря, я не уверен, что даже сейчас можно было бы создать такой компилятор, который эффективно использовал стековую архитектуру 8087. А иначе действительно смысла нет в регистрах большей точности, если при каждой операции операнды из регистров преобразуются обратно в память в меньшую точность. Поэтому лично для меня Quire звучит как чистая теория малоприменимая на практике.
А иначе действительно смысла нет в регистрах большей точности, если при каждой операции операнды из регистров преобразуются обратно в память в меньшую точность.Смысла действительно мало, но при чем здесь стековая архитектура? Современные компиляторы достаточно умны, чтобы понимать что переменная совсем не обязательно должна занимать область в памяти и может жить только в регистрах.
А иначе действительно смысла нет в регистрах большей точности, если при каждой операции операнды из регистров преобразуются обратно в память в меньшую точность
Э, ну нет. Многие классические задачки отлично целиком помещаются на FPU-стеке, в пределах классических восьми регистров расширенной точности, и когда наружу в переупакованном виде выходит только результат — это хорошо (хотя само по себе такое программирование может быть изунряющим). Так что сама по себе идея правильная, и если регистров сделать больше, а компилятор научить их использовать, то вообще-то можно отлично жить.
Компилятор не в состоянии знать что от него ожидает разработчик — надо ли делать округление и где именно. Разные варианты могут давать разные результаты и не всегда попытка округлять как можно меньше даст правильный ответ.
Не понял, что вы хотели сказать и как это относится к написанному выше.
Компилятор нельзя «научить использовать quire / FPU-стек». Точнее сказать, ему можно разрешить это делать, но разработчик должен явно дать ему добро на это и понимать что результат может быть непредсказуем. В силу этого обычно на это идут не для повышения точности а наоборот — там где точность не очень важна. А для «повышения точности» — указывают порядок округлений вручную. Например оперируя long double в аккумуляторах и промежуточных значениях вычислений.
Все равно ничего не понял.
Мы выше обсуждали как раз тот факт, что если писать на ассемблере (или если есть умный компилятор), то некоторые вычисления могут делаться без выгрузки промежуточных результатов в память, при этом точность каждого числа в стеке FPU x87 — тот самый long double. И это многолетняя практика, следовательно идея длинных регистров Quire — по сути лишь совершенствование этой практики, кажется вполне эффективное (с чем не все выше согласны). С чем из написанного вы не согласны?
Мы выше обсуждали как раз тот факт, что если писать на ассемблере (или если есть умный компилятор), то некоторые вычисления могут делаться без выгрузки промежуточных результатов в память, при этом точность каждого числа в стеке FPU x87 — тот самый long double. И это многолетняя практика, следовательно идея длинных регистров Quire — по сути лишь совершенствование этой практики, кажется вполне эффективное (с чем не все выше согласны). С чем из написанного вы не согласны?
Если Вы пишете long double то компилятор использует стек x87. Если Вы пишете double, то компилятор обязан каждый раз округлять число до double. Аналогичным образом он обязан гарантировать строго тот порядок вычислений (и соответственно округлений после каждой операции) который Вы указали. Если компилятору разрешить делать операции (и следовательно округления) в другой последовательности или не делать округления вообще, то результат вычислений непредсказуемо меняется, иногда с очень забавными последствиями. Поэтому x87 регистры, собственно, обычно компилятором и не используются а в настройках x87 есть опция автоматического округления результатов FPU-регистров к double. С quire будет та же история — если long double не используют то quire тоже не будут.
Вот чертовщина какая-то, ей Богу: все, что вы пишете, я понимаю по сути (банальные вещи потому что), но какую в точности генеральную идею вы хотите высказать — не могу понять. :(
Единственная фраза, за которую я могу ухватиться — "если long double не используют то quire тоже не будут". Вы таким образом хотите сказать, что идея вычислений на увеличенных регистрах на самом деле не имеет соответствующей success story и стало быть Quire тоже не взлетит? Я правильно вас понял? Если да, то я должен заметить: вы свое утверждение базируете на постулате о том, что во-первых никто не юзает long double, и во-вторых компилятор С/С++ ничего не может сделать с предложенным ему кодом в части перестановки операций (и не может даже в том числе убрать «лишние» пересылки в память с соответствующим округлением). И если с первым я просто не согласен (ну, да, кому не надо — те не используют, много кто и double не использует), то второе — вопрос оптимизации. Повторюсь, немало вещей с использованием FPU-стека прямо на ассемблере херачилось, ну, потому что так надо, и получаемые результаты (в том числе эффекты округления) принимал на себя программист. Если мы постулируем, что создать достаточно умный компилятор невозможно (ну или мы не хотим этого во имя сохранения целостности некоторых базовых вещей), а кроме того любой программист с удовольствием пренебрежет такой возможностью в пользу более простого и переносимого кода, то тогда конечно и Posit/Quire не взлетит. Но это аргумент, знаете ли, из серии «и это тоже делать не надо, не взлетит, слишком революционно», так можно отказ от любых новшеств обосновать.
Единственная фраза, за которую я могу ухватиться — "если long double не используют то quire тоже не будут". Вы таким образом хотите сказать, что идея вычислений на увеличенных регистрах на самом деле не имеет соответствующей success story и стало быть Quire тоже не взлетит? Я правильно вас понял? Если да, то я должен заметить: вы свое утверждение базируете на постулате о том, что во-первых никто не юзает long double, и во-вторых компилятор С/С++ ничего не может сделать с предложенным ему кодом в части перестановки операций (и не может даже в том числе убрать «лишние» пересылки в память с соответствующим округлением). И если с первым я просто не согласен (ну, да, кому не надо — те не используют, много кто и double не использует), то второе — вопрос оптимизации. Повторюсь, немало вещей с использованием FPU-стека прямо на ассемблере херачилось, ну, потому что так надо, и получаемые результаты (в том числе эффекты округления) принимал на себя программист. Если мы постулируем, что создать достаточно умный компилятор невозможно (ну или мы не хотим этого во имя сохранения целостности некоторых базовых вещей), а кроме того любой программист с удовольствием пренебрежет такой возможностью в пользу более простого и переносимого кода, то тогда конечно и Posit/Quire не взлетит. Но это аргумент, знаете ли, из серии «и это тоже делать не надо, не взлетит, слишком революционно», так можно отказ от любых новшеств обосновать.
1. Вам не надо использовать ассемблер чтобы работать со стеком x87. Пишите long double и компилятор все отлично сам соберет
2. Тем не менее количество использующих long double мало.
3. Компилятор не имеет права выполнять описанную оптимизацию без явного одобрения программиста, т.к. это приводит к непредсказуемому результату. В лучшем случае у Вас программа собранная разными версии компилятора будет давать немного разный результат, в худшем — код который совершенно явно для программиста должен был давать число >= 0 сгенерирует отрицательное.
2. Тем не менее количество использующих long double мало.
3. Компилятор не имеет права выполнять описанную оптимизацию без явного одобрения программиста, т.к. это приводит к непредсказуемому результату. В лучшем случае у Вас программа собранная разными версии компилятора будет давать немного разный результат, в худшем — код который совершенно явно для программиста должен был давать число >= 0 сгенерирует отрицательное.
Вам не надо использовать ассемблер чтобы работать со стеком x87. Пишите long double и компилятор все отлично сам соберет
Речь не шла о том, что работать со стеком х87 можно только на ассемблере, но для эффективного его использования — людям приходилось. Как-то вот не всегда компилятор мог удачно расположить переменные в регистрах. Поэтому среди прочего поднимается вопрос о том, что в Quire должно быть побольше регистров.
Компилятор не имеет права выполнять описанную оптимизацию без явного одобрения программиста, т.к. это приводит к непредсказуемому результату
Вот это и есть предмет обсуждения, начатого этим постом. Типа (в определенных случаях) описанных неожиданностей с новым форматом должно стать меньше.
На ассемблере можно было только ускорить код, не более того. Результат должен был бы быть тем же а мы говорим именно о результате
Неожиданностей может быть меньше только если можно гарантировать какой-то новый детерминированных их порядок — к примеру, полное отсутствие округлений. Но для подавляющего большинства задач ожидать что результаты будут все время храниться в quire-регистрах нереально. Время от времени их понадобится выгружать в память и тут сразу возникнет вопрос — как гарантировать что выгрузки (и возникающие округления) будут детерминированными. У long double это хотя бы решается тем что ldouble таки туда выгружабелен, но если у quire такой возможности не будет, то компилятор просто не сможет не делать округления столкнувшись с нехваткой регистров.
Неожиданностей может быть меньше только если можно гарантировать какой-то новый детерминированных их порядок — к примеру, полное отсутствие округлений. Но для подавляющего большинства задач ожидать что результаты будут все время храниться в quire-регистрах нереально. Время от времени их понадобится выгружать в память и тут сразу возникнет вопрос — как гарантировать что выгрузки (и возникающие округления) будут детерминированными. У long double это хотя бы решается тем что ldouble таки туда выгружабелен, но если у quire такой возможности не будет, то компилятор просто не сможет не делать округления столкнувшись с нехваткой регистров.
На ассемблере можно было только ускорить код, не более того
Ну, не только. В зависимости от того, как в целях оптимизации разложены переменные по регистрам и как сделан алгоритм, пересылок в память (с округлением, если оно нужно) могло быть больше или меньше. Результат при этом конечно будет отличаться (если его эквивалентность — на самоцель, например).
Неожиданностей может быть меньше только если можно гарантировать какой-то новый детерминированных их порядок — к примеру, полное отсутствие округлений
И именно на это уповает автор поста.
Но для подавляющего большинства задач ожидать что результаты будут все время храниться в quire-регистрах нереально. Время от времени их понадобится выгружать в память и тут сразу возникнет вопрос — как гарантировать что выгрузки (и возникающие округления) будут детерминированными.
Ну выше как раз и говорится о том, что надо больше регистров богу регистров. И конечно вы правы, что когда-то их не хватит (да и за имеющиеся придется неслабо так заплатить), и тогда мы вернемся на круги своя.
У long double это хотя бы решается тем что ldouble таки туда выгружабелен, но если у quire такой возможности не будет, то компилятор просто не сможет не делать округления столкнувшись с нехваткой регистров.
И в конечном итоге потребуется некая оптимизация (коей по сути и является 64-битный Posit), чтобы все-таки и выгружать, и точность при округлении терять поменьше. То есть… ну, да, очередной long double получится, только более точный. Об этом и говорят те комментаторы, которые пишут про «те же яйца, только в профиль».
пересылок в память (с округлением, если оно нужно) могло быть больше или меньше
Пересылка в память ничего же не меняет в результате вычислений. Вот округление — меняет, но компилятор его сам вставлять не будет, поэтому если разработчик его явно не вставит то результат у компилятора будет тот же.
Пересылка в память ничего же не меняет в результате вычислений
Конечно. Но в обычной жизни оно сопровождается округлением (с 80 бит регистра до 64/32 бит в памяти). Я об этом говорил.
если разработчик его явно не вставит то результат у компилятора будет тот же
Я же говорил о сравнении сгенерированного компилятором и написанного урками ассемблерного кода.
Конечно. Но в обычной жизни оно сопровождается округлением (с 80 бит регистра до 64/32 бит в памяти). Я об этом говорил.
Не-а. В память можно 80-бит писать и компилятор именно FSTP в код вставит если там long double. Соответственно если программист явно не вставил округление (стал писать в 64 или тем более 32 бита) то у него результат будет тем же что у компилятора
В память можно 80-бит писать и компилятор именно FSTP в код вставит если там long double
Да, да, да — если там long double. Выше уже сто раз про это написали друг другу )))
у него результат будет тем же что у компилятора
Нет, не будет, банально потому, что он порядок вычислений на ассемблере по-другому сделает. Иначе зачем бы он вообще полез в ассемблер?
Нет, не будет, банально потому, что он порядок вычислений на ассемблере по-другому сделает
Порядок вычислений компилятор тоже не меняет
Иначе зачем бы он вообще полез в ассемблер?
Очевидно для того чтобы сделать код быстрее. Не точнее а быстрее. Точность же будет одной и той же. Возвращаемся к
На ассемблере можно было только ускорить код, не более того. Результат должен был бы быть тем же а мы говорим именно о результате.
Это я все в контексте «создания умного компилятора» пишу. Компилятор уже умный, там ничего нового появиться не может. А значит если long double используется редко то и quire едва ли будет большую полезность.
Порядок вычислений компилятор тоже не меняет
В моем сообщении «он» — программист. На ассемблере.
Очевидно для того чтобы сделать код быстрее. Не точнее а быстрее. Точность же будет одной и той же.
Не обязательно. Вот вы написали некий код, переменные таки объявили как long double, они легли в регистры, но порядок вычислений был один, стало быть и результат один. А потом вы написали аналогичный по сути алгоритм напрямую, и ради каких-то соображений об эффективности сделали другой порядок вычислений. Результат будем другим, хотя это все те же лонгдаблы (не углубляясь в то, когда это различие в результатах вообще станет значимым).
Если вдруг внезапно подвезли Quire, и делают сравнительные вычисления именно в нём, а не в Posit, т.е. по сути вычисления ведутся на самом деле с 512 бит точностью, то сравнивать это с вычислениями на прямую в float/double — не корректно. Эдак можно создать железку, которая будет так-же хранить числа в IEEE 754, а внутри иметь очень широкие регистры, к примеру те же 512 бит, и вычисления производить только в них.
Если сравнивать форматы корректно, то и нужно сравнивать честно — т.е. сопоставлять вычисления в float/double соответствующим Posit (именно posit, а не quire — с выгрузкой и последующей загрузкой значений в регистры при каждой математической операции).
Просто у IEEE 754 сейчас по сути нет аналога Quire. Хотя раньше что-то подобное было — до появления SSE, вычисления велись с 80-и битной точностью в регистрах математического сопроцессора, даже если в памяти числа представлялись 32/64-х битными.
Если сравнивать форматы корректно, то и нужно сравнивать честно — т.е. сопоставлять вычисления в float/double соответствующим Posit (именно posit, а не quire — с выгрузкой и последующей загрузкой значений в регистры при каждой математической операции).
Просто у IEEE 754 сейчас по сути нет аналога Quire. Хотя раньше что-то подобное было — до появления SSE, вычисления велись с 80-и битной точностью в регистрах математического сопроцессора, даже если в памяти числа представлялись 32/64-х битными.
Если вдруг внезапно подвезли Quire, и делают сравнительные вычисления именно в нём, а не в Posit, т.е. по сути вычисления ведутся на самом деле с 512 бит точностью, то сравнивать это с вычислениями на прямую в float/double — не корректно.Отчасти согласен, но тут важно понимать, что Quire – часть стандарта Posit, а для Float любая поделка в этом направлении будет собственным велосипедом.
Эдак можно создать железку, которая будет так-же хранить числа в IEEE 754, а внутри иметь очень широкие регистры, к примеру те же 512 бит, и вычисления производить только в них.Можно, только регистры прийдется делать не 512-битными, а уже 640-битными. Проблема в том, что формат представления Float не очень хорошо подходит для реализации «Quire для Float».
Отчасти согласен, но тут важно понимать, что Quire – часть стандарта Posit, а для Float любая поделка в этом направлении будет собственным велосипедом.
Ну раньше примерно так и было — все вычисления внутри процессора велись в 80-и разрядных регистрах с плавающей запятой(а не fixed point). Но когда пришло время SSE2, то решили, что скорость вычислений гораздо важнее точности, для процессоров массового потребительского сегмента. Для 3D игрушек, рендеринга и прочего — достаточно.
Для игрушек и рендеринга я бы рассмотрел Posit16 – диапазон значений 2^-28...2^28, размер Quire – всего 128 бит, точность будет скорее всего выше чем у Float32, а гонять по периферии нужно в два раза меньше данных.
1) Если будем молотить 128-и битными регистрами — то встанет вопрос о скорости, энергопотреблении и размерах кристалла с его ценой. К примеру, соверемнные процессоры имеют в регистрах место для 16*8=128 float чисел, всего 4096 бит регистровой памяти, а с Quire будет 16 384 бит. А стоит ли оно того? Это ещё вопрос дискуссионный.
2) Если вспомнить рекламное описание Posit, о том что Posit вдвое меньшего размера сопоставим с float/double — то там говорилось, что «сопоставим в определённых use cases», т.е. далеко не всегда. Если говорить о 3D играх, то там с float на расстояниях ~16км от центра координат, уже начинают наблюдаться серьёзные погрешности, вполне отличимые на глаз. Posit как мы знаем, более точен чем float (при одинаковом размере, скажем 32 бита) как раз возле центра координат, а не на периферии. Как с этим будут обстоять дела у Posit?
3) Из-за того, что указано в п.2, по сути не получится использовать Posit16 там где используется Float32, кроме узко специализированных случаев (к примеру нейросетей).
Из-за всего вышеперечисленного делаю вывод, что этот Posit — в чём-то лучше, в чём-то хуже чем IEEE 754, но преимущества не так уж значительны. А всё остальное лишь волна хайпа.
2) Если вспомнить рекламное описание Posit, о том что Posit вдвое меньшего размера сопоставим с float/double — то там говорилось, что «сопоставим в определённых use cases», т.е. далеко не всегда. Если говорить о 3D играх, то там с float на расстояниях ~16км от центра координат, уже начинают наблюдаться серьёзные погрешности, вполне отличимые на глаз. Posit как мы знаем, более точен чем float (при одинаковом размере, скажем 32 бита) как раз возле центра координат, а не на периферии. Как с этим будут обстоять дела у Posit?
3) Из-за того, что указано в п.2, по сути не получится использовать Posit16 там где используется Float32, кроме узко специализированных случаев (к примеру нейросетей).
Из-за всего вышеперечисленного делаю вывод, что этот Posit — в чём-то лучше, в чём-то хуже чем IEEE 754, но преимущества не так уж значительны. А всё остальное лишь волна хайпа.
Сразу говорю, что я не эксперт в графике, но позволю себе порассуждать:
Основной пожиратель энергии, как правило – это память и передача данных. Насколько я понимаю, для видеокарт это даже более актуально, чем для процессоров. Так что повышенное потребление на вычислениях должно с лихвой компенсироваться в 2 раза меньшими объемами данных. То же самое и с площадью – получается что нам нужно в 2 раза меньше видеопамяти для тех же вычислений (ценой увеличения площади вычислителей). Тут нужно смотреть какое соотношение площади в видеокартах.
Не совсем понимаю, чем именно вызываются погрешности, чтобы точно ответить на ваш вопрос. Если погрешностями вычислений – то quire должны радикально решить этот вопрос. Если погрешностями представления значений, то стандарт предполагает, что Quire можно представить в виде суммы одного, двух или трех Posit. При этом с каждым шагом точность возрастает радикально. Я думаю что для специфических случаев это можно использовать.
Если будем молотить 128-и битными регистрами — то встанет вопрос о скорости, энергопотреблении и размерах кристалла с его ценой.Скорость должна быть высокой, при правильной реализации, потому что fixed-point арифметика хорошо пайплайнится – нам не нужны все 128 бит результата для того чтобы начать вычислять следующую операцию. Если разбить вычисления на 4 шага по 32 бита, то появится небольшая общая задержка, но общая производительность будет выше (как 32-битные integer против 32-битных float).
Основной пожиратель энергии, как правило – это память и передача данных. Насколько я понимаю, для видеокарт это даже более актуально, чем для процессоров. Так что повышенное потребление на вычислениях должно с лихвой компенсироваться в 2 раза меньшими объемами данных. То же самое и с площадью – получается что нам нужно в 2 раза меньше видеопамяти для тех же вычислений (ценой увеличения площади вычислителей). Тут нужно смотреть какое соотношение площади в видеокартах.
Если говорить о 3D играх, то там с float на расстояниях ~16км от центра координат, уже начинают наблюдаться серьёзные погрешности, вполне отличимые на глаз. Posit как мы знаем, более точен чем float (при одинаковом размере, скажем 32 бита) как раз возле центра координат, а не на периферии. Как с этим будут обстоять дела у Posit?
Не совсем понимаю, чем именно вызываются погрешности, чтобы точно ответить на ваш вопрос. Если погрешностями вычислений – то quire должны радикально решить этот вопрос. Если погрешностями представления значений, то стандарт предполагает, что Quire можно представить в виде суммы одного, двух или трех Posit. При этом с каждым шагом точность возрастает радикально. Я думаю что для специфических случаев это можно использовать.
Из-за того, что указано в п.2, по сути не получится использовать Posit16 там где используется Float32, кроме узко специализированных случаев (к примеру нейросетей)Для нейросетей хватает даже 8-битных posit (с quire), в большинстве случаев.
Вы совершенно упустили из виду п.2 — Posit16 эквивалентен Float32 далеко не всегда. Так что в общем случае всё равно придётся использовать Posit32 там где используется Float32. Т.к. posit16 может выдать в любом случае не более 16 бит информации, в то время как в float32 только мантисса уже 24 бита.
И да, речь идёт именно о представлении в памяти, а не о вычислениях внутри процессора, т.к. когда речь идёт о многих тысячах или миллионах точек в виртуальном пространстве — у процессора просто не может быть такого количества регистров.
Таким образом утверждения об экономии на передаче данных — не более чем маркетинг, и актуально только для узкого круга специфических вычислений. Но мы же как всегда, видим жёлтый заголовок новости, о том что Posit16 эквивалентен Float32, видим только это и верим, забывая что это утверждение истинно только для узкого круга задач, а не везде.
Самый большой куллер в системнике, стоит на процессоре, а на памяти вообще нет вентилятора… Это как бы должно вызывать вопросы…
И да, речь идёт именно о представлении в памяти, а не о вычислениях внутри процессора, т.к. когда речь идёт о многих тысячах или миллионах точек в виртуальном пространстве — у процессора просто не может быть такого количества регистров.
Таким образом утверждения об экономии на передаче данных — не более чем маркетинг, и актуально только для узкого круга специфических вычислений. Но мы же как всегда, видим жёлтый заголовок новости, о том что Posit16 эквивалентен Float32, видим только это и верим, забывая что это утверждение истинно только для узкого круга задач, а не везде.
Основной пожиратель энергии, как правило – это память и передача данных.
Самый большой куллер в системнике, стоит на процессоре, а на памяти вообще нет вентилятора… Это как бы должно вызывать вопросы…
Т.к. posit16 может выдать в любом случае не более 16 бит информации, в то время как в float32 только мантисса уже 24 бита.Представление одного значения в виде суммы двух posit16 дадут вам те же самые 32 бита информации, а мантиссу вплоть до 28 бит, поскольку quire представляется в виде суммы нескольких posit не абы как, именно так чтобы дать максимальную точность.
При этом в тех случаях где такая точность не нужна, можно вполне обойтись одним значением. Обратите внимание, что такой подход требует минимальной дополнительной логики в железе, в отличии от одновременной поддержки float16/float32/float64.
И да, речь идёт именно о представлении в памяти, а не о вычислениях внутри процессора, т.к. когда речь идёт о многих тысячах или миллионах точек в виртуальном пространстве — у процессора просто не может быть такого количества регистров.Я предполагаю, что эти точки обрабатываются последовательно, и потому не так уж важно тысячи их или миллионы – все равно вам достаточно будет разумно конечного количества регистров. В конечном итоге нас интересует проекция всех этих точек на экран, и тут размерности и точности одного posit16 должно хватить вполне.
Но мы же как всегда, видим жёлтый заголовок новости, о том что Posit16 эквивалентен Float32, видим только это и верим, забывая что это утверждение истинно только для узкого круга задач, а не везде.Аналогичными словами я закончил и свою статью. Я даже не сомневаюсь что есть задачи, где float будет вести себя лучше именно из-за своих характеристик.
Самый большой куллер в системнике, стоит на процессоре, а на памяти вообще нет вентилятора… Это как бы должно вызывать вопросы…Тут вы делаете неверные выводы. Куллер стоит на процессоре потому что там самая высокая плотность транзисторов с частыми переключениями. Так что плотность энергопотребления – выше, а само энергопотребление – не факт. И нужно учитывать потребление не только самой памяти (хранение информации), но и ее передачи, за которую отвечает в том числе процессор (и вся его иерархия кешей).
Представление одного значения в виде суммы двух posit16 дадут вам те же самые 32 бита информации, а мантиссу вплоть до 28 бит, поскольку quire представляется в виде суммы нескольких posit не абы как, именно так чтобы дать максимальную точность.
Т.е. так и есть — в общем случае там где был Float32, будет Posit32. И ни какого выигрыша по передаче данных.
Там где Posit16 сопоставим с Float32 — там да, выигрыш есть, но это специфические случаи. Для тех-же радиоастрономов, передающих гигабиты измерений в секунду по своим кластерам, оно актуально. Или для нейросетей. Но это не о процессорах общего назначения и массового сегмента, это специфические задачи, и для специфических задач, специальная аппаратура и специальные форматы данных действительно дают лучший результат. Для этих целей Posit хорош.
При этом в тех случаях где такая точность не нужна, можно вполне обойтись одним значением. Обратите внимание, что такой подход требует минимальной дополнительной логики в железе, в отличии от одновременной поддержки float16/float32/float64.
Нативная поддержка форматов float16/float32/float64 в кремнии делается для максимизации производительности вычислений. Если речь должна идти о максимизации точности вычислений, то внутри себя процессор может оперировать одним вычислительным конвеером шириной 64 бита, или даже больше, не зависимо от входного формата данных, собственно как и было раньше, пока Intel не выпилила математический сопроцессор, оставив только SSE/AVX.
Я предполагаю, что эти точки обрабатываются последовательно, и потому не так уж важно тысячи их или миллионы – все равно вам достаточно будет разумно конечного количества регистров. В конечном итоге нас интересует проекция всех этих точек на экран, и тут размерности и точности одного posit16 должно хватить вполне.
Именно важно точное и равномерное их местоположение в виртуальном обширном пространстве, и тут posit16 уже окажется недостаточен. И ряд трансформаций с перемножениями матриц 4x4 (координата точки, координата и направление камеры и комбинация их погрешностей, Quire здесь не спасёт, т.к. погрешности уже в представлении чисел), тоже должен обладать высокой точностью, перед тем как точки окажутся в screen space координатах, где да, posit16 уже достаточно, но там это уже по сути не имеет значения.
Тут вы делаете неверные выводы. Куллер стоит на процессоре потому что там самая высокая плотность транзисторов с частыми переключениями. Так что плотность энергопотребления – выше, а само энергопотребление – не факт.
Самая главная печка — блок вычислений SIMD, а не память, как только он включается на полную — начинается ад и пекло :)
И да, очень много энергии тратится внутри процессора на передачу данных — но внутри процессора, на конвейерах вычислений и не будет уже posit-а с его плюшками. Там будет суровый мегатранзисторный ад.
А самый главный профит от posit-а декларируется именно на передаче данных между вычислительными узлами по сети в кластерных вычислениях, и только в тех узких задачах где это применимо.
А в общем случае, Posit не является уж сильно лучше, чем IEEE754. Здесь больше фанатизма чем здравого анализа, и честного не эмоционального подхода.
Самая главная печка — блок вычислений SIMD, а не память, как только он включается на полную — начинается ад и пекло :)Подозреваю, что это связано с тем, что выполнение SIMD требует чтения 512 бит из памяти на операцию, а значит и более агрессивного обновления кешей.
На одно переключение транзистора в кэше ЦП, при вычислениях будут десятки, если не сотни переключений транзисторов в конвейере вычислений. Так что хоть и кэш является очень громоздкой и тяжёлой по энергопотреблению конструкцией в ЦП, но далеко не он является главным по энергопотреблению вообще.
У вас прочно засел в сознании маркетинговый хайп, что Posit16 == Float32. Хотя это вообще то не так, за исключением редких и специфических случаев. В общем случае можно рассматривать, что Posit32 == Float32, при том, где-то лучше, где то хуже.
На мой взгляд единственными недостатками IEEE754 по сравнению с Posit как формата данных, является то, что -0 != +0, и достаточно широкое пространство NaN. Всё остальное хайп и фанатизм. И стоит ли оно того, что бы переворачивать всю индустрию с ног на голову — вопрос очень спорный. Но это не значит, что Posit для нас вообще не нужен — он будет с успехом использоваться, там где действительно того стоит, в специфических научных вычислениях, в нейропроцессорах и т.п., т.е. займёт свою специализированную нишу.
У вас прочно засел в сознании маркетинговый хайп, что Posit16 == Float32. Хотя это вообще то не так, за исключением редких и специфических случаев. В общем случае можно рассматривать, что Posit32 == Float32, при том, где-то лучше, где то хуже.
На мой взгляд единственными недостатками IEEE754 по сравнению с Posit как формата данных, является то, что -0 != +0, и достаточно широкое пространство NaN. Всё остальное хайп и фанатизм. И стоит ли оно того, что бы переворачивать всю индустрию с ног на голову — вопрос очень спорный. Но это не значит, что Posit для нас вообще не нужен — он будет с успехом использоваться, там где действительно того стоит, в специфических научных вычислениях, в нейропроцессорах и т.п., т.е. займёт свою специализированную нишу.
GPU оптимизирована для вычислений с 4-мерными векторами из 32-битных float
Основное место на кристалле занимают регистры (4-мерные) и АЛУ (для 4-мерных операндов)
Если заменить АЛУ и регистры из 4х32 бит на 4х512 бит то энергоэффективности это не повысит никак
На мобилках вообще рекомендуют использовать для вычислений на gpu half (float16) потому что они энергоэффективны и на мобилках это важно (время работы от батареи, throttling). И речь тут именно про вычисления, не текстуры и т.п. память (текстуры в подавляющем большинстве случаев вообще 8 бит на канал fixed-point)
Основное место на кристалле занимают регистры (4-мерные) и АЛУ (для 4-мерных операндов)
Если заменить АЛУ и регистры из 4х32 бит на 4х512 бит то энергоэффективности это не повысит никак
На мобилках вообще рекомендуют использовать для вычислений на gpu half (float16) потому что они энергоэффективны и на мобилках это важно (время работы от батареи, throttling). И речь тут именно про вычисления, не текстуры и т.п. память (текстуры в подавляющем большинстве случаев вообще 8 бит на канал fixed-point)
Для графики posit может и зайдет, а вот quire совершенно бесполезен. На GPU и 64-bit float используют только в научных вычислениях на high-end видеокартах.
Так ведь никто не мешает взять Posit меньшей битности, чтобы точность была примерно такой же, а объем данных меньше (см. мой ответ автору выше). Вполне себе могу представить ситуацию, что видеокарты на posit показывают лучше производительность. Другой дело, чтобы это дошло до массового использования нужно всего лишь обновить весь стек от самого нутра железа, компиляторов и до игровых движков с учетом специфики Posit.
Если posit идет в связке с quire, то не покажут posit-вычисления лучшую производительность никогда. Касаясь нашей дискуссии, можно достигнуть лучшей производительности путем уменьшения нагрузки на шину памяти за счет упаковки данных (а во избежание потери точности использовать posit-формат), и можно достигнуть большей точности за счет выполнения многобитных вычислений в по quire-принципу. Так вот я говорю, что если первая идея в некоторых ситуациях может оказаться здравой, то вторая в принципе невозможна без серьезной деградации общей производительности видеопроцессора, которая в современных реалиях графических приложений не стоит даже идеально точных вычислений. Но, еще раз, это я говорю о GPU. Если речь идет о центральном процессоре, то это вполне можно добавить как дополнительную возможность, главное что бы это не мешало основным инструкциям.
UFO just landed and posted this here
Не проще ли использовать целочисленную арифметику, если так уж нужна точность? Ну или — целочисленные дроби?
Целочисленная арифметика — это ад для программиста, т.к. цены мл. разрядов операндов надо выравнивать вручную.
UFO just landed and posted this here
не очень понимаю, почему ад для программистов именно именно, я думал — ад для математиков-вычислителей
Ну мну с фиксированной запятой познакомился будучи программистом на "автокоде" — аля асм с выхлопом в виде бинарника, очень весело было пересобирать все (и всем), после того как математики диапазоны чисел уточняли :)
Внезапно, quire – это и есть целочисленная арифметика (на самом деле с фиксированной точкой, но большой разницы я тут не вижу), как раз на случай, когда «так нужна точность».
UFO just landed and posted this here
И переформулировка задач в целочисленных терминах очень трудна и не всегда возможна.
Я бы сказал, почти всегда невозможна, потому что точные вычисления замкнуты только относительно примитивных операций: +, -, *, /. Как, например, без потери точности взять sqrt(2) или sin(pi/ 4)? А такие операции сплошь и рядом в компьютерной графике.
Может тогда сразу в аналитические вычисления перейти, где корень будет представляться именно корнем, а не приблизительным числом.
Думаю, исходя из арифметики вычисления корней, вопрос нужно ставить по-другому, т. к. точность вычислений напрямую зависит от количества разрядов дробной части (зависит и Muller's Recurrence в комментах ниже). Математики говорят: "
прямоугольник изоляции".По-моему описываемый quire полностью ортогонален posit. Я с тем же успехом могу заявить что float-ы обеспечивают long double точность, т.к. я могу в качестве аккумулятора использовать стек x87 и ошибка округления возникнет лишь на этапе записи посчитанного в память. Имхо — это бред. Идея quire вполне обсуждаема, но явно независимо от posit-ов.
Не совсем ортогонален. Для Float и Double точные аккумуляторы требуют 640 и 4288 бит регистров, а для Posit32 и Posit64 – только 512 и 2048 соответственно. Конечно, вычислять можно с произвольной точностью на произвольно больших регистрах, но еще есть вопрос как хранить значения с минимальной потерей при сжатии. У тут float не лучший вариант, поскольку создавался как компромис между эффективностью хранения и эффективностью вычислений.
Я провел эксперимент для IEEE 754 с одинарной и двойной точностью, а также для 32-битных Posit+Quire. Вычисления проводились в арифметике Quire, но каждое значение в таблице преобразовано в Posit.
Я правильно понял — в самом вычислении Posit вообще никак не участвовал? просто вместо того, чтобы сразу привести Quire к символьному виду, вы его сначала преобразовали в Posit? Но почему вы не сделали того же самого с float и double? Опять на подтасовку фактов смахивает.
И все таки, было бы интересно посмотреть на таблицу сходимости рекуррентного соотношения Мюллера, при расчёте на чистом Posit. Сдаётся мне, что сдадутся они ещё раньше.
Делал уже:
4.47059
4.64475
4.77073
4.85972
4.99343
6.59878
30.0151
88.4203
99.3479
99.9673
99.9984
99.9999
100
100
100
4.47059
4.64475
4.77073
4.85972
4.99343
6.59878
30.0151
88.4203
99.3479
99.9673
99.9984
99.9999
100
100
100
Эта сеть телескопов генерирует 200 петабайт данных в секунду
ну для таких случаев всякие хитрые оптимизации могут понадобиться, а тем кто не числодробилки делает может уже на рациональные числа можно переходить? Они Мюллера не бояться, правда производительность в реальности трудно измерить.
Вы не могли бы выложить в открытый доступ код с тестом формулы Мюллера?
Во-первых, хотелось бы увидеть как правильно делать вычисления на posit/quire
Во-вторых, это позволит интересующимся поиграться с новым форматом.
Sign up to leave a comment.
И все-таки, почему Posit являются достойной альтернативой IEEE 754