MT5 and speed in action - page 71
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 suggest that this is the end of theorising, which will never intersect with practice here.
Then I suggest you also stop the pointless single-threaded synchronous tests.
Expecting to get parallel results.
The problem is not solved in any way. MQL programs will become much more complex if the internal variables are read\write accessed from different threads, for example.
It's just that MQL6 should be similar to Erlang, not C++ )
Then I suggest you stop the pointless single-threaded synchronous tests too.
Expecting to get parallel results.
I am concerned about lags of large magnitude occurring on almost every tick. It has nothing to do with threads. The developers are figuring it out.
It's just that MQL6 should be similar to Erlang, not C++ )
then Scala is better.
.... but no matter how you look at it, behind the wrappers of these strong functional languages with dynamic typing... will still be machine C++, Python is a proof of that, the discussed java with event loops is from another galaxy where you need to have a distributed multiprocessor system to get some kind of expansion and scalability of the computing system
At school.
- Vovochka, how do you use chicken fluff?
- I don't know.
- Well, what do you sleep on?
- On the floor.
- And what do you put your head on?
- On a felt boot.
- And what do your parents sleep on?
- On the floor.
- And what do they put their heads on?
- On the valenki.
- And what does Grandma sleep on?
- On the stove.
- And what does she put her head on?
- On a pillow.
- And in the pillow, what's the fluff?
- And in the pillow is a valenki.
Scala is better then
.... but no matter how you look at it, behind the wrappers of these strong functional languages with dynamic typing... Python is a proof of that, the discussed java with event loops is from another galaxy where you have to have a distributed multiprocessor system to get some kind of extensibility and scalability of the computational system.
That's the thing, Python is written in C and Python has an asyncio library which is based on the event loop model.
So much for the swath anecdote ))
then Scala is better.
The main thing is to compile in VHDL and make your own server)
The discussion has gone somewhere sideways - the speed of integration with Python is of course an important issue, but there are many basic problems that affect the speed of EAs execution.
I suggest to focus on the problem that in the OnTradeTransaction function in the final call of TRADE_TRANSACTION_HISTORY_ADD the fields of MqlTradeTransaction and MqlTradeResult structures are almost empty, i.e. they are not filled in the same way as the order is later reflected in the History tab and how they are shown in Help/Documentation. The correction of this flaw would already give a real speedup in the combat execution, as there would be no need to call HistoryOrderSelect unnecessarily to obtain comprehensive values about the executed order.
And on the whole, on the Mql community level, the elimination of this gap will lead to a massive reduction of effort required to create different crutches in Expert Advisors to bypass the shortcomings of the current implementation of OnTradeTransactio.
The question is how to influence MQ team? Maybe a separate post with voting and collecting signatures for elimination of this shortcoming of this function?
The question is how to influence the MQ development team?
My recipe seems to work: reproducing the problem with concise code.
The discussion has gone somewhere sideways - the speed of integration with Python is of course an important issue, but there are many basic problems that affect the speed of EAs execution.
I suggest to focus on the problem that in the OnTradeTransaction function in the final call of TRADE_TRANSACTION_HISTORY_ADD the fields of MqlTradeTransaction and MqlTradeResult structures are almost empty, i.e. they are not filled by analogy with how the order is then reflected in the History tab and how they are filed in Help/Documentation. The correction of this flaw would already give a real speedup in the combat execution, as there would be no need to call HistoryOrderSelect unnecessarily to obtain comprehensive values about the executed order.
And on the whole, on the Mql community level, the elimination of this gap will lead to a massive reduction of effort required to create different crutches in Expert Advisors to bypass the shortcomings of the current implementation of OnTradeTransactio.
The question is how to influence MQ team? Maybe a separate post with voting and collecting signatures for elimination of this shortcoming of this function?
Python is a good example of an event-driven model. And Igor's anecdote is exactly on point.
And if the developer has grasped the meaning of the example, then he knows where to dig.
Any expectation of timely result sooner or later rests on a synchronous execution model.
In mql it has come. The possibilities of the language are very rich, but artificially limited to synchronous execution.
Roman:
Не понимание примера с Python, говорит о не понимании обсуждения асинхронности в целом.
You're the one who doesn't understand. Don't clutter up the thread.