Pull to refresh

Comments 16

1) Можно ли привести прирост производительности? Все-таки у СУБД, на которые вы ссылаетесь, несколько другие задачи. Тут, мне кажется, прирост будет составлять несколько процентов. И очень редко — теоретические 50%.
2) Наверное стоило сказать, что все это о 64 битах.
Да с просонья вообще такое читать не следует. Мало того, что не увидел перевод, так еще и про 64-битность пропустил. Но все равно остаюсь при мнении, что профит будет минимален, если будет вообще.
Из перевода
8 Мб распределены по четырем большим страницам, а 1760 Кб — по стандартным. Мне это дало прирост производительности Zend в 3% при больших нагрузках.
Так понимаю, что прирост производительности будет за счёт уменьшения размера кеша выделенного под хранение таблицы страниц, не более того.
Не совсем. Будет меньше промахов при обращении в TLB, и, следовательно, меньше обращений в память к оставшейся таблице размещения страниц.
Т.е. размер самого TLB останется прежним
Ммм… а разве размер TLB можно в принципе поменять?
Насколько я знаю, нет. Я всего лишь уточнял комментарий про «уменьшение кэша, выделенного под таблицу размещения страниц», поскольку сам TLB, собственно и можно рассматривать в качестве этого самого кэша.
имеется в виду что меньше записей в кэше (он физический, вы с ним ничего сделать не сможете при всем желании), меньше вероятности кэш мисов так как меньше вероятности перезаписи.
Вот вы сейчас про какой кэш говорите? Я запутался! :)
Про тот, который физическую память кэширует или про TLB? И кэш-промахи при обращении к чему? К той части таблицы размещения страниц, которая не влезла в TLB, или при обращении уже собственно за данными, которыми оперирует программа?
А как на C/C++ кроссплатформенно(Linux/Win) выделить память на больших страницах. Что-то нагуглить ничего не выходит. Понимаю, что вопрос не совсем в тему, но больно уж удачно статья на близкую тему вышла :)
В win есть аналогичный механизм
Sign up to leave a comment.