Быстро ли мое решение?

Question

[ralpt]

Задача: Есть буфер (массив) который периодически изменяется и обрабатывается. Мне требуется обрабатывать вновь появившиеся данные + сохранять часть. Т.е. обрабатывается вновь прибывший буфер и часть старого.
Я подумал зачем заниматься перезаписью и реализовал решение аналогичное примеру ниже:

int a[] = {1,2,3,4};
int b[] = {5,6};
int* c[6];
for(size_t i=0; i<4; i++){
    c[i] = a+i;
}
for(size_t i=0; i<2; i++){
    c[i+4] = b+i;
}
for(int i=0; i<6; i++){
    printf("%d\n", c[i][0]);
}

Вывод: 1 2 3 4 5 6.

Т.е. я иду по массиву неизменяемых указателей и работаю с ним.
Является ли это быстрым решением? Большой буфер, кусочек старого требуется маленький. Или будет быстрее и правильней создать еще один массив и туда переносить все через memcpy?

Подскажете литературу в этом направлении (как правильно писать быстрый код, связь с ассеблером, связь с механизмами ОС, распараллеливание)?

Comments

[0xD34F]

3.1, 3.4

[ralpt]

0xD34F, Подправил

[0xD34F]

ralpt, не всё. Почему тэгов до сих пор 5?

[ralpt]

0xD34F, Понял

Answer 1

[Wataru]

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

Ваш текущий вариант вносит дополнительное разименовывание указателя на каждое число.
Вариант с memcpy внесет дополнительное копирование, что помедленнее разыменовывания указателя по идее.

Но на практике все зависит от кучи факторов. Много ли у вас чисел, попадают ли они в кеш процессора, как далеко лежат две части буффера, как долго идет обработка каждого числа. Проверить это в итоге можно только практикой, но, скорее всего, ваше текущее решение будет быстрее memcpy, потому что единственное приемущество memcopy будет в том, что данные лежат в памяти подряд, что очень дружественно к кешу. Но вашем текущем решении и сами указатели и то, куда они указывают, итак лежат в памяти подряд (кроме одного индекса, где меняются массивы).

Answer 2

[mayton2019]

Измерение перформанса - это великое искусство. В данном конкретном приложении скорее всего узким местом будет не игры с массивами а конкретно печать на экране
printf("%d\n", c[i][0]);
поэтому из быстрых алгоритмов печать надо вышвырнуть. Или заменить ее на агрегацию результата или
думать об асинхронных и параллельных операциях записи результата в файл если уж он так сильно нужен.

Очень многие начинающие прокалываются на этом. Еще попробуй отказаться от индекса в массиве и заменить
его на "подвижный" указатель по массиву. Часто бывает что умные компилляторы умеют распознавать такой шаблон но я-бы предложил написать две реализации и сравнить.

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

Comments

[ralpt]

printf - это аналог обработки. В реальной задаче вывод в терминал не использую.

[mayton2019]

ralpt, как ты меряешь время? Считаешь среднее? Медиану? Делаешь холодный запуск? Или ждешь прогрева кешей?

[ralpt]

подвижный указатель это типа этого?: *(a+i) == a[i]

[ralpt]

mayton2019, Скорее просто узнаю у знатоков, как лучше сделать и все, спрашиваю литературу. Вот то, что printf долгая операция, спасибо, понял.

[mayton2019]

ralpt, да верно. Только для движения его вперед можно делать инкремент и разыменование.

[mayton2019]

Вот то, что printf долгая операция, спасибо, понял.

Это сильно зависит от ЯП и API. Но беда в том что если печать идет на живой экран - функция может
блокироваться и ждать скролла. Это уже не микро-секунды а милисекунды. На 3 порядка дольше.

[Василий Банников]

ralpt, она не просто медленная. Она непредсказуемо медленная.

[res2001]

ralpt,

printf долгая операция

Помимо printf к долгим операциям можно отнести аллокацию памяти (malloc, new). Если в реальном коде вы будете каждый раз выделять динамическую память для c, то это может стать заметным тормозом.
Оценка скорости printf и malloc сильно зависят от задачи. Если у вас идет обработка потока данных или объем обрабатываемых данных измеряется в МБ и больше , то эти операции могут быть узким местом. Если же это что-то другое, то заморачиваться на счет скорости printf и malloc не стоит.
Вообще любая операция ввода/вывода может быть "непредсказуемо медленной" и от вас это может вообще никак не зависеть, например чтение/запись файла на диске, данных из сети и т.п.

Вообще в вашей задаче, если вам в дальнейшем не нужен общий массив, содержащий данные a и b, то самым быстрым вариантом будет не объединять массивы вообще никак, т.е. сначала обрабатываете a, затем b по отдельности. Если же после обработки вам зачем то нужен объединенный массив, то a и b лучше объединить сразу и работать уже с объединенным массивом.

[ralpt]

res2001, "a" это грубо говоря постоянно меняющийся буфер, а "b" это кусок старого. Требуется это для цифровой обработки данных, таким образом создантся эффект непрерывного потока данных. По отдельности ну уж слижком будет некрасивая конструкция. В примере немного неправильно, "b" тогда уж должен быть равен {-1,0}.

[mayton2019]

ralpt, нам нужно видеть протокол этого метода. Где переменные. Где константы. Что от чего зависит.

По тому огрызку кода уже нельзя больше делать суждения.

[ralpt]

mayton2019, принял