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

 
Aleksey Vyazmikin:

Возникает вопрос, за счет чего эффект - из кода я конечно видел, что по сути убрали "if"? Но хотелось бы комментарий, ибо не ясно за счет чего всё ж прирост в плане ускорения логики.

Интуитивное решение — вынести большой код в функцию (еще лучше было бы в отдельный инклуд), избавиться от if, инкремента и брейка.

Меня еще очень смущает получение значений анализируемых переменных. В тестовом примере это рэндомы, а в реальности? Я бы уже там оставлял чистые булевы значения, чтобы потом вместо (double_a > 10.0) проверять (bool_a).

 
Igor Zakharov:

Новый билд, новый тестер, новый компилятор... в сводной таблице не хватает колонки "билд мт5"

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

 
Andrey Khatimlianskii:

Интуитивное решение — вынести большой код в функцию (еще лучше было бы в отдельный инклуд), избавиться от if, инкремента и брейка.

На самом то деле это и так уже функция, поэтому и не ясно откуда такой прирост производительности!

Инклюд я использую в рабочем коде, но это чисто перенос кода, а как Вы предлагаете его организовать? Брей существенно добавляет производительности - как от него избавиться, что б не потерять в скорости?

Andrey Khatimlianskii:

Меня еще очень смущает получение значений анализируемых переменных. В тестовом примере это рэндомы, а в реальности? Я бы уже там оставлял чистые булевы значения, чтобы потом вместо (double_a > 10.0) проверять (bool_a).

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

 
Maxim Romanov:
3800х почти догнал по производительности на поток i7 8700. И оторвался от 2700.
Вероятно это связано с уменьшившимися задержками при работе с памятью и вдвое большим кэшем.
Вывод: для мт5 решающим фактором являются задержки при обращении к памяти и скорость чтения из памяти.
Это же подтвеждается низкой производительность на поток 2990 wx. У них большие задержки по памяти несмотря на 4-х канал и специфичная работа с кэшем.
То есть скорость самих ядер не так важна.
Возможно это так работает.

а что 3800X не должен был оторваться от 2700?

 
Aleksey Vyazmikin:

Тогда предположу, что при оптимизации частота падает просто по идеологии. Сделайте ради интереса прогон любого советника подольше - не 16 проходов, а допустим 160 - интересно, как там меняется время прохода - разница должна быть минимальна - в пределах 1 секунды.

F


PS а может у Вас есть тест при котором грузится ОЗУ?

 
Pavel Verveyko:

F


PS а может у Вас есть тест при котором грузится ОЗУ?

Спасибо, средний показатель примерно совпал с 16 проходами - будем считать, что это корректные данные.

Для памяти, к сожалению, ничего подходящего нет в открытом доступе.

 
Pavel Verveyko:

а что 3800X не должен был оторваться от 2700?

Должен был, я предположил причины, чтобы в дальнейшем на что-то опираться при выборе железа.
 
Maxim Romanov:
Должен был, я предположил причины, чтобы в дальнейшем на что-то опираться при выборе железа.

понял, спасибо.

 
Aleksey Vyazmikin:

Брей существенно добавляет производительности - как от него избавиться, что б не потерять в скорости?

Заменить ретурном, как у меня в примере.


Aleksey Vyazmikin:

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

Вместо

int Povtor_High_M1 = X;

if ( Povtor_High_M1>=0 ) ***

if ( Povtor_High_M1< 0 ) ***

Сделать

bool Povtor_High_M1 = (X >= 0);

if ( Povtor_High_M1 ) ***

if ( !Povtor_High_M1 ) ***
 
Andrey Khatimlianskii:

Заменить ретурном, как у меня в примере.


Вместо

Сделать

К сожалению туплю, но там же X>=0 может быть больше любого иного числа - много комбинаций же - все не предусмотреть в коде, да и код вырастит на много порядков из за разных комбинаций.

Причина обращения: