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