Оцениваем ядра CPU для оптимизации - страница 28

 
Dmitriy Shal #:

Перепроверил еще раз, я ввел вас в заблуждение - 16 агентов грузят R9 при SMT (32 потока) на 64-65%, что все равно выше 50%. 
И я думаю, что если выключить SMT, то прирост будет небольшой, сейчас не могу попробовать.


очень странно что всего на 70% загрузка процессора... у меня на 100% грузится без проблем при активации всех потоков..

 
Dmitriy Shal #:

Ну по моим "сферическим" тестам выше:

Ядро R9 мощнее EPYC в 1.41 раз, значит 16 ядер R9 это 22.56 ядер EPYC, значит он мощнее в 2.83 раза.

Но у EPYC 8-канальный контролер, у  R9 - 4 канальный, т.е. теоретически, в задачах, где важна память он не особо будет отставать.

я исходил из тестов бенчмарка сравнивая два процессора между собой).. так то разные тесты конечно дают разные показатели..
и МТ5 в бенчмарке нет)

 
Aleksey Vyazmikin #:
Многие говорят о влиянии частоты ОЗУ на производительность в терминале - предлагаю это проверить - интересны тесты на низких и стандартных частотах. Память для многоядерников - дорогое удовольствие, и хотелось бы понять, можно ли на ней экономить в системах для чисто оптимизации.

по моим тестам вообще помощи от оперативной памяти не было по каждому тику..

я брал в аренду сервер..

сначала 4 ядра и 8 гб оперативки.. ядра однопоточные..


по каждому тику оптимизация..

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

1 прогон около 1 минуты проходил..

в итоге 4 ядра сьедали все 8 гб оперативной памяти..

я пошёл дальше.. взял 12 гб провёл тесты.. 16 гб... 20 гб... 32 гб..


по итогу 4 ядра максимум сьели 22 гб оперативной памяти а скорость оптимизации не изменилась.. вот такой парадокс..

если разницы нет между 8 гб и 22 гб.. то частота видимо тоже никак не повлияет на скорость..

как-то всё странно и непонятно.. куда уходит оперативная память..в чёрную дыру???)))
может я где-то что-то упустил..утверждать не буду.. 

но факт в том что когда оптимизируешь по каждому тику 32 потокам порой не хватает 128 гб оперативной памяти..

что происходит? изначально у меня было 64 гб оперативной памяти.. в итоге процессор грузился всего на 30-50% а оперативка на все 100%

в итоге когда я купил ещё 64 гб оперативки.. то обнаружил что процессор теперь может работать на полную мощность.. но на каких-то парах всё равно 32 потока поедали всю оперативку..

и выходом было только отключить порой до 10-15 потоков.. чтобы процессор работал на полную мощность 100%.. вот так вот.. отключаешь 30% потоков а он всё равно может работать около 100% в загрузке..


если вы хотите оптимизировать по ценам открытия или OHLC то для 32 потоков вам свободно хватит 48 гб..  даже 32..


 
Pavel Malyshko #:

по моим тестам вообще помощи от оперативной памяти не было по каждому тику..

я брал в аренду сервер..

сначала 4 ядра и 8 гб оперативки.. ядра однопоточные..


по каждому тику оптимизация..

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

1 прогон около 1 минуты проходил..

в итоге 4 ядра сьедали все 8 гб оперативной памяти..

я пошёл дальше.. взял 12 гб провёл тесты.. 16 гб... 20 гб... 32 гб..


по итогу 4 ядра максимум сьели 22 гб оперативной памяти а скорость оптимизации не изменилась.. вот такой парадокс..

если разницы нет между 8 гб и 22 гб.. то частота видимо тоже никак не повлияет на скорость..

как-то всё странно и непонятно.. куда уходит оперативная память..в чёрную дыру???)))
может я где-то что-то упустил..утверждать не буду.. 

но факт в том что когда оптимизируешь по каждому тику 32 потокам порой не хватает 128 гб оперативной памяти..

что происходит? изначально у меня было 64 гб оперативной памяти.. в итоге процессор грузился всего на 30-50% а оперативка на все 100%

в итоге когда я купил ещё 64 гб оперативки.. то обнаружил что процессор теперь может работать на полную мощность.. но на каких-то парах всё равно 32 потока поедали всю оперативку..

и выходом было только отключить порой до 10-15 потоков.. чтобы процессор работал на полную мощность 100%.. вот так вот.. отключаешь 30% потоков а он всё равно может работать около 100% в загрузке..


если вы хотите оптимизировать по ценам открытия или OHLC то для 32 потоков вам свободно хватит 48 гб..  даже 32..


На какой частоте у Вас работает 128gb?
Там вроде бы падает частота, если задействовать все 4 слота.

 
Pavel Verveyko #:

На какой частоте у Вас работает 128gb?
Там вроде бы падает частота, если задействовать все 4 слота.

частота 3200 у каждой..игровая оперативка.. 128 гб обошлось в 61 000
хотя пишет что почти 131 гб оперативной памяти в характеристиках..

за частотой не следил какую выдаёт.. поэтому тут не отвечу.. 

 
Dmitriy Shal #:


Так наглядней, это 128 агентов на 256 потоках, но запускал на горячий терминал уже.

Ладно, спать пора, хватит технику мучать))))

Понял, но всё же странно. Тогда от добавления агентов не приходится ждать улучшений - кстати в последнем билде пишут, что решили эту проблему - ждем тесты.

 
Pavel Malyshko #:

по моим тестам вообще помощи от оперативной памяти не было по каждому тику..
...

что происходит? изначально у меня было 64 гб оперативной памяти.. в итоге процессор грузился всего на 30-50% а оперативка на все 100%

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

Я тестирую в OHLC, и тут всё упирается в число индикаторов и размер таблиц с данными - я работаю с МО, поэтому памяти бывает и много надо.

 
Pavel Malyshko #:

никакие комплектующие тут не помогут... если задействовать в оптимизации на 100 процентов все 32 потока..а как известно в МТ5 указаны потоки в агентах а не ядра..

то вы ничем не охладите турбобуст.. и я уже обьяснил вам с него выгоды никакой ..5% максимум добавите.. повысите износ и плату за электричество..

если почитать отзывы, то многие жалуются на перегрев.. если же человек не задействует на все 100% процессор в многопоточном режиме, то не заметит проблемы с перегревом..

в сервисе тоже сказали, что охлаждение таких монстров проблема.. что если не хотите проблем, то смотрите в сторону 65 ватных процессоров..(но они существенно слабее)

если брать 64 ядерный Эпик то там частота максимальная заявлена 3.5 .. 4.7 ничто бы не охладило просто)) поэтому есть водянки которые справляются с его охлаждением


на Ryzen все процессоры настраиваются в биос, можно ограничить PPT на 105W-процах, так и наоборот поднять до нужных значений 65-W модели,

Ryzen что 3800x, 5800 с TDP-105W никакого смысла брать нет, единственное там может быть более отборные чипы, которым вольтаж меньше требуется по той-же частоте

а из 5700x и 5800x, так младшая модель вышла почти на год позже, на новом степпинге, с более низкими утечками вольтажей, гораздо выгодней 5700x взять, цена в китае 15тр сейчас,

у меня новый комплект лежит с 5700x, пока не собирал в комп.

 
на ваших 5950 тоже можно ограничить PPT в биосе, но это ограничение будет только на многоядерность, а буст останется прежним т.к. он не упирается в лимиты 
 
Dmitriy Shal #:

Т.е. R9 32 прохода на 2 тесте на 16 агентах делает в среднем за 35 сек за проход, а на 32 агентах за 183 сек, я перепроверил, могу логи выложить, кто не верит.

на 16 агентах наверное частота значительно выше? процессор не перегревается и не сбрасывает как на 32? в энергоэффективности конечно 2раза по 16 агентов запускать большой проигрыш должен быть

на 16 агентах тест был запущен после 32, кэш там не мог быть использован с прошлого прохода?
Причина обращения: