Russian Qt Forum

Добрый вечер

Вопрос конечно "теоретический" но все же интересно разобраться/понять. "С детства" (ну отрочества) вдалбливалось: целочисленная арифметика (намного) быстрее, всегда используйте shl вместо div и.т.п. Но так ли это сейчас (на дворе 2011 год, времена (со)процессоров давно канули в Лету)? Главное что смущает - RISC архитектура. Ведь если RISC - то (в общих чертах) все команды исполняются за 1 такт. Следовательно операции с флотами "столь же быстры" как и с int (ведь и те и те 1 такт). О каком же преимуществе int тогда идет речь?

Лично мои тесты (когда у меня есть такая возможность) показывают что целочисленная арифметика пошустрее но ни о каких "разах" не может быть и речи. А у Вас?

Спасибо

FPU хоть и включили в ядро, но он всё также лежит отдельным модулем, так что как ни крути... а всё равно медленней... правда моя уверенность тоже пошатнулась, сейчас сам попробую проверить.

вот что у меня получилось:
конечно не разы, но 2 раза есть

C
#include <time.h>
#include <unistd.h>
#include <stdio.h>
 
double processCpuTime()
{
	struct timespec tp;
	clock_gettime(CLOCK_PROCESS_CPUTIME_ID, &tp);
	return tp.tv_sec + tp.tv_nsec * 1.0e-9;
}
 
int main()
{
	int i;
	int ii;
	const int maxii=0xfffffff;
	double id;
	const int maxid=maxii;
	double time=processCpuTime();
 
	for(ii=0;ii<maxii;ii++);
	printf("int sum time: %g\n",processCpuTime()-time);
 
	time = processCpuTime();
	for(id=0;id<maxid;id++);
	printf("double sum time: %g\n",processCpuTime()-time);
 
	printf("=================================================\n",processCpuTime()-time);
 
	time = processCpuTime();
	for(i=0;i<10000;i++)
		for(ii=maxii;ii>1;ii/=2);
	printf("int div2 time: %g\n",processCpuTime()-time);
 
	time = processCpuTime();
	for(i=0;i<10000;i++)
		for(ii=maxii;ii>1;ii>>=2);
	printf("int shift div2 time: %g\n",processCpuTime()-time);
 
	time = processCpuTime();
	for(i=0;i<10000;i++)
		for(id=maxid;id>1;id/=2);
	printf("double div2 time: %g\n",processCpuTime()-time);
 
	printf("=================================================\n",processCpuTime()-time);
 
	time = processCpuTime();
	for(i=0;i<10000;i++)
		for(ii=maxii;ii>1;ii/=3);
	printf("int div3 time: %g\n",processCpuTime()-time);
 
	time = processCpuTime();
	for(i=0;i<10000;i++)
		for(id=maxid;id>1;id/=3);
	printf("double div3 time: %g\n",processCpuTime()-time);
 
	printf("=================================================\n",processCpuTime()-time);
 
	time = processCpuTime();
	for(i=0;i<10000;i++)
		for(ii=maxii;ii>1;ii/=7);
	printf("int div7 time: %g\n",processCpuTime()-time);
 
	time = processCpuTime();
	for(i=0;i<10000;i++)
		for(id=maxid;id>1;id/=7);
	printf("double div7 time: %g\n",processCpuTime()-time);
 
 
}
 

Когда то для процессора Pentium III Tualatin делал на асме высокооптимизированные алгоритмы ЦОС с использованием MMX и XMM (челочисленные и с плавающей точкой SIMD расширения соответственно). С XMM было чуть-чуть медленнее, в общем, сопоставимый результат.

xmm так вроде регистры sse называются. Но всё это уже совсем другие яица... я так понял сабж именно про FPU  и на сколько он реально отстаёт от обычной целочисленной арифметики. Да и понятно, почему не большая разница в скорости, всё же sse появился сильно позже mmx.

Исходя из этого:
если FPU является блоком в CPU, то целочисленная арифметика по определению будет быстрее.

сейчас самые задержки в процессоре на сбоях конвейера, потому что с памятью (и даже кэшем) работа намного медленнее, чем с регистрами. Один останов и перезаполнение конвейера могут стоить дороже нескольких арифметик. Даже если согласиться, что инты и правда 'по определению быстрее', то остаётся вопрос на сколько. Если на 0.01% то это всё равно что не быстрее. Если же на 50% то другое дело.

см. мой пост(#3) получается, что в 2 раза... хотя я рассчитывал на 3-7 раз...

мне показалось тест не очень чистый но сейчас смотрю -- нормальный тест. Надо ещё с SSE2 сравнить. SSE2 должен инты побить :)

а gcc оказывается хитрый жук... посмотрел асм код, а он всю FPU арифметику как SSE расписал...
перекомпилировал:

$ gcc -O0 -mfpmath=387 -lrt 2.c
$ ./a.out
int sum time: 0.792594
double sum time: 1.12118
=================================================
int div2 time: 0.00117913
int shift div2 time: 0.00040503
double div2 time: 0.00157286
=================================================
int div3 time: 0.00114019
double div3 time: 0.00339716
=================================================
int div7 time: 0.000804634
double div7 time: 0.00189564

в итоге результаты немного хуже, но почти незначительно.
ЗЫ: SSE2 это вы про целочисленную арифметику имеете в виду? тогда тест должен быть более мудрёный... например 2-4 числа одновременно увеличивать(делить) в цикле, а на тыком простом скорей всего ничего не получится, хотя надо пробовать :)
ЗЗЫ: на всякий случай система x64
ЗЗЗЫ: надо бы это всё на асме переписать...

а почему не -O3?


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

Насчет тестов - часто с картинкой (пикселями) удобнее что-то делать в float и это удобство/общность перевешивает 50-100% выигрыш с int, Я когда-то писал тесты, постараюсь найти и выложить.

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

Вот простой но разумный пример в аттаче. Картинку лучше выбирать побольше (ну или увеличить радиус осреднения, сейчас 9). У меня выдает (секунды)

(int) 1.585
(float) 1.721

Т.е. далеко даже до полутора раз