Войти
ПрограммированиеФорумОбщее

Потестируйте билд на Unity на предмет загрузки процессора

#0
14:06, 23 мая 2019

Потестируйте, пожалуйста, билд на Unity на предмет загрузки процессора: https://dl.dropbox.com/s/flay945gn4ifwpr/Fluids.zip (Win x64, 20 Мб)

Интересует четыре вещи:

Для любой ОС

1. Загрузка процессора процессом Fluids.exe в диспетчере задач на закладке «Процессы» в Windows 7 или на закладке «Подробности» в более свежих ОС.

Теоретически там должно быть 100%. Vsync в проекте выключен и он при любом количестве частиц должен грузить процессор на полную. Если вдруг ваш процессор жутко быстрый и 40000 частиц по умолчанию ему мало для полной загрузки, можно поднять количество частиц клавишей «2» до максимального количества 65000. Если и этого окажется мало и скорость будет упираться в видео, можно отключить рендер точек и линий клавишами «P» и «L». Тогда уж точно скорость упрётся в процессор. Но, я думаю, она и так в него упрётся сразу.

Лично у меня 100% никогда не получается, 4-ядерный процессор загружен на ~75%, а остальные ~25% ― бездействие. Три рабочих потока шуруют на полную, а главный поток предпочитает их ждать и ничего не делать. От кадра к кадру иногда тоже включается в работу, но в среднем можно считать, что бездействует. Непонятно, с чем это связано. Возможно, Unity или Windows неправильно определяют истинную загруженность процессора.

+ Показать

2. Разогнан ли процессор? Мой разогнан с 3,3 до 4,4 ГГц.

Для Windows 10

3. Загрузка процессора процессом Fluids.exe на закладке "Процессы". Совпадает ли это значение со значением в первом пункте? У меня не совпадает:

+ Показать

4. Показывает ли менеджер задач правильную частоту процессора? Она там написана аж в четырёх местах:

+ Показать


#1
15:08, 23 мая 2019
+ Показать

загрузка порядка 70% (это не ошибка)
а так юнити очевидно резервирует часть CPU для всего прочего. было бы глупо загрузить все ядра вхлам и не оставить времени на рендер и прочую лабуду

железо гавно, но GPU симуляция конечно быстрее. правда в упор загружает видяху, что тоже зло.
Изображение

#2
(Правка: 16:07) 16:02, 23 мая 2019

Не должен Unity резервировать. В коде в очередь добавляется цепочка зависящих друг от друга IJobParallelFor-джобов, способных загрузить все ядра на 100% одновременно, без простоев, и в конце вызывается jobHandle.Complete(). Соответственно, главный поток не может продолжить выполнение, пока все джобы не будут выполнены. Этот Complete в главном потоке должен распределить джобы по потокам так, чтобы выполнить их как можно быстрее, в том числе часть работы выполнить самому. Так оно и происходит, если в очереди один джоб ― он выполняется на всех доступных потоках/ядрах. Если же джобов в очереди несколько, то первый выполняется на всех ядрах, а остальные иногда тоже на всех, но чаще главный поток не помогает, а стоит и ждёт, пока другие не выполнят всю работу.

Если jobHandle.Complete() вызывать не один раз, а много ― после добавления каждого нового джоба, то работает как ожидается ― все потоки заняты вычислениями, вычисления выполняются быстрее, простоев нет, больше FPS.

Если вызывать jobHandle.Complete() один раз в конце (как в демо), то работать в теории должно точно так же. Даже рекомендуется не вызывать Complete без надобности. По факту получается хрень. Эмпирически установлено, что вероятность выполнения джоба всеми потоками/ядрами зависит от порядкового номера джоба в очереди. На глаз что-то типа 95%, 15%, 3%, 0%, 0%... Первый джоб у меня короткий и на скольких ядрах он выполняется, особо на скорость не влияет. Второй и третий ― самые долгие.

В этой демке на рендер по сравнению с симуляцией времени тратится очень мало. На втором скриншоте обособленный синий кусочек в 1,5 мс в конце кадра ― это рендер ~400 000 линий и 40 000 точек. Но линии и точки можно выключить и посмотреть, не вырастет ли загрузка процессора.

#3
16:30, 23 мая 2019

alexzzzz
честно сказать не знаю как там внутри устроен планировщик юнити, очевидно там не все прозрачно.
я в нативе парралелил - грузит все ядра как и положено, без танцев с бубном.
на счет рендера у меня сомнений нет, оно все отлично, симуляция у меня будет вялая что на юнити что в нативном коде по этому тут не оценить.

#4
(Правка: 16:51) 16:46, 23 мая 2019

на ноуте первую минуту было 99% (95 на приложение остальное на всякую фигню), дальше упало до 77% и вентилятор тоже утих.

+ Показать

на графике виден переход от полной нагрузки к неполной.
+ Показать

при повторном запуске аналогично - полторы минуты 98% дальше 80%

+ Показать
#5
16:56, 23 мая 2019

А на закладке «Подробности» у fluids.exe загрузка такая же?

#6
(Правка: 17:20) 17:20, 23 мая 2019

alexzzzz
забавно, на вкладке "подробности" загрузка ~80% и в первую минуту и после, остальные 24% - бездействие.
Возможно, там по-разному учитывается время проведенное в системных вызовах или что-то в этом роде.

#7
20:29, 15 июня 2019

У меня на всех восьми по максимуму, по процентам 85% загрузка.

#8
20:56, 15 июня 2019

В диспетчере задач Windows 10 на закладке «Производительность» на картинке показана полная загрузка 8 ядер, а на закладке «Подробности» у процесса Fluids.exe загрузка ЦПУ 85%, а остальные 15% приходятся на бездействие.
Я правильно понимаю?

#9
21:05, 15 июня 2019

alexzzzz
Да, только у меня win7

#10
(Правка: 21:12) 21:11, 15 июня 2019

У меня то же самое. Похоже, на графиках блокированные ожиданием потоки считаются потребляющими ЦПУ.

ПрограммированиеФорумОбщее