![MQL5 - Language of trade strategies built-in the MetaTrader 5 client terminal](https://c.mql5.com/i/registerlandings/logo-2.png)
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
I am interested in how fast the tester runs on a particular hardware. The simpler the code, the less influence it has on the results. The tester is wobbling the code compiled by the regular compiler. Therefore, it does not matter what it is - a script or an Expert Advisor. However, there will always be some ambiguity with the Expert Advisor since we will never get the ideal conditions. From my viewpoint, begemot61's suggestion is interesting. But even in this case it is not necessary to run the indicator from an Expert Advisor. The time can be measured inside the indicator.
I am not really interested in the speed of the script running on a certain hardware. I am interested in the optimization speed. The closer the test is to the real task, the better for the test and me - the pig-saurus.
How to eliminate ambiguity - there is a solution, and I have given it. What was suggested as a simplified version is also acceptable. As opposed to measuring "cfc in".
What is the "reality" of the task? That the optimiser "trades in his head"?, so this trading is the execution of ordinary, no different from "non-trading" functions. And it is exactly trading functions that will give slightly different results. So why apply them when testing the optimizer?
Because it will utilize machine resources in the same way as in the real optimization. Script cannot provide this by its very nature. And it would be strange to invent a simulated optimization in a script with a live optimizer.
Because it loads machine resources in the way that real optimisation would. A script, by its very nature, cannot do that. And it would be strange to invent a simulated optimization in a script with a live optimizer.
I'm not trying to insist on the script, I just want to say that trading functions must be removed in Expert Advisor to test optimizer, that's all. Since moderators have already inquired about this thread, perhaps they would like to clear up the question: "What is the difference between trading and non-trading functions in the optimizer in terms of runtime?
I'm not insisting on the script, but I am saying that in Expert Advisor for testing optimizer must be removed from trading functions, that's all. As long as moderators are interested in this thread, maybe they will ask: "How do trading and non-trading functions differ in runtime in the optimizer?
))) What do you think they're interested in the branch for? They're curious about it themselves! So we'll have to clarify it))).
No kidding, even according to the most general considerations, absence of trade functions in a test reduces its validity. Whether they do or don't affect it is not what we are trying to find out.
Belford's Phenom II behaves quite strangely: on the script it performs much worse than the "blue" Core 2 Duo series, but on the optimization it slightly outperforms them.
Rather the opposite ...))
I've given the results on page 44 at nominal CPU mode. Script 44*2.8=123, EA 150*2.8=420.
For example for "blue" Core 2 Duo E7200 - script 117, Expert Advisor 539.
123-117=6 (<5%, it's not significant)
539-420=119 (>20%, and the Phenom II outperforms significantly on optimisation)
I am interested in how fast the tester runs on a particular hardware. The simpler the code, the less influence it has on the results. The tester is wobbling the code compiled by the regular compiler. Therefore, it does not matter whether it is a script or an Expert Advisor. However, there will always be some ambiguity with the Expert Advisor since we will never get the ideal conditions. From my viewpoint, begemot61's suggestion is interesting. But even in this case it is not necessary to run the indicator from an Expert Advisor. The time can be measured inside the indicator.
This is the purpose of hardware testing using different synthetic benchmarks that minimize impact on what in a particular case should not affect the result. Testing the memory subsystem, processor, bus, etc., then deriving an overall performance index.
A real estimation of a trader's machine, would be the creation of several such benchmarks - scripts, non-trading Expert Advisors, indicators, and the subsequent calculation of the final rating.
Except that for some reason ALWAYS in different reviews the results of synthetic tests are only a LESS part. And the LARGER part is always the tests of REAL programs. The set of such programs may vary, but they are always there. And, by the way, the industry standard SPECxxx consists of a mixture of REAL programs code, not synthetic tests. And on ixbt.com they've refused to use synthetics at all, precisely because it's the proverbial horse.
Understand one very simple thing. What we see in any real performance tests is usually quite far from what modern processors are capable of. On the one hand they are much faster than processors of previous generations, but on the other hand they can work even faster. But marginal optimization of programs for them is very labor-intensive and often impossible (because of the algorithms used). That is, any real tests show the processor's performance under the conditions typical of the program in question. In other words, we can see the influence of various bottlenecks. And you suggest getting rid of these bottlenecks. But if you really optimize the Expert Advisor, they will appear again!
I am not insisting on the script, I am saying that trading functions must be removed in an Expert Advisor to test the optimizer, that is all. Since moderators have already inquired into this thread, perhaps they will ask: "What is the difference between trading and non-trading functions in the optimizer in terms of execution time?
joo. They say that one should not get into personalities in an argument.
But I suggest that in this case look at it this way. You are a structural engineer and I am not going to argue with you about anything that has to do with strength calculation. And I'm not going to argue with Mathemat about mathematics. Or even with anyone on this forum directly about trading, as my experience in the field is tiny.
But when it comes to processors (computers in general), their performance, measurement of that performance - I'll argue. For I am an engineer by profession "Computing machines, complexes, systems and networks". For I have always been interested in how it all works at the lowest level. And in this area in all likelihood I will give you all a head start.
Even the question you asked is meaningless as it generally has no answer. The time from function call to control return is a variable value. I.e. even 2 particular functions are almost impossible to compare, since a situation may occur where one or the other is faster than the other. But you want to compare the whole "classes" of functions.
I'm not really interested in the speed at which the script runs on a particular hardware. I am interested in the optimization speed. And the closer the test is to the real problem, the better for the test and for me - the pig-saurus.
How to eliminate ambiguity - there is a solution, and I have given it. What was suggested as a simplified version is also acceptable. As opposed to measuring "sf.c. in."
I too am mainly interested in the speed of optimisation. Trading functions I'm not sure they are significantly different from any other functions.
The call should be comparable to other functions. I just don't know what they are inside.
And how does logging slow things down?
It's just that in the case of the script we separated floating point and integer operations for some reason. And it didn't surprise anyone.
And in the Expert Advisor, we are doing something but we are not interested in what it is. I wonder why? Because it is difficult to determine?
I'm mainly interested in the speed of optimisation as well. Trading functions-I'm not sure if they are significantly different from any other functions.
The call should be comparable to other functions. I just don't know what they are inside.
And how does logging slow things down?
It's just that in the case of the script we separated floating point and integer operations for some reason. And it didn't surprise anyone.
And in the Expert Advisor, we are doing something but we are not interested in what it is. I wonder why? Because it's hard to define?
Yeah. In the script I at least tried to separate the tasks somehow. But in the proposed Expert Advisors everything is in a "heap". Try to figure out why this or that machine is faster, whether because the memory is cooler, or because the CPU is more powerful, or maybe the bus is faster....