Testing the new MQL5 compiler for x64 platforms - 2 to 10 times faster calculations! - page 9
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
For a well-written robot, computation speed is negligible compared to transaction execution speed.
A well-written robot still needs to be written and tested. And optimised.
And with the exchange... it's complicated and always will be.
Because for a fully correct test, you need the history of the stack, the tape... And it will still be wrong and not accurate because of the frontrunners, which are not present in the tester, but are present in the real
A well-written robot still needs to be written and tested. And optimize it.
Thank you for your support.
That's what I am talking about:
There is no strategytester for the trading terminal!
Why should we compete in math calculations if it is impossible to test a robot?
And about the speed of execution?
The exchange processes requests in 1 ms. Who cares how fast the terminal works if the MT5 server does not pass orders faster than 6 ms?
By the time the MT5 server is thinking, a good price will already be taken).
To developers and sympathisers:
Why are you trying to overtake C++?
For a normally written robot, computation speed is negligible compared to transaction execution speed.
The MT5 server is slowing down. How about setting up the server first and then competing in mathematical calculations?
...
Thank you for your support.
That's what I'm saying:
why compete in math calculations if you can't test the robot?
And about the speed of execution?
The exchange processes orders in 1 ms. What does it matter how fast the terminal works if the MT5 server does not pass orders faster than 6 ms?
By the time the MT5 server is thinking, a good price will have already been taken).
Thank you for your support.
Well... It wasn't exactly an endorsement )
In combat conditions the speed of execution is not so important.
If it is critical, it can be solved by optimizing the code, moving it into a dll or at least splitting it across different machines.
But during testing and optimization the speed is very crucial. And the language acceleration will solve this problem.
By the way, C# isn't so fast, by the way. If it were so, hft-blockers would use it instead of plus and java.
Dr.Trader andSergey Eremin
Thanks for the bug reports!
The sinput variable access generation error has been fixed.
Greetings.
I can't seem to get the optimisation to work. Purposely removed previous version of terminal, installed from scratch, connected to demo server, updated to build 1108 (from 23 April). The files are as follows:
metaeditor64.exe - 8,941,528 bytes
terminal64.exe - 14 052 296 bytes
I close everything, write the key in metaeditor.ini
[Experts]
Author=Copyright 2014, MetaQuotes Software Corp.
Address=http://www.mql5.com
Optimize=1
Any test will take a long time to run, as it would have done without optimisation. What's the problem?
When compiling for debugging, Optimize key is ignored, we haven't worked on debugging optimization yet.
...And by the way, C# is not that fast. If it were, hft-people would be using it instead of pluses and java.
Oh, come on. Are you going to claim that Java is faster than C#?
True HFT is programming the network card microcontroller directly. The languages themselves fall by the wayside.
People laughed 15 years ago, saying "how can it compete with Metastock, with Tradestation?
Tradestation has become a broker and they have a history of intraday futures for 27 years. Why don't you become a broker too?
You wouldn't have to ask brokers for the correct history. You can download what you need and how you need it. With Forsts, the history of the RTS Index is even easier - since 2005.
For me, the whole history, starting from one-minute data, will be enough.