Bitcoin Forum
December 03, 2016, 05:49:35 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Native Miners  (Read 1200 times)
usagi
VIP
Hero Member
*
Offline Offline

Activity: 812


13


View Profile
July 11, 2011, 02:52:54 PM
 #1

Native Miners
1480787375
Hero Member
*
Offline Offline

Posts: 1480787375

View Profile Personal Message (Offline)

Ignore
1480787375
Reply with quote  #2

1480787375
Report to moderator
1480787375
Hero Member
*
Offline Offline

Posts: 1480787375

View Profile Personal Message (Offline)

Ignore
1480787375
Reply with quote  #2

1480787375
Report to moderator
1480787375
Hero Member
*
Offline Offline

Posts: 1480787375

View Profile Personal Message (Offline)

Ignore
1480787375
Reply with quote  #2

1480787375
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1480787375
Hero Member
*
Offline Offline

Posts: 1480787375

View Profile Personal Message (Offline)

Ignore
1480787375
Reply with quote  #2

1480787375
Report to moderator
1480787375
Hero Member
*
Offline Offline

Posts: 1480787375

View Profile Personal Message (Offline)

Ignore
1480787375
Reply with quote  #2

1480787375
Report to moderator
hugolp
Hero Member
*****
Offline Offline

Activity: 742



View Profile
July 11, 2011, 02:56:43 PM
 #2

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
Member
**
Offline Offline

Activity: 98


View Profile
July 11, 2011, 06:52:15 PM
 #3

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
Legendary
*
Offline Offline

Activity: 1848


View Profile
July 12, 2011, 12:25:43 AM
 #4

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

https://bitfinex.com <-- leveraged trading of BTCUSD, LTCUSD and LTCBTC (long and short) - 10% discount on fees for the first 30 days with this refcode: x5K9YtL3Zb
Mail me at Bitmessage: BM-BbiHiVv5qh858ULsyRDtpRrG9WjXN3xf
fpgaminer
Hero Member
*****
Offline Offline

Activity: 546



View Profile WWW
July 12, 2011, 02:03:26 AM
 #5

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.

Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!