OSDev

Для этого достаточно линейно считывать большие блоки.


Для этого достаточно производить выборочное чтение.


Для этого достаточно наполнить кэш, а все следующие за этим циклы записи будут либо сквозными, либо вызывать сброс старого содержимого кэша в ОЗУ (что, в принципе, одно и то же).

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

Между комппами 8 толи 10 лет разницы.



Производительность выросла.
1,56=0,437500/0,280802
2,78=2,171875/0,780005
2,77=2,937500/1,060807
2,60=3,328125/1,279208
Производительность выросла в среднем 2,4275 раза

Скорость памяти выросла
4,50=0,140625/0,031200
1,80=3,125000/1,731611
3,77=13,234375/3,510022
2,26=10,625000/4,695630
Скорость памяти выросла в среднем 3,0825 раза

PS. это был замер на скорость. А где-то у меня ещё на задержки был но не нашёл.

Скорость памяти мало кому интересно. А вот особенность винды может быть.
Я произвожу колибровку измертельной системы. и выясняю насколько она равномерна.
Так вот за примерно 10-20 секунд наблюдается 300-500 выбросов. Велечина выброса порядка 0,001-0,002 секунд.
Это я так понимаю всякие прерывания системы обслуживаются. На производительности это оказывает погрешнось 0,5-1%.
Вы спросите как же переключения на другие задачи? Да на другие задачи виндоус тоже переключается, но делает это настолько редко либы тут же возвращает управление.
Те если другие программы возвращают, то я их отношу к прерываниям.

За 10 секунд при обычной работе максемальный выброс составил 0.153 секунды. он был единственным и это один случай из десятка запусков.
Т.е на производительность процессов длящихся 10 секунд и более оказывает влияние в виде 1,5% и то с вероятностью 0,1.

Обычная работа это запущенный автокад, антивирус, браузер, офис и тому подобное.

Правда если вы запустите расчёт чего либо в паролели, то ваша программа при условие установления на неё фокуса получит 75-50% рабочего времени.

Однопоточный тест-то, поди? Не очень интересно. А уж тест под виндой с кучей левого софта - совсем не то (давайте определяться на какую область смотрим, а то, например, в десктопных вещах и вебе производительность мало важна, важна отзывчивость).
Я тут про малый смысл тупого наращивания частоты и количества ядер не просто так говорил: когда несколько потоков/процессов бьются за память, то можно даже получать "прикольные" эффекты типа "с двумя включёнными ядрами задача считается быстрее, чем с 4мя". А много каналов просто так не сделать, да и начинаются проблемы что ОС должна правильно учитывать NUMA-ноды и хитро выделять память. Да и само приложение становится нетривиальным.

К слову, что винда, что линух - иногда одинаково печальные штуки. Реально продвинутые пендосы используют специальные ОСи для высокопроизводительных вычислений - те очень мало дёргают таблицы страниц, хитро контексты переключают и стараются всё мапить непрерывными большими кусками. И реально ведь получается выигрыш в производительности (можно в статейках с того же v3vee почитать), правда, оно всё очень закрытое. Пилите вот какой-нибудь BareMetalOS, родина не забудет (а потом догонит и ещё раз не забудет..).

Это какие высокопроизводительные вычисления? 462 из ТОП-500 суперкомпьютеров используют Линукс. Есть ещё более высокопроизводительные вычисления? В недрах АНБ?


Это как?


А это как?


Тут уже обсуждали потенциальный выигрыш. Получается примерно минус одно обращение к памяти на 1024 промахов мимо кэша, т.е. порядка 0.1%. Зато есть существенный проигрыш в эффективности распределения памяти, так что, овчинка выделки не стоит.

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

Линух бывает разный.
Собственно, накидаю ссылок на вентилятор:
http://en.wikipedia.org/wiki/Cray_XT3
http://www.sandia.gov/asc/redstorm.html
http://ieeexplore.ieee.org/xpl/freeabs_ ... er=1253322

Не понял, к чему эти ссылки. К тому что узлы Cray XT3 работают на SUSE Linux Enterprise Server?
А к чему ссылка на платную статью по сравнению производительности специализированного ядра LWK с обычным Линуксом? Там ведь самой статьи нет. Да и что удивительного в том, что специализированное ядро быстрей? Лучше бы дал ссылку на http://en.wikipedia.org/wiki/Lightweigh ... ing_System
Тут сразу понятно, что производительность специализированного ядра обеспечивается:
1. Использованием упрощённого алгоритма планировщика и менеджера памяти;
2. Вытравливанием всех демонов до абсолютного минимума;
3. Иерархической организацией некоторых демонов, таких как запуск задач, чтобы обеспечить масштабируемость на десятки тысяч узлов;
4. Тщательным выбором сетевых коммуникационных протоколов, чтобы обеспечить максимальную скорость обмена между узлами.
Ни о каких особенных способах переключения контекста и 4-мегабайтных страницах там не написано. Хотя я допускаю мысль, что такие страницы действительно могут использоваться в некоторых вариантах ядра для суперкомпьютерных вычислениях, если у тебя единственная задача работает сутками на десятках тысяч узлов, но это оооочень специфический случай и ощутимого выигрыша не даст.

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

Я про Cougar, Catamount и их предшественников.
> на SUSE Linux Enterprise Server
"OS based on SUSE Linux Enterprise Server" != "SUSE Linux Enterprise Server"

Ссылка на статью - можно ж найти где скачать статью нахаляву.

На тему дёргания страниц - распространённые версии linux (как и всякое десктопное ядро) очень любит всякие выделения памяти on-demand (выделим адреса, а дальше по #PF подтягивать страницы), ksm (и его более простые предшественники), поиск working set с последующим отсвопливанием невошедшего. В общем, таблицы страниц меняются много и часто.
На тему контекстов - пардон, я про переключение задач. Насколько понимаю, в специальных осях минимизируют как сами переключения (почти до состояния коллективной многозадачности), так и оверхед^W накладные расходы на них.

Ладно, вполне может статься что это становится заметным только когда начинают извращаться с виртуализацией: в случае спец. осей себя лучше ведёт shadow paging, в то время как в случае linux накладные расходы с shadow paging весьма и весьма велики, да ещё и шустро растут при масштабировании.

Я буду в виртуальном пространстве системы создавать для всех задач с окнами буфер для окна и при создании пространства для этой задачи ставить буфер этой задачи на то место где в системе стоит видео буфер экрана(у меня 8 мб - 20мб). Система должна видеть видео данные сразу всех окошек, чтобы их рисовать, а задача будет иметь постоянный адрес для своего окна. Т.е. виртуальное пространство задач будет хранить данные и код недоступные системе, чтобы с их помощью что то делать и результат показывать на экране, а сама задача будет видеть системный код и данные для его использования. Библиотеки можно будет грузить на пространство системы или задачи, по желанию.
Идея вроде не плохая, как думаете.
Пытаюсь спроектировать объект "Задача", в которой будет адрес каталога страниц и всякая инфа о задаче, плюс функции добавления памяти в задачу или освобождении и другие.

Кстати функция копировании файла с диска в нужные страницы задачи должна быть.