GCC опции для максимального принудительного рекурсивного использования inline

[V1KT0P]

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

Код:

-finline-limit=n

Так и не понял что за лимит устанавливает и какое число выбрать.

Код:

-finline-functions

На всякий случай включаем инлайнивание.
Еще три параметр(правильно ли я их написал?):

Код:

--param max-inline-insns-recursive 450
--param max-inline-recursive-depth 8
--param min-inline-recursive-probability 10

Второй это ясно инлайн в глубину. Хоть я и неплохо читаю документацию на английском но вот понять что делает первый и третий параметры не могу. Может тупо установить все три параметра в 9000? =).
Есть что-то еще что поможет увеличить какие-то там лимиты?

[Bepec]

Помоему вы немного страдаете фигнёй

Где то тут в дебрях имелась крутая темка про inline. В которой предпочиталось оставлять его на откуп компилятору. При максимальной оптимизации он сам заинлайнит всё куда надо и ненадо.

PS хотя вроде бы писалось, что при ВЕЛИКОМ умении можно выиграть некоторые проценты (1-3) в производительности.

[Пантер]

http://bit.ly/GUfkEI

[Tonal]

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

[V1KT0P]

http://bit.ly/GUfkEI

Думаешь я в гугле не лазил =). Вот везде советуют:

Код:

#define inline __forceinline

Но некоторые говорят что он не 100% инлайнит и может отказаться. Я даже находил тему где человек огорчился что GCC отказывался инлайнить функции и поэтому был медленее на 20% чем MSVS который заинлайнил все.

[Igors]

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

Это не ответ на Ваш вопрос но, как Вы сами понимаете, любая возня с inline в лучшем случае сулит не более 5%. Есть смысл поискать др ходы

1) Задействовать icc - прирост может быть ощутимым

2) Вычислять параллельно

Код

C++ (Qt)
#pragma omp parallel for
for (int i = 0; i < limit; ++i)
 DoCalc(i);
 

3) Поанализировать сами вычисления и код (нужен хороший профайлер)

[V1KT0P]

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

Это не ответ на Ваш вопрос но, как Вы сами понимаете, любая возня с inline в лучшем случае сулит не более 5%. Есть смысл поискать др ходы

1) Задействовать icc - прирост может быть ощутимым

2) Вычислять параллельно

Код

C++ (Qt)
#pragma omp parallel for
for (int i = 0; i < limit; ++i)
 DoCalc(i);
 

3) Поанализировать сами вычисления и код (нужен хороший профайлер)

1) Спасибо попробую, как-то вылетело из головы. Я им вообще никогда не пользовался из-за платности.
2) Распараллелить будет не проблема, при чем параллелиться оно просто невероятно просто и хоть на тысячи ядер =).
3) Ну я и так знаю что там самым узким местом будет вычисление интегралов. И так там уже все оптимизировал.

[Igors]

2) Распараллелить будет не проблема, при чем параллелиться оно просто невероятно просто и хоть на тысячи ядер =).

Здесь лучше переоценить чем недооценить 

3) Ну я и так знаю что там самым узким местом будет вычисление интегралов. И так там уже все оптимизировал.

Я получал по ушам в самых неожиданных местах, напр

Код

C++ (Qt)
void DoCalcSomething( .. )
{
 Point temp[128];   // тормоз: Point имеет конструктор
 ...
}
 

Лучше все-таки профилить а не полагаться на "я и так знаю"