Hi,

as I understand it, the miner goes through up to 2^32 values of the nonce field (which the fourth word in the message), calculates sha(sha(message)), and submits the proof-of-work to the pool if the last word in the hashing result equals to 0. Good.

Now the questions.
1 What other fields can we change in the message when mining, other than the nonce?
2 Where is the extraNonce located?
3 Where is the time (and can we change it as we see fit while mining, or are we required to keep it in a certain range)?

I've been reading through the protocol specs on wiki, but couldn't really figure it out.... Thanks!

-B

Hi all,

First of all, I'm very glad that there's lots of people now out there trying to improve the kernels. Thanks for doing this!

Second, if I may ask this of you... could you please be very very careful when introducing these modifications? By careful, I mean test your changes for at least a day or so and see what happens. As well, looking at the disasm results in kernel analyzer never hurts

Third... Most of the changes that I saw deal with removing some adds and stuff. Normally, any modern compiler should be able to remove all useless adds, such as adding two constants, etc. So I saw no reason for these changes to actually help with the speed. However, some of them were helping, which warranted at least some looking into why they help. So...

Fourth. Here's why I think they help. Most compilers will rip out expressions like (a&b)+c and replace it with a single constant, as long as a,b,c are constants. However. They won't do this if you're using an intrinsic in the expression. For instance, if you do a rotate as x<<(32-n) | x>>n, for constants x and n the whole expression will get replaced with just a single constant. However, if you use amd_bitalign for this, it will not get replaced with a constant (especially if you do it for Ch/Maj, which is patched - how can it?). Yet, if you do a rotate using bitshifts but x or n aren't constants, you'll be slowing things down because now the compiler can't optimize it and you've replaced a bitalign() with a bunch of ops. So, long story short, less intrinsics and more constant expressions is probably the reason your changes help.

PcChip and I tested out this theory; we've replaced the rotates that use intrinsics with the rotate that uses shifts and or-s (i.e. the stuff the compiler can easily see through) for inputs that are constant. We've got 1-2% improvement, PcChip posted the kernel here http://pastebin.com/NPDTfAVd, but we've done it only for the rotates... if somebody could go through the kernel carefully and find other constants and constant expressions that could be removed, it would probably help even more.

Fifth. Feel free to donate coins, but also consider donating to PcChip and the original authors of these kernels; these people put a lot of work into the miners that everybody is using, and they deserve donations more than some dude who happened to notice a 3% improvement to Ma()

(also, I'm not being critical or overly judgmental, just sharing some stuff that I happen to know; it is all my personal opinion, I may be wrong, so feel free to criticize and/or disagree)

I keep hearing that the same .cl kernels compiled with SDK 2.1 and 2.4 are giving different MH/sec results, and 2.4 seems to be giving worse results. So... is this true? Presumably, the same source code compiles into different machine code, but does anybody know what exactly is the difference that's causing this?

I have only 2.4 installed... if nobody knows what the difference is, would it be too much to ask somebody to compile phatk's kernel with 2.1 and post the disasm of the code to pastebin or some such? (just copy/paste it from AMD's kernel analyzer, and I dig through the stuff myself)

Thanks a lot!

I just tried this and got >3% improvement in mining speed. On my 6870, I was getting 299 MHash/sec, and now I'm getting 308 or so. The change is simple enough for anyone to do it - you don't need to be a programmer to use it.


EDIT - Thank you! This has been added to git (not by me), so now everyone can use this speed-up without editing any files. https://github.com/m0mchil/poclbm/commit/3d43c4e4c2c476cf367822868202f02d168d6f3b Also, please read the comments here http://www.reddit.com/r/Bitcoin/comments/i9yba/2_3_increase_in_mining_per_gpu/; the person who added it to git knows more than I do, you should listen to him about SDK versions etc. Thanks for all the donations too!

EDIT2 - Thanks to the awesomeness of reddit and these forums, I now know that this change has been applied to Diablo miner as well. https://github.com/Diablo-D3/DiabloMiner/commit/ae16718dfa538aeef31f34e19542f3c18501efe5 I guess we can stop this thread now, and everyone can enjoy the speedup without editing any files. Thank you for trying this out.


You can go to phatk's kernel.cl file (don't worry, it just sits there in the open, no need to recompile anything), find this line
  #define Ma(x, y, z) amd_bytealign((y), (x | z), (z & x))
and change it to this line
  #define Ma(x, y, z) amd_bytealign( (z^x), (y), (x) )
Once you've done it, restart the miner.

Technically, this is 1 less instruction for the Maj function in the hash, which is called ~128 times for each nonce value, so we get +3% to mining speed. This will ONLY WORK if you're running with BFI_INT. I'm using phoenix with phatk kernel on Ubuntu, so YMMV, but I see no reason for this to not work with other setups. As always, do play around with aggression and other settings after you've applied the change. Deepbit seems to be accepting my shares generated this way, but it comes AS IS, without any warranty whatsoever - if it doesn't work for you, or has been posted already, please don't blame me

If this helps you mine faster, please share your MHash/sec results, before and after. You can also donate to 15igh5HkCXwvvan4aiPYSYZwJZbHxGBYwB . I hear people are getting 50 BTC for things like this, and it would be nice to get some.

If you want to verify the correctness of the change, here's the truth table for the new Ma() function

x y z   Ma
0 0 0   0
1 0 0   0
0 1 0   0
1 1 0   1
0 0 1   0
1 0 1   1
0 1 1   1
1 1 1   1

and here's C code that was used to generate it

#include <stdio.h>
int main()
{
#define CH(src0,src1,src2)   (  ((src1)&(src0)) |  ((src2)&~(src0))  )
   unsigned int x,y,z;
   for(z=0;z<=1;z++) for(y=0;y<=1;y++) for(x=0;x<=1;x++)
   {
      printf("%d %d %d   %d\n",x,y,z, CH(z^x,y,x) );
   }
  return 0;
}

Finally, I am newbie, so it would be nice if someone reposted this to the proper Bitcoin mining thread/board and/or checked-in this change into the source control.

Thanks and have fun!