Метаслой: идеи о применении предсказания для оптимизации программирования и распределения ресурсов в ОС

[RPG18]

выбора наиболее оптимального числа потоков для параллельной обработки в цикле сложных данных — использовались динамически построенные в метаслое модели временных характеристик;

Зачем проделывать такую работу, когда можно было получить это число эмпирически?

[DrZlodberg]

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

[pekunov]

Если программа будет работать только на одной конкретной ЭВМ, то, конечно, можно и эмпирически. Но если ЭВМ заранее неизвестна, то все уже не так просто. Но это даже не главное. Объём вычислений в цикле может очень сильно зависеть от входных данных, соответственно и оптимальное число потоков может от них сильно зависеть. Если входные данные постоянно меняются, то единого эмпирического оптимального числа потоков просто нет. Вот тогда и может пригодиться построенная модель.

[RPG18]

А не проще взять несколько репрезентативных наборов данных разного объема и прогнать программу на 2, 4, 8, 16, 32, 64,… потоках. Построить [график](https://ru.wikipedia.org/wiki/%D0%97%D0%B0%D0%BA%D0%BE%D0%BD_%D0%90%D0%BC%D0%B4%D0%B0%D0%BB%D0%B0#/media/File:AmdahlsLaw.svg) и выбрать подходящее значение.
Тут мы можем упереться в количество ядер, закон Амдала.

[pekunov]

Если таких наборов данных — один или два, то можно и по графикам. А если их пять-десять-больше, то я предпочту что-то вроде того, что предлагается в публикации. Потому в начале и было написано про потенциально «большие данные», где подход может оправдать себя.

[RPG18]

А если их пять-десять-больше

Их все равно придется делать, что бы протестировать код.

про потенциально «большие данные», где подход может оправдать себя.

А там это нужно? Люди собирают кластер, с безумно большим количеством ресурсов, и не парятся.

[wlbm_onizuka]

Оптимальное число потоков равно числу ядер. Если же нет, то нужно оптимизировать код, а не число потоков.

[pekunov]

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

[qw1]

Представляю такую ОС будущего.

Пришёл с работы, поиграл часок в пасьянс, потратил 0,2 кВт⋅ч электроэнергии, лёг спать.
А система всю ночь обсчитывает модели и трассы этого пасьянса, задействуя все (неиспользуемые ночью) ядра и видеокарты, и к утру нажгёт 5 кВт⋅ч.

[pekunov]

:) Да, конечно, до такого лучше не доводить. А если серьезно, то для такой ОС целесообразно ввести простое ранжирование приложений по требуемому уровню обслуживания (пасьянсу — нулевой).