Добрый день,
  у меня программа, написанна на С, выполняет простые математические операции с плавающей точкой с помощью математического сопроцессора. Нужно реализовать эти же операции, но так чтобы математический сопроцессор в вычислениях не участвовал. Пробовала перевести числа в формат с фиксированной точкой. К сожалению, функции выполняющие перевод тоже используют математический сопроцессор.
 Подскажите что делать?

Взять библиотеку эмуляции сопроцессора из какого-нить древнего языка и выдрать оттуда нужные функции...
А какой смысл НЕ использовать сопр?

Есть такое мнение, что работа с числами с плавающей точкой занимает больше тактов работы процессора, чем с числами с фиксированной точкой. Надо это мнение проверить.
Не подскажете библиотеку эмуляции сопроцессора? И какой язык можно взять для поиска этой библиотеки?

Если вы работаете на обычных современных процессорах, то это мнение просто бред.

Это сообщение отредактировал(а) W4FhLF - 21.12.2010, 15:09

Нет, это не совсем бред. По-идее, так оно и есть. Просто я не вижу смысла в такой оптимизации на современных процессорах. Опишите задачу, пожалуйста. Наверняка есть более простое и логичное ее решение

Задача проста:
 дана функция, ее надо оптимизировать. При профилировке было замечано, что код использующий математические операции с плавающей точкой работает особенно медленно. Соответсвтвенно было решено оптимизировать эти выражения. Код был заменен на ассемблерный аналог, но выигрыша во времени это не дало. Вот теперь оптимизация добралась до перевода чисел в формат фиксированной точки (8.24).

если уж дошло до деталей настолько близких к конкретному процессору, то, возможно, есть смысл почитать его сравнительные скорости различных операций на нём

если рассматривать абстрактный процессор, боюсь, на таком уровне оптимизации уже бессмысленны

Как узнать какой у меня процесссор?

liliputochka, 
Тогда вопрос о компетентности ассемблерной оптимизации встаёт ребром.

CPU_Z возьми и посмотри. 
А когда будешь оптимизировать используй CPUID .

Что оптимизировали? Какую задачу решали? 

Какая операция самая медленная?

Какие оптимизационные методики использовали? Алгоритм уже оптимизирован? Надеюсь что код уже рассчитан на неравномерный доступ к памяти? Число обращений к памяти уменьшено? А парализация данных уже задействована?  

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

Первоначальная функция:

Код, который оптимизировали с помощью ассемблера выделен жирным шрифтом.
Ассемблерный код:

Функция на С уже оптимизированна.

Добавлено через 6 минут и 32 секунды
Вот этот код тратил особенно много процессорного времени:

Вот то о чём я и говорил.



И чего вы хотели добиться простым переписыванием этого кода на ассемблер? Любой современный компилятор лучше вас оптимизирует код. Забудьте про ассемблер.

А второе очевидно, что в этом коде нет никаких ресурсоёмких операций (типа логарифма или корня), они простейшие и на современных процессорах занимают единицы тактов. Операнды -- простые переменные, которые компилятор кладёт в регистры, в любом случае они кешированы и на доступ к ним время практически не тратится.

У вас тормозит НЕ этот код. А тот, что идёт перед ним:



Первые две строки, где вы обращаетесь к памяти занимают больше всего времени. А профайлер вам показывает на следующие строки потому что процессор ждёт пока будут получены значения из памяти. Профайлер это программа и в силу колосальной сложности современных процессоров она не всегда точна (скорее всегда неточна). Нужно понимать, что она показывает и как это на самом деле интерпретируется.

На современных процессорах любое чтение из памяти эквивалентно тысяче сложений/умножений/вычитаний. Вот и подумайте какой смысл оптимизировать арифметику если всего-лишь одно обращение к памяти съест любой прирост производительности вычислений. Вам нужно оптимизировать работу с памятью, вычислить паттерн обращений к таблице gSin_tabl и организовать доступ таким образом, чтобы был эффективно задействован кеш процессора. В идеале следует стремиться к тому, чтобы доступ был последовательным. 

Следует почитать литературу по оптимизации прежде, чем тратить время на всякую ерунду типа переписывания кода на ассемблер или обход сопроцессора. 

Это сообщение отредактировал(а) W4FhLF - 22.12.2010, 13:52

W4FhLF те строки что вы указали в качестве ресурсоемких являются массивом. На сколько я представляю, массив хранится в кеше или оперативке, доступ к которой занимает 1 такт процессорного времени. К тому же стоки, которые я указала как ресурсоемкие были выявлены эмпирически, а не профайлером. Профайлер указал саму функцию.

Вы неправильно представляете. 

Какой у вас размер массива?

1 так чтение из кэша 14 при кэш промахке+частота процессора/частоту памяти(1-5 такта). Но это не на самых последних. В самых последних видимо уже всё по другому так как частоту памяти уж практически дотянули до частоты процессора.
Умножение выполняется быстро, но не так как хочется. 

Пока в коде еще не разбирался но по первому взгляду скажу тормазят вычисления. Но от таблице лучше отказаться. Рекомендации дам чуть по позже.