Evaluating CPU cores for optimisation - page 10

[Aleksey Vyazmikin]

Pavel Verveyko:

The folder returned to its place, brakes are gone, with respect to mathematical calculations for some reason the tester is confused need to open it by clicking on something from the icons and there select the settings c mat. calculations.
Now I tried it again without F
The result is shown in the picture:

it's clear something's going wrong.)

Erase the Tester\cache.

[Andrey Khatimlianskii]

@Aleksey Vyazmikin

Try my suggestion.

[Pavel Verveyko]

Aleksey Vyazmikin:

Erase the Tester\cache

it worked, I'll post the last EA now.
Done. I put it all in that message.

[Aleksey Vyazmikin]

Pavel Verveyko:

it worked, I will now post the last Expert Advisor.
it's done. i put it all in that post.

I have entered the data. From the logs, it seems that there is some trotting under load and this is the reason for the variation of agents' pass times in one optimization mode. Therefore I ask you to make tests with normal frequencies as well, which will be more useful for the community.

I am publishing the summary table without taking into account build costs. Filtering by penultimate column, as not everyone ran tests with the last EA, I remind you the value of the column shows how many passes the processor will make in 1 hour, i.e. its efficiency.

[Aleksey Vyazmikin]

Andrey Khatimlianskii:

@Aleksey Vyazmikin

Try my suggestion.

Thanks for your time!

The performance gain is significant, from 28 seconds to 17 per pass! Question arises, what caused the effect - of course I saw that "if" was removed from the code? But I'd like a comment, because it's not clear what is the gain in the sense of faster logic.

And the size of the compiled file unpleasantly grew from 14 megabytes to 24, ie actually 10 megabytes - and how to explain it - is not clear.

[Pavel Verveyko]

Aleksey Vyazmikin:

I have entered the data. From the logs, it seems that there is some trotting under load and this is the reason for the variation of agents' pass times in one optimization mode. Therefore I ask you to make tests with normal frequencies as well, which will be more useful for the community.

I am publishing the summary table without taking into account build costs. Filtering by the penultimate column since not everybody ran tests with the last EA, I remind you the column shows how many passes the processor makes in 1 hour, i.e. its efficiency.

The nuance is that I didn't use overclocking... (ps not overclocking at all, it works itself)))
I only set the motherboard's declared frequency of RAM to 3200, according to the memory controller and which is supported by the motherboard.
AMD Ryzen (Matisse) processors support DDR4 3200/2933/2667/2400/2133 ECC and non-ECC, bufferless memory

and the Windows software supports other memory types)

ps the computer does not make noise) leading to the fact that it looks like it either operates at its default frequency or considers it as default

[Aleksey Vyazmikin]

Pavel Verveyko:

The nuance is that I did not use overclocking... (ps don't do overclocking at all, it works itself)))
I only set the motherboard's declared frequency of RAM 3200, according to the memory controller and which is supported by the motherboard.
AMD Ryzen (Matisse) processors support DDR4 3200/2933/2667/2400/2133 ECC and non-ECC, bufferless memory

and the Windows software supports other memory types)

ps the computer does not make noise) leading to the fact that it looks like it either operates at its default frequency or considers it as default

Then I will assume that during optimization the frequency drops simply by ideology. For the sake of interest do a longer run of any EA - not 16 passes, but say 160 - I wonder how it changes the run time - the difference should be minimal - within 1 second.

[Maxim Romanov]

The 3800x almost caught up with the i7 8700 in terms of performance per thread. And got away from the 2700.

This is probably due to reduced memory latency and twice as much cache.

Conclusion: for mt5 the decisive factor is the memory access latency and the memory read speed.

This is also evidenced by the low performance on the 2990 wx thread. They have high memory latencies in spite of 4 channel and specific cache handling.

That is, the speed of the cores themselves is not that important.

Maybe that's the way it works.

[Igor Zakharov]

Aleksey Vyazmikin:

The question arises as to what accounts for the effect...

...and how to explain it is not clear.

New build, new tester, new compiler... the summary table is missing the "build mt5" column

[Aleksey Vyazmikin]

Maxim Romanov:
The 3800x almost caught up with the i7 8700 in terms of performance per thread. And pulled away from the 2700.

This is probably due to reduced memory latency and twice as much cache.

Conclusion: for mt5, the deciding factor is the memory access latency and the memory read speed.

This is also evidenced by the low performance on the 2990 wx thread. They have high memory latencies despite the 4-channel and specific cache handling.

So the speed of the cores themselves is not that important.

Maybe that's the way it works.

I think the important thing is not so much the increase of cache, as the change of the principle of work with it - here in article it is possible to read in detail, plus acceleration of work with instructions AVX2 and as a whole the raised clock frequency of the processor. I'm not sure that RAM plays a role here - there's no history handling, no large write operations.

By the way, note that different processors handle EAs differently

Shows average time per pass in seconds.