> Всё можно сделать на всём. Мы говорим об эффективности. Логические элементы, из
> которых сделаны процессоры, не знают и про целочисленную арифметику, кстати -
> из этого никак не следует, что следует отменить целочисленное ядро.

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

> Правда? А то, что x87 - это не просто стек и 80-разрядных
> регистры, а железка, позволяюшая в среднем меньше чем за такт правильно
> выполнить арифметическую (и не только) IEEE 754 - операцию?

У которой тоже есть траблы с точностью и если четко не знать ограничений стандарта, то при математических вычислениях можно встать на хорошие грабли. Это к вопросу о том, что x87 не панацея/
Это к вопросу о таблицах Брадиса и точности-))

> Вы собираетесь тащить таблицы Брадиса? Если не секрет, с какой дискретностью/точностью
> вы хотите их представить?

От задачи зависит. Кстати, как думаете, как процессор синус считает?-)
То, что в ваших задачах вам может
> хватать _очень_ грубых приближений, не означает, что это всегда так. Или,
> всё-таки, промежуточные значения вы будете сильно не спеша считать?

Опять таки от задачи зависит. нет универсальных алгоритмов, для каждой задачи разработчик включает мозг и думает как ему ее решить. Пример, если у меня SVGA разрешение, то мне на фиг не надо считать координаты с точностью до 25 знака. Точно также, как сдиг заменяет деление на 2. И если я считаю загрузку состава, то мне int достаточно, ну хотя бы потому, что 60 вагонов порой предел. Но современные горе программеры любят на всякий случай использовать float. А когда тыкаешь пальцем в этот говонокод, то объяснить они зачем у них так сделано они не в состоянии.-)

> Кстати, любое табличное представление в лучшем случае забивает кеши (когда вам везёт,
> оно маленькое и вы не промахиваетесь), в худшем - вызывает прокачивание
> по шине памяти.

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

> У вас massively parallelizable application. Это очень ограниченный (хотя и сильно полезный)
> класс приложений. Увы и ах, огромное количество приложение не-(или плохо-)параллелизуемы.
> Уж не говорю о том, что сама по себе параллельность требует
> накладных расходов и на массе задач они просто не окупаются.

Правильно, поэтому в каждом конкретном приложении или, если быть точнее, в каждом типе приложений стоит использовать те или иные подходы.

Завтра попробую откомпилировать. Кстати по поводу компиляторов, попробуйте  откомпилировать приложение, так чтобы оно было 64 битным работало только на процессорах с SSE4 и по возможности их использовало, не использовало команд x87. Не расскажите, как в  том же Visual Studio это сделать?