Native Miners | Bitcointalksearch.org

fpgaminer

hero member

Activity: 560

Merit: 517

Quote

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. Wink

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.

Sukrim

legendary

Activity: 2618

Merit: 1007

Yet they are BOTH written in Python! Roll Eyes

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...

OCedHrt

member

Activity: 111

Merit: 10

Quote from: hugolp on July 11, 2011, 09:56:43 AM

Quote from: usagi on July 11, 2011, 09:52:54 AM

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.

hugolp

legendary

Activity: 1148

Merit: 1001

Radix-The Decentralized Finance Protocol

Quote from: usagi on July 11, 2011, 09:52:54 AM

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.

usagi

vip

Activity: 812

Merit: 1000

13

Native Miners

Topic: Native Miners (Read 1478 times)