Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Рассмотрим следующую ситуацию

PD>Надо пропустить достаточно большое количество задач, каждая из которых выполняет большое количество арифметических операций. Иных действий в задачах нет.Все данные для всех задач уже размещены в ОП. Всего задач N, причем К типов , каждого типа nk задач.

PD>Задачи независимы и выполнять их можно в любом порядке.

Условия какие — то сферические.

PD>Цель — пропустить все задачи за минимальное астрономическое время.
PD>Отнесем каждую задачу к одному из этих классов на основе интуитивных соображений. Вполне возможно, что это отнесение окажется неверным, это не беда(см. ниже).

PD>Выберем 4 задачи разных классов и запустим их под управлением собственного менеджера в отдельных потоках, при этом установим потокам affinity mask таким образом, чтобы каждый поток мог выполняться только на "своем" ядре.

PD>Через некоторое время (квант времени) менеджер определяет для каждой задачи счетчики производительности (количество кеш-промахов, количество переданных байт из RAM и др.) , анализирует их и выясняет, не мешают ли задачи друг другу. Если выяснится, что задачи мешают друг другу, значит , их первичная классификация была произведена неверно. В этом случае менеджер изменяет отнесение задачи к классу и приостанавливает одного из "конкурентов" , запуская следующую задачу, которая вроде бы по классификации не должна конкурировать за ресурсы с той задачей, что осталась.

PD>Вопросы же такие.

PD>1. Сама идея имеет право на существование ? Я тут ничего важного не пропустил, что может помешать ей реализоваться ?

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

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

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Рассмотрим следующую ситуацию

PD>Надо пропустить достаточно большое количество задач, каждая из которых выполняет большое количество арифметических операций. Иных действий в задачах нет.Все данные для всех задач уже размещены в ОП. Всего задач N, причем К типов , каждого типа nk задач.

PD>Задачи независимы и выполнять их можно в любом порядке.

Условия какие — то сферические.

PD>Цель — пропустить все задачи за минимальное астрономическое время.
PD>Отнесем каждую задачу к одному из этих классов на основе интуитивных соображений. Вполне возможно, что это отнесение окажется неверным, это не беда(см. ниже).

PD>Выберем 4 задачи разных классов и запустим их под управлением собственного менеджера в отдельных потоках, при этом установим потокам affinity mask таким образом, чтобы каждый поток мог выполняться только на "своем" ядре.

PD>Через некоторое время (квант времени) менеджер определяет для каждой задачи счетчики производительности (количество кеш-промахов, количество переданных байт из RAM и др.) , анализирует их и выясняет, не мешают ли задачи друг другу. Если выяснится, что задачи мешают друг другу, значит , их первичная классификация была произведена неверно. В этом случае менеджер изменяет отнесение задачи к классу и приостанавливает одного из "конкурентов" , запуская следующую задачу, которая вроде бы по классификации не должна конкурировать за ресурсы с той задачей, что осталась.

PD>Вопросы же такие.

PD>1. Сама идея имеет право на существование ? Я тут ничего важного не пропустил, что может помешать ей реализоваться ?

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

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