Является ли эта идея проекта Java практичной? (Планировщик потоков и частицы Swarm Optimization)

Question

На коробке многоядерной, решения планировщиков Java нить достаточно произвольны, он назначает приоритеты потоков на основе, когда была создана нить, из которой нити она была создана и т.д.

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

Конечно, было бы больше параметров, так как приоритеты будут сдвигаться во время прогона, чтобы найти оптимальную функцию приоритета.

Насколько практично, интересно звучит идея? и любые предложения. Только некоторые фон, Являлся программированием в java/c/C++ в течение нескольких лет с различными проектами, другой альтернативой было бы создание планировщика потоков на основе этого в c, где планировщик потоков по умолчанию является ОС.

Answer 1

Лучший способ узнать - начать проект с открытым исходным кодом и увидеть использование/реакцию людей.

Мне кажется очень интересным для меня - но я лично лично не очень полезен. Возможно, мы просто не в той точке, где параллельное программирование столь же распространено и легко, как могло бы быть.

С поощрением функционального программирования, я думаю, что мир будет двигаться в направлении избежать синхронизации потоков как можно больше (что делает нить планирования меньше влияния на общую производительность)

Из моего личного субъективного опыта, максимальной производительности проблемы в программном обеспечении могут быть решены путем улучшения одной области узких мест, на которую приходится 90% замедления. Этот оптимизатор может помочь найти это. Я не уверен, насколько стратегия планирования может улучшить общую производительность.

Не обескураживайте! Я просто говорю из воздуха. Это звучит весело, так почему бы не просто поиграть с ним в любом случае :)

Answer 2

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

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

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

Я думаю, что это несколько субъективный вопрос, но в целом нет, не думайте, что это сработает.