В приведенном примере мы имеем самый простой случай, когда из задачи размера N делается 2 независимых задачи размера N / 2 , поэтому имея к ядер мы получаем увеличение скорости в k раз теоретическое. Проблема состоит в том, что не все задачи поддаются такой процедуре, из-за того, что возникают проблемы с синхронизацией, а так же, разумеется не все задачи подлежат такой декомпозиции, потому что итерации / этапы могут быть зависимыми. Но и этим дело не кончается. Особый случай мы получаем в играх. Например Crysis работает следующим образом: на одном ядре делается физика на другом - логика и рендеринг. Здесь возникает проблема, что кадр уже просчитан. а физический модуль ещё не до считал, либо же наоборот - физика опережает рендер, поэтому приходится ждать пока он закончит. В первом случае мы наблюдаем эффект запаздывания реакции на наши действия. например, с клавиатуры, во втором случае - процессор простаивает. Как вы можете заметить, здесь довольно таки сложный механизм нарисововается. Поэтому о простых решениях и речи не идет. Что касается не рилтайм приложений - то создавать разное число потоков взависимости от разного числа ядер концептуально просто, на деле чуть сложнее.Возникает ряд проблем:например, на самом деле HDD даёт неслабый оверхэд, поэтому чтобы параллелизация работала очень эффективно, можно грузить в RAM всё.

С квадом дела вообще очень сложно и туманно. Я думаю этот вопрос лучше задать на форуме Intel. Я с квадом никогда не работал. Возможно выбираются два наиболее незагруженных ядра.

Теперь поговорим об архиваторах. У меня Winrar работает в 3х потоках. Это скорее всего означает что система там Отец-сын-сын. У вас видимо старый винрар. Однако периодически видно, что двое потоков кудато пропадают периодически и появляется один. Это скорее всего означает, что там система менеджера заданий. Главный поток даёт этим двум задания, а когда они отрабатывают - то они терминируются, главный поток это видит и дает им новые задания. Это сделано для того, что это очень эффективно позволяет параллелить на разное число ядер. Однако создается оверхэд определенный.

Грецкий!
C архиваторами. Ведь это вполне реально. Я уже даже привык начинать думать заранее, чтобы собирать однотипные задачи в кучу и так их реализовывать.

Dick46
А собственно зачем этим заморачиваться?
Добавлено спустя 31 минуту, 3 секунды
Aside & All
Работать через RAM действительно эффективно. На её примере после I-Ram у меня как-то родилась следующая идея:
I-Ram очень сильно ограничен завязкой на SATA. Хотя при этом он даёт очень весомое преимущество. При чём самое интересное, что то, на чём обычный винт в реальном использовании проседает не по-детски, т.е. при множествнном доступе к разбросанным участкам и малом их размере (до считаных мегабайт в секунду), I-Ram остаётся на пике. Супер! Но лучшее - всегда враг хорошего. Мегабайты в секунду - не гигабайты, как у ОЗУ. Микросекунды доступа - не наносекунды, как у неё же. Многие юзали Рамдрайв и знают это не по-наслышке. Так вот -вопрос: если всё воспринимать в виде иерархии кэш систем, чем Вам это не кэш 3 или 4 уровня после проца и т.д. по уровням через I-Ram до винта или чего там ещё может быть через WiFi и пр.? Закон производительности/ёмкости/стоимости тут своей стабильностью и закономерностью вполне напоминает закон Мура. Я к чему? Наиболее распространённая XP 32 bit видит максимум 3,4 ГБ ОЗУ, 0,5 от корорых отобрал маппинг девайсов. ОК. Наиболее распространённый софт юзает вообще не больше 2-х ГБ и мы обычно не заинтересованы из-за многих узких мест юзать всё это многозадачно. Ну так отлично! Если мамка поддерживает до 8ГБ ОЗУ, давайте отдадим 2 - винде, 0,5 девайсам, а остальные 5,5 можно БИОСом же отдать под некий виртуальный HDD с опупенной производительностью (понятно, что со своей системой адресации и пр.), пусть и энергозависимый, но за то всякие ReadyBoost Flash драйвы не то, что нервно курят в сторонке... Пусть я и отклонился от темы топика, но про самый тормоз в любом ПК (а именно он чаще всего CPU imho и мешает) - поговорить стоит. Ну действительно, в тех же гамах, когда нервы уже сдают от этих длительных "лоад", представьте, какой кайф, когда уровень или сейв грузится порой не минуту, а 6 секунд! (без балды! примеры нужны?)
Другим языком, стоит представить, что ты нафаршировал свой ПК во все возможные щели (как того позволяет конфа) и теперь есть некое раздолье, как поднять эффективность, отдав некоторую работу одних девайсов - другим. Это как бы ещё один взгляд на тему топика. Это сначала: "а нафига", "да вроде дорого и глупо", "да это мне не нужно", - а потом, когда просекаешь - втягиваешься, мама не горюй.
Добавлено спустя 4 минуты, 33 секунды
+ Aside
3 потока архиватора или 33 - не важно. Суть в том, что имея в запасе ещё ресурсы - ты можешь их использовать. Я лишь говорю, что вместо подёргать ещё пару минут пальчиками по клаве, чтобы заставить наш пресловутый архиватор задействовать оставшиеся потоки в работу, софт может предложить нам сделать это сам. Тоже, читай, вроде after-оптимизация, но уже своей собственной работы. "Время, понимаешь - жалко" (С) ...

У меня, когда стояла Vista x64, под ускорение реально задействовалась часть памяти из установленных 6Гб (технология только называется Superfetch вроде). Многие программы действительно быстрее загружались, например Document Explorer для MSDN 2008 - моментально, если сравнивать с классикой в Win 2003 x64. Что касается большого RAMDISK- у меня одно время была мечта нашпиговать серверную маму под 64Гб FB-DIMMами, и в ней установить RAMDrive Plus. Дороговато только оказалось это для реализации.. Сейчас мечтаю рядом с компом поставить мамку Gigabyte GA-P35-S3G, нашпиговать ее i-RAMами до 5 штук (пока только один есть), а на сам комп подключить шустрый SATA-RAID(PCI-E) контоллер с дополнительными 256МБ кэша. Боюсь только, что раньше чем у меня появятся лишние деньги, выйдет новая ревизия (не PCI) с поддержкой DDR2 и SATA300.