A little surprised :) Thought I'd share and ask a NOT rhetorical question. - page 15
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
We're talking about an optimiser, not a lot of single tester runs. The concept of an optimiser is quite different. There significant speed gains are achieved at the expense of small errors in the results. The optimizer doesn't need models based on ticks at all. At most, they are based on opening prices. An optimizer is not a tester, it is another thing altogether. Your approach is different, and quite logical too.
By making an unreliable tester (and there's no way the margin of error there will be 1%), the developer will get a stain for life. And the talk about "100 times faster" will seem unimpressive compared to "how has it been seen that an optimizer has a right to load something"?
On the contrary, we are fighting for maximum accuracy and speed of the optimizer due to
- optimised algorithms
- maximized performance and functionality of the MQL5 language
- multi-threaded, remote and cloud-based agents
- Detailed M1 history with spreads support
- use of 64 bit versions
Parallelization of the optimization of strategies has immediately led to a linear speedup in the number of calculation cores and MQL5 has become a giant leap forward in comparison with MQL4.By making an unreliable tester (and there will be no error of 1%), the developer will get a stain for life.
I feel as if we are speaking different languages. I am not reproaching you for anything. What's more, I said that the developers took the only right path.
Just don't criticize all the other developments that don't concern you. My Expert Advisor is 100 times faster than MT4-tester and its error is <1% ON MY EA ONLY. I don't need it for other Expert Advisors.
You see, I had to, and I've done it for myself, and I'm not imposing this way on anyone. I'm only saying that, if necessary, it's always possible to write a non UNIVERSAL dumb, but very fast calculator. And after that its results should be polished on a well-designed MT4-MT5 tester, which is not even dumb, but rather a real trading simulator.
You have to be an idiot to criticize the developers that the optimizer is not as fast as the calculator. And you'd have to be very stubborn to claim that a specially written calculator for a particular case isn't faster than a universal tester in this particular case.
Again, the developers are fed by their clients - the brokerage companies, represented by an army of traders. MTS provides food for their clients - the markets. Everyone is doing his business. Just do not criticize each other. You can treat each other with respect and without disrespect.
The topikstarter almost started by attacking the developers. Several times he said that it is not allowed. Developers began to go overboard in the end, too, saying their own thing. Let's just respect each other.
To summarise what I've done for myself - MT5 tester/optimiser is a MUST, no matter what special cases (both personal and applied) it's not applicable, as nothing is perfect. Tk.
For me personally the discussion was useful. At least it became clear to me that from the point of view of the developers, the solution they implemented is the best. The fact that someone may need to make billions of runs is another question. You may do it yourself. That is all. We cannot change the MT5 optimizer in the direction of performance increase (to exorbitant values), it's not real. They have done a lot, almost everything possible in terms of performance. Good for them.
So I got an answer to my non-rhetorical question.
TO hrenfx : What answer do you want from Renat? He answers the way a developer should. IMHO, he understands everything you say. But he does not answer you personally - but everyone who reads it. So you should always read the responses from developers.
We complain about life, while they make software not for us personally, but for consumers. Apparently, if we paid them millions they would make software for us personally.
So thank you. Answer received. :)
TO hrenfx : what answer do you want from Renat? He answers as a developer should. IMHO, he understands everything you say very well. But he does not answer you personally - but everyone who reads it. That's how you should always read the developers' answers.
In light of the above topic of quality and speed of various universal testers, I forgot to mention MQL5's real competitor - Stock#.
In fact, creating a Data-Crusher or a parser, as you call it, is not a simple thing.
As you have already noticed above - it is reasonable to change from prices expressed in the form of floating numbers to prices in the form of integers, because firstly it reduces memory capacity at least 4 times, because USHORT occupies only two bytes and has a range of values from 0 to 65535, which even for five digits in principle is enough. So it turns out 6553 old points is more than enough, while DOUBLE takes 8 bytes.
That is, if we have 50 million ticks for example on one symbol (taking into account that we also encode time in USHORT, we obtain the tick size 3*2 = 6 bytes) Therefore 50 * 6 is roughly 300 megabytes. And in a case if we store the tick as DOUBLE and even if time is USHORT, we get 2 * 8 + 2 = 20 bytes, then 20 * 50 is at least a gigabyte.
Well, if the characters let's say 7, it is in one version of 7 * 300 = 2.1 gigabytes and the second 7 giga. OP. If we take 4 gigs of RAM for 64-bit machines as a standard, it turns out that we have already gone 100% to swap.
Well, if you don't store ticks during optimization and generate them before a run, it will certainly take less space :)). But it will not be a digital robot anymore.
OK - let's go further. Suppose we are clever and have generated ticks. And they take 2 gigs of memory, but if we are smart and diligent, but lack of experience and know little about high performance - then we'll create our own "thread" for each run from the beginning of the story to the end, and it will run. But only on the last "stupidity" we will lose about fourfold in productivity. Think about it! Four times as much - I'm all about C, of course. So if someone more than one would like to have a super-performance optimizer (not a tester), I'm ready to create such a program. But it will take time and that's why I want money. :)
I mean, here I've just counted an SEVEN times acceleration.
That's about 150 million ticks in 12 seconds on DOUBLE in whole numbers even four times faster, that is 4 seconds run all the ticks on three characters from 1999 to the present day.
I have such a tester (for MT4 environment even with support for compiler with MT4 and C++ native one) with multicurrency. It's easy to remake it for net trading. I will not compile with MT5, I'm lazy. By the way, it supports MT4 debugging :)) Directly in studio. I can attach there distributed processing on neighboring machines, but will there be performance gain, we will have to see.
With charts, with performance counters, with loading of own any history ... So it's not a small one - 10,000 lines at a guess. :)
If moderators don't mind, post screenshots of examples of your tester here. Take some standard EA, convert it to "all-in-one" (without indicators) and run it in different optimizers, including your own. The results, at least in the form of screenshots.
It makes no sense to show me my tally (I've already said it above), because it cannot be called anything better than the word "tally". According to your statements you have almost (I don't know all) full-fledged optimizer. The developers have laid out their optimizer (even two of them - MT4 and MT5). We can discuss and criticize it. Show us something of your own. There may be potential buyers.
Perhaps, even the developers will have second thoughts if your universal optimizer really calculates much faster and with an acceptable error.
There is also a question of indicators. I personally do not need them for writing EAs, but 99% of Expert Advisors use them, so the architecture of their tester-optimizer has been customized according to the realities of the majority. Hence there can be some architectural speed loss for "all in one" (it could be faster), but there is a great advantage for variants with indicators (than it could be).
P.S. Your numbers are obviously inaccurate: you can't have history in INT occupying 2.1Gb, and in DOUBLE occupying 7Gb. The difference should always be exactly 2 (USHORT is not enough) times. Switching to integer arithmetic with prices gives a significant advantage when all logic in an EA can be replaced with integer logic. This does not happen very often.
If moderators don't mind, post screenshots of examples of your tester here. Take some standard EA, convert it to "all-in-one" (without indicators) and run it in different optimizers, including your own. The results, at least in the form of screenshots.
It makes no sense to show me my tally (I've already said it above), because it cannot be called anything better than the word "tally". According to your statement you have almost (I don't know all) full-fledged optimizer. The developers have laid out their optimizer (even two of them - MT4 and MT5). We can discuss and criticize it. Show us something of your own. There may be potential buyers.
Perhaps, even the developers will have second thoughts if your universal optimizer really calculates much faster and with an acceptable error.
There is also a question of indicators. I personally do not need them for writing EAs, but 99% of Expert Advisors use them, so the architecture of their tester-optimizer has been customized according to the realities of the majority. Hence there can be some architectural speed loss for "all in one" (it could be faster), but there is a great advantage for variants with indicators (than it could be).
P.S. Your numbers are obviously inaccurate: you can't have a story in INT occupying 2.1Gb and a story in DOUBLE occupying 7Gb. The difference should always be exactly 2 (USHORT is not enough) times. Switching to integer arithmetic with prices gives a significant advantage when all logic in an EA can be replaced with integer logic. This does not happen very often.
Well if you think USHORT is not enough, then yes. But I believe that it will be enough. Besides, you don't need double - FLOAT is half as much and faster.
And what about skins - then :
Yeah, ok - I'll show them if I have time, but not skins - as it is not a windowed application, but I'll show something like a video.
Buyers I think there will not be. :) And in summer, maybe time will come, I will convert it to net and put it "for sale". I will make a website in English and put it up. I think that selling it :) ( I'm actually already laughing - here I have not engaged in life sharavara toloko) will be for 30-50 quid. But it's interesting - think about it: you write it on MT4 and debug it in studio :) :)
If there is such an indicator on a symbol with the same parameters it is not recalculated. But to be honest I do not remember what exactly is not there, but everything is there, that is necessary in MT4. And the ticks are coming from each symbol in the EA being tested, not only from that symbol on which the EA operates, like in MT5 now.
That reminds me - there's even libraries and export ... Well, there is everything. :)
Integer (and even if short short) data cannot be used in any division and multiplication operations. Where to store fractional values of 15 digits? Similarly, it is dangerous and suicidal to use float, which absolutely lacks accuracy. The amount of accumulated errors in float is such that you should never use it to calculate indicators.
Beginner developers are not aware of this. They don't yet see the full extent of the complexities.
There is no particular advantage to converting prices to integers. Yes, it effectively reduces volumes, but many times it loses speed due to unavoidable conversion to double. It is unavoidable, because it is not possible to make the entire system integer, the computable mathematics still have to be done in double (which accuracy is not even enough).
Integer (and even if short short) data cannot be used in any division and multiplication operations. Where to store fractional values of 15 digits? Similarly, it is dangerous and suicidal to use float, which totally lacks accuracy. The amount of accumulated errors in float is such that you should never use it to calculate indicators.
Beginner developers are not aware of this. They don't see the full scope of complications.