Полигон-2

BreakPoint написал:

[q]

только вот при доступе к множеству маленьких файлов дисковая система больше всего и нагружается.

[/q]

Та блин. Есть CHM-файл из сотни html-страниц. Если эту сотню мелких файлов по одному читать с диска это одно. Каспер же берёт ОДИН такой составной файл, распаковывает его в оперативке (если её хватает) и делает опять же всё в памяти. Повторю: с диска читается ОДИН файл. (когда сидишь на 98-й с 32Мб ОЗУ это очень чувствуется. Проверено на себе )

BreakPoint, на практике, к сожалению, приоритет не всегда можно установить - у антивируса, например, или у системных процессов, т.к. запрещён доступ. Кроме того, ведь постоянно запускаются разные программы, для каждой вручную ставить приоритеты... Конечно, есть сторонние утилиты, которые облегчают всё это дело, но всё равно два процессора или ядра намного комфортнее в работе.

Rio444 написал:

[q]

И незаметные 1-2% выливаются в 10-20% и больше.

[/q]

откуда инфа? напишите простенькое приложение, и запустите его под дос и под винду. и посмотрите какая будет разница. уж тожно не 10-20%

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

это во первых. во вторых в контексте многопроцессорных систем все становится еще хуже. планировщик потоков в винде не гарантирует, что поток будет всегда исполнятся на каком то процессоре. то есть исполнялся поток на процессоре 1, и тут вдруг планировщику что то стрельнуло, и он этот поток на проц 2 отправил. а все данные и код остались в кэше процессора 1. и вот проц 2 загружает в кэш код и данные. исполняет поток отведенный квант. и тут планировщику опять "стреляет" и поток перепланируется на проц 1.

естесвенно планировщик потоков не дураки делали, и он такие ситуации старается разруливать. но тем не менее такое случается. конечно поток можно "руцями" пригвоздить к определенному процессору. но гайд майкрософта по многопоточным приложениям этого крайне не рекоммендует.

более того, можно написать простую многопоточную программу, которая на системе с одним процом будет работать в несколько раз быстрее чем на системе с одним процом

По поводу отзывчивости ничего сказать не могу, т.к. это чисто субъективная оценка

BreakPoint написал:

[q]

откуда инфа? напишите простенькое приложение, и запустите его под дос и под винду. и посмотрите какая будет разница. уж тожно не 10-20%

[/q]

В DOS процессор тоже постоянно "отвлекается" на прерывания. Прогоните тесты на слабой машине, уровня 386, с отключенной и включенной мышью. А ведь прерывания мыши - далеко не единственные.
10-20% - экспертная оценка. Относится к не очень мощному процессору, до 1 ГГц.


BreakPoint написал:

[q]

то во первых. во вторых в контексте многопроцессорных систем все становится еще хуже. планировщик потоков в винде не гарантирует, что поток будет всегда исполнятся на каком то процессоре. то есть исполнялся поток на процессоре 1, и тут вдруг планировщику что то стрельнуло, и он этот поток на проц 2 отправил. а все данные и код остались в кэше процессора 1. и вот проц 2 загружает в кэш код и данные. исполняет поток отведенный квант. и тут планировщику опять "стреляет" и поток перепланируется на проц 1.

[/q]

Году в 2006 был у меня Athlon64 x2 3600 s939. С актуальной на то время виндой (скорее всего WinXP SP2), именно так и было. Создавалось впечатление, что одно ядро полностью отдано операционке, второе - основному приложению. Переключение по Alt+Tab из Prey в Windows происходило за доли секунды. На одноядернике Athlon64 4000 2400@2880 - примерно пару секунд.
Потом мелкософт что-то докрутил в винде, и двухядерники потеряли такую отзывчивость.
Плюс сами программы стали использовать два и более ядер.

BreakPoint написал:

[q]

есть у меня мамка на 440LX двухпроцессорная. если ее с одним процом запускать, то терминатор нужен?

[/q]

Формально нужен, но из-за невысокой FSB как правило и так работает. Во FreeBSD SMP
можно отключить kern.smp.disabled=1, и не надо вытаскивать процессоры.

Только не делайте эту проверку на версии FreeBSD 4.x, ее SMP очень сырой, используется
так называемая BIG GIANT LOCK, и выигрыш во многих задачах гораздо меньше теоретически
возможного. Иногда даже проигрыш был. Начиная с версии 5.x BIG GIANT стали дробить на
мелкие + новый планировщик - и работа SMP резко улучшилась!

Об отзывчивости - эта схема microsoft (GUI - один условный процессор, второй все
остальное) смешная и нелепая конечно, но для рабочей станции может действительно
уменьшать время реакции от user-а. Однако она плохо масштабируется, если число CPU >2.
А вот для сервера такая схема бесполезна, тк GUI там и не нужен фактически.


BreakPoint написал:

[q]

это во первых. во вторых в контексте многопроцессорных систем все становится еще хуже. планировщик потоков в винде не гарантирует, что поток будет всегда исполнятся на каком то процессоре. то есть исполнялся поток на процессоре 1, и тут вдруг планировщику что то стрельнуло, и он этот поток на проц 2 отправил. а все данные и код остались в кэше процессора 1. и вот проц 2 загружает в кэш код и данные. исполняет поток отведенный квант. и тут планировщику опять "стреляет" и поток перепланируется на проц 1.

[/q]

Я даже больше скажу - начиная с FreeBSD 8.4(именно 8.4) активный процесс периодически
меняет CPU, на котором он исполняется.

Так в версии 8.3 запускаем один экземпляр >dd if=/dev/zero of=/dev/null bs=1m> - и греется
AP CPU, BSP холодный. Запускаем второй экземпляр dd - грееются и AP, и BSP CPU.

В версии 8.4 даже один экземпляр dd "бегает" между CPU, и нагрев равномерный.

Все это видно по выводу >top -P>, переключение происходдит раз в несколько секунд.