Оцениваем ядра CPU для оптимизации - страница 26
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
никакие комплектующие тут не помогут... если задействовать в оптимизации на 100 процентов все 32 потока..а как известно в МТ5 указаны потоки в агентах а не ядра..
то вы ничем не охладите турбобуст.. и я уже обьяснил вам с него выгоды никакой ..5% максимум добавите.. повысите износ и плату за электричество..
если почитать отзывы, то многие жалуются на перегрев.. если же человек не задействует на все 100% процессор в многопоточном режиме, то не заметит проблемы с перегревом..
в сервисе тоже сказали, что охлаждение таких монстров проблема.. что если не хотите проблем, то смотрите в сторону 65 ватных процессоров..(но они существенно слабее)
если брать 64 ядерный Эпик то там частота максимальная заявлена 3.5 .. 4.7 ничто бы не охладило просто)) поэтому есть водянки которые справляются с его охлаждением
Мне не понятно другое, почему нет троттлинга и сброса частоты при перегреве процессора?
По факту получается, что устройство неисправно из коробки.
Ну в общем вот мои тесты, устал я уже комп перезагружать)))
Сначала они мне показались интересными, т.к. я начал гонять их на агентах, запущенных в качестве служб (выделено серым) через MetaTrader 5 Strategy Tester.
При этом загрузка EPYC по ощущениям не превышала 70%, и он был абсолютно холодный. В общем, конкретно на этих тестах существуют видимо какие-то накладные расходы, которые снижают скорость тестирования за счет большого числа потоков, да и службы запускаются с самым низким приоритетом и коннект к ним идет по сети.
Но все же меня поразила разница скорости выполнения прохода на полноценном ядре (82) против логического SMT (317-314), я даже перезапустил тест, чтоб точно понять, что это не ошибка.
Когда я рестартанул сервер и переключил его профиль в оптимизацию выполнения операций с double и int (CPU Intensive), то почему-то разница в скорости между разными агентами была огромна, скажем один агент выполнил задачу за 40 секунд, другой - за 7 минут. Я тоже списал это на агентов, запущенных в качестве службы.
Частота у EPYC на всех ядрах была 3250 во всех тестах, буст на отдельные ядра до 3500 я не видел, хотя по идее, когда осталось 2-3 задачи можно и буст включить.
Далее я отключил SMT и прогнал уже тест на локальных агентах (выделено синим), это единственный тест, где EPYC загрузился на 100%, затем я сделал тест с включенным SMT, загрузка процессора опять была ниже 100%.
Тест на 256 потоках сделать пока не могу, МТ5 не дает пока это сделать из-за каких то тех проблем, вроде решается это сейчас.
По R9 5950X - Hyper-Threading значительно снижает производительность в этих тестах. В первом тесте полноценное ядро оказалось быстрее логического почти в 3 раза, во втором - в 5 раз. Все ядра работали на 4300 во время тестов.
Пока можно сравнить только полноценные ядра, по ним 1 ядро R9 в 1.41 раза быстрее 1 ядра EPYC, видна четкая закономерность. При этом частота R9 в 1.32 раза выше, чем частота EPYC.
*Цифра 1.41 подтверждается и этим тестом: 263/187=1.4064
Как решится проблема с 256 агентами, потестирую еще раз и погоняю профили полее детально.
Забыл уточнить - разгон не применялся нигде.
По R9 5950X - Hyper-Threading значительно снижает производительность в этих тестах. В первом тесте полноценное ядро оказалось быстрее логического почти в 3 раза, во втором - в 5 раз.
16 Агентов withotHT быстрее 32 агентов withHT?
16 Агентов withotHT быстрее 32 агентов withHT?
В этой конкретной сферической задаче - да, в 3 и 5 раз))) По EPYC это тоже на сетевых агентах прослеживается.
В этой конкретной сферической задаче - да, в 3 и 5 раз))) По EPYC это тоже на сетевых агентах прослеживается.
Т.е. R9 32 прохода на 2 тесте на 16 агентах делает в среднем за 35 сек за проход, а на 32 агентах за 183 сек, я перепроверил, могу логи выложить, кто не верит.
VS
Ну в общем вот мои тесты, устал я уже комп перезагружать)))
Спасибо, думаю это многим будет интересно!
Ну в общем вот мои тесты, устал я уже комп перезагружать)))
Сначала они мне показались интересными, т.к. я начал гонять их на агентах, запущенных в качестве служб (выделено серым) через MetaTrader 5 Strategy Tester.
При этом загрузка EPYC по ощущениям не превышала 70%, и он был абсолютно холодный. В общем, конкретно на этих тестах существуют видимо какие-то накладные расходы, которые снижают скорость тестирования за счет большого числа потоков, да и службы запускаются с самым низким приоритетом и коннект к ним идет по сети.
Но все же меня поразила разница скорости выполнения прохода на полноценном ядре (82) против логического SMT (317-314), я даже перезапустил тест, чтоб точно понять, что это не ошибка.
Если действительно агенты имеют разную производительность в зависимости от способа их активации, то это очень важный аспект, требующий дальнейших исследований. И, он объясняет низкий PR системы.
Когда я рестартанул сервер и переключил его профиль в оптимизацию выполнения операций с double и int (CPU Intensive), то почему-то разница в скорости между разными агентами была огромна, скажем один агент выполнил задачу за 40 секунд, другой - за 7 минут. Я тоже списал это на агентов, запущенных в качестве службы.
Так может не все ядра этот режим поддерживают или ещё что - тут надо копаться в особенностях этого режима, и для чего он придуман был.
Далее я отключил SMT и прогнал уже тест на локальных агентах (выделено синим), это единственный тест, где EPYC загрузился на 100%, затем я сделал тест с включенным SMT, загрузка процессора опять была ниже 100%.
Я не совсем понимаю, ведь SMT дает просто второй поток на ядро, и если Вы потом включили SMT, а агентов было 128, то как получилось нагрузка близкая к 100% - это странно! У меня обычно в режиме Hyper-Threading загрузка 50%.
Если это действительно так, то тогда понятно, почему MQ обрубили потоки для клауда, это как раз близко к датам покупки ими серверов AMD.
Надо понять, где там узкое место, возможно как раз работа с памятью медленная, если считать для каждого потока.
Кстати, не пробовали отключить файл подкачки, если он есть?
По R9 5950X - Hyper-Threading значительно снижает производительность в этих тестах. В первом тесте полноценное ядро оказалось быстрее логического почти в 3 раза, во втором - в 5 раз. Все ядра работали на 4300 во время тестов.
Зато третий очень хорош для обоих процессоров, и там есть явный эффект! Код по сути делает одно и то же, просто реализация чуть-чуть отличается, а такая вот разница... Так что хороший программист экономит на железках :) Но это не про меня, увы.
Интересно будет, когда появится 7950X c 170 TDP ) Мощнее и ещё горячее
у Эпика 280 ватт TDP .... у него 64 ядра но по бенчмарку он в 2.5 раза мощнее..а не в 4.. чем 5950x
Я не совсем понимаю, ведь SMT дает просто второй поток на ядро, и если Вы потом включили SMT, а агентов было 128, то как получилось нагрузка близкая к 100% - это странно! У меня обычно в режиме Hyper-Threading загрузка 50%.
Если это действительно так, то тогда понятно, почему MQ обрубили потоки для клауда, это как раз близко к датам покупки ими серверов AMD.
SMT у R9 и у EPYC это другая технология, не HT, у EPYC 7003 я так понял более продвинутая чем у R9, но нужно тесты делать.
Т.е. 16 агентов грузят R9 на 100% все 32 логических ядра, когда включен SMT. Как у новых Интелов я не знаю, раньше да, как вы и описывали, 1 агент в Hyper-Threading грузил бы физический процессор на 50%.
Кстати, не пробовали отключить файл подкачки, если он есть?
Да он мизерный, для совместимости.