AMD or Intel as well as the memory brand - page 62
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
New answers and new questions - you are still faster than you should be. And the reason is just as obvious - the transactions are still less than mine (43012 at the same settings)... Although the difference is not so big anymore - about 10%.
But what else to do with it - not figured out yet.
I have made changes to the table.
Mathemat, run a test with parameters like in Peter's post - how many deals will be?
Peter, is this your maximum number of trades? I mean sorting the results by number of trades?
Peter, is this your maximum number of trades? I mean sorting the results by number of trades?
No. This is just the first iteration of the optimization. Are you interested in extremums by number? Then I'll have to re-run the test - I've already left that terminal. But I can - the computer is not busy yet. Do I need it that way?
510 -12767.51 8719 0 .72 -1.46 13779.51 1.38% MovingPeriod=55 MovingShift=10 Lots=0.1 MaximumRisk=0.02 DecreaseFactor=3
1 -56968.97 39923 0 .61 -1.43 57046.37 5.70% MovingPeriod=5 MovingShift=1 Lots=0.1 MaximumRisk=0.02 DecreaseFactor=3
Well, that was, oddly enough, the first and last iteration.
What else can I do? I can post history export file (22 m of archive - 150 uncompressed) and you can run your test by importing it. My spread at the time of optimization (I was racing offline) was 17 pips in their Alpari five digits. You can set it up too - I gave you the link to the software.
My test is the same, 9:05.
1 -56631.66 41959 0.62 -1.35 56711.86 5.67% MovingPeriod=5 MovingShift=1 Lots=0.1 MaximumRisk=0.02 DecreaseFactor=3
It seems, Peter, that you have sorted by number of deals, because my external parameters are the same as yours (highlighted in blue). Well we got 5% down, but it doesn't satisfy me...
BARS here advised to put an external graphics card (the integrated one burns up memory). I'll be able to check that out.
And I think there's one more factor - synchronization of FSB of stone and memory. Maximum performance is when they are equal, but I would have to overclock the stone one and a half times, up to about 3.8 GHz. The stone can withstand this, it is capable, but my board is not the right one, not for overclocking...
And the memory timings are not too critical, I think somewhere on ixbt read.
P.S. I also have Alpari, but I downloaded the data from the metaquot server.
I have a total of 6,710,383 trades and accordingly a pass average of 13157.61
BARS advised me to put in an external graphics card (the integrated one is eating up memory). I'll be able to check that.
And I think there's another factor - synchronisation of FSB of the stone and memory. Maximum performance is when they are equal, but I would have to overclock the stone one and a half times, up to about 3.8 GHz. The stone can withstand this, it is capable, but my board is not the right one, not for overclocking...
I have read somewhere on ixbt, memory timings are not too critical.
For such a memory speed and 2 channels available, integrated video can be neglected - it will seriously slow down only in 3D. On the desktop it will be within the measurement margin of error.
For synchronous operation of FSB processor and memory it is possible to reduce multiplication factor. 7*400 for example will be only 2.8GHz.
The sensitivity to timings depends primarily on the task at hand. Some applications will not notice the timings degradation at all and some will react quite noticeably.
OK.
Since we want realism in tester speed testing, and we really don't want to deal with useless and irrelevant non-trading experts as well as useless spherical horses, let's estimate how much time is spent on what.
1. The overhead of the terminal operation and the optimizer in it. t1
2. Time of log writing into the file. t2
3. Expert Advisor execution time, full 1 cycle on the bar void start(). t3
Total time:
T=k*bars*(t1+t2+t3)
k-number of passes in the optimizer, same for all
bars- number of bars in the history, the difference between the test participants is not more than 1% (I think), it can be accepted with a good accuracy, const
t1 - does not depend on external factors (weather, economic crisis, etc. :), depends only on the hardware being tested.
t2-depends on the iron.
t3 - depends on a lot of factors, not directly related to the iron, and affecting the accuracy of the results due to the content in the code of trading functions.
In order to provide equal conditions for all the test participants, which of the three components can we influence?
Well, probably t3.
The number of trades is difficult to be dealt with. But we can add a block of "very useful" calculations to the Expert Advisor's code in order to reduce the influence of negative factors to a minimum. Say, the block of "very useful" calculations would take 95-99% of the total time. That's all. The task is solved. We will achieve high enough fidelity for our experiments.
zy. About the spherical horse aka script. I have a lot of tasks that have nothing to do with optimizing Expert Advisors in the optimizer. They are both resource-hungry indicators and complex mathematical calculations in scripts. For example, my indicator uses ns with 400-600-200 neurons. In total it uses 360800 weights. I use a separate script to train this heavyweight. The indicator reads ready weights from the file. It's clear that if we implement the training in the indicator itself, we will have problems with chart displaying. You can give more examples.
Ouch, that's what I wanted too, by the way. I have 6,577,074 transactions, slightly less than you, Docent.
P.S. Just ran it again. My time was 8:18 (498 sec!!!), though I did absolutely nothing. But that niggle (i had "wondered" about optimization for a minute or so before) was gone.
Deleted both files I needed (from cache and history). I don't understand anything. I'm going to try to put in a video card again.