another 3% mining increase with poclbm kernel.cl

[goxed]

you have to change this line in kernel.cl. tested this with poclbm kernel only.

   u W0, W1, W2, W3, W4, W5, W6, W7, W8, W9, W10, W11, W12, W13, W14, W15;
to
    __local u W0, W1, W2, W3, W4, W5, W6, W7, W8, W9, W10, W11, W12, W13, W14, W15;

basically, add a  __local  key keyword to this line and it should increase your performance.

[1714914578]

1714914578

[1714914578]

1714914578

[1714914578]

1714914578

[PcChip]

Any idea if it would work with PhatK as well?

Normally I wouldn't try it without a truth table proof like bitless posted on his speedup, but since you're just making variables local to a function, it makes sense.  I'll try and report back!

edit: I noticed the PhatK kernel.cl doesn't contain the exact line to modify, I looked for W0 - W15 variables to make __local but I'm no OpenCL coder, so I can't find them if they even exist at all.

There's a u W[128] at the beginning of the Search() function, would those be the same as poclbm's w0-w15 ?

edit2: changed u W[128] to __local u W[128] and no change in hashrate (except from 217.5 -> 217.7 which could be noise), perhaps it's already compiling as local

[bitless]

Thank you, you are a scholar and a gentleman (for finding and sharing this)

I'll try it out tonight and report my results, will definitely tip you if it helps!

[bitless]

There's a u W[128] at the beginning of the Search() function, would those be the same as poclbm's w0-w15 ?

TLDR - Probably yes, maybe not. Try it anyway

When mining, you're calculating SHA256( SHA256( w0,w1,... nonce ..., w15) ), where the w-s are some constants, most of which depend on the block you're trying to solve. The calculation of each SHA consists of two stages - the expansion (a.k.a. message schedule), which takes your input words w0 through w15, and expands them into 64 words, w0 through w63, and the compression, which iterates on these 64 expanded words 64 times, with each wi used only once, on iteration i. So.... There are at least two ways to carry out this calculation. 1 - expand the 16 original input words into 64 words, and then use them. 2 - expand these as necessary, i.e. calculate wi on the iteration i, when it is needed. My guess is that one kernel implements #1, and another implements #2. So, w[128] is probably the same as w0,w1... . It is also hard to tell which way is better, it depends on the compiler and your hardware (register pressure, scheduling and so on)... What I don't know is why they've got 128 words instead of 64; perhaps it is because of calculating the hash twice, or it could be because they're calculating two hashes at once, in parallel. Unfortunately, I don't have access to the source code at the moment, so all I can do is guess I hope this helps.

[ThatOtherDude]

This method actually caused a decrease of 30%. I went from 26.81 MHash/s down to 18.71 MHash/s.

[goxed]

This method actually caused a decrease of 30%. I went from 26.81 MHash/s down to 18.71 MHash/s.

I have used this with a Radeon 5830 card. from 305MH/s to 315Mh/s
Here's some proof.


new kernel
http://imgur.com/JcMmZ

old kernel
http://imgur.com/YrRuL

[Soak]

New release of m0mchil's poclbm (2011-06-27) : https://github.com/downloads/m0mchil/poclbm/poclbm_py2exe_20110627.7z

Added an improvement in kernel (use phatk with modification of Ma formula).
+3% hashrate in average.

[ThatOtherDude]

This method actually caused a decrease of 30%. I went from 26.81 MHash/s down to 18.71 MHash/s.

I have used this with a Radeon 5830 card. from 305MH/s to 315Mh/s
Here's some proof.


new kernel
http://imgur.com/JcMmZ

old kernel
http://imgur.com/YrRuL

I was using it with a Geforce GTS 360M.  Perhaps it only works with ATI cards?

[bitless]

new kernel
http://imgur.com/JcMmZ
old kernel
http://imgur.com/YrRuL

I see some Ma3() function in your kernel (I don't have it), which seems to be almost the same as the original Ma(), and my optimization could be applied to it as well. Why didn't you change this Ma3()? Any particular reason?

[goxed]

new kernel
http://imgur.com/JcMmZ
old kernel
http://imgur.com/YrRuL

I see some Ma3() function in your kernel (I don't have it), which seems to be almost the same as the original Ma(), and my optimization could be applied to it as well. Why didn't you change this Ma3()? Any particular reason?

Good catch I have been playing a little bit with the kernel. this macro was added by me and is not part of original kernel.

[BombaUcigasa]

basically, add a  __local  key keyword to this line and it should increase your performance.

Sorry, this doesn't work for me, performance dropped 33% instead.

[tayfun369]

Where do I find that kernel.cl?

I've got a folder called "poclbm_py2exe_20110428" and run poclbm with a batch file. But I do not find any kernel.cl in that folder.

[Soak]

Where do I find that kernel.cl?

I've got a folder called "poclbm_py2exe_20110428" and run poclbm with a batch file. But I do not find any kernel.cl in that folder.

If you have problems, simply update your poclbm with the latest version (20110627) including the phatk kernel modification of this thread. Just launch your miner as you do usually.

https://github.com/downloads/m0mchil/poclbm/poclbm_py2exe_20110627.7z

For answer your question, kernel.cl is on the poclbm folder of kernels folder from Phoenix miner. You need to modify the BitcoinMiner.cl of your poclbm miner because you mine with poclbm and not with Phoenix.

[SlipperySlope]

I use linuxcoin and the kernel I edited was named BitcoinMiner.cl, located in /opt/miners/poclbm.

This simple change took each of my six 5770 GPUs, overclocked to 960 MHz, from 204 MH/sec to 212 MH/sec, a 4% increase!

[PcChip]

Do you mind if I ask why people choose poclbm over phoenix with PhatK ?

as I understand it PhatK with 2.4 SDK has a decent performance edge over poclbm

[Soak]

Do you mind if I ask why people choose poclbm over phoenix with PhatK ?

No, but poclbm now include PhatK (there is the same as Phoenix+PhatK).

[SlipperySlope]

Do you mind if I ask why people choose poclbm over phoenix with PhatK ?

as I understand it PhatK with 2.4 SDK has a decent performance edge over poclbm

On linuxcoin I experimented with phoenix+phatk but found that my CPU utilization went up sharply - from say 3% per miner to 20% or more.  I am heat-constrained, operating my caseless rigs in the crawl space under my Austin, Texas house without air-conditioning or extra fans, so poclbm appeared more watt-efficient, and also I had some stability issues, e.g. crashes when overclocking my Radeon HD 5770 GPUs to 960 MHz with phoenix.  In contrast, poclbm handles my overclocking OK.

[PcChip]

On linuxcoin I experimented with phoenix+phatk but found that my CPU utilization went up sharply - from say 3% per miner to 20% or more.  I am heat-constrained, operating my caseless rigs in the crawl space under my Austin, Texas house without air-conditioning or extra fans, so poclbm appeared more watt-efficient, and also I had some stability issues, e.g. crashes when overclocking my Radeon HD 5770 GPUs to 960 MHz with phoenix.  In contrast, poclbm handles my overclocking OK.

That's an excellent reason, I'd say.  Living in Texas I know exactly what you mean.  I'm actually considering trying to change the software my dedicated miners out in the storage room are running, the MH/s are great but the mining threads use 100% of the CPU so it probably wastes electricity (three CPU's pegged out).  I'm using command-line phoenix 1.5 with phatk, what can I switch to that won't drop my hashrate but will lower CPU usage?

[SlipperySlope]

what can I switch to that won't drop my hashrate but will lower CPU usage?

You could try poclbm, as I do not know much about configuring phoenix.  

[bonker]

yup, I gets a speedup on my 5770 too. Respect due