Как стать автором
Обновить

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

Время на прочтение 4 мин
Количество просмотров 2.3K
Всего голосов 5: ↑5 и ↓0 +5
Комментарии 10

Комментарии 10

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

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

Особенно если учесть, что создатель задачи априори обладает существенно большей информацией о её потребностях. В том числе и о будущих, которые зачастую невозможно предсказать по текущим. Да и задача сама вполне способна (при правильном подходе) динамически подстраивать свои потребности под доступные ресурсы. Единственное, что для этого требуется — возможность простого получения реалистичной информации об этих самых ресурсах (без учёта эмуляций и виртуализаций)
Если программа будет работать только на одной конкретной ЭВМ, то, конечно, можно и эмпирически. Но если ЭВМ заранее неизвестна, то все уже не так просто. Но это даже не главное. Объём вычислений в цикле может очень сильно зависеть от входных данных, соответственно и оптимальное число потоков может от них сильно зависеть. Если входные данные постоянно меняются, то единого эмпирического оптимального числа потоков просто нет. Вот тогда и может пригодиться построенная модель.
А не проще взять несколько репрезентативных наборов данных разного объема и прогнать программу на 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) и выбрать подходящее значение.
Тут мы можем упереться в количество ядер, закон Амдала.
Если таких наборов данных — один или два, то можно и по графикам. А если их пять-десять-больше, то я предпочту что-то вроде того, что предлагается в публикации. Потому в начале и было написано про потенциально «большие данные», где подход может оправдать себя.
А если их пять-десять-больше

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


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

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

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

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

Публикации

Истории