Native Miners

[usagi]

Native Miners

[hugolp]

Ok ok, so poclbm is written in python. What sort of performance increase are we looking at, if any, versus a theoretical "native miner"?

I used to a lot of assembly language programming and it's something I think of from time to time. At the least I could have a look and rewrite parts of the code in assembly language. Is this something that is "worth it" to any degree? Worth it means, if we can get 2 or 3%, it's worth it. Another question, would it serve any purpose to rewrite pyopencl in C? or for that matter, would it become significantly slower in Java? Note that I don't really care which language is faster; I only care that if one language was deemed to be faster for a certain purpose (such as assembly language) would writing or rewriting a miner in that language produce a noticeable improvement in mHash/s.

The processing part is taken care by opencl, and the processor is not the bottleneck (my processor rarely goes over 20% with 4 gpus hashing 1800Mh/s), so I doubt it will make a difference. The key for speed is in the opencl code not in the python part, and that is why there is people optimizing the mining opencl kernels.

[OCedHrt]

Ok ok, so poclbm is written in python. What sort of performance increase are we looking at, if any, versus a theoretical "native miner"?

I used to a lot of assembly language programming and it's something I think of from time to time. At the least I could have a look and rewrite parts of the code in assembly language. Is this something that is "worth it" to any degree? Worth it means, if we can get 2 or 3%, it's worth it. Another question, would it serve any purpose to rewrite pyopencl in C? or for that matter, would it become significantly slower in Java? Note that I don't really care which language is faster; I only care that if one language was deemed to be faster for a certain purpose (such as assembly language) would writing or rewriting a miner in that language produce a noticeable improvement in mHash/s.

The processing part is taken care by opencl, and the processor is not the bottleneck (my processor rarely goes over 20% with 4 gpus hashing 1800Mh/s), so I doubt it will make a difference. The key for speed is in the opencl code not in the python part, and that is why there is people optimizing the mining opencl kernels.

Interestingly, I get ~10-15% higher hash rate on poclbm vs phoenix using the same kernel. I'm pretty sure my settings are equivalent (vectors, bfi_int). And the kernels compile to same size.

[Sukrim]

Yet they are BOTH written in Python!

Usually what matters most is how a program's written, not in which language.

How hashrates are displayed is also up to discussion - an average of "X shares per 10 minutes" or so would be much better...

[fpgaminer]

I guess after reading more about the subject what I want to do is avoid compiling a .cl file at runtime and write the kernel code manually. Otherwise, what assurances do I have that the .cl file has been compiled *and optimized* by the compiler?

Yes, if you're up for the challenge, that is likely to gain you far more performance than writing the supporting code in C or ASM. Be aware that you need to have a very intimate relationship with the GPU, inside and out, to extract out every bit of performance. You will have to check your local laws to determine if such relationships are even legal in your district.  

Note that your optimizations will be specific to a certain GPU (1), so if you write for a 5850, your code won't get the same efficiency on a 6950.

(1) Unless polygamy is allowed in your country.