Ulrich Drepper (http://people.redhat.com/drepper/) опубликовал полный текст документа "What every programmer should know about memory (http://people.redhat.com/drepper/cpumemory.pdf)" (PDF, 900Кб). Это одна из лучших и подробных (114 страниц) публикаций, в которой затрагиваются различные вопросы взаимодействия ПО с памятью и советы по оптимизации.
Ниже ссылки на текст разбитый на главы, ранее доступный только для подписчиков lwn.net:
- "Introduction (http://lwn.net/Articles/250967/)" - аппаратная организация работы памяти;
- "CPU caches (http://lwn.net/Articles/252125/)" - работа кэшей CPU;
- "Virtual memory (http://lwn.net/Articles/253361/)" - рассказ о виртуальной памяти;
- "NUMA systems (http://lwn.net/Articles/254445/)" - особенности архитектуры NUMA (Non-Uniform Memory Access);
- "What programmers can do - cache optimization (http://lwn.net/Articles/255364/)" - оптимизации связанные с эффективным использованием кэша CPU;
- "What programmers can do - multi-threaded optimizations (http://lwn.net/Articles/256433/)" - оптимизации для многопоточных приложений;
- "Memory performance tools (http://lwn.net/Articles/257209/)" - средства для оценки скорости работы программы с памятью;
- "Future technologies (http://lwn.net/Articles/258154/)" - технологии будущего;
- "Appendices and bibliography (http://lwn.net/Articles/258188/)" - примеры кода и список литературы.URL: http://lwn.net/Articles/259710/rss
Новость: http://www.opennet.me/opennews/art.shtml?num=12909
Мега-интересно. Автор - настоящий джедай.
эх был бы я девелопером :)
(немного поразмыслив) Такие девеловские
статейки клад для игрописателей. Вот начнут
игры под линукс писать, эт пипец будет :)
возможность выжать 100% производительности
из железа) тогда точно все про венду забудут
Самое удачное приспособление для игр -- это игровая консоль ("приставка"). Почему? Потому что лишь в этом случае аппаратные средства жестко ограничены и ненаращиваемы, поэтому девелоперам ставят задачу вместить как можно более интересную/красивую/прожорливую игру в эти жесткие аппаратные рамки.В случае же с PC всегда можно на CD-коробке с тетрисом написать: "Requirements: IBM BlueGene" и никто не будет заниматься какой-бы то ни было оптимизацией.
Для наглядного примера достаточно вспомнить Sony Play Station -- там были такие игры, аналогов которым по интересности, красоте и скорости не было на PC, а если и были, то с требованиями к железу во много раз превосходящим вычислительные способности SPS.
Блин развели опять не нужную демагогию, лучше обсудите теоретические вопросы, что из этого можно ещё где пременить, или как всегда только еденицы прочитали эту статью целиком.
> Блин развели опять не нужную демагогию, лучше обсудите теоретические вопросы, что из
> этого можно ещё где пременить, или как всегда только еденицы прочитали эту статью целиком.Теоретик? прочитал целиком? ну и как впечатления? на практике будешь применять?
На самом деле не нужно читать всю охапку "от корки и до корки"
чтобы понять что там написано. Не так много задач, где
могут потребоваться такие оптимизации - это игры,
обработка видео/аудио. В серверных приложениях, полагаю,
авторы не дураки и всеми этими фишками пользуются.
Узкоспециализированные области вроде рассчетов по химии/физике
думаю даже затрагивать не стоит.
> Узкоспециализированные области вроде рассчетов по химии/физике
> думаю даже затрагивать не стоит.А вот и напрасно.
Был я тут на конференции по High-Performance Computing. Слушал умных дядечек из Саровского инженерного центра (это "открытая" часть кадров ВНИИЭФа - если вы не знаете, что такое ВНИИЭФ, про "узкоспециализированные области вроде расчётов по химии/физике" вам лучше вообще не заикаться). Они приводили великолепную табличку "прожорливости" применяемых в миру алгоритмов. Так вот, наименее прожорливыми оказались всякие там прогнозы погоды, "середнячками" были молекулярная динамика, CAM и CAE (да-да, гидроаэродинамика и динамическая теория сопротивления материалов -- это, как оказалось, далеко не предел мечтаний :), а почётное первое место заняли таки квантовомеханические расчёты.
Что, впрочем, очевидно: квантовая механика "скушает" столько вычислительной мощности, сколько у вас есть: чем у вас её больше, тем с большим количеством электронов систему вы сможете обсчитать.
Один мой старинный друг в своё время работал в аспирантуре в США, занимался там сравнением GAMESSа с Gaussianом (ну, не только этим, но и этим тоже :). Так вот, он показывал мне толщину пачки бумаги, на которой он распечатал _только_ тот код, который считает обменные интегралы в операторе Фока. Листов так под четыреста будет... Оптимизируется _каждый_ частный случай. Иначе вообще ничего посчитать будет нельзя.
Так что как раз-таки "расчётникам" такие оптимизации будут _очень_ кстати. ;)
P.S: Определитель Гаусса средненького белка -- 70..90 ГИГАбайт. ОЗУ мы тоже очень любим. ;)
Однако, интересно. Вот у нас тут тоже 95% химиков пользуются Gaussian, кватовомеханические рассчеты. С ними меньше всего проблем :)) Только железа давай побольше :))
>P.S: Определитель Гаусса средненького белка -- 70..90 ГИГАбайт.
> ОЗУ мы тоже очень любим. ;)Вы ещё юэаете 2-х мерные массивы, ........... ню-ню.
>>P.S: Определитель Гаусса средненького белка -- 70..90 ГИГАбайт.
>> ОЗУ мы тоже очень любим. ;)
>
>Вы ещё юэаете 2-х мерные массивы, ........... ню-ню.ага, матрица как правло не более 5 % заполнения, а если привести к ленточно-диагональному виду то очень компактно можно хранить. Эх мне бы да эту статью лет 5 назад, когда я решал диф уравнения в частных производных, а сейчас для меня не сильно актуально. Кстати есть очень много алгоритмов по работе с матрицей, еще придуманных в 80 годах. Так вот на лично препод показывал как обрабатывал матрицы размером 1000 на 1000 на i386 методом кусочной обработки с хранением промежуточных решений на винте. Щас книжки пошли, только один перевод забугорного хлама, например, самый "крутой" медод решения диф. урав. метод рунге кута 6 порядка или нелинейный метод эйлера - и ето все, реальные задачи (молекулярная физика, химия, електроника) на них расходятся. Или все нелинейные задачи сводят к методу ньютона, хотя есть много прогресивных методов которые по сходимости на порядок лучше