Как использовать возможности сопроцессора на 100% ?
Почему long double 64 bit?
А не 80 как было в "отсталом" DOC'е
Теряется и точность и скорость.

какой компилятор? какие настройки?

если компилировать под x86 Debug, то:
sizeof(long double)=10
sizeof(double)=8
sizeof(float)=4

если под P-III SSE или AMD 3DNOW, то выгодней использовать float
если под P-IV SSE2, то double (64-бит)

Для совместимости.
Очень хорошая публикация по этому поводу. Посмотрите также линки, прведённые автором - там ещё больше по спецификациям IEEE. Можете почитать ещё это.

pva
MSVC 6.0
void main()
{
  printf("s= %d %d", sizeof(double), sizeof(long double));
}  
results:
s= 8 8
(debug & release)

Не понял что значит выгодней?
Как записать число, ну допустим 2.7 e+1000
Да и не в только порядке дело, значащих цифр меньше тоже.

hasherfrog
Из первой Вашей ссылки:
И дальше, как я понимаю, описывается как этот "нехороший формат" превратить в "хороший" double

Вы меня не поняли.
Мне нужны мат функции работающие с long double 80
sin, cos, log, etc...
Может либа какая-есть?
Можно конечно написать в старом компиляторе 16-разрядную длл со всей математикой, но согласитесь, это похоже на чесание левой рукой за правым ухом.

bilytur
То есть конвертнуть из 80-битного в 64-битное, а потом уже с этим работать - это Вам не подходит?

hasherfrog
Нет. Не подходит.
Я просто хотел использовать возможности железа на 100%
А это как раз 80 битный формат сопроцессора.
Повышенная точность, больший диапазон чисел, ну и скорость.
Не нужно постоянно конвертировать double <=> 80bit
(Ну по крайней мере для x86 это так.)

Удивительно что в Win32 это убрали.
В досе, как я уже говорил это было.
В Паскале например этот тип кажется назывался extended
Может в делфе он и сейчас поддерживается?
Надо спросить у делфистов...

Искал в интере, есть какая-то либа, но скачать только за тугрики. :(
Под *nix правда много что есть. Но мне надо под Win 32.
Еще советуют фортран. :(  
Интеловский компилер по идее должен поддерживать.
Только что пришло в голову.
Попробую поискать.

bilytur
дело в том что с появлением ММХ это уже не так, сейчас регистры для работы с плавающей запятой 64 битные, так что быстрее теперь 64бит доубле.

Vlad Drakula
а ты SSE/SSE2 и 3DNow! учитываешь? ;)
Как ни странно, это ЦЕЛОчисленные расширения.... :wink:


[s]Исправлено: bgg0408, 1:13 21-06-2004[/s]

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

Vlad Drakula
Так сразу и начал бы о них и говорить!
MMX все-таки не SSE.
Согласен. Открываем Гука (или аналогичную книгу) и начинаем читать :)

А если прога должна работать на любом компе, начиная с 486
Быстродействие в принципе не так важно.
(Я пишу калькулятор, важнее точность.)
Есть же мат сопроцессор.
Хотелось бы его использовать.
И имхо не так уж он и медленно работает.
Или в MMX компах его уже нет?

Для информации: Кратко об MMX, SSE, FPU

bilytur
если нужно точность то писать нужно не на С.
я бы посоветовал выбрать какойнибеть другой язык.
в принципе доубле обеспечивает точность до 12 знаков после запятой.

сопроцессор, как отдельная викросхема, был до 486, с появлением пней сопроцессор стал не отемлемой частью ядра.
т.к. место в центре кристало очень дорого, решили обрезать доубле до 64 бит т.к. почти никто не пользовался другими.

bilytur
для вычислений сбольшой точностью есть специальные библиотеки "бесконечной точность" или библиотеки символьных вычислений, их задача исенно в том чтобы обеспечить большую точность, но быстродействие у них не велико!

Сопроцессор есть в любом современном компе. Он "интегрирован" в сам процессор. До 486, как правильно заметил Vlad Drakula, процы и сопроцессоры выполнялись в виде двух отдельных модулей.

Vlad Drakula
А на чем же? Можно написать и на Си, лишь бы терпения хватило ;)

bgg0408
для выполнения вычислений с повышенной точность есть другие языки, напимер фартран.

С изначально не расчитавался как язык для мат вычислений.
т.е. это быстрый язык(если так можно выразиться), но это не его стихия.

если писать беблиотеку символьных вычислений самому с нуля, да еще на чистом С... то тут действительно нужно много терпения!

Из статьи от hasherfrog
И все-таки жаль что нельзя это использовать. (в С под Win32)
(На других языках или других платформах этого запрета нет.)

Vlad Drakula
Да мне уже предлагали. Спасибо.
Или С, но тогда под ДОСом.  На выбор. :)

Вобщем проблему свою я решил несколько другим способом. (Нашел линуковскую либу, в исходниках. портанул под вин32, вроде скомпилилась и работает.)

Всем большое спасибо.

Дело было немного по-другому, имхо: по шине дано было гонять эти регистры, а она 64-бита. Экономили скорее не место, а скорость (коряво сказал как-то).
Но это детали, главное, что bilytur решениевроде бы нашёл. Только вот я не совсем понял...
bilytur
А чем компилил? MVC, BC, GNU C??? Что, при компиляции появился новый тип данных? Или там в исходниках полно ассемблерного кода?

Vlad Drakula
Ты не прав. Ты знаешь почему используют ФОРТРАН дял вычислений? Не потому, что это "супер-пупер" язык. Просто много модулей уже написано на нем :( Вот и юзают :(
Можно сделать так:
у нас есть массив char'ов. Каждый элемент - цифра. Складываем два массива => получаем третий с суммой. так можно построить математическую библиотеку. Правда, расход памяти большой, зато просто.

hasherfrog
мультипрецижн арифметик:
http://www.swox.com/gmp/

Точность в принципе любая, написан на чистом С (не ++) и асме
Что обрадовало - не фортран.
Я в принципе не против фортрана, просто сейчас я изучаю С/++
Распыляться не хотелось. Да и считаю С языком на котором можно
написать все что угодно. И даже математику. :) . имхо

Вообщето к FPU это отношения не имеет. Но данный вариант меня устраивает
даже больше.


Добавлено:

А да, компилил mingw

У меня никогда проблем не возникало. Если я компилирую под x86, и ставлю флажок "не эмулировать FPU", то всегда используется сопроцессор с полной точностью (80 бит). Если под P-4 SSE2, то иногда, когда компилятор посчитает нужным, используются регистры XMM с точностью 64 бит.
Я использовал Borland C++ Builder 3, 4, 6, Borland C++ 5.02, Intell C++ Compiler 6.0, Metrowerks CodeWarrior 8.0.

О балансе совместимости и быстродействия.

Любой процессор архитектуры IA-32 (т.е. начиная с i486) имеет сопроцессор, который умеет работать с 80-бит long double. Если речь идёт о совместимом софте под винду, то можно смело использовать сопроцессор на полную точность. Если хочется при этом побыстрее - некоторые процессоры работают быстрее с 32-бит float (поэтому его использует Direct3D). При этом нужно делать сопроцессору специальное (программное) переключение. Понятно, что точность при этом резко упадёт. Если планируется использовать функции трансцендентные сопроцессора (sin, cos, ...), то забудьте о скорости. Они считаются сотни тактов (на максимальной точности).
Любой компилятор под x86 должен отводить под long double 80 бит.

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

Большую роль играет align. Intel рекомендует укладывать long double по 16 байт.

Если хочется выйти за машинную точность, пробуйте эмулировать сопроцессор.

Расширения процессора SSE и SSE2 работают с плавающей арифметикой. Ускорение достигается за счёт одновременного вычисления однотипных операций и на разных модулях параллельно. SSE работает с float, SSE2 - с double. Трансцендентные функции не сделаны, поэтому intel предлагает либо считать их на сопроцессоре, либо в рядах на SSE (на сайте есть библиотека с исходниками).

bilytur
Все правильно. Для арифметики повышенной точности необходима спец.библиотека. Т.к. "80-байтные плавающие" являются внутренним форматом FPU. А сам FPU имеет только команды загрузки из- и сохранения в память таких данных. Этот внутренний формат используется как раз для того, чтобы потеря точности при вычислениях double и float была минимальной, когда в FPU появляются какие-нибудь промежуточные результаты, за счет увеличенной длины мантиссы и порядка. Младшие биты мантиссы результата получаются точнее.  :)

Или использовать его, но немного по-другому :)
Т.е. писать (или юзать) библиотеку расчетов...
А почему 3DNow! не рассматривается? Он тоже предлагает расширения плавающей арифметики. А недавно еще SSE3 вышел в массы.

pva
У меня msvc, у него этого нет. у mingw тоже.
Хотя вопрос в принципе решен, остался академический интерес.
Из вышеперечисленных компилеров где-то лежит инсталятор Borland C++ 5.02. Будет время (на днях) попробую.
Хотя ... Только что распаковал справку там 64 бит. Про 80 почему-то ни слова. ?
bgg0408
Это все очень интересно. Но прога должна работать на максимально-возможном кол-ве компов.
Вы посмотрите минимальные требования у коммерческих прог.
(супер игры не в счет).
Winamp (к примеру) работает на 486 DX100 (Сам видел!)
А уж для простого калькулятора требовать 3DNow! и SSE3 это уже снобизм. :)

bilytur
Согласен и поддерживаю. Но
1) ММХ есть на всех современных и не очень машинах (до пня133ММХ). Остальные уже слишом сильно устарели. Или Вы не согласны?
2) а уж коли вводите поддержку SSE/SSE2, то не забудьте 3DNow!: обижаете АМДшников.
3) реализуем поддержку DLLек с оптимизациями под конкретный проц. Юзер - не ламер, знает, что внутри ящика и выберет нужный. Или всегда должен быть "софтваре", т.е. эмуляция
А вот это Вы не правы!!! W2kSP3 и IE6 для них минимум.
и простите за настойчивость меня, нескромного человека, сидящего на АМДшном проце и Интеловском чипсете :)

[s]Исправлено: bgg0408, 7:00 1-07-2004[/s]