Bitcoin Forum
October 22, 2018, 05:46:07 PM *
News: Make sure you are not using versions of Bitcoin Core other than 0.17.0 [Torrent], 0.16.3, 0.15.2, or 0.14.3. More info.
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Native Miners  (Read 1375 times)
usagi
VIP
Hero Member
*
Offline Offline

Activity: 812
Merit: 1000


13


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

Native Miners
1540230367
Hero Member
*
Offline Offline

Posts: 1540230367

View Profile Personal Message (Offline)

Ignore
1540230367
Reply with quote  #2

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

Posts: 1540230367

View Profile Personal Message (Offline)

Ignore
1540230367
Reply with quote  #2

1540230367
Report to moderator
hugolp
Legendary
*
Offline Offline

Activity: 812
Merit: 1000


semux


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.

            ▄▄████▄▄
        ▄▄██████████████▄▄
      ███████████████████████▄▄
      ▀▀█████████████████████████
██▄▄       ▀▀█████████████████████
██████▄▄        ▀█████████████████
███████████▄▄       ▀▀████████████
███████████████▄▄        ▀████████
████████████████████▄▄       ▀▀███
 ▀▀██████████████████████▄▄
     ▀▀██████████████████████▄▄
▄▄        ▀██████████████████████▄
████▄▄        ▀▀██████████████████
█████████▄▄        ▀▀█████████████
█████████████▄▄        ▀▀█████████
██████████████████▄▄        ▀▀████
▀██████████████████████▄▄
  ▀▀████████████████████████
      ▀▀█████████████████▀▀
           ▀▀███████▀▀



.SEMUX
█ █
█ █
█ █
█ █
█ █
█ █
█ █
█ █
█ █
█ █
█ █
█ █
█ █
█ █
█ █
█ █
█ █
█ █
█ █
█ █
█ █
█ █
█ █
█ █
█ █
█ █
█ █
█ █
  Semux uses .100% original codebase.
  Superfast with .30 seconds instant finality.
  Tested .5000 tx per block. on open network
█ █
█ █
█ █
█ █
█ █
█ █
█ █
█ █
█ █
█ █
█ █
█ █
█ █
█ █
OCedHrt
Member
**
Offline Offline

Activity: 111
Merit: 10


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.

ALL.ME  ●●●  SOCIAL NETWORK OF THE BLOCKCHAIN TIME ●●●
▄▄▄▬▬▄▄▄  Bounty all.me ▶ Jan 29th - May 8th 2018  ▄▄▄▬▬▄▄▄
Facebook   ▲   Twitter   ▲   Telegram
Sukrim
Legendary
*
Offline Offline

Activity: 2394
Merit: 1002


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://www.coinlend.org <-- automated lending at various exchanges. No fees(!).
Mail me at Bitmessage: BM-BbiHiVv5qh858ULsyRDtpRrG9WjXN3xf
fpgaminer
Hero Member
*****
Offline Offline

Activity: 560
Merit: 500



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!