Ускорить вызов функции внутри цикла

Question

Ускорить вызов функции внутри цикла

0

loop over a very long container (millions elements)
{
   each element compute 8 integers:  k1,k2,k3,...,k8

   call function    func(k1,k2,k3,...,k8)
}

container is a std::vector, element is a long integer
each k can only take {0,1,2,..5} six values.
func is a simple expression of complex number calculation, 
  involves std::conj and std::exp

Чтобы ускорить работу, я кэширую все возможные результаты функции func в массив и вместо этого вызываю func_array [k1] [k2] [k3].... Но если просто определить func_array как: std:: complex func_array [6] [6] [6]..., программа умирает при переполнении стека.

Какие-нибудь лучшие решения для ускорения?

Tim 08 июль 2013, в 17:25

Источник

7

Выделить свой массив в кучу?
nouney 08 июль 2013, в 14:55
2

На этом уровне нам нужна дополнительная информация о вашей структуре данных: что такое контейнер, какие элементы, какие вычисления вы делаете, чтобы получить k… Непрерывная память может сильно помочь, так как компилятор будет векторизовать ее
Tristram Gräbener 08 июль 2013, в 14:58
0

Если я что-то не пропустил, это массив из 6 ^ 8 значений, что составляет около 2 миллионов, так что на самом деле не так уж много. Может быть, просто выделить массив int [1679616], чтобы избежать дополнительных затрат на размещение вложенных массивов?
C4stor 08 июль 2013, в 14:59
1

@C4stor C4stor умножьте на 8 байтов или около того, и вы получите 10 мегабайт, что может нарушить некоторые стеки. Переход к классу или глобальной области видимости, или использование указателя ослабит это давление в стеке.
user645280 08 июль 2013, в 15:01
0

@ebyrob Это действительно зависит от окружающей среды. Но я предпочел стандартный современный компьютер, на котором 10 мегабайт не так много в моей книге.
C4stor 08 июль 2013, в 15:02
2

@C4stor C4stor Похоже, что некоторые компиляторы Visual Studio по умолчанию для некоторых потоков по- прежнему составляют всего 1 мегабайт : msdn.microsoft.com/en-us/library/tdkhxaks.aspx Стек часто стоит дороже , куча может составлять 16 гигабайтов ... Или проще Если вы когда-либо пробовали Google Code Jam, как часто вам приходилось перемещать переменные из стека, чтобы избежать переполнения без полной переделки параметров компилятора?
user645280 08 июль 2013, в 15:04
0

из какого диапазона значений находятся элементы в векторе? Вы говорите, что они длинного типа, но есть ли еще ограничения? Является ли func в некотором смысле симметричным в некоторых аргументах? (возможно, предоставьте код)
Arne Mertz 08 июль 2013, в 15:09
0

@ebyrob Очень хорошо, я бы не догадался, что по умолчанию для стека будет только 1M. Спасибо :)
C4stor 08 июль 2013, в 15:11

Показать ещё 6 комментариев

Теги:

c++

performance

2 ответа

Ещё вопросы

На этом уровне нам нужна дополнительная информация о вашей структуре данных: что такое контейнер, какие элементы, какие вычисления вы делаете, чтобы получить k… Непрерывная память может сильно помочь, так как компилятор будет векторизовать ее
Если я что-то не пропустил, это массив из 6 ^ 8 значений, что составляет около 2 миллионов, так что на самом деле не так уж много. Может быть, просто выделить массив int [1679616], чтобы избежать дополнительных затрат на размещение вложенных массивов?
@C4stor C4stor умножьте на 8 байтов или около того, и вы получите 10 мегабайт, что может нарушить некоторые стеки. Переход к классу или глобальной области видимости, или использование указателя ослабит это давление в стеке.
@ebyrob Это действительно зависит от окружающей среды. Но я предпочел стандартный современный компьютер, на котором 10 мегабайт не так много в моей книге.
@C4stor C4stor Похоже, что некоторые компиляторы Visual Studio по умолчанию для некоторых потоков по- прежнему составляют всего 1 мегабайт : msdn.microsoft.com/en-us/library/tdkhxaks.aspx Стек часто стоит дороже , куча может составлять 16 гигабайтов ... Или проще Если вы когда-либо пробовали Google Code Jam, как часто вам приходилось перемещать переменные из стека, чтобы избежать переполнения без полной переделки параметров компилятора?
из какого диапазона значений находятся элементы в векторе? Вы говорите, что они длинного типа, но есть ли еще ограничения? Является ли func в некотором смысле симметричным в некоторых аргументах? (возможно, предоставьте код)
@ebyrob Очень хорошо, я бы не догадался, что по умолчанию для стека будет только 1M. Спасибо :)

Darius X. · Answer 1 · 2013-07-08T13-59-00.000Z

Если функция func() всегда возвращает одно и то же значение для заданного набора входов (например, не зависит от времени, зависит от последовательности и т.д.), вы можете сделать следующее:

1. Всякий раз, когда вы вызываете func(), сохраните результат в кеш [используя значения k1... через k8 в качестве ключа к записи кэша]

2. Перед вызовом функции func() проверьте, есть ли у вас значение кэшированного значения

Кэш сам по себе может быть Картой, где вы строите ключ, объединяя k1... thru... k8 в некотором роде, который подходит для их типа данных.

Разве многомерный массив C ++ не ведет себя почти как хэш-карта с точки зрения производительности чтения? Единственное преимущество, которое я мог видеть в динамическом хеше, было бы, если бы входные значения выходили за пределы ожидаемого диапазона 0-5.
Он сказал, что кэширует «все возможные» результаты. Итак, я думаю, что он создает «8-мерный» массив из 6 значений каждый, что означает более миллиона записей. Предполагая, что это то, что он делает, ему нужно только кэшировать до и после фактического использования.
@DariusX. Наличие ведра не обязательно означает, что оно заполнено ... Насколько я понимаю, только ведра предварительно распределены.
Да, но он сказал: «Я кеширую все возможные результаты« func »в массив». В любом случае, только ОП может раскрыть тайну. Может быть, я просто неправильно его прочитал.

James Kanze · Answer 2 · 2013-07-08T13-47-00.000Z

0

Вы создаете массив std::complex[6][6]...[6] на стек? Во-первых, это может привести к переполнению стека: это довольно большой массив для множества стеков. И второе: если вы создаете он в стеке, он будет повторно инициализироваться каждый раз, когда вы вызываете функция. Вероятно, вам нужен локальный статический массив, который будет инициализирован один раз (первый раз, когда он встречается), и затем сохраните его значение между вызовами функций.

James Kanze 08 июль 2013, в 13:47

0

Я кеширую его в переменной-члене, цикл находится внутри функции-члена.
Tim 08 июль 2013, в 15:22
0

static std::complex func_array[6][6][6][6][6][6][6][6] = {0}; тогда внутри метода класса?
user645280 08 июль 2013, в 15:28
0

Если программа используется часто, и даже лучшим решением было бы вычислить все значения один раз и вывести их как инициализатор массива C ++, чтобы вы могли скомпилировать полностью инициализированную статическую переменную в программу. Это может быть невозможным, однако --- у меня иногда "не хватало памяти" от компилятора с инициализаторами, сгенерированными машиной. В противном случае запишите двоичные данные в файл и mmap их. (Для этого вам понадобится сложное приведение, но вы можете спрятать его во встроенной функции.)
James Kanze 08 июль 2013, в 16:04
0

Этот член будет 1679616*sizeof(std::complex) . Если вы поместите этот член в объект, который находится в стеке, то вы вполне можете уничтожить свой стек. Вы должны либо динамически размещать массив внутри объекта (используйте std::complex* ), либо размещать родительский объект с new вместо прямой локальной переменной.
ams 08 июль 2013, в 16:20
0

@ams Из своего описания он должен быть в состоянии определить объект как статический констант. При условии, что его компилятор не взрывается, когда он встречает 1679616 инициализаторов.
James Kanze 08 июль 2013, в 17:35
0

@JamesKanze: конечно, но это не реентерабельное, а потому плохая практика.
ams 09 июль 2013, в 09:14
0

@ams Что ты имеешь в виду, не реентерабельный. Это совершенно реентерабельно. (Это не проблема, если сама функция не является рекурсивной.)
James Kanze 09 июль 2013, в 09:20
0

@JamesKanze: как он может быть повторно введен, если он использует локальные данные? ОК, кэшированное содержимое может быть применимо ко всем вызывающим абонентам, но это не указано, и вам может потребоваться добавить какую-то блокировку. Как вы говорите, хотя, если нет рекурсии и только один поток, это нормально, но это все же то, что мы должны упомянуть, давая советы.
ams 09 июль 2013, в 12:48
0

@ams Как статически инициализированные, локальные данные const влияют на повторный вход? Данные инициализируются при загрузке программы и никогда не меняются. Он не может иметь различного кэшированного содержимого в любом месте, поскольку нет никакого другого содержимого для кэширования.
James Kanze 09 июль 2013, в 13:19
0

@ams Обратите внимание, что если бы это было не так, у нас была бы настоящая проблема. Поскольку статически инициализированные, локальные данные const в значительной степени совпадают с машинным кодом программы.
James Kanze 09 июль 2013, в 13:20
0

@JamesKanze: О, вы хотите статически инициализировать все содержимое кеша, а не просто выделить хранилище ?! Я не видел этого изначально, потому что это безумие!
ams 09 июль 2013, в 14:20
0

@ams Почему это безумие? Вы делаете это один раз, перед компиляцией кода, а не каждый раз, когда запускаете программу. (Я делаю подобные вещи все время, и я, конечно, не единственный. От этого зависит любое количество широко используемых инструментов.)
James Kanze 09 июль 2013, в 15:03
0

Много-мегабайтная таблица поиска? Конечно, вы могли бы сделать это, но лучше бы это было важное улучшение.
ams 09 июль 2013, в 15:18
0

Это справочная таблица размером ~ 12 МБ (при условии, что sizeof (complex) == 8) в любом случае, вопрос в том, будем ли мы ее заполнять или заполнять по ходу дела. Это компромисс между размером исполняемого файла и временем выполнения. На самом деле предварительно вычисленный способ будет использовать меньше памяти, так как ему не нужно иметь дополнительный массив, хранящий флаги для того, заполнена ли запись в кэше.
Sebastian Redl 17 июнь 2014, в 13:55

Показать ещё 12 комментариев