При каких обстоятельствах большие страницы могут произвести ускорение?
Современные x86 центральные процессоры имеют способность поддерживать большие размеры страницы, чем наследие 4K (т.е. 2 МБ или 4 МБ), и существуют средства ОС (Linux, Windows) для доступа к этой функциональности.
Ссылка Microsoft выше указывает, что большие страницы "увеличивают эффективность буфера перевода, который может увеличить производительность для памяти, к которой часто получают доступ". Который не очень полезен в предсказании, улучшат ли большие страницы какую-либо данную ситуацию. Я интересуюсь бетоном, предпочтительно определенным количественно, примеры того, где перемещение некоторой логики программы (или целое приложение) для использования огромных страниц привело к некоторому повышению производительности. Кто-либо получил какие-либо истории успеха?
Существует один особый случай, который я знаю меня: использование огромных страниц может существенно уменьшить время, должен был разветвить большой процесс (по-видимому, поскольку количество необходимости записей TLB, копирующей, сокращено фактором на порядке 1 000). Я интересуюсь тем, могут ли огромные страницы также быть преимуществом в менее экзотических сценариях.
3 ответа
Я попытался придумать код, который бы максимизировал трэш TLB с 4k страницами, чтобы изучить возможный выигрыш от больших страниц. Приведенный ниже материал работает в 2.6 раза быстрее (чем 4K страницы), когда 2MByte страницы предоставляются libhugetlbfs's malloc (Intel i7, 64bit Debian Lenny ); надеюсь, очевидно, что scoped_timer и random0n делают.
volatile char force_result;
const size_t mb=512;
const size_t stride=4096;
std::vector<char> src(mb<<20,0xff);
std::vector<size_t> idx;
for (size_t i=0;i<src.size();i+=stride) idx.push_back(i);
random0n r0n(/*seed=*/23);
std::random_shuffle(idx.begin(),idx.end(),r0n);
{
scoped_timer t
("TLB thrash random",mb/static_cast<float>(stride),"MegaAccess");
char hash=0;
for (size_t i=0;i<idx.size();++i)
hash=(hash^src[idx[i]]);
force_result=hash;
}
Более простая "прямая" версия с hash=hash^src[i] получила только 16% с больших страниц, но (дикая спекуляция) причудливое оборудование Intel для предварительной выборки может помочь в случае 4K, когда доступ предсказуем (я полагаю, я могу отключить предварительную выборку, чтобы проверить, так ли это).
Я видел улучшение в некоторых сценариях HPC/Grid - в частности, в физических пакетах с очень, очень большими моделями на машинах с большим количеством оперативной памяти. Также процесс, запускающий модель, был единственной активной вещью на машине. Я подозреваю, хотя и не измерял, что некоторые функции БД (например, массовый импорт) также выиграют.
Лично я думаю, что если у вас нет очень хорошо спрофилированного/понятного профиля доступа к памяти и если вы не выполняете много обращений к большой памяти, маловероятно, что вы увидите значительное улучшение.
Я получаю ~5% ускорения на серверах с большим количеством памяти (>=64GB), на которых запущены большие процессы. Например, для java-процесса объемом 16 ГБ, это 4M x 4kB страниц, но только 4k x 4MB страниц.