search

tochev / git-vanity

a tool for generating git vanity commits
GNU General Public License v3.0
76 stars 6 forks source link

Sometimes finding incorrect hashes on a Mac #3

Open lukebatchelor opened 6 years ago

lukebatchelor commented 6 years ago

Completely understand that this is a pretty old project, so I don't expect a response at all, but just wondering if you might know why I'm getting intermittent (but consistent) errors when using certain prefixes.

This is the output I'm seeing

$ python3 ~/git-vanity/git_vanity.py '13131313' -W

# ... ...

Found sha1 prefix `13131313'
with sha1 `da8012b2b54026a46c1fd034db6374cadd5d4359'
Using 000000002CAED3E3
================
tree 5658bb0a57f6ceaf844a1ed92318bcebc827b2fe
parent f581ae8f8ad39b2f6f2ae789911dd229e63bfdf3
author Luke.Batchelor <redacted@gmail.com> 1516102222 +1100
committer Luke.Batchelor 000000002CAED3E3 <redacted@gmail.com> 1516102533 +1100

New commit
================

Writing changes to the repository...

Luke.Batchelor 000000002CAED3E3
[lbatch/test da8012b] New commit
 Author: Luke.Batchelor <redacted@gmail.com>
 Date: Tue Jan 16 22:30:22 2018 +1100
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 foo
Current HEAD:
da8012b2b54026a46c1fd034db6374cadd5d4359
All done.

I've had tons run fine, but certain prefixes consistently fail. '13' and '13131313'. Even after changing the state of the repo (making more commits, changing author name).

More info:

$ git cat-file -p HEAD

tree 5658bb0a57f6ceaf844a1ed92318bcebc827b2fe
parent f581ae8f8ad39b2f6f2ae789911dd229e63bfdf3
author Luke.Batchelor <redacted@gmail.com> 1516102222 +1100
committer Luke.Batchelor 000000002CAED3E3 <redacted@gmail.com> 1516102533 +1100

New commit
OSX Yosemite 10.10.5
MacBook Pro (Retina, 15-inch, Mid 2015)
2.5 GHz Intel Core i7
16 GB 1600 MHz DDR3
Intel Iris Pro 1536 MB

I was actually able to run all this without installing any of openCL. When running I get these options

Choose platform:
[0] <pyopencl.Platform 'Apple' at 0x7fff0000>
Choice [0]:0

Choose device(s):
[0] <pyopencl.Device 'Intel(R) Core(TM) i7-4870HQ CPU @ 2.50GHz' on 'Apple' at 0xffffffff>
[1] <pyopencl.Device 'Iris Pro' on 'Apple' at 0x1024500>
[2] <pyopencl.Device 'AMD Radeon R9 M370X Compute Engine' on 'Apple' at 0x1021c00>

and it runs fine with all three devices (except for getting the wrong sha's sometimes).

tochev commented 6 years ago

Thanks for reporting the problem and for the detailed information.

The good news is that I am able to reproduce the bug on a Sierra 10.12.6 MacBook Air 13 (Late 2010). Using the GPU (GeForce 320M) produces wrong results with any prefix, while using the CPU (Core2 Duo L9600) produces correct results (so far).

Unfortunately, at the moment I don't have a lot of free time and I will have to borrow the hardware in order to be able to debug the problem, but I hope to be able to work on it during this weekend and/or the weekend after. :)

lukebatchelor commented 6 years ago

Oh wow, that would be awesome, thank you!

tochev commented 6 years ago

@lukebatchelor I seem to have fixed it for the Air in 6a0bbdfec083f7be74ca9ccbcc6edb9cd62923bc .

I would like to run more tests, but the GeForce 320M does only about 3 MHash/s. I will continue with the tests next weekend.

For some reason on the Air's GPU it behaves in a mind boggling way, not that I'm an OpenCL guru (and I have used it almost exclusively on AMD), but some of the behaviour is outright bizarre. I'll wait on merging it in the master for now. I'm considering rewriting the whole OpenCl code, but I'll probably not have the time.

It would be great if you could confirm that this works with your setup :)