Comments by Javier Luis Lopez (Top 29 by date)

It was due #include <chrono> was not added to the .hpp code because I try write includes in the .cpp only or in a more complex project as in the following way:
https://photos.google.com/photo/AF1QipOtS9iHdhEHSJPpKOKrvy6X6ukVN2rETHklez1b

Thanks, at least I removed null_char; at the code

Thank you, I updated it but using
std::chrono::time_point<std::chrono::system_clock> if not errors appeared

OK, I also had to add #include <unistd.h> in linux
and compile with g++ instead of gcc.
I also modified it to use <chrono> but using system_clock() instead of high resolution one that not works in all systems.

...but the function compiled ok in windows:

double _hypo(double x,double y)
{
x*=x;y*=y;return sqrt(x+y);
}

(I am sorry about posting as solution, thank you CPallini)

At end I tried it on linux but either sqrt and hypot where rejected by the compiler error: sqrt not declared in this scope.
I unsuccessful tried to include unistd.h, cmath and math.h.

It should be easier if SSEs whould use the same assigning values, operations and vector types than OpenCL

" Please tell me which CPU "
At least I found results in an old drive backup:
Pentium 2 4 GHz: double prec: (d+d)/d+cte*d 49.6 Mops
Pentium D 3Ghz : 59.8 Mops

I think that the result was very fast due perhaps that operations could be pipelined.

Unfortunately I lost data from 10 years ago, so I have to withdrawn about old cpus.
The problem is perhaps thai in my code the divide operations can not pipelined, as long as it is needed to calculate one division and then the next.

I have tested also this line and had 520MOPs:
for (int i=0;i<size/20;i++)
dsum=1.1/(dsum+2.2/(dsum+2.3/(dsum+2.4/(dsum+2.5/(dsum+2.6/(dsum+2.7/(dsum+2.8/(dsum+2.9/(dsum+2.1/(dsum+2.2/(dsum+2.3/(dsum+2.4/(dsum+2.5/(dsum+2.6/(dsum+2.7/(dsum+2.8/(dsum+2.9/(dsum+3.1/(dsum)))))))))))))))))));

I read also about xeon architecture and said that the division performance IS VERY POOR, as can be seen in this recomended article: https://gmplib.org/~tege/x86-timing.pdf
And also here: https://stackoverflow.com/questions/4125033/floating-point-division-vs-floating-point-multiplication in the Peter Cordes reply (but explain only integer one).
The best of all was the AMD ZEN architecture with double throughput.

But in older processors multiplications, sums and divisions required the same clock cycles as long as "old" floating point ALUs performed all in one cycle.
The impact now is:
Multiplications: 2 times slower than sums
Divisions: 100 times slower!!
It seems that divisions are performed by SW as the first processors (that needed coprocessors)
This makes processors floating point at lower level than raspberry pi 40$ micros
Some engineering programs could get unserviceable.

Then, there are any processors with floating point divisions similar to sums performance?

I am not an Intel architecture espertise, only made the tests. The E5 V3 has
3 integer ALUs and 2 vector ALUs (to use in AVX). Also it has a sandy bridge microarchitecture with schedulers that can be used to parallelize vector operations as can be seen here:
https://www.realworldtech.com/includes/images/articles/sandy-bridge-5.png
It can be seen the full diagram here: https://www.realworldtech.com/includes/images/articles/sandy-bridge-7.png?x51911). So I think (can be wrong) Intel tried to parallelize more vector operations at the cost of make division operations serially as in the first historic processors.

Which is the right directory?

Accordingly Khronos the float4 must be aligned with float2 and float1 (float3 with float4) as can be seen here: https://www.khronos.org/registry/OpenCL/sdk/1.2/docs/man/xhtml/dataTypes.html

Unfortunately there is something wrong because it did not work, I tried this with uchars:
__global uchar* image0;
.....
if (pix==0)
{
__local uchar16 vv;
async_work_group_copy((__local uchar *) &vv,&imagen0[0],16,0);
printf("===GPU vv: %4v16i \n",vv);
}
if (pix<16)
printf("imagen0[%2i]=%3i",pix,imagen0[pix]);


But the result was wrong, only the first value was right. It can be seen result here:
https://photos.app.goo.gl/QrgjyaNRvxnnKN672

Thank you Jachen, but as you say it can be wrong depending on compiler (and gpu driver).

Could be used vload or vload4 to load arrays of data?

It is true, using double you should use more large arrays to have problems. I had only errors when managing large matrix inverse. (My problem now was test opencl code at cpu. In opencl works faster using floats as needs less kernels)

long double = double when working in visual studio

Be aware using other libraries with more bytes mantissa can be too slow when working with large arrays.

Sorry I made a mistake due my bad english I should say just the opposite: no question is asked

Thank you!. That is the answer, I updated the code.

You are true. fill not only can fills with zeroes a float array but also can be used to fill array with anything. It is a great advance.

You may be right, in my code there is a lot of memory transfer between CPU and GPU, that is typical in video applications. But if there is a lot of operations for every data the GPU will be a good option.

>For such cases you can still implement both and provide a user option to select the method or perform short tests to let your application choose the fastest method.

In my code at github there are the two options. Anybody can modify it to test gpu vs cpu methods

I supose that the memory allocation remains until delete[] operator destroy it.

Thanks, I edited delete[] instead delete.
Also I removed the check for null. The initial value of *data=NULL allows using delete[] without error.

You are right. I like to hide the variable in a class, allocate it in the constructor and deallocate it in the destructor.
An exception is when you not know the initial size of the variable, as example in a function that reads a file, but you should take care of not use the same variable for other purposes and delete it in the right way.

The copy operator is a way.

Copying the struct or class to a character array also would be useful to send it through tcpip or save it at a file in this way:

char *buffer=new char[sizeof(class_tobe_copied)];
memcpy(buffer,&class_tobe_copied,sizeof(class_tobe_copied));

//...transmit the data
//Recover the class to class2:
memcpy(&class2,buffer,sizeof(class2));

I have a doubth:
Is this method safe using different OS and compilers at the encode and decode side?

Could depends also on the CPU or GPU?
Some CPUs allows making operations in parallel, so perhaps some optimizations avoids or allows using SSE, SSE2 or any other