оптимизация сравнений в С++

[Andrey_Kireew]

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

На счёт вспомогательного массива flag я так и не увидел никаких плюсов.
В варианте с массивом flag всё равно придётся обрабатывать 2 массива - сам flag и оригинальный fe типа double.
В моём варианте обрабатывается только один массив double и нет никаких дополнительных сравнений и логических "и", это в любом случае быстрее.

Единственный проигрыш может быть на этапе создания:

Используется синтаксис C

char *flag=new char[Len];
 

будет конечно побыстрее, чем

Используется синтаксис C

double *scopy=new double[Len];
memcpy(scopy,fe, Len*sizeof(double));
 

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

-- 08.08.2018, 20:35 --

Dmitriy40 в сообщении #1331238 писал(а):

причём замечу что отдельный массив флагов я давно предложил и уж точно не double).

Ну это, собственно, и есть развитие Вашего предложения, без него бы ничего и не было. Но я стал использовать ещё дополнительное условие отбора, которое удалось найти после долгих размышлений. Получилось действительно серьёзное ускорение, примерно в 30 раз.

По поводу double я объяснил в предыдущем посте, намой взгляд так будет рациональнее

[photon]

Andrey_Kireew в сообщении #1331241 писал(а):

массивы довольно большие, по нескольку тыс. эл.

Это маленькие массивы. Сравните, например с числом пикселей в кадре.

Я не знаю вашу задачу, и какие временные рамки ставятся, не знаю, какая у вас там обработка, поэтому тяжело судить, существенна ли экономия времени на выделении/очистке памяти. Уменьшение размера типа обычно имеет смысл, как выше уже отметил Dmitriy40, для выигрыша в работе с кэшем.

[realeugene]

photon в сообщении #1331235 писал(а):

а вы уводите куда-то в сторону: то рассказываете про добавление к имеющемуся булевскому типу, которого у ТС не имелось,

Вот только, пожалуйста, не нужно перевирать мои слова. Про bool тут написал именно ТС, вы же ему дали совет ими не пользоваться, а пользоваться для флагов char:

photon в сообщении #1331148 писал(а):

Andrey_Kireew в сообщении #1331138 писал(а):

Здесь его, конечно можно сделать bool, но на 64 битной машине от этого толку не особо.

Разница есть. Короткие типы, требуют меньше памяти и если массив большой, то его куски реже надо будет подгружать в кэш. Если же вы решите векторизовать проверки, то это станет еще более критичным. Я бы без векторизации делал char.

Вы уже, как модератор, намекаете, что продолжение обсуждения этого - оффтопик (впрочем, что есть в этой теме "топик", похоже, не особо понятно не одному мне). Хорошо, не буду продолжать с вами обсуждение этого. Остановлюсь на том, что я считаю ваш этот совет вредным, особенно, для уровня ТС. И замечу ещё, что то, что вы всё-таки поправились и добавили в свой пример кода ключевые слова "const" при объявлении констант - это, разумеется, здорово. Без них ваш код для меня выглядел просто устрашающе, несмотря на внешнюю красоту.

[Andrey_Kireew]

photon в сообщении #1331235 писал(а):

Я бы не писал "flag" в своей программе, если планируется время жизни кода больше пары дней....

Не то, чтобы планируется - она уже "живёт" около 2-х лет, и за это время претерпела огромные изменения, как в производительности, так и в своих возможностях. Имена переменных в ней хоть и короткие, но вполне мнемоничные. По крайней мере, после полугодового перерыва, я "врубился" в код меньше чем за день.

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

-- 08.08.2018, 20:56 --

photon в сообщении #1331243 писал(а):

Это маленькие массивы. Сравните, например с числом пикселей в кадре.

Я же пишу, что их самих много, тоже несколько тыс. Вот и получается $7000\cdot3000\cdot 8\approx 160 MB $ не так уж это и мало

[photon]

Andrey_Kireew в сообщении #1331246 писал(а):

Я же пишу, что их самих много, тоже несколько тыс

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

[Andrey_Kireew]

На счёт этого, да, запас памяти довольно большой. Любые вспомогательные массивы создавать можно (впрочем, их и так создаётся там достаточно много). Имеет значение только итоговая скорость выполнения кода.

[realeugene]

Andrey_Kireew в сообщении #1331252 писал(а):

Любые вспомогательные массивы создавать можно (впрочем, их и так создаётся там достаточно много). Имеет значение только итоговая скорость выполнения кода.

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

[Dmitriy40]

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

(Пример теста)

Есть великолепный реальный пример для сравнения стоимости L1 vs L2 vs L3 в скорости: primesieve, генератор простых чисел, которому можно указать размер используемого кэша. Вот мой пример L1/L2/L3:

C:\>primesieve.x64con.exe 1e11 -s32
Sieve size = 32 kilobytes
Time elapsed  : 8.466 sec
C:\>primesieve.x64con.exe 1e11 -s256
Sieve size = 256 kilobytes
Time elapsed  : 12.859 sec
C:\>primesieve.x64con.exe 1e11 -s2048
Sieve size = 2048 kilobytes
Time elapsed  : 27.843 sec

[realeugene]

(Оффтоп)

Dmitriy40 в сообщении #1331264 писал(а):

Вот мой пример L1/L2/L3:

Это у вас на скольки нитях?

[Dmitriy40]

(Оффтоп)

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

[realeugene]

(Dmitriy40)

Dmitriy40 в сообщении #1331270 писал(а):

В 4 потока везде.

Хм... У меня на 4 нитях (при 4 доступных ядрах с HT) минимум при s256 и равен 10.8 секунд. При s16 - 15.3 секунды. Влияние L1 вообще не заметно.

[Andrey_Kireew]

Не знаю, размеры у них примерно по несколько тыс. эл., и всего их штук 5, может одновременно в кэш и не полезут. Обращение к ним, разумеется, идёт не по порядку. Скорее всего там разные куски туда - сюда перегружаются постоянно.