[bilytur]

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

[hasherfrog]

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

[Vlad Drakula]

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

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

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

[bgg0408]

Есть же мат сопроцессор. Хотелось бы его использовать. И имхо не так уж он и медленно работает. Или в MMX компах его уже нет?

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

Vlad Drakula

если нужно точность то писать нужно не на С.

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

[Vlad Drakula]

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

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

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

[bilytur]

Из статьи от hasherfrog

процессоры Pentium содержат 80-разрядные регистры, которые обслуживают блоки FPU и MMX. При работе FPU регистры ST0-ST7 образуют кольцевой стек, в котором хранятся числа с "плавающей точкой", представленные в формате с расширенной точностью (80 разрядов).

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

Vlad Drakula
Да

фартран.

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

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

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

[hasherfrog]

место в центре кристало очень дорого

Дело было немного по-другому, имхо: по шине дано было гонять эти регистры, а она 64-бита. Экономили скорее не место, а скорость (коряво сказал как-то).
Но это детали, главное, что bilytur решениевроде бы нашёл. Только вот я не совсем понял...
bilytur

портанул под вин32

А чем компилил? MVC, BC, GNU C??? Что, при компиляции появился новый тип данных? Или там в исходниках полно ассемблерного кода?

[bgg0408]

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

[bilytur]

А чем компилил? MVC, BC, GNU C??? Что, при компиляции появился новый тип данных? Или там в исходниках полно ассемблерного кода?

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

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

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


Добавлено:

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

[pva]

У меня никогда проблем не возникало. Если я компилирую под 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 (на сайте есть библиотека с исходниками).