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

 
Fast235:
не пойму, зачем я сменил 16гб рам на 32, тестер как жрал 16рам +16 виртуал, сейчас жрет 32рам +31 виртуалки, бред какой-то, купил 32гб разгрузить SSD и продлить ему жизнь, а фиг. за день по террабайту пишет, бедный ssd

А если запретить создание файла подкачки? И, другой вариант, создать этот файл на RAM диске в 16 гигов.

 
Aleksey Vyazmikin:

А если запретить создание файла подкачки? И, другой вариант, создать этот файл на RAM диске в 16 гигов.

при запрете подкачки тестер пишет не хватает памяти в режиме Все тики

 
Fast235:

при запрете подкачки тестер пишет не хватает памяти

Тогда остается вариант с RAM диском.

 

Не могу скомпилировать Tree_Brut_TestPL_F_Fast

Виснет на 16%. Пробовал на 2х разных компах. Видимо дело в билде MetaEditor. Сбросьте скомпилированный плиз.

 
dsfx:

Не могу скомпилировать Tree_Brut_TestPL_F_Fast

Виснет на 16%. Пробовал на 2х разных компах. Видимо дело в билде MetaEditor. Сбросьте скомпилированный плиз.

Сколько ждали по времени? Там компиляция до часу занимает - зависит от мощности ядра процессора.

Откомпилированные файлы кидать запрещено на форум.

 
Aleksey Vyazmikin:

Сколько ждали по времени? Там компиляция до часу занимает - зависит от мощности ядра процессора.

Откомпилированные файлы кидать запрещено на форум.

Хммм, минут 10 ждал))). Но примерно того же размера Tree_Brut_TestPL_F вроде за минут 5 скомпилировался. Подожду подольше...

 

Результаты по Ryzen 9 3950X

Так и не разобрался, что действительно влияет на скорость тестирования у этого процессора. Что только не пробовал, результаты в пределах одних и тех же значений. Изменение базовой частоты CPU предустановленными материнкой значениями до +600MГц ни к чему не приводят. Видимо потому, что он и без посторонней помощи разгоняется на тестах. Характеристики памяти, как видно из таблицы, тоже не особо сказываются. Будут идеи, кому интересно, напишите плиз!


Что касается практического использования этого процессора для тестов в МТ5 - тут некоторые нюансы, о которых сразу и не подумаешь!

Во-первых, каждый агент МТ5 зачем-то выделяет для себя отдельно кусок оперативки, даже, если тест идет на одной паре, а не на разных. Причем, для примера, если тестировать на кроссах, то он еще подгружает мажоры. В результате, при тестировании на реальных тиках за период 2 года, каждый агент берет на себя по 7ГБ памяти. Да, стоит сказать, что я пробовал на популярном брокере, у которого 70% тиков повторяющиеся (с одинаковыми Ask и Bid). Попробую еще на кастомной истории и цифры выложу позже. Таким образом, чтобы загрузить 64ГБ памяти, можно тестировать только на 8 агентах. Выход - кастомная история с фильтрацией повторяющихся тиков, постоянный контроль объема памяти, а следовательно и периода тестирования, 128ГБ памяти и тестировать на 16 агентах. Так что-ли получается!? Так это я за два года тестировал....а если более длительный период брать...?!


Во-вторых. Я поставил пока временно SSD с другого компа EVO 860. Столкнулся с еще одной проблемой (ранее писали уже о подобном). При запуске оптимизации даже из 8-ми проходов, агенты пытаются одновременно получить доступ к SSD, чтобы накачать для себя в RAM тиковой истории. Никакой очередности не предусмотрено, из-за чего SSD становится "красным" и в журнале МТ5 сыпятся ошибки:

Т.е. тестер не может выполнить проходы, из-за того, что не удалось скачать тики, хотя пишет, что недостаточно памяти! Действительно, если прикинуть, что мой SSD, судя по показаниям системы тужился в то время до 600MB/s, чтобы заполнить даже 64ГБ RAM ему потребуется более 100 секунд. Следовательно старые SSD вообще не подходит, жду EVO 970 со скоростью 3500GB/s, но даже с ним 128ГБ будет заполняться более 30 секунд. Т.е. ошибки останутся.


Т.о., ГОСПОДА РАЗРАБОТЧИКИ. Нужно ваше внимание к этой проблеме, иначе использовать многоядерные процессоры получается крайне неудобно, а то и невозможно!

Если возможно, то было бы чудесно более экономно использовать память RAM. Пусть даже только при оптимизации на одной валютной паре! Ведь, если тест идет на одной паре, наверняка можно всем агентам обращаться к одной и той-же области памяти. Зачем им каждому плодить себе копии?! Тогда отпадет проблема в нехватке памяти, в скорости считывания с жесткого диска и удешевит существенно конструкцию!

Если же это невозможно, то хотя бы сделать какую-то очередь для доступа агентов к жесткому диску и(или) увеличить время ожидания копирования. Но оптимизация использования памяти конечно была бы гораздо эффективнее!

Спасибо!

 
dsfx:

Результаты по Ryzen 9 3950X

Так и не разобрался, что действительно влияет на скорость тестирования у этого процессора. Что только не пробовал, результаты в пределах одних и тех же значений. Изменение базовой частоты CPU предустановленными материнкой значениями до +600MГц ни к чему не приводят. Видимо потому, что он и без посторонней помощи разгоняется на тестах. Характеристики памяти, как видно из таблицы, тоже не особо сказываются. Будут идеи, кому интересно, напишите плиз!

Частота работы процессора будет влиять на производительность - попробуйте её фиксировать или ставить приделы. Для вычислений в первую очередь важен сопроцессор, поэтому от многопотока(XMP) прирост не линейный получается, т.е. ускорение за счет более быстрой подготовки данных для вычислений сопроцессорами.

По остальной части поста - тики это зло, особенно если им необходимы кроссы - процент ошибочного воспроизведения сильно возрастает. Колебание кроссов и базовых валют не синхронно.

Ошибки при работе с SSD странны - действительно ли есть в этот момент достаточно ОЗУ? Не отключили ли виртуальную память? 

 
Aleksey Vyazmikin:

Частота работы процессора будет влиять на производительность - попробуйте её фиксировать или ставить приделы. Для вычислений в первую очередь важен сопроцессор, поэтому от многопотока(XMP) прирост не линейный получается, т.е. ускорение за счет более быстрой подготовки данных для вычислений сопроцессорами.

По остальной части поста - тики это зло, особенно если им необходимы кроссы - процент ошибочного воспроизведения сильно возрастает. Колебание кроссов и базовых валют не синхронно.

Ошибки при работе с SSD странны - действительно ли есть в этот момент достаточно ОЗУ? Не отключили ли виртуальную память? 

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


Виртуальная память "по выбору системы". Поменял SSD на с evo 860 на evo 970 plus - стало повеселее заполнять RAM (примерно в 3-4 раза) и можно стартануть с большим количеством агентов, но ошибки все равно остаются, если оставить включенными агентов больше чем хватит на них памяти. Но на практике я выработал следующую стратегию оптимизации. Диспетчер задач всегда включен. Запускаю сначала 8 агентов и контролирую загрузку RAM, затем включаю еще по 4 до тех пор, пока не заполнится RAM процентов на 80. Если ничего не трогать, то все оптимизируется, не теребя винт. Но стоит мне ошибиться и прибавить больше агентов, тут же включается на всю катушку ssd и зачем-то винда разгружает память примерно на 50%. Оптимизация заметно замедляется и выход только перезагрузка терминала и старт заново. Как то так.

 

Результаты тестов "Tree_Brut_TestPL_F_Fast" для этого:

Агент на ядро:

2020.01.20 16:28:24.603 Tester  optimization finished, total passes 12
2020.01.20 16:28:24.614 Statistics      optimization done in 0 minutes 20 seconds
2020.01.20 16:28:24.614 Statistics      shortest pass 0:00:18.226, longest pass 0:00:19.507, average pass 0:00:18.679
2020.01.20 16:28:24.614 Statistics      12000 frames (4.71 Mb total, 412 bytes per frame) received
2020.01.20 16:28:24.614 Statistics      local 12 tasks (100%), remote 0 tasks (0%), cloud 0 tasks (0%)

Агент на поток:

2020.01.20 16:29:29.065 Tester  optimization finished, total passes 24
2020.01.20 16:29:29.076 Statistics      optimization done in 0 minutes 25 seconds
2020.01.20 16:29:29.076 Statistics      shortest pass 0:00:22.934, longest pass 0:00:24.012, average pass 0:00:23.194
2020.01.20 16:29:29.076 Statistics      24000 frames (9.43 Mb total, 412 bytes per frame) received
2020.01.20 16:29:29.076 Statistics      local 24 tasks (100%), remote 0 tasks (0%), cloud 0 tasks (0%)

Tree_Brut_TestPL

2020.01.20 16:50:25.514 Statistics      optimization done in 0 minutes 39 seconds
2020.01.20 16:50:25.514 Statistics      shortest pass 0:00:36.626, longest pass 0:00:38.832, average pass 0:00:37.448
2020.01.20 16:50:25.514 Statistics      12000 frames (4.71 Mb total, 412 bytes per frame) received
2020.01.20 16:50:25.514 Statistics      local 12 tasks (100%), remote 0 tasks (0%), cloud 0 tasks (0%)


2020.01.20 16:51:48.969 Statistics      optimization done in 1 minutes 01 seconds
2020.01.20 16:51:48.969 Statistics      shortest pass 0:00:54.094, longest pass 0:01:01.868, average pass 0:00:58.784
2020.01.20 16:51:48.969 Statistics      24000 frames (9.43 Mb total, 412 bytes per frame) received
2020.01.20 16:51:48.969 Statistics      local 24 tasks (100%), remote 0 tasks (0%), cloud 0 tasks (0%)

Tree_Brut_TestPL_F

2020.01.20 16:55:17.840 Statistics      optimization done in 0 minutes 57 seconds
2020.01.20 16:55:17.840 Statistics      shortest pass 0:00:53.159, longest pass 0:00:56.540, average pass 0:00:54.924
2020.01.20 16:55:17.840 Statistics      12000 frames (4.71 Mb total, 412 bytes per frame) received
2020.01.20 16:55:17.840 Statistics      local 12 tasks (100%), remote 0 tasks (0%), cloud 0 tasks (0%)


2020.01.20 16:57:48.843 Statistics      optimization done in 2 minutes 18 seconds
2020.01.20 16:57:48.843 Statistics      shortest pass 0:01:57.327, longest pass 0:02:18.116, average pass 0:02:06.879
2020.01.20 16:57:48.843 Statistics      24000 frames (9.43 Mb total, 412 bytes per frame) received
2020.01.20 16:57:48.843 Statistics      local 24 tasks (100%), remote 0 tasks (0%), cloud 0 tasks (0%)
Причина обращения: