Once again, about multithreading
Dear Developers, I searched on the subject of multithreading and found a phrase that you said that you were not going to add functions that create and manage threads in MQL5. It was said more than a year and a half ago. I wonder if your views have changed since then?
If you still do not want to bother with it, why not let the users implement it themselves? For that we need a function pointer. How about adding such a feature? I.e. GetPointer(myfunc)
Also, if you'd like to explain why you did not implement multi-threading in MQL5. Why did you see any particular difficulties? Or maybe it was just a matter of principle?
May I remind you that this is not the year 2000 anymore and multicore processors have long since become the norm for all, the number of cores will only increase every year. Now it is 4, in a couple of years it will be 6-8, etc. And you do not allow users to properly use the processor with the program they are executing.
What's the point of your constant speed comparisons between MQL and C++ then, if you are only comparing work in one thread? After all, no reasonable C++ programmer would hang a resource-intensive task from one thread when there are several processors that can increase the performance many times over. That's why all your tests have little relation to real life. In a few years the processor core will grow to 10 cores and you will still be proud of your single-threaded MQL tests?
As for using OpenCL, that's shamanism, especially in the way it is implemented here - via the text line. So you debug your code somewhere else, and then copy it into MQL5... What a circus! It would then be easier to implement all this in a DLL and import it. Moreover, very few people would want to write a program in several languages.
Multithreading in MQL5 is still available, but unlike C++, it is implemented as a virtual execution environment called a chart.
Each chart is running in a separate thread. This is done to avoid troublesome synchronization of threads, data access and other issues that arise during communication between threads.
Pretty ugly? Yes, but for the mass user (who is already complaining about the complexity of the language) it's just the right thing.
As far as OpenCL is concerned, it is a separate issue. It wasn't even in the platform development plans. At the beginning, the advanced forum users attracted the interest of developers on this topic, but the official response was "no and will not be". But then the leadership of MQ have changed their anger for mercy(thanks Ilyaz).
About Dll: MQ considers them potentially dangerous, so whenever possible to avoid them they try to implement it, especially for public services. But it does not forbid them in general, because programmers write not only for the public, but also for the interlocutors.
All in all, it looks like pure theoretical statements.
There is nothing wrong with multithreading and full use of processors in the terminal. Look how many threads are running in the terminal and how the number of threads changes in time. The principles of multi-threading have been explained and demonstrated many times. For example, how independent threads of indicator recalculation, symbol recalculation, chart data paging and independent operation of all Expert Advisors and scripts work.
In order to parallelize calculations of anything, you should first realize that only a tiny part of mathematics can be parallelized.
Look at the multi-core tester, MQL5 Cloud Network and OpenCL. We've been ahead of the curve for a long time now, especially in cloud computing. Right now, turn on the MQL5 Cloud Network in your tester and get up to 14,000 CPUs to help you:
You don't seem to know anything about OpenCL either. Presenting program code in source form to be sent to the OpenCL compiler is the usual and standard way of working. Keep in mind that different OpenCL handlers (Ndivia, AMD, Intel, etc.) have to get the code and rework it for themselves.
- cloud.mql5.com
What is multithreading in MetaTrader 5:
Just clicked on the test, instantly got 5,743 agents/CPU's to work and executed 381,468 passes in the optimizer in 6 minutes. Each pass took between 1 and 2 seconds to run. If I ran the test on my computer with 8 cores, I would have spent 800 to 1600 minutes instead of 6 minutes (381468 / 8 = 47683 seconds = 794 minutes).
And apart from hitting the start button, I didn't have to do anything else. Some skynet got up, synchronised all the required chart history on its own, distributed the task to thousands of computers around the world and worked them off en masse.
Welcome to reality...
Renat,
question about creating threads inside MQL5 Expert Advisor.
Renate,
The question about the creation of threads inside MQL5 Expert Advisor.
I'm aware of that.
I just didn't write that it's better not to talk about multithreading to a person who doesn't understand why there is no multithreading in an applied computational language. We have implemented the whole infrastructure multi-threading of the terminal in a full and effective way.
Real multithreading is needed in places where you can actually parallelize tasks. This is a tester. And this is the place where we have implemented it in such a way that many people are far away from understanding the quality, control and volume of the work done.
My example with claude is a simple proof of the quality and level of elaboration of the task.
Yes, Renat, you didn't read my post carefully. We are not talking about multithreading of MT5, but about multithreading of MQL5. We cannot create these threads in a running program by ourselves. The program opening of a new chart with an indicator is a tambourine dance, not a solution.
It's amazing, you have made a lot of unnecessary things in MQL5, considering a mass user. And as far as I'm concerned, you are focused mainly on dummies, not on literate programmers. Hence the heap of restrictions, impossibility of working with memory directly, etc. So the question is, why do dummies need e.g. classes?
If you position your product not only for dummies, why can't you give experienced programmers an opportunity to effectively use system resources?
The lack of multithreading will not be compensated with any classes. However smart a program might look but if it uses the system resources inefficiently, it is a shame for it all. Perhaps you in the pursuit of innovation have forgotten that the MQL language is intended primarily for writing trading and analytical programs, and not for programming for the sake of programming. Therefore, the speed and the effectiveness of the program, rather than the speed of writing code, should be the first priority. Because the work with large data sizes is expected a priori.
I think the capabilities of MQL4 will be quite enough for the majority of users. The only things that were missing was support of structures, pointers to variables and pointers to functions (or built-in support of callback functions). And that's all. Having this arsenal, you can create any programs that work very effectively, create the required number of threads, callbacks, etc.
meat, no offence, but with this level of understanding of the issues in kindergarten.
I've read everything carefully, but I don't have the possibility to give a full-scale education. I have 11 years of experience in MQL/MQL2/MQL4/MQL5 languages.
It's not about MT5 multithreading at all, it's about MQL5 multithreading. We cannot create these threads in the running program by ourselves. And the software opening of a new chart with an indicator is, you will agree, a tambourine dance, not a solution.
The most surprising thing is that you have made so many unnecessary things in MQL5, if we take into account a mass user.
If you take a single user, there may be a lot of unnecessary things. And when you start to widen your horizons and additional features are required, it turns out that, on the contrary, something is already there, while something is missing.
MQL5 is still under development. Something new is being added little by little. Although, of course, there are also disadvantages, for example, you can't create your own events, there are no exception handlers and multithreading. I hope all this will come out someday? But I doubt it will all be implemented tomorrow.
If one really wants to, multi-threading is available to test agents in OpenCL as well. It is not entirely convenient, but still it is there and you can parallelize tasks.
meat, no offence, but with this level of understanding of the problems in kindergarten.
And you say not the corporate standard))
If questions are asked, it means that the answers are not on the surface...
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
You agree to website policy and terms of use
If you still do not want to bother with it, why not let the users implement it themselves? For that we need a function pointer. How about adding such a feature? I.e. GetPointer(myfunc)
Also, if you'd like to explain why you did not implement multi-threading in MQL5. Why did you see any particular difficulties? Or maybe it was just a matter of principle?
May I remind you that this is not the year 2000 anymore and multicore processors have long since become the norm for all, the number of cores will only increase every year. Now it is 4, in a couple of years it will be 6-8, etc. And you do not allow users to properly use the processor with the program they are executing.
What's the point of your constant speed comparisons between MQL and C++ then, if you are only comparing work in one thread? After all, no reasonable C++ programmer would hang a resource-intensive task from one thread when there are several processors that can increase performance many times over. That's why all your tests have little relation to real life. In a few years the processor core will grow to 10 cores and you will still be proud of your single-threaded MQL tests?
As for using OpenCL, that's shamanism, especially in the way it is implemented here - via the text line. So you debug your code somewhere else, and then copy it into MQL5... What a circus! It would then be easier to implement all this in a DLL and import it. Moreover, very few people would want to write a program in several languages.