Just to get back to the performance bit of non-ocl vanitygen (standard v0.22 lifeboat version), some figures (applicable to the i7-4702MQ 2.2GHz config).

Ran each test for 5 minutes.  Relative efficiency is based only on the number of 'found' keys in that timespan.

type	command	generated keys	'found' keys	% matched	relative efficiency
regex	vanitygen.exe -o file.lst -k -q -F compressed -r .*	21,262,638	82,797	0.38940%	98.72%
standard	vanitygen.exe -o file.lst -k -q -F compressed 1	21,534,544	83,874	0.38949%	100.00%
input list (1A,1B,..,1a,1b,..,11,12,..)	vanitygen.exe -o file.lst -k -q -F compressed -f input.lst	21,688,744	84,499	0.38960%	100.75%
case insensitive	vanitygen.exe -o file.lst -k -q -F compressed -i 1	21,917,217	85,410	0.38969%	101.83%
non-compressed	vanitygen.exe -o file.lst -k -q 1	22,324,562	87,019	0.38979%	103.75%
64-bit version	vanitygen64.exe -o file.lst -k -q -F compressed 1	27,455,567	106,980	0.38965%	127.55%
64-bit, non-compressed	vanitygen64.exe -o file.lst -k -q 1	29,042,542	113,150	0.38960%	134.90%
64-bit, non-compressed, four processes	vanitygen64.exe -o file.lst -k -q 1	104,220,011	406,105	0.38966%	484.18%

Using compressed keys adds a few percent overhead, so dropping that might be a reasonable idea (remember though that 'compressed keys' are preferred).  The 64bit version is quite a bit faster than the 32bit version as well.  Combining the two there's a pretty reasonable speed gain.  There's maybe a bit more to gain with the case-insensitive option, but I'd have to run much longer tests to see if that's a real gain or just a wee bit of luck in that run.
Running four concurrent processes was much faster still - apparently there's a good bit of overhead of code that doesn't/can't be run multithreaded when using such short prefixes.

The other thing that stands out is that even though there's a significant number of keys generated, vanitygen only selects a very, very small portion of them as matches - even though every single one of them should be valid.  This is primarily why a program that's specifically written for the task would be much better.  In fact, given how few vanitygen actually returns here, I wouldn't be surprised if one of the existing python libraries or even javascript (bitaddress.org's bulk generator is slower, but there might be some performance to gain in their implementation as well) would perform much better.  It also reminds me of that weird bounty/'rendezvous points' hunt, which - at least for CPU - might be an easier starting point for modification (if not starting from scratch):-

A comparison against longer patterns:

type	command	generated keys	'found' keys	% matched	relative efficiency
'1'	vanitygen.exe -o file.lst -k -q -F compressed 1	21,534,544	83,874	0.38949%	100.00%
'1A'	vanitygen.exe -o file.lst -k -q -F compressed 1A	16,982,045	66,152	0.38954%	78.87%
'1AA'	vanitygen.exe -o file.lst -k -q -F compressed 1AA	72,843,612	49,592	0.06808%	59.13%
'1AAA'	vanitygen.exe -o file.lst -k -q -F compressed 1AAA	256,016,211	3,419	0.00134%	4.08%

One thing that stands out here is that the percentage that 'matched' is the same for patterns '1' and '1A', which I think shouldn't be the case.
The other thing is the total number of keys generated.  '1A' having generated fewer than '1', while '1AA' and '1AAA' generated more and far more respectively.

tl;dr: vanitygen is weird when used for purposes other than what it was designed for

---

Edit: As the above tables were made using the Lifeboat version of vanitygen, the tables again with vanilla v0.22 (note that there's no 'compressed key' support unless patched in):

type	command	generated keys	'found' keys	% matched	relative efficiency
input list (1A,1B,..,1a,1b,..,11,12,..)	vanitygen.exe -o file.lst -k -f input.txt -q 1	21,858,878	85,213	0.38983%	98.62%
regex	vanitygen.exe -o file.lst -k -r -q .*	22,057,282	85,920	0.38953%	99.44%
standard	vanitygen.exe -o file.lst -k -q 1	22,179,614	86,408	0.38958%	100.00%
case insensitive	vanitygen.exe -o file.lst -k -i -q 1	22,208,398	86,570	0.38981%	100.19%
64-bit version	vanitygen64.exe -o file.lst -k -q 1	29,060,532	113,316	0.38993%	131.14%
64-bit version, four processes	vanitygen64.exe -o file.lst -k -q 1	94,486,821	368,135	0.38962%	426.04%

type	command	generated keys	'found' keys	% matched	relative efficiency
1	vanitygen64.exe -o file.lst -k -q 1	29,060,532	113,316	0.38993%	100.00%
1A	vanitygen64.exe -o file.lst -k -q 1A	23,848,310	93,430	0.39177%	82.45%
1AA	vanitygen64.exe -o file.lst -k -q 1AA	92,005,255	63,455	0.06897%	56.00%
1AAA	vanitygen64.exe -o file.lst -k -q 1AAA	316,811,630	4,000	0.00126%	3.53%

http://nextdifficulty.com/
Conservative: 2.1% 2.7% Continous: 4.3 %

goodbye negative

If you do have it I'm sure eventually someone will thank you for it.   The original one is not up I don't believe.

I was doing some cleaning of my files and somehow deleted it off my dropbox.  That and a usb hard disk dying with me having sold my 1T a while ago makes it where I wont be able to get the image to share with others.

Interesting for running S5+ boards on S5 controller.

I suppose this also mean you could run some salvaged S5+ blades on S5 controllers later on. That could come in handy.

Find a good signature campaign, use those payouts to buy in on various alts and hope one gets rising!!!  (but you'll lose if the coin fails, obviously - in that case, hold in BTC  )

Static pressure for Scythe fan:

I know the SP120 did NOT move enough air to cool an S5 but that miner is not enclosed like the S4. My recommendation of the Scythe is purely from my tests on an S5 and from having owned a few S4's.

Very early in the week but here is bitwisdom:

Bitcoin Difficulty:    54,256,630,328
Estimated Next Difficulty:    54,370,133,238 (+0.21%)
Adjust time:    After 2004 Blocks, About 14.1 days
Hashrate(?):    408,339,410 GH/s

And price is still around 230 no huge moves.