#include <iostream>
using namespace std;
int f(int a[8])
{
int sum=0;
for(int i=0;i<8;i++)
sum+=a[i];
return sum;
};
int main()
{
int a[8];
int sum = f(a);
cout << sum << endl;
return 0;
}
на -O0 понятное дело все осталость как есть. на -O2 заинлайнил функцию f внутрь main'a. а вот на -O3...
zaufi /work/tests $ g++ --version
g++ (Gentoo 4.4.2 p1.0) 4.4.2
Copyright (C) 2009 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Re: Способен ли компилятор правильно разматать такой цикл?
Я пробовал, но у меня компиялтор даёт строго последовательный код.
А с интринсиками? А с float point?
09.11.09 17:03: Перенесено модератором из 'Алгоритмы' — Кодт
Re[2]: Способен ли компилятор правильно разматать такой цикл
От:
Аноним
Дата:
09.11.09 13:11
Оценка:
Здравствуйте, CreatorCray, Вы писали:
CC>А почему ты считаешь что с точки зрения оптимальности кода твой вариант "размотки" будет лучше чем последовательное суммирование?
Потому что идёт распаралеливание на уровне команд.
Например, p6 может исполнять паралельно две команды сложения за такт.
Re: Способен ли компилятор правильно разматать такой цикл?
Здравствуйте, Аноним, Вы писали:
А>Я пробовал, но у меня компиялтор даёт строго последовательный код. А>А с интринсиками? А с float point?
Intel c++ может такое делать, но не факт, что будет именно 4 штуки sum1..sum4, а не 2 или 3.
Re[3]: Способен ли компилятор правильно разматать такой цикл
Аноним 311 пишет: > > Потому что идёт распаралеливание на уровне команд. > Например, p6 может исполнять паралельно две команды сложения за такт.
Самый лучший способ проверить себя написать оное на асме в обоих
вариантах и проверить и на своем компьютере (на другом результаты могут
оказаться другие).
Posted via RSDN NNTP Server 2.1 beta
Re[3]: Способен ли компилятор правильно разматать такой цикл
Здравствуйте, <Аноним>, Вы писали:
А>Потому что идёт распаралеливание на уровне команд. А>Например, p6 может исполнять паралельно две команды сложения за такт.
Компилятору совершенно не кажется правильным ради копеечной экономии вытеснить всё то, что он закешировал в регистрах ради суммирования 8 чисел.
Этот код ведь не в вакууме исполняется.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[2]: Способен ли компилятор правильно разматать такой цикл
Здравствуйте, D14, Вы писали:
А>>Я пробовал, но у меня компиялтор даёт строго последовательный код. А>>А с интринсиками? А с float point? D14>Intel c++ может такое делать, но не факт, что будет именно 4 штуки sum1..sum4, а не 2 или 3.
Распоследний ICC (11.1) выдал вот такой код:
Походу никто таким заморачиваться не будет. Потому как копеечное улучшение в этом кусочке в результате может вылиться в просадку производительности в целом.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[3]: Способен ли компилятор правильно разматать такой цикл
От:
Аноним
Дата:
09.11.09 13:51
Оценка:
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, D14, Вы писали:
А>>>Я пробовал, но у меня компиялтор даёт строго последовательный код. А>>>А с интринсиками? А с float point? D14>>Intel c++ может такое делать, но не факт, что будет именно 4 штуки sum1..sum4, а не 2 или 3. CC>Распоследний ICC (11.1) выдал вот такой код:
CC>
CC>Походу никто таким заморачиваться не будет. Потому как копеечное улучшение в этом кусочке в результате может вылиться в просадку производительности в целом.
Поскольку процессоры Intel за такт могут произвести только одно чтение, для них
дествительно это может быть лучший код, но AMD может произвести два чтения за такт, и для него оптимален другой код.
Re[3]: Способен ли компилятор правильно разматать такой цикл
Здравствуйте, CreatorCray, Вы писали:
CC>Походу никто таким заморачиваться не будет. Потому как копеечное улучшение в этом кусочке в результате может вылиться в просадку производительности в целом.
Дык, тут тип int С ним действительно можно не заморачиваться, т.к. большое кол-во чисел типа int редко когда складывают, а с плавающей точкой оптимизирует. Там за счет задействования конвеера приличное ускорение можно поиметь.
Re[4]: Способен ли компилятор правильно разматать такой цикл
Здравствуйте, D14, Вы писали:
D14>Дык, тут тип int С ним действительно можно не заморачиваться, т.к. большое кол-во чисел типа int редко когда складывают, а с плавающей точкой оптимизирует. Там за счет задействования конвеера приличное ускорение можно поиметь.
Компилятор с вами не согласен.
#define NUM_VALUES (100)
float f(float* a)
{
float sum=0;
for(int i=0;i<NUM_VALUES;i++)
{
sum+=a[i];
};
return sum;
};
int main ()
{
float var[NUM_VALUES];
return f (var);
}
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, D14, Вы писали:
D14>>Дык, тут тип int С ним действительно можно не заморачиваться, т.к. большое кол-во чисел типа int редко когда складывают, а с плавающей точкой оптимизирует. Там за счет задействования конвеера приличное ускорение можно поиметь.
CC>Компилятор с вами не согласен.
Здорово. А теперь тоже самое, но с double.
Re[6]: Способен ли компилятор правильно разматать такой цикл
Здравствуйте, D14, Вы писали:
D14>>>Дык, тут тип int С ним действительно можно не заморачиваться, т.к. большое кол-во чисел типа int редко когда складывают, а с плавающей точкой оптимизирует. Там за счет задействования конвеера приличное ускорение можно поиметь. CC>>Компилятор с вами не согласен. D14>Здорово. А теперь тоже самое, но с double.
можно и с int, и с float, и с double. просто в данном конкретном случае ICC решает что векторизовать работу со столь маленьким массивом невыгодно (о чем и говорит в vec-report). нет, его конечно можно явно прагмой пнуть, но смысл? увеличь размер массива (можно обернуть еще в цикл), и получишь векторизацию.
например так (для double):
A>можно и с int, и с float, и с double. просто в данном конкретном случае ICC решает что векторизовать работу со столь маленьким массивом невыгодно (о чем и говорит в vec-report). нет, его конечно можно явно прагмой пнуть, но смысл? увеличь размер массива (можно обернуть еще в цикл), и получишь векторизацию. A>например так (для double):
А я и не утверждал, что обязан всегда. Я писал, что может использовать количество аккумуляторов по своему усмотрению.
Re[3]: Способен ли компилятор правильно разматать такой цикл
Здравствуйте, <Аноним>, Вы писали:
А>Здравствуйте, CreatorCray, Вы писали:
CC>>А почему ты считаешь что с точки зрения оптимальности кода твой вариант "размотки" будет лучше чем последовательное суммирование?
А>Потому что идёт распаралеливание на уровне команд. А>Например, p6 может исполнять паралельно две команды сложения за такт.
Нескромный вопрос, вы производительность меряли ?
... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[5]: Способен ли компилятор правильно разматать такой цикл
