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
...
It is even difficult to imagine such an EA that it lacks the power of one core in real life. For example, if in the tester the Expert Advisor makes one pass of one symbol per day on one year's history (it is too much! Maybe we should rewrite the code!), then in real life, it will load the CPU on average 1/250 of power = 0.4%.
For an EA on ten symbols - you get an average load of 4%. There's not much point in loading the other cores.
As for Konstantin's(Lizar) idea, I think it's good. But for this kind of solution we need to separate the events which come directly from the chart and those which are generated custom. For custom events, we can have two event queues and two handlers, like OnUserEvents.
And an interesting addition to custom events would be the ability to explicitly specify their priority (say from 0 to 9), which could allow the user to control the preempting and handling of certain events. For example, such a feature would allow to execute events with a lower value, and remove them from the queue with a higher value (if the queue is full of more important events, new ones will not be queued).
I've never done any software development, so I can't speak the technical language of software developers. I will describe what I would like to get from my 4-core computer and MT5. In general it looks like this:
Handling of several tools is now possible and the developers created a perfectly workable solution.
2. About the work of the tester and a heap of cores. It is a special case and it is not correct to compare this mechanism with real trading. The essence of solving the problem of the tester is that having several Expert Advisor variants (or rather one Expert Advisor + a lot of unique sets of parameters) it is reasonable to distribute calculations among all available cores/agents. Thus we get asynchrony for the whole set of tasks, but from the standpoint of an individual agent everything is synchronized.
3. When it comes to multithreading, we are not talking about processing multiple tools at the same time, but about processing multiple events at the same time (and within a specific single agent). That was not present in any version of the terminal.
The developers are also understandable: too much overhead, too "motley" mix of users, too many problems with synchronization of data a "multi-threaded" Expert Advisor will have access to, etc.
On the other hand, the idea with events is not taken to its logical conclusion. Ok, it's expensive and problematic to implement "multithreading" but it is possible to maximally parallelize processes and information flows within the terminal itself + create a set of handlers sufficient to solve the maximum number of tasks (and with a normal set of parameters).
My Expert Advisor on M5, on the period 04.01.2010 - 01.09.2011 on 12 currencies makes a single pass in 1436 sec (24 minutes) and at the same time makes 5687 trades. Only one core is loaded, the other three are idle. That is, at each single pass I lose 3/4 of the time because the platform does not use computer power. This is a significant drawback of the platform when debugging a strategy. Cores are fully utilized only during optimization. But optimization is much rarer than single runs. And a lot of time is wasted on single runs.
The "losing 3/4 of the time" approach indicates that you believe: using multithreading is just a missed opportunity and a clear flaw of the developers.
Unfortunately, multi-threading on sequential tasks (and a single tester pass is a sequential task) is not given for free. In reality, multi-threading has huge (sometimes multiple) losses for process synchronization. In fact, all accesses to shared resources have to be tied up with synchronizers.
We deliberately moved the tester out of the terminal into a separate process just for the sake of allowing it to work in a single thread without any locks for 99% of the testing time. It resulted in a significant speed gain.
The suggestion "let's shove multitasking into each EA" is from a complete misunderstanding of the cost (total slowdown) of multithreading in this case and the consequences (slowdown + blowing the roof off 99% of non-professional developers).
We have effectively solved the issues of applying multitasking in the terminal, tester and enabled almost unlimited scaling of power in the remote agent and MQL5 Cloud Network modes.
If there are 12 different charters with different symbols, it means that each symbol of each char is obviously running in its own thread without affecting the others.
If the charts start to slow down, the reason is banal - one of the indicators is very uneconomical. In this case, no amount of multitasking will help, because the root is the work of the programmer, who writes indicators in the head, not caring about the efficiency.
I can not get the reverse chart, something is wrong, the new bar glitches on this variant
the original indicator I've been fiddling with is attached
Please advise what the problem is.
I am writing a multicurrency
I get MA indicator handle
I am doing the same for the remaining 10 currencies allowed in the Championship, but I get error 4801 during testing, all 12 currencies are in the history (I think)
I am testing on EURUSD chart
the Expert Advisor is testing GBPUSD (I have set it so in the settings, in order to optimize it)
Please advise what the problem is.
I am writing a multicurrency
I get MA indicator handle
I am doing the same for the remaining 10 currencies allowed in the Championship, but I get error 4801 during testing, all 12 currencies are in the history (I think)
I am testing on EURUSD chart
the Expert Advisor is testing GBPUSD (I have set it so in the settings, in order to optimize it)
papaklass:
Now answer me such a simple question ....
I will answer even more simply, even if not politely.
Unfortunately, you are completely off topic and make statements that show only superficial ideas about the processes.
I'm afraid most of our technical arguments will not be understood, nor will even the basic problem of synchronisation and the loss on its provision be understood.
Hence there is no need to make requests "you tell us your arguments and we'll speculate", the situation is perfectly understandable
I can't find any answers to these questions for a newbie:
1) When adding another element to a dynamic array, is it necessary to expand it with ArrayResize?
2) Is there a function in MQL5 to delete an element (one in the middle of an array, for example) from a dynamic array i? If no, what is the best way to do it?
As a newbie, I can't find any answers to these questions:
1) When you add another element to a dynamic array, do you have to expand it with ArrayResize?