Evaluating CPU cores for optimisation - page 15

 
Fast235:
I do not understand why I changed the 16gb ram to 32, the tester as ate 16 pcs +16 virtual, now it eats 32 pcs + 31 virtual, nonsense, I bought 32gb SSD to unload and prolong his life, and Pish. per day by terrabyte writes, poor ssd

How about disabling the creation of a swap file? And, alternatively, create this file on a 16 gig RAM disk.

 
Aleksey Vyazmikin:

How about disabling the creation of a swap file? Alternatively, create the file on a 16 gig RAM disk.

If you disable swap, the tester says not enough memory in All ticks mode

 
Fast235:

If paging is disabled, the tester says not enough memory

This leaves the RAM disk option.

 

Can't compile Tree_Brut_TestPL_F_Fast

Fails to compile at 16%. Tried it on 2 different computers. It may be because of MetaEditor build. Please reset the compiled one.

 
dsfx:

Can't compile Tree_Brut_TestPL_F_Fast

Fails to compile at 16%. Tried it on 2 different computers. It may be because of MetaEditor build. Please reset the compiled one.

How long did you wait? It takes up to an hour of compilation - depends on the CPU core power.

It is forbidden to upload compiled files to the forum.

 
Aleksey Vyazmikin:

How long did you wait? It can take up to an hour to compile - it depends on CPU core power.

It's not allowed to upload compiled files to the forum.

Hmmm, waited about 10 minutes)). But about the same size Tree_Brut_TestPL_F seems to compile in about 5 minutes. I'll wait longer...

 

Ryzen 9 3950X results

Still haven't figured out what really affects the test speed of this processor. I've tried everything, the results are within the same values. Changing CPU base frequency with motherboard preset values up to +600MHz does not lead to anything. Apparently, that's because it overclocks in the tests without any help. Memory characteristics, as you can see from the table, don't really affect it either. Any ideas who'll be interested, post please!


As for practical usage of this processor for tests in MT5 - here are some nuances that you won't think of at once!

First, every agent in MT5 for some reason allocates a separate piece of memory for itself, even if the test is run on one pair and not on different ones. And, for example, if we test on the crosses, it loads more majors. As a result, when testing on real ticks for the period of 2 years, each agent takes 7GB of memory. Yes, it's worth mentioning that I tried it on a popular broker, which has 70% of ticks repeating (with the same Ask and Bid). I'll try some more on a custom story and I'll post the figures later. So, to load 64GB of memory I can only test on 8 agents. Exit - custom story with filtering of repeating ticks, constant control of memory size and hence testing period, 128GB of memory and test on 16 agents. Is that how it works!!!? So this is me testing for two years.... what if you take a longer period...?!


Secondly. I put a temporary SSD from another computer EVO 860. Ran into another problem (have already written about similar before). When I start optimization, even of 8 passes, agents try to access SSD simultaneously to pump for themselves into RAM tick history. There is no queue, so the SSD becomes "red" and errors appear in the MT5 journal:

I.e., the tester cannot execute passes, because it failed to download ticks, although it writes that there is not enough memory! Indeed, if you consider that my SSD was pushing up to 600MB/s according to system readings at the time, it would take it over 100 seconds to fill even 64GB RAM. Hence old SSD not suitable at all, waiting for EVO 970 with 3500GB/s, but even with it 128GB will fill more than 30 seconds. I.e. the errors will remain.


So, Gentlemen Developers. We need your attention to this problem, otherwise using multi-core processors is extremely inconvenient, if not impossible!

If it is possible, it would be nice to use RAM memory more economically. Even if only when optimizing on one currency pair! After all, if the test runs on one symbol, surely all agents can access one and the same memory space. Why would each of them produce copies? Then there will be no problem with memory shortage, speed of reading from the hard disk and it will make the design cheaper!

If this is not possible, then at least make some kind of queue for agents to access the hard drive and/or increase the wait time for copying. But optimising memory usage would of course be much more efficient!

Thanks!

 
dsfx:

Ryzen 9 3950X results

Still haven't figured out what really affects the test speed of this processor. I've tried everything, the results are within the same values. Changing CPU base frequency with motherboard preset values up to +600MHz does not lead to anything. Apparently, that's because it overclocks in the tests without any help. Memory characteristics, as you can see from the table, don't really affect it either. Any ideas, anyone interested, post please!

CPU frequency will affect performance - try fixing it or setting limits. For calculations, co-processor is of primary importance, so multithreading (XMP) gives you a non-linear gain, i.e. acceleration due to faster data preparation for calculations by co-processors.

As for the rest of the post - ticks are evil, especially if they need crosses - the error rate increases significantly. Crosses and base currencies fluctuate out of sync.

SSD errors are strange - is there really enough RAM at this point? Has virtual memory been disabled?

 
Aleksey Vyazmikin:

Processor frequency will affect performance - try to fix it or set limits. For calculations, co-processor is first of all important, so multithreading (XMP) gives non-linear gain, i.e. acceleration due to faster preparation of data for calculations by co-processors.

As for the rest of the post - ticks are evil, especially if they need crosses - the error rate increases significantly. Crosses and base currencies fluctuate out of sync.

SSD errors are weird - is there really enough RAM at this point? Has virtual memory been disabled?

Yes indeed. After fixing the CPU at different frequencies, noticeable result. Practice showed that it's better not to fix - latest firmware in the bios doesn't have that CPU model yet, and pre-installed fixed frequencies below are known to get maximal frequency in turbo mode without fixing. I haven't got into bios yet, but criteria of dependency are already clear. Waiting for new firmware.


Virtual memory "by system choice". Changed my SSD from evo 860 to evo 970 plus - it became more fun to fill RAM (about 3-4 times better) and I can start with more agents, but there are still errors if I leave more agents than enough memory for them. But in practice, I've developed the following optimization strategy. Task manager is always on. I start 8 agents first and control RAM load, then turn on 4 more until RAM is about 80% full. If I don't touch anything, everything is optimised without straining the drive. But as soon as I make a mistake and add more agents, immediately the ssd goes full throttle and for some reason the windup offloads memory by about 50%. Optimization slows down noticeably and the only way out is to reboot the terminal and restart. Like this.

 

Tree_Brut_TestPL_F_Fast" test results for this:

Agent per core:

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%)

Agent per thread:

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%)