OpenCl and the tools for it. Reviews and impressions. - page 6
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 suspect that's what Mischek was shouting about a month ago.
I see OpenCL's application in either heavy testing or very intensive parallelized calculations on the fly.
So far I don't need it (all heavy calculations are in my init() of the inductor), but it's worth mentioning.
Alexey, I have the same problem: I try to drag something to init, and then to real time :)
My brain is turned on a procedural language. OOP is desirable, but not native.
For those fanatic B4 fans who don't visit mql5.com : OpenCL: internal tests of implementation in MQL5
Thanks, I personally didn't see that one. Only it's not that simple.
Besides, Rinat is confusing people: OpenCL 1.0 can work fine with double float, it's a "public option" supported by all manufacturers - BUT NOT FOR ALL OLD MAPS.
http://www.khronos.org/registry/cl/sdk/1.0/docs/man/xhtml/
"Optional Double Precision and Half Floating Point
OpenCL 1.0 adds support for double precision and half floating-point as optional extensions. The double data type must confirm to the IEEE-754 double precision storage format.
An application that wants to use double will need to include the #pragma OPENCL EXTENSION cl_khr_fp64 : enable directive before any double precision data type is declared in the kernel code. This will extend the list of built-in vector and scalar data types to include the following:.....".
It can work in the Strategy Tester but it won't work in the OpenCL 1.0 Expert Advisor not because, as Rinat says, "there is no double float there" but, as I've already mentioned, because there is no safe threading in OpenCL 1.0 and there is no threading in MT4-5.
OpenCL (and CUDA) is confusing in general. What do you want? After all, the iron and radio engineers set out to change the concept of programming. They have an iron mindset.
There will also be a problem with the so-called "PLATFORM SELECTION": the program, that is, MT or DLL or Expert Advisor, MUST, just MUST choose the platform (AMD, Nvidia, Intel), which can be several different ones that will run the OpenCL connector, and then manually select DEVICE if your computer is running Multi-GPU. The platform auto-selection in OpenCL is not there yet. Rinat talks about "auto-select the most powerful" but I don't know how it is. In the example shown there, there is no platform selection and no device selection (GPU, CPU).
Furthermore, there is as yet no automatic OpenCL parallelization of tasks on several GPUs or on GPU+CPU in the standard. Let us put it this way: in some versions of its drivers/SDK AMD used to introduce such autoprovisioning but had some problems and for the time being AMD has switched this feature off.
Bottom line: to develop and enable OpenCL programs c/o MT4-5 requires some manual effort and therefore will not work automatically or by "recompiling with option". Which in turn is fraught with a lot of stalling in real-world operation. It will be a subtle work and, what is important, I allow myself to repeat, unfortunately it is JEWISH ORIENTED PROGRAMMING, which is wrong. Debugging parallel programs for CUDA or OpenCL turned out to be much more difficult than the iron revolutionaries assumed. Nvidia even cancelled their fall 2011 CUDA conference - due to driver issues and a lot of complaints about stalling debugging. So, they added another 1000 new features to the latest Toolkit - and what to do with it, if the simplest programs don't even run or run with interruptions? After all, they haven't even mentioned half of the internal mechanism of OpenCL or CUDA in their descriptive tools.
GPU speed (in GigaFLOPS) of a hanging video card due to driver or software compatibility is zero.
Thank you, I haven't personally seen it. Only it's not that simple.
....That's not really the point. You can write in procedural style on a five.
joo: And , I'm discouraged by this fact, akhtung! - MQL4 calling dll works faster than MQL5 calling the same dll...
This is what's so alarming.
They could have developed native support for OMP in MQL5. It would be easy and cheap for the coder, and there is no need to write any dll.
But this swarm of bees written in an incomplete iron programming language... doesn't exactly inspire me yet. Well, yes, a hundredfold acceleration in some cases is great, but in terms of programming culture it's a step back.
There is a lot of confusion in OpenCL (and CUDA) in general. What do you want? After all, the iron and radio engineers have set out to change the concept of programming. They have an iron mindset.
There will also be a problem with the so-called "PLATFORM SELECTION": the program, that is, MT or expert DLL or EA, MUST, just MUST choose the platform (AMD, Nvidia, Intel), which can be several different ones on your computer and on which the OpenCL connector will be running, and then manually select DEVICE if your computer is running Multi-GPU. The platform auto-selection in OpenCL is not there yet. Rinat talks about "auto-select the most powerful" but I don't know how it is. In the example shown there, there is no platform selection and no device selection (GPU, CPU).
Furthermore, there is as yet no standard way to automatically parallelize OpenCL tasks across several GPUs or across GPU+CPU. Let us put it this way: in some versions of its drivers/SDK, AMD used to implement such autoparallelization but there were problems and AMD has so far turned it off.
Bottom line: to develop and enable OpenCL programs c/o MT4-5 requires some manual effort and therefore will not work automatically or by "recompiling with option". Which in turn is fraught with a lot of stalls in real-world operation. It will be a subtle work and, what is important, I allow myself to repeat, unfortunately it is JEWISH ORIENTED PROGRAMMING, which is wrong. Debugging parallel programs for CUDA or OpenCL turned out to be much more difficult than the iron revolutionaries assumed. Nvidia even cancelled their fall 2011 CUDA conference - due to driver issues and a lot of complaints about stalling debugging. So, they added another 1000 new features to the latest Toolkit - and what to do with it if the simplest programs don't even run or run with interruptions? After all, they haven't even mentioned half of the internal mechanism of OpenCL or CUDA in their descriptive tools.
The GPU speed (in GigaFLOPS) of a hanging video card due to driver or software compatibility is equal to zero.
That's not really the point. You can write in procedural style on 5 as well.
But this is alarming.
They could have developed native support for OMP in MQL5. It's simple and serene, no dll has to be written.
But this swarm of bees in an incomplete hardware programming language... ...doesn't seem very exciting. Yes, a hundredfold acceleration in some cases is great, but in terms of programming culture it's a step backward.
I've also come across facts when mql4 works faster than MQL5. In most cases it is manifested in mathematical operations optimized by the programmer.
But I think this is not the main problem - by using OpenCL MQ they took a road that runs parallel to the main programming path - maybe so far this requires a step back, but in the future development of computer technology we will see integrated scalable systems where it will already depend on the code whether the sequential or parallel processing is used.
So the road is quite right. Although nowadays there are not so many algorithms demanding implementation of parallel approach, but it is rather because mathematical thought did not have equipment for implementation of parallel computations and hence there was no need to create such algorithms.
Alexey, just think about one fact, all mathematical discoveries were made 200-300 years ago, the last 100 years the mathematical thought was just polishing what is. It was only the discovery of NS that created the demand for parallel calculations. The next 100 years will see substantially parallel algorithms. And you, among others, can invent one of them.
I've also seen facts when mql4 is faster than MQL5. This is most often seen in matrix operations optimized by the programmer.
But I think this is not the main problem - by entering OpenCL MQ have taken a road that runs parallel to the main programming road; maybe so far this requires a step back, but in the future development of computer technology we will see integrated scalable systems where it will already depend on the code whether the sequential or parallel processing is used.
So the road is quite right. Although nowadays there are not so many algorithms demanding implementation of parallel approach, it is rather because mathematical thought did not have equipment for implementation of parallel computations and hence there was no need to create such algorithms.
Alexey, think only about one fact, all mathematical discoveries were made 200-300 years ago, last 100 years mathematical thought was just polishing what is. It was only the discovery of NS that formed the demand for parallel calculations. The next 100 years will see substantially parallel algorithms. And you, among others, can invent one of them.
No, you are not quite hopeless after all. :)
Hi.
MQ are good, they were not afraid to deal with such a pain (for them) as introduction of support for GPU calculations. The pain, first of all, is connected with the fact that the introduction of fundamentally new technologies (any) reduces the reliability and fault tolerance of the platform as a whole at first. But they perfectly understand, that the future belongs to parallel computing and sooner or later they would have to do something in this direction (the first step was already made - cloud).
PS Hi Nikolai. Why did you disappear? - Drop me a line.
This is not a fact as it is not. The qualitative development of mathematics has never been interrupted.
And parallel calculations are not only needed by NS, there are more mundane tasks - say, video coding or rendering.
But the general vector of MQ movement is certainly encouraging.