Congratz!

But... any news about entropy import?

I'm seeing 4x increase. I don't care not getting 6x, 4x is an amazing improvement in any case .

Intel(R) Xeon(R) CPU E5420  @ 2.50GHz (8 cores):


v0.6 single thread to v0.6 8 threads: 174878/28363 = 6.1657x (expect 8x)
v0.6 single thread to v0.10 single thread: 164485/28363 = 5.7992x (expect 6x as announced)
v0.6 8 threads to v0.10 8 threads: 884067/174878 = 5.0553x (expect 6x as announced)

Oops, my fault, it's not 4x but 5x. I stopped vanitygen v0.6 8 hours ago and started v0.10 some minutes ago. I judged the improvement not by the rate but by the time remaining, and I suspect I didn't take into account the fact that when I stopped v0.6 this morning, it had been running for some hours and the time remaining was, of course, less than at the start .

Well, I'm pretty sure it's still faster than it was on the old version, even with the old running at 8 threads, but I'd need to recompile the older version if I wanted to compare. Just running a case-insensitive prefix:


Up to this point, CPU usage in Activity Monitor is about what one expect, being roughly 100% times the number of threads.


5 threads was having CPU hovering between 420% and 440%, and a lower keygen rate, which makes me think that there's some kind of contention for something that's not CPU-bound.


Using 6 and 7 threads was roughly the same as 5, with CPU slightly higher, maybe between 425% and 445%.


Using 8 threads somehow brings even more contention, with CPU hovering just around 400%.

I'm not remembering exactly what speeds I was getting before on v0.8, but when I ran 8 threads it was using about 800% CPU, and I'm pretty sure it was well south of 200000 K/s, probably more like 100000, but I really don't remember so I wouldn't rely on that number at all.

And just for completeness, here's my hardware configuration:

Thanks again!

I don't think I was clear before: I have 8 physical cores, and hyperthreading is on, so I see 16 logical CPUs in Activity Monitor. I wasn't surprised with the older version when it maxed out performance at 8 as opposed to 16, but maxing out at 4 seems a little weird.

It's so awesome to churning through billions of addresses. Amusing how this is even less useful than mining is, and yet somehow is more fun.

That's oddly slow, you should be getting about twice that key rate on that CPU.


Indeed!  Try running two instances at four threads each.  If the OS X scheduler is smart, it will isolate each to a processor package to minimize the cost of contention.

Just built up a script (pywallet.py 1.0) allowing export/import private keys in shortened format (mostly as a lightweight alternative to showwallet for those who didn't manage to compile the branch). Requires only openssl libs (for elliptic curve cryptography). URL: https://github.com/joric/pywallet

New version 0.11 posted.

• Allow the RNG to be seeded from a file, suggested by Shevek
• Tweak the synchronization on the pattern list

Try a single instance of the new version.  It should make a lot fewer pthread synchronization calls, and hopefully scale better on your multi-processor machine.  However, I'm still stumped on why each thread is getting about 1/2 the expected key rate.  You should be able to do >1MK/s on that machine.

Yes, this seems to be scaling much better. 550000–575000 K/s on 8 threads, 320000 or so on 4 threads, 82000 on 1 thread.

Thank you very much.

And for anyone else compiling on a Mac, I have to add "-I/Developer/SDKs/MacOSX10.5.sdk/usr/include/php/ext/pcre/pcrelib/" to the makefile flags for it to find <pcre.h>. Perhaps there's a better way to get it into the build, but it seems to work for me.