LINUX.ORG.RU

Обработка массива в памяти


0

1

Одинаковое ли время занимают обработка массива с начала до конца и от конца к началу?

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

Если бы это был файл, то можно было бы сослаться на алгоритм упреждающего чтения, а так же на что диск вращается в определенную сторону (с ssd это уже не так). Т.е. в случае чтения файла, лучше читать от начала к концу.

А вот если массив только в памяти, то будет ли по аналогии заполнение tlb-кеша (кешей первого-второго уровня и какие там еще кеши бывают) приводить к более быстрой обработке массива от начала к концу по сравнению с обратным порядком?

Приветствуются варианты практической проверки (устраняющие влияние специфики алгоритмов разделения времени используемой ОС)

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

вообще, да, интересно, слежу за темой ...

x905 ★★★★★
()
Ответ на: комментарий от x905

все это академические изыски

ещё бывают собеседования и тогда это самый что ни на есть практический вопрос, способный повлиять на жизнь человека

aragorb
() автор топика

А доступ в озу у нас же вроде как за константу. Дак разве может тогда разница быть? А так, насколько я помню господина Таненбаума, в кеш данные считываются страницами поэтому [vanga] разницы нет [/vanga]

actics
()
Ответ на: комментарий от actics

а вот нифига. Начиная с Pentium III Tualatin есть в процессорах такая фича как Hardware prefetching (как подсказали более опытные товарищи)

http://www.behardware.com/articles/623-6/intel-core-2-duo-test.html

[vanga] разницы нет [/vanga]

тут фишка может быть в том, что префетчер угадывает одинаково хорошо как чтение вперед, так и чтение назад. Надо больше тестов!

aragorb
() автор топика
Ответ на: комментарий от aragorb

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

actics
()
Ответ на: комментарий от aragorb

ещё бывают собеседования и тогда это самый что ни на есть практический вопрос, способный повлиять на жизнь человека

в разработке ПО вопросы быстродействия памяти и процессора - это такая мелочь, о которой можно спорить, но смысла она не имеет

x905 ★★★★★
()
Ответ на: комментарий от x905

о которой можно спорить, но смысла она не имеет

и устроился ты после этого не в крупную транс-национальную компанию, а пошел за ползарплаты фрилансить и возиться с отчетами для налоговой

aragorb
() автор топика

Если мне не изменяет память, как раз из-за этого начался срач между Дреппером и Adobe. В libc memcpy копировала с начала к концу, и программеры Adobe использовали memcpy для копирования пересекающихся участков памяти, если dest находится перед source, хотя по стандарту в таком случае поведение не определено и надо использовать memmove. Но на x86-64 копирование с конца к началу оказалось быстрее, и когда разработчики libc поменяли реализацию memcpy, то Adobe словила нехилый баттхерт.

hippi90 ★★★★★
()
Ответ на: комментарий от aragorb

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

actics
()

Я когда-то проверял, кажется было одинаково в обе стороны, на x86 и arm9.

amaora ★★
()

Есть разные prefetch'и (кэша, страниц), и работают они обычно только вперёд. На практике разница минимальна, но измерима - у меня на i7 порядка 0.65% (быстрее от начала к концу, разумеется).

http://www.roguewave.com/portals/0/products/threadspotter/docs/2011.2/manual_...

slovazap ★★★★★
()
Последнее исправление: slovazap (всего исправлений: 1)
Ответ на: комментарий от slovazap

насчет кеширования согласен

Deleted
()

Версия memcpy с sse3 копирует от конца к началу. Intel говорит, что на сколько-то там заметных процентов быстрее.

i-rinat ★★★★★
()
Ответ на: комментарий от actics

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

Не парься с этим, этим должен заниматься твой компилятор.

anonymous
()
Ответ на: комментарий от anonymous

неплохой такой мануальчик, на 800 страниц. Спасибо

actics
()
Ответ на: комментарий от anonymous

а есть какойнить манул на amd х86_64 в котором все ассемблерные инструкции были бы даны? Я в свое время найти не смог

actics
()
Ответ на: комментарий от actics

Ну да optimization guide только один из мануалов. Есть еще application programming guide и system programming guide. Вернее так было лет 5-7 назад :)

Смотри там рядом они должны валяться.

anonymous
()
Ответ на: комментарий от anonymous

и правда нашел. В прошлый раз, когда я искал, страницы были недоступны

actics
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.