Проблема, собственно - понятна. Крайне малое число приложений, задействующих всю мощь CPU. Так что вопрос скорее в простых способах её решения.
Интересуют эти самые способы, т.к. кое какие уже есть, но их мало и кто-то может знает ещё. Заодно надежда на то, что на этот топик обратят внимание разработчики программ.
"Если гора не идёт к Магомету..." Поясню на примерах:
1. Архиваторы.
Не важно какой - запускаем на упаковку архива. Смотрим в диспетчер задач, видим, что загрузка далека от 100%. Для дальнейшего сравнения замеряем время процесса. Разбиваем архив на 2 - n примерно равных части (в зависимости от многопоточности архиватора и количества ядер CPU в системе), запускаем на архивацию каждый по отдельности, но одновременно. Получаем: загрузка 100%, резкое уменьшение времени процесса, правда у нас 2 - n архивов, несколько "лишних" манипуляций и проблема, если пакуется один большой файл. Собственно, куда смотрят разработчики, если они могут реализовать всё это без описанных проблем вместе с окончательным соединением частей в один архив прямо в архиваторе?
2. Кодирование видео.
Суть метода аналогична архиваторам, только предварительно режем файл, а потом склеиваем.

Вопросы вроде простого одновременного запуска разнородных приложений с целью 100% загрузки CPU в силу их банальности здесь не рассматриваем. Это скорей вопрос планирования собственных действий, играть ли одновременно с кодировкой видео или нет.

Очень хотелось бы узнать о замечаниях и дополнениях.

Модераторам: если посчитаете, что всё же ошибся разделом, просьба переместить куда нужно не пиная при этом. Вопрос, как-никак, очень насущный. Спасибо.

Нормальная ОСь сама разберется. Или ей можно подсказать. Помнится, видел однажды, как собиралась Генту на 8-ядерном ХРшном 380-том ПроЛаинте. Вот это было зрелище... 10-мегабитного канала не хватало.

вообще что-то изучал? многопоточные приложения, их проблемы, какие приложения УЖЕ используют более одного ядра?

смотря о каких архиваторах и средствах кодирования видео идет речь...

через что режем?

Именно для различным приложений - это одно.
Видеокодирование давно этим пользуется. С архиваторами не уверен, народ подправит.

А собстенно говоря в чем вопрос? "Почему не везде используются 2+ ядра?"
Если вкратце, то наиболее просто для реализации распараллеливать процесы приблизительно равные по вычислительным затратам и минимально зависящие от других вычислений/событий.

armadillo & QNX
Речь идёт про те, которые по многочисленным тестам и не только всё никак не могут приблизиться к 100% загрузки.

QNX
Да хоть через VirtualDub. Таких прог много.

Грецкий!
Для различных приложений их просто шедулить грамотно и всё. Той многопоточности, что реализовано в виндах - достаточно. Цель не стоит выжать все 100%. Вопрос в другом: почему всего 7%, когда можно 97%, 87% и т.п.? Т.е. нет даже смысла особо заморачиваться на приблизительную равность по затратам, хоть это и целесообразней. Время - важнее. Если смотреть на КПД загрузки того же CPU в неделю/месяц, процентов - вообще кот наплакал.
С архиваторами просто оказался наиболее показательным пример того, когда есть всего одна задача, но сделать её нужно именно сейчас и эффективность её выполнения можно повысить даже в разы. И когда додумываешься до этого, недоумеваешь, почему почти никто так не делает, и что пришлось придумывать самому, а не всего лишь спросить кого-то.

а в данном случае? мне интересны детали режима работы, который подразумевается под

Потому что при создании большинства приложений распараллеливание или не применяется (скорее всего) или применяется, но распаралеливаются только мелкие задачи.

ну так при работе winrar и 7zip загрузка обоих ядер доходит до 100%

Базара нет, почему так не справедливо, ведь в основе своей мощные процессоры простаивают (наприм. мой 8400), т.е. даже в серьёзных играх (COD 4) загрузка не на полную при макс. настройках. Да хрен с ними с играми, насколько шустрее были бы процессы кодирования видео или архивация !!!

Странно... на моем winrar даже два ядра (из 4) полностью не загружает, а 7zip - грузит на 100% все что есть (если принудительно не указать что использовать только 2)

AlexGogo

может процессор слишком быстрый, и архиватор тормозит из-за медленного HDD?

+1 для мощных CPU тесты стоит проводить на данных, размещенных на виртуальных дисках.

это вопросы к девелоперам.

QNX
Тот же виртуалдуб позволяет много чего делать с видео покадрово, не только резку-склейку. Ему, кстати тоже не хватает подобного описанного для архиваторов "внутреннего" режима работы с дозагрузкой CPU (и не только CPU, т.к. принцип применим ко многим девайсам).

В том-то идело, что загрузка Rar`ом и 7zip только обоих ядер CPU. А если у тебя их 4 или 8 (Skulltrail)? Дальше в процах - больше ядер будет.

Возможное наличие медленного HDD я в методологии учёл. В том смысле, что описана ситуация, когда он не ограничивает. Если же ограничивает, то тут стоит задуматься либо о смене носителя, если возможно, либо о некотором увеличении степени компрессии (всё равно в случае медленного винта она будет условно бесплатной).

ядерный отход
Так это и есть отчасти вопросы к девелоперам. Почему у меня в моём примере всё работает, а у них - нет? Если я это делаю так просто, то что сложного у них-то? Я какой-то особенный?

Silent forest
Согласен. И не только тесты. Например, для того я себе и поставил 2 x I-Ram в Raid 0. Это для "кэширование" того, с чем я сейчас работаю. Не важно, гама это или кодирование видео. Зато чистые 270 МБ/сек при 50 мксек доступ. Тоже своего рода оптимизация, только не программная, как я предложил в первом посте, а аппаратная и для носителей, а не для CPU.

demonnn
Ну почему же хрен с играми? Помнится тот же Doom 3 народ перепаковывал зипом на макс. сжатие чтобы ускорить его загрузку с медленных винтов. Читай, переложили часть работы на CPU.

Вот если сравнивать карбон на 1 и 2ядерном проце, то на 1 лагает страшно, хотя фрапс показывает 35-60 кадров.А если поставить 2 ядерный , то ничё не лагает и идёт идеально.Почему? Тоже не понятно.

Unrealyourock
Если ошибается даже фрапс, то похоже, что либо в дело вклинивается какой-то процесс (похоже с реалтайм приоритетом) и стопарит всех (в фоне ничего такого не запущено? Критические обновления и прочая хрень - всё стоит?), либо может ставил софт на 2 ядра, а потом отключал одно. Тогда проги и дрова могут не знать про это и пытаться использовать оптимизацию под 2 ядра, что и вызывает сбои (понятно, что те же кэши общих ресурсов при этом работают в совершенно разных режимах и по разным алгоритмам).

Ааа, знакомо. Почему девелоперы такие [вписывается].
Потому, что раньше это было не надо, вот почему.
Информация 'на подумать':
1. как ты будешь разделять на треды процесс, который делает А->B->C->D?
Для обработки видео это будут фильтры. Для справки - некоторые фильтры работают не только с одник кадром, им нужен предыдущий(е) и 'последующий'.
Если ответом будет 'через какое-то место', то учти, на конвертирование и согласования 'этого места' надо время и поддержка специального формата.
(для справки - в avisynth есть соответствующий фильтр)
2. скорость работы N процессоров не быстрее в N раз. Могу привести вполне численный пример, в S&M тест памяти на нескольки ядрах идет медленнее, чем на одном(!)
Кроме ядер процессора есть еще и сопутствующие компоненты, которые явно теряют производительность при множественном доступе.
Добавлено спустя 3 минуты, 34 секунды
3. При работе нескольки процессоров с общими данными скорость падает от 'ужастно' до 'катастрофически'. (а при распараллеливании, что делают разные треды?)
Вовсе не от хорошей жизни в К10 поставили кешь 3 уровня.
В этом отношении самый эффективный и сбалансированный процессор - C2D (не путать с C2Q).

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

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

Не читал всех постов, но скажу пару слов в защиту разработчиков. На примере архиваторов, любой программер может написать архиватор, который будет кушать 100% процессорного времени по крайней мере для одного ядра, для всех остальных это сделать тоже не трудно. Но, если загрузить CPU на 100%, не те, что показывает Process Explorer, а реальное процессорное время, то вы даже курсор едва сможете пошевелить, слушатели событий просто не смогут уловить событие и если вы начнёте что-либо архивировать, то прервать этот процесс будет не просто, особенно если это можно будет сделать только кликом мыши! В связи с этим, в настоящее время и уже достаточно давно, все приложения многопоточные (на уровне ОС) и в частности не целесообразно отдавать процессу архивации все 100%, поэтому отдаётся по возможности не более 95%. "По возможности" связано с особенностью работы многопоточности в определённой ОС, именно она регулирует этот процесс. Что касается аппаратной реализации в случае с многоядерностью, то ситуация конечно сложнее, потому как производители CPU используют свои собственные технологии для повышения производительности приложений не приспособленных к многоядерности и в результате многоядерный CPU в таком случае с точки зрения ОС выглядит как обычный одноядерный. Кто не согласен, начинайте бить ногами!

Ещё не стоит забывать о приоритетах, ОС организует многопоточность с использованием приоритета процесса, и если вы вашему архиватору отдадите приоритет реального времени, при условии, что он будет использовать 100% CPU TIME, то, что называется "вешайтесь" .