Полигон-2

La Forge написал:

[q]

куча небольших CHM-файлов т.е

[/q]

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


La Forge написал:

[q]

один p3 кодирует видео и отжирает ресурсы -> комп неюзабельный

[/q]

выкрутите привритет в Idle, и комп опять юзабельный.


i8088 написал:

[q]

Переключите диск в PIO, и посмотрите что будет быстрее.

[/q]

так а чем второй проц в ПИО поможет?

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

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 - примерно пару секунд.
Потом мелкософт что-то докрутил в винде, и двухядерники потеряли такую отзывчивость.
Плюс сами программы стали использовать два и более ядер.