Once again, about multithreading - page 3
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 recommend that you re-read your original post, pay attention to all your epithets, then go below to the answers.
The answers were given calmly, with some soft questions like "To parallelize calculations of something you must first realize", then the answers were given and the current state of affairs was explained "what really should be parallelized".
But instead of a quick learning curve you spewed more nonsense and put the dogs on us. The result was a harsh response.
OK, I agree with the epithets, I did go a bit overboard, and I apologise for that. I didn't say anything rude though, just overly emotional criticism, but it's totally inadequate to the harshness with which you react to it. Nowhere did I say that the developers are useless and do not understand anything, so do not exaggerate.
Since I've brought up this topic, I'm well aware of what it's needed for and there's a lot to parallelize. Not all the algorithms are limited with "hello world!", there are much more complex and resource-intensive ones. That's why it's very strange to hear such moral teachings about what you need to parallelize and what you don't while you haven't even seen the algorithm.
As for implementing code in the DLL as well as using OpenCL, it has no relevance to MQL. And the question was about programming in MQL.
OpenCL works within MQL5 code.
Here is a sample code.
As for implementing the code in the DLL, as well as using OpenCL, this is no longer relevant to MQL. And we were talking about programming in MQL.
And what was your answer? You started telling me what a great terminal and tester you have, working in multiple streams. And I haven't said a word about your terminal. I meant about another thing: multi-threading in MQL code. When an algorithm can be split into several parts, and each part is executed in parallel. And you, not even having understood the essence of it, start being rude. Well, as I see, with this approach there is no constructive approach, so there's no point in continuing the discussion.
There are some constructive solutions even with the current state of affairs. Several mql-programs (Expert Advisors and/or indicators) can exchange messages, and consequently, tasks and results of task execution - of course, if you create and arrange an appropriate exchange protocol. All the Expert Advisors work in different threads (each in his/her own thread), hence, such a joint calculation scheme is obviously multi-threaded and will evenly load them if there are several cores.
An exchange of messages (using mql5 tools) is possible through
1. terminal events
2. named channels
3. DLL
4. files
5. etc.
From this set of tools, you can choose the most suitable one or use more than one (all at once). Each method has its advantages and disadvantages, for example named pipes allow you to transfer information over local network, hence there is a possibility to parallelize task for more than one multi-core processor.
Good luck.
OpenCL works within MQL5 code.
Here's a sample code.
Well, the fact that it works is half the battle. But how to edit and debug it afterwards? If it is contained in a string constant, how would you look for an error? It means that it must be developed in an external program and then inserted into MQL. But if you constantly deal with this kind of porting, you'll go crazy, as I pointed out in the first post. Since the code development is done elsewhere anyway, what's the point of putting it all into MQL? It's easier to compile as a DLL and import it.
Of course, I understand that the purpose is to create an open source code, without using any self-written dlls. But this is special cases. Usually the program is written for yourself and not for others. And few people would want to constantly be engaged in meaningless manipulations on dragging the code from one program to another.
But if you make a built-in compiler for all this, it's another story. And by the way, why not? I mean, it's like a C syntax in there. I.e. you could use it all as a part of regular mql-code, just by adding additional functions to your MetaEditor. And then the compiler would format the corresponding code fragment in an appropriate way, adding \r\n, etc.
Well, the fact that it works is half the battle. How do you edit and debug it afterwards? If it's in the string constant, how can we find the error? It means that it must be developed in an external program and then inserted into MQL. But if you constantly deal with this kind of porting, you'll go crazy, as I pointed out in the first post. Since the code development is done elsewhere anyway, what's the point of putting it all into MQL? It's easier to compile as a DLL and import it.
Of course, I understand that the purpose is to create an open source code, without using any self-written dlls. But this is special cases. Usually the program is written for yourself and not for others. And few people would want to constantly be engaged in meaningless manipulations on dragging the code from one program to another.
But if you make a built-in compiler for all this, it's another story. And by the way, why not? I mean, it's like a C syntax in there. I.e. you could use it all as a part of regular mql-code, just by adding additional functions to your MetaEditor. And then the compiler would format the corresponding code fragment in an appropriate way, adding \r\n, etc.
Whoever wants it, looks for opportunities. Who doesn't want to, reasons © Proverb
There are constructive solutions even with the status quo. Several mql-programs (Expert Advisors and/or indicators) can exchange messages, and consequently, tasks and results of task execution - of course, if you create and arrange an appropriate exchange protocol. All the Expert Advisors work in different threads (each in its own thread), hence, such a joint calculation scheme is obviously multi-threaded and will evenly load them if there are several cores.
An exchange of messages(using mql5 tools) is possible through
1. terminal events
2. named channels
3. DLL.
4. files
5. etc.
From this set of tools, you may choose the most suitable one or use more than one (all at once). Each method has its advantages and disadvantages, for example named pipes allow you to transfer information over the local network, hence there is a possibility to parallelize the task for more than one multi-core processor.
Good luck.
Well, let's say not all of them are mql5 tools :) And it wasn't about how to solve (circumvent) this problem. You can always find a way around it, there's no doubt about it. The question is why we can't add the corresponding functionality to mql5, so that you don't have to get rid of it.
You must admit that it is not rational and reliable to launch a lot of Expert Advisors with appropriate charts just to arrange their processing in several threads.
Who wants, looks for possibilities. Who doesn't want to, the reasons © Proverb
First of all we need to understand the feasibility :) I mean the reasonability of using MQL5 in general, and MT5, respectively, whether it is worth switching to this platform. If, like in MT4, in order to work properly you need to use some magic, to run several EAs or to transfer the code to DLL, then it makes no sense to change a piece of ass for a piece of ass. If the code must be written in DLL, then it is easier and safer to use a platform with an open API, than to have an additional padding in the form of an Expert Advisor (and a running terminal as a whole).
Firstly we need to understand the feasibility :) I mean the reasonability of using MQL5 in general, and MT5, respectively, whether it is worth switching to this platform. If, like in MT4, in order to work properly you need to use some magic, to run several EAs or to transfer the code to DLL, then it makes no sense to change a piece of ass for a piece of ass. If the code has to be written in DLL, then it is easier and safer to immediately use a platform with an open API, than to have an additional padding in the form of an Expert Advisor (and a running terminal as a whole).
No one is forcing anyone to switch to MQL5. For example, I missed the functionality of MQL4, so I had to switch to MQL5.
For example, all functionality can be implemented in С++ and MQL5 should contain only executive part and the whole stuff should be tied with a protocol using named channels. There are a lot of variants. All you need is a strong will.