Здравствуйте!

Есть программулина. Написана на дельфях. Есть 2 ядерный процессор.
Программулина выполняет достаточно емкие и обьёмные задачи. При выполнении программы процессор максим загружаеться на 50%. При этом остальная часть ресурсов бездействует. Можно ли как-то использовать все ресурсы процессора?

Заранее всем огромное спасибо!

-----
моя подпись!

| Сообщение посчитали полезным:

Просто в проге 1 поток, и он по-переменно испоняется на каждом порце. В результате 50%.

| Сообщение посчитали полезным:

s0larian пишет:
Просто в проге 1 поток, и он по-переменно испоняется на каждом порце. В результате 50%.
т.е. выход только в создании многопоточности? А выхлоп будет? Намного увеличиться скорость?

-----
моя подпись!

| Сообщение посчитали полезным:

Используй RealTime -приоритет, т.к. писать под многоядерные/многопроцессорные платформы никто не хочет.

-----
продавец резиновых утёнков

| Сообщение посчитали полезным:

locker_fx, ессно выход только в дополнительных потоках. Есть есть несколько ядер, то для их использования надо несколько потоков (или процессов). У NT/XP операционок unit of scheduling это поток. Если у тебя простая задача типа brute force, то распараллелив вычисления на два потока ты получишь прирост производительности в два раза. Ессно не всё так просто в других задачах, т.к. будут потери времени на синхронизацию/сообщения/события/сигналы.

Про процессы - иногда проще написать маленький manager запускающий несколько процессов с кусками задачи. В этом случае не надо реализовывать потоки/сихронизацию.

| Сообщение посчитали полезным:

юзай SSE

| Сообщение посчитали полезным:

s0larian пишет:
locker_fx, ессно выход только в дополнительных потоках. Есть есть несколько ядер, то для их использования надо несколько потоков (или процессов). У NT/XP операционок unit of scheduling это поток. Если у тебя простая задача типа brute force, то распараллелив вычисления на два потока ты получишь прирост производительности в два раза. Ессно не всё так просто в других задачах, т.к. будут потери времени на синхронизацию/сообщения/события/сигналы.

Про процессы - иногда проще написать маленький manager запускающий несколько процессов с кусками задачи. В этом случае не надо реализовывать потоки/сихронизацию.

Моя задача не юрут форс. НО ращделить на несколько независимых частей можно. К примеру есть 6(может быть чуть больше, а может чуть меньше) частей, на которые можно разделить для параллельной обработки. Как лучше сделать: создать 6 потоков(в каждом обрабатывать свой кусок) или 2 потока (в каждом обработать по 3 части) ?

-----
моя подпись!

| Сообщение посчитали полезным:

HiEndsoft пишет:
Используй RealTime -приоритет, т.к. писать под многоядерные/многопроцессорные платформы никто не хочет.

procedure TForm1.FormCreate(Sender: TObject);
begin
SetPriorityClass(GetCurrentProcess, REALTIME_PRIORITY_CLASS);
end;

-----
Что один человек сделал , другой всегда сломать может...

| Сообщение посчитали полезным:

Воспользуйся логикой. Если 6 сущностей предназначены для пераллельного выполнения, то запускай их в отдельных потоках, прочитав про синхронизацию у Рихтера. Только не занимайся ерундой вроде рилтайм приоритетов, если нет желания провесить систему.

| Сообщение посчитали полезным:

MACKLIA пишет:
procedure TForm1.FormCreate(Sender: TObject);
begin
SetPriorityClass(GetCurrentProcess, REALTIME_PRIORITY_CLASS);
end;
Попробовал, разницы не заметил.

S_T_A_S_ пишет:
Воспользуйся логикой. Если 6 сущностей предназначены для пераллельного выполнения, то запускай их в отдельных потоках, прочитав про синхронизацию у Рихтера. Только не занимайся ерундой вроде рилтайм приоритетов, если нет желания провесить систему.
Вот как раз из-за соображений логики и спрашиваю:
Смотри. Если я сделаю 6 потоков, то по логике выполняться все сразу на полную мощь они не смогут(по логике только 2 могу на полную мощь, 50% берёт один, а оставшиеся 50% заберёт другой). Но винда подумает, что выполнять надо все 6 параллельно, и имхо будут потери среди переключений между этими потоками. Или я не прав?
Поэтому и спрашиваю, что лучше 6 потоков или 2?

-----
моя подпись!

| Сообщение посчитали полезным:

Сейчас 2 ядра, завтра 4, опять переписывать? Оверхед от переключения контекстов практически не зависит от того, сколько тредов в твоём процессе - в системе их и так еще несколько сотен. Гдавное не создавать и не уничтожать треды постоянно - это дорогая операция в винде.

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

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

| Сообщение посчитали полезным:

S_T_A_S_ очень правильно всё говорит. Добавлю лишь что тебе надо написать абстракцию потоков и задач и потом изменить главную часть проги что б она закидывала эти задачи. Потом посмотришь как себя ведёт прога на 1/2х/4х процессорной системе с pool-ом из 1го/2х/3х/4х/10ти потоков.

| Сообщение посчитали полезным:

s0larian пишет:
locker_fx, ессно выход только в дополнительных потоках. Есть есть несколько ядер, то для их использования надо несколько потоков (или процессов).

Нет никакой гарантии что два потока будут выполняться на разных ядрах, а не на одном ;)

-----
have a nice day

| Сообщение посчитали полезным:

locker_fx пишет:
Попробовал, разницы не заметил.

Ну значит установка более высокого приоритета в твоём случае не канает.

Nimnul пишет:
Нет никакой гарантии что два потока будут выполняться на разных ядрах, а не на одном ;)

Практика покажет ,у меня к сожалению железо старое ,так что услышу ответ от других испытателях.

-----
Что один человек сделал , другой всегда сломать может...

| Сообщение посчитали полезным:

Гарантии есть в MSDN: The SetThreadAffinityMask function sets a processor affinity mask for the specified thread. Хотя SetThreadIdealProcessor может оказаться лучше.

| Сообщение посчитали полезным:

Nimnul пишет:
Нет никакой гарантии что два потока будут выполняться на разных ядрах, а не на одном ;)
Статистически, поток поподает на процессор с вероятностью примерно 50%. Удвоим кол-во потоков, и удвоим загрузку. Опять же, статистически, наши два потока кушают большцю часть времени, и scheduler сможет закинуть второй поток на второй проц когда перывй занят. Гарантии нету, это ж не RTOS, но статискика близка к теории.

| Сообщение посчитали полезным: