Comments 4
У вас какие-то странные тесты и графики: 32bit/1ns=3.7Gb/s 64bit/0.5ns=15Gb/s. Да и методика тоже.
Если хотите истощить кэш, то надо создать массив указателей которые указывает на следуюй элемент, перемешать и щемиться по нему:
void test(void* p) { while(p) p=*(void**)p; }
Такой тест не даст расслабиться ни кэшу ни банкам в dram. И покажет поряда 0.1Gb/s при пропускной способности в ~70Gb/s при последовательном доступе.
ps: еще заниматнльный момент если память последовательно заполнять нолями и не нулями то можно добиться разных резултатов, т.к. процессор для нулей использует агресивные оптимизации. То есть если сначала заполнить участок нулями, а потом данными и так идти пачками, то получиться быстрее чем если просто заполнять данными.
А насколько большая задержка от конвертации данных в код? Я слышал что архитектура современного компьютера не является на 100% фон-Нейманновской, особенно если в предмете исследования имеет место быть многоядерность. Тот же L1 до сих пор разделён как принято в Гарвардской архитектуре.
И ещё интересно, будет ли дополнительное проседание производительности если в массив p перед прогоном теста положить не просто адреса следующих ячеек (возможно, процессор может в какой-то мере это предсказать), а чтобы эти ячейки ещё и рандомизировать для полного исключения последовательного доступа.
будет ли дополнительное проседание производительности если в массив p перед прогоном теста положить не просто адреса следующих ячеек (возможно, процессор может в какой-то мере это предсказать), а чтобы эти ячейки ещё и рандомизировать для полного исключения последовательного доступа.
Однозначно - если указатели лежат подряд, префетчер будет заранее зачитывать следующие элементы в кеш (при этом ещё и кеш линейку используем полностью) и мы упрёмся в пропускную способность памяти, если рандомизировано - префетчер уже не угадает адрес следующего элемента, соотвественно упираемся в latency, при этом ещё и из зачитанной кеш линейки реально используем только sizeof(void*).
а почему 32 и 64 в расте слышал есть и 128
на фрибсд еще было бы интересно так как он мульти юзер спейс не сингл. и вкусная организация процессов )
(SIMD) gather effect можно обойти устанавливая конкретно порядок отправки и выравнивая данные тогда плавающая точка будет ускореннее вроде, тоесть образно отправляя последовательности прям в том порядке как нужно
примерно 2000 000 должно быть, там будет вроде ощутимо, но я давно тестил
На сколько же медленнее произвольный доступ на самом деле?