Once again, about multithreading - page 4
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
Well, let's say, not everything you've listed relates to mql5 tools :) And the question was not about how to solve (circumvent) this question. You can always find a way around it, there's no doubt about it. The question is why we can't add the appropriate functionality to mql5 without any details.
MQL5 has everything we need, we just need to learn to use it.
Transfer part of the calculations to the indicator and run it from an Expert Advisor.
And no one will do the basic paralleling for 2 dozens (optimistically) users.
There are scripts for multithreading. And you don't need it in the tester
How do you run a script from an Expert Advisor?
Transfer some of the calculations to the indicator, and run it from the Expert Advisor.
There you go again with the tambourine dance. I was talking about a normal implementation.
And no one will do the usual paralleling for 2 dozen (optimistically) users.
It seemed to me from the beginning that MQL5 is positioned as a language for more or less skilled programmers, in contrast to mql4. This means that the optimization of the algorithm, paralleling it across multiple threads must be a daily necessity. That's why I drew your attention to this point in the beginning of the topic. And Renat for some reason reacted very painfully to it.
Constantly solving the issue of optimization through one place, as many people here suggest, is not something one wants to do at all.
Besides, I've already said at the very beginning that I'm not asking them to do normal paralleling. I'm perfectly capable of paralleling everything myself, using WinApi. All I need is a function address. That's why I asked to add only pointers to functions. Of course, it is desirable to support __stdcall directive, but it is not necessary, you can do the necessary manipulations on your own.
Pointers to functions is actually a very useful thing. Using them to create threads is only one of the many uses. They are also used, for example, to specify callback functions in various asynchronous operations. They will also be arch-usefully transferred to the DLL, which simplifies the communication between the DLL and the Expert Advisor that imported it, i.e. complete integration. At runtime, the DLL can directly call the MQL function and get some needed information from it. Now in order to do it, we need to generate an event (eg, a tick), which will call an Expert Advisor and then pass the required information to the DLL... All in all, extra hassle and time consumption
- Adding multithreading to the language implies creation of a special API that supports multithreading,
- Have to rewrite the MQL5 compiler optimiser - actually worsen the optimisations.
- This is a place for hard-to-find user bugs.
Well and lastly, not very few users need it and lack of support can be bypassed.which in turn will run slower than API without such support, I hope it is clear (loki, etc.).
About pointers to functions.
The question is open with regard to their use within the MQL5 code.
Unfortunately, we will not be able to pass the pointer to DLL - we had to sacrifice the call agreement for crossplatform x86/x64.
Regarding multithreading.
The man is just trolling (I thought the language was...) for theoretical reasoning and does not understand neither the applied nature of the language nor consequences of multithreading.
In fact, he doesn't even have a real task for concurrency.
mql5:
...Ну и последнее, нужно это не очень малому числу пользователей и отсутствие поддержки можно обойти.
I like the idea of using scripts, but how do you call them from the EA?
I like the idea of using scripts, but how do you call them from the EA?
But there is a way, through a template of a chart, if you write a script in it instead of the Expert Advisor.
When applying such a template to a new chart, the script is launched (however, this is an "undocumented feature", which may not become available one day)...
What is your task?
Why don't you have a ready to run Expert Advisor on the adjacent chart, which will do its job after receiving an Event?
Launching a new MQL5 program is expensive, because of the protection of EX5 files.
Unfortunately, scripts cannot be launched from MQL5.
But there is a way, through a chart template, if we put a script in it instead of the Expert Advisor.
When applying such a template to a new chart, the script is launched (however, this is an "undocumented feature", which may not become available one day)...
What is your task?
Why don't you have a ready to run Expert Advisor on the adjacent chart, which will do its job after receiving an Event?
Launching a new MQL5 program is expensive, because of the protection of EX5 files.
I have thousands of graphical objects to analyse: delete unnecessary ones, change properties, calculate statistical characteristics, etc. Even on one chart there are lags, and what if there are several of them?
The problem of working with graphical objects should be solved algorithmically. Economically and don't mix commands for changing and reading objects. For example, 1000 reads and only 1000 writes will be much faster than 1000 reads and writes.
About multithreading.
- Adding multithreading to the language implies creation of a special API that supports multithreading,
- Have to rewrite the MQL5 compiler optimiser - actually worsen the optimisations.
- This is a place for hard-to-find user bugs.
Well and lastly, not very few users need it and lack of support can be bypassed.which in turn will run slower than API without such support, I hope it is clear (loki, etc.).
About pointers to functions.
The question is open with regard to their use within the MQL5 code.
Unfortunately, passing a pointer into a DLL will not work - we had to sacrifice the calling convention for x86/x64 crossplatform.