Asynchronous and multi-threaded programming in MQL - page 23

 
Maxim Romanov:
Explain to me what is wrong with opencl. The terminal implements the ability to write opencl code, and this is multithreading. I want to understand for myself what are the differences of multithreading which is written here and this feature.
Well, or who knows, explain so I can understand.

There are no video cards on VPS servers, or it's very unprofitable if they are ))
Even most users on local, video cards do not support opencl))
Not to mention the complexity of writing proper code for opencl.
Yes, there is an option, but for a very small circle of people.

 
Roman:

Video cards are not available on VPS servers, or very unprofitable if they are available ))
Even most users on a local site do not support opencl))
Not to mention the complexity of writing proper code for opencl.
Option yes, there is, but to a very narrow circle of people.

On a processor opencl also works. You simply select the device which will execute the code. It's not just for video cards technology. On servers, I know there's trouble with videocards.
 
Maxim Romanov:
On an opencl processor, it works too. You simply select the device that will execute the code. It's not just video card technology. On servers, I know there's trouble with videocards.

But I didn't know that opencl also works on CPUs. I still can't get to Renat's article to read about opencl.
I read a post about opencl here too, but I can't get all programmers on opencl, native methods of tasks out of the box look more usable.
So, does opencl work on any processor? Or it also depends on the model?

 
Roman:

But I didn't know that opencl also works on processors. I still can't get to Renat's article to read about opencl.
I read a post about opencl here too, but you can't put all the programmers on opencl, the standard methods of tasks from the box look more usable.
So, does opencl work on any processor? Or it also depends on the model?

Yes, it seems to work on both Intel and amd processors, one only needs to install drivers. I tried it on amd and it worked.
 
Maxim Romanov:
It seems that yes, it should work on Intel and amd, you just need to install drivers. I tried it on amd and it worked.

It turns out that all the same, some degree of dependence depends on either the processor model or the drivers.
This may not be suitable for all, for example, those who distribute (sell) their work.
There are people who care about portability of the program, in my opinion it is also an important parameter.

Can opencl work with custom dlls?
i.e. asynchronously call exported functions from dll?
If we had an internal class to work with tasks, we could call our own functions from the dll asynchronously.
That is, the regular functionality is much more usable, and more accessible in writing code.

 

Too bad we haven't heard from the head of the transport department - what specific task do you want to implement multi-threading? Draw a simple block diagram of the proposed solution.

You are stubbornly trying to squeeze in an MKL task for which it was not originally intended. In a word, not at all. There are ready-made solutions - look at ZeroMQ which has API to almost all the JDs. Moreover, kind man Ding Li developed a library for ZeroMQ using with MQL4/5 with set of examples. Please read forum thread on this topic with practical examples of code.

Why are you (the topic starter) pushing water in a pan? Or are you also tied to the market?

Good luck

Interesting Whitepapers - zeromq
  • zeromq.org
Unlike other (centralised) messaging systems which are based on the well-understood theoretical foundation, there are almost no resources regarding distributed messaging in general and ØMQ in particular that an interested reader can be pointed to. The goal of this paper is to explain the elementary concepts of ØMQ architecture, how they fit...
 
Roman:

Does opencl know how to work with custom dlls?
I.e. asynchronously call exported functions from dll ?
There was an in-house class to work with tasks, you could call your functions from the dll asynchronously as well.
That is, the regular functionality is much more usable, and more accessible in writing code.

Call the DLL function. You create a thread in the DLL and transfer data to it, disconnect the thread and forget about it - it completes its task by itself. When you disconnect the thread in the DLL, the terminal thread is released. The whole process takes, I believe, less than a millisecond. Judging by the fact that even without disconnecting the thread, the process of writing to the database is 4-5 ms. Well, and 60 ticks/min is enough to not be sad about asynchronous call from terminal.

 
Vladimir Perervenko:

Too bad we haven't heard from the head of the transport department - what specific task do you want to implement multi-threading? Draw a simple block diagram of the proposed solution.

You are stubbornly trying to squeeze in an MKL task for which it was not originally intended. In a word, not at all. There are ready-made solutions - look at ZeroMQ which has API to almost all the JDs. Moreover, kind man Ding Li developed a library for ZeroMQ using with MQL4/5 with set of examples. Please read forum thread on this topic with practical code examples.

Why are you (the topic starter) pushing water in a pan? Or are you also tied to the market?

Good luck

I try not to use third-party solutions.
I have already found a solution for my networking problem, so all I have to do is study it, apply it and not fuck my brains out.
But there are programmers here who also need non-blocking calls and asynchrony.
That's why I suggested to implement this functionality into standard language delivery. And it is up to developers, the main thing is the idea, and it is sensible.
Why do you think that the terminal is not designed to implement EventLoop? Especially from the word go...
What algorithm is used to execute local agents? Probably in a thread pool, right? Who manages them, distributes the tasks?
So, the terminal already has such an algorithm, why not use it to extend its functionality?
Give programmers an asynchronous mode of code writing.
I'm for the idea, if no one needs it asynchronously, well what can I say, I only regret that many are stuck in a single thread.


 
Yuriy Asaulenko:

Call the DLL function. You create a thread in the DLL and transfer data to it, disconnect the thread and forget about it - it will terminate on its own after completing its task. When you disconnect the thread in the DLL, the terminal thread is released. The whole process takes, I believe, less than a millisecond. Judging by the fact that even without disconnecting the thread, the process of writing to the database is 4-5 ms. Well, 60 ticks/s is enough to not be sad about the asynchronous call from the terminal.

Here, thanks for another idea, I can write dll according to local articles, but unfortunately they don't describe entry point procedure, initialization,memory allocation, thread creation, etc.
I can't find any literature on this subject, I can't find how to handle entry point properly. If there is any information on this subject, please let me know.
Or if you can teach me, I will be glad to accept knowledge.
I have not studied as a programmer, all I learn myself, therefore, do not kick me bore ))

 
Maxim Romanov:
Explain to me what is wrong with opencl. The terminal implements the ability to write opencl code, and this is multithreading. I want to understand for myself what are the differences of multithreading which is written here and this feature.
Well, or who knows, explain so I can understand.
To be honest, opencl didn't study it attentively. I caught some dependence of this solution and stopped being interested. It occurred to me that I should pull wires from one place to another and screw something on. May be I'm wrong, but I haven't met any practitioners using opencl here and there was nobody to break my prejudice. Perhaps I'll change my mind later on, when I've got to know them better, or vice versa. In any case, the external dependency is stressful, because the portability of programs is crucial to me.