Originally posted by: notzed Sorry - i missed the bit about you using opencl on cpu before (maybe i need glasses since it's right there in the topic). opencl on cpu is pretty much the same as c on the cpu, and memcpy isn't really all that magic either.
If this is related to your other post about vectors i'd say the overhead of marshalling to a vector is outweighing any advange of a single vector multiply and that's where your problem is, not with the memory loads. |
Ha! I missed it too! I guess then, my question is why OpenCL? Are you planning on hitting up the GPU/APU side later?
Anyhow, I would expect everything to be aligned already, so hopefully there is no marshalling into vectors, since, again, I'd hope, their vectors are juat float*, int*, etc...16 byte aligned blocks of contiguous blocks of 16 bytes of data. That maps well to SSE, and GPGPU, almost 0 overhead, etc.
I guess the problem is what is your image format? Is each element 8 bits, 16 bits, 32 bits? 19x19 doesn't give us a lot to go on, that could be 2 16 byte copies, or it could be 5 16 byte copies. Its true, since its an image, reading 19x19 from an arbitrary location isn't going to be as fast as it could, but here is what I'd do.
First off, do you have to copy. Memory operations, even on the CPU are expensive. Even L1 cache can have an extra cycle associated with it. If you can just calculate 19 row offsets, it's probably faster than copying 361 bytes at 8 bits per pixel (greyscale, or 256 color), and especially 1,444 bytes at 8 bits per channel, 4 channel rgba. 19 operations vs 361 in x86 mode not using SSE for copies. Basically, if you can destroy your original image, and operations on pixels don't trigger re-reads of the 19x19 section, you're better off calculating the offsets, and destroying the original data.
If you have to copy, you have a few options, with various complexity, and performance. Best bet, is to do aligned reads. Calculate an offset before the start of the 19x19 data you need, and overread a little. Read 16 bytes at a time, pad the end of the image by 16 bytes, so if you overread a little, it won't crash. This means still calculating the offsets, but you could break your image into 19 19 element buffers, so there's only 1 offset.
Next best bet would probably be no aligned reads, but still using vectors to get 16 bytes at a time. OpenCL might not let you do that, I don't know, SSE can use movdqu for unaligned data, with a penalty. lddqu was supposed to do what I described above, but doesn't seem to on anything but netburst, and that didn't help netburst much...
Next best bet is to move unsigned longs at a time. In openCL thats 8 bytes at a time, if you're in x64 mode, thats a single register at a time.
You can probably see where this is going, but next best bet is unsigned ints at a time, which is 4 bytes at a time, or a single x86 protected mode register at a time.
Anything less, and you're wasting cycles 🙂
