If anyone would like to get started early building llr v3.8.7dev:

http://www.mersenneforum.org/showthread.php?p=288014#post288014

Support now for 64 bit platforms. It will be good to see time comparisons between 32 and 64 bit AND to see how this affects the AVX builds. NOTE: v3.8.7dev still comes with gwnum v26.5. To build for AVX, you'll need gwnum v27.2 (ftp://mersenne.org/gimps/source272.zip).

UPDATE: gwnum v27.3 (ftp://mersenne.org/gimps/source273.zip)

Please post your builds and any timing results in this thread.

Good Luck!

UPDATED: 18 FEB 2012

llr Non-AVX v3.8.7 w/gwnum v26.5
Windows 32 bit: llr387dev.zip by Jean
Windows 64 bit: cllr387dev-win-x64.7z (VS2005) by Michael or llr64bit-win (VS2010) by Rebirther
Linux 32 bit static: llr387devslinux.zip by Jean or sllr32_dev387.tar.bz2 by rroonnaalldd
Linux 64 bit static: sllr64_dev387.tar.bz2 by rroonnaalldd
MacIntel 32&64 bit: llr387devsrc.7z by Iain

llrAVX v3.8.7 w/gwnum 27.2
Windows 32 bit: llr32bit-AVX-win by Rebirther UPDATED to gwnum 27.3
Windows 64 bit: llr64bit-AVX-win by Rebirther UPDATED to gwnum 27.3
Linux 32 bit static: sllr32_dev387_gwnum273.tar.bz2 by rroonnaalldd UPDATED to gwnum 27.3
Linux 64 bit static: sllr64_dev387_gwnum273.tar.bz2 by rroonnaalldd UPDATED to gwnum 27.3
MacIntel 32&64 bit: llr387devsrc_avx.7z by Iain


Also available...from the AVX build of pfgw thread

pfgwAVX v3.6.0 w/gwnum 27.3
Windows 32 bit: pfgw3.6.0-AVX-32bit by Rebirther
Windows 64 bit: pfgw3.6.0-AVX-64bit by Rebirther
____________

I built a 32-bit Linux AVX executable of LLR 3.8.7dev (using gwnum 27.2, of course). Runtimes are indistinguishable from 3.8.6 (any diff is less than 0.1%). I ran various triple and quadruple checks of known primes and non-primes from the command line using prpclient (short tests, like the low port and SGS). All residuals matched vs. the prior version.

I'm attempting to build a 64 bit version but am encountering difficulty. The linker complains about the 32-bit gwnum library, so I'm trying to build a 64-bit version of that, which fails, seemingly wanting a custom-built version of the curl library, at least according to comments in the makefile. Is this effort worth it? Comments on mersenneforum seemed to indicate a speed-up vs. 32-bit, but past history says 32-bit == 64-bit, speed-wise, for LLR.

--Gary
____________
"I am he as you are he as you are me and we are all together"

87*2^3496188+1 is prime! (1052460 digits)
4 is not prime! (1 digit)

I'm attempting to build a 64 bit version but am encountering difficulty. The linker complains about the 32-bit gwnum library, so I'm trying to build a 64-bit version of that, which fails, seemingly wanting a custom-built version of the curl library, at least according to comments in the makefile. Is this effort worth it? Comments on mersenneforum seemed to indicate a speed-up vs. 32-bit, but past history says 32-bit == 64-bit, speed-wise, for LLR.

Until this new release of llr, llr could only be built as a 32-bit app. Now that a 64-bit llr can be built, it means that a 64-bit build of llr should be faster than a 32-bit build of llr.

Until this new release of llr, llr could only be built as a 32-bit app. Now that a 64-bit llr can be built, it means that a 64-bit build of llr should be faster than a 32-bit build of llr.

Waiting for that LLR :)
Linux or Windows version doesn't matter :)

boinc@Lubuntu32:~/Cuda/llrCPU$ ./sllr_dev387_gwnum272 -d -q"30448908048555*2^666666-1"
Starting Lucas Lehmer Riesel prime test of 30448908048555*2^666666-1
Using zero-padded Core2 type-1 FFT length 72K, Pass1=96, Pass2=768
Iter: 6/45, ERROR: ROUND OFF (1) > 0.4
Continuing from last save file.
Disregard last error. Result is reproducible and thus not a hardware problem.
For added safety, redoing iteration using a slower, more reliable method.
Continuing from last save file.
Iter: 6/45, ERROR: ROUND OFF (1) > 0.4
Continuing from last save file.
Unrecoverable error, Restarting with next larger FFT length...
Starting Lucas Lehmer Riesel prime test of 30448908048555*2^666666-1
Using zero-padded Core2 type-3 FFT length 80K, Pass1=320, Pass2=256
Iter: 6/45, ERROR: ROUND OFF (1) > 0.4
Continuing from last save file.
Unrecoverable error, Restarting with next larger FFT length...
Starting Lucas Lehmer Riesel prime test of 30448908048555*2^666666-1
Using zero-padded Core2 type-1 FFT length 84K, Pass1=112, Pass2=768
Iter: 6/45, ERROR: ROUND OFF (1) > 0.4
Continuing from last save file.
Unrecoverable error, Restarting with next larger FFT length...
Starting Lucas Lehmer Riesel prime test of 30448908048555*2^666666-1
Using zero-padded Core2 type-3 FFT length 96K, Pass1=128, Pass2=768
Iter: 6/45, ERROR: ROUND OFF (1) > 0.4
Continuing from last save file.
Unrecoverable error, Restarting with next larger FFT length...
Starting Lucas Lehmer Riesel prime test of 30448908048555*2^666666-1
Using zero-padded Core2 type-3 FFT length 112K, Pass1=448, Pass2=256
Iter: 5/45, ERROR: ROUND OFF (1) > 0.4
Continuing from last save file.
Iter: 5/45, ERROR: ROUND OFF (1) > 0.4
Continuing from last save file.
Unrecoverable error, Restarting with next larger FFT length...
Fatal error at setup : Number sent to gwsetup is too large for the FFTs to handle.

boinc@Lubuntu32:~/Cuda/llrCPU$ ./sllr_dev387 -d -q"30448908048555*2^666666-1"
Starting Lucas Lehmer Riesel prime test of 30448908048555*2^666666-1
Using zero-padded Core2 type-1 FFT length 72K, Pass1=96, Pass2=768
V1 = 5 ; Computing U0...done.Starting Lucas-Lehmer loop...
30448908048555*2^666666-1, iteration : 10000 / 666666 [1.50%]. Time per iteration : 1.281 ms.
30448908048555*2^666666-1, iteration : 20000 / 666666 [3.00%]. Time per iteration : 1.321 ms.
30448908048555*2^666666-1, iteration : 30000 / 666666 [4.50%]. Time per iteration : 1.256 ms.
^C
Caught signal. Terminating.

boinc@Lubuntu32:~/Cuda/llrCPU$ ./sllr_dev387_gwnum272 -d -q"30448908048555*2^666666-1"
...
Unrecoverable error, Restarting with next larger FFT length...
Fatal error at setup : Number sent to gwsetup is too large for the FFTs to handle.

Many posts ago (somewhere) it has been suggested that gwnum v27.2 might have problems with the large k in SGS. Therefore, that won't change until v27.2 is updated...regardless of 32 bit vs. 64 bit llr. :)

Made the comparison 'sllr64_dev387' vs 'sllr_dev387':

boinc@vmware2k-3:~/Cuda/test/llr-apps CPU$ ./sllr64_dev387 -d -q"30*2^400000+1"
Starting Proth prime test of 30*2^400000+1
Using all-complex Core2 type-1 FFT length 24K, Pass1=32, Pass2=768, a = 7
30*2^400000+1, bit: 10000 / 400004 [2.49%]. Time per bit: 0.334 ms.
30*2^400000+1, bit: 20000 / 400004 [4.99%]. Time per bit: 0.328 ms.
30*2^400000+1 is not prime. Proth RES64: 703F8ACAB9634020 Time : 131.398 sec.

boinc@vmware2k-3:~/Cuda/test/llr-apps CPU$ ./sllr_dev387 -d -q"30*2^400000+1"
Starting Proth prime test of 30*2^400000+1
Using all-complex Core2 type-1 FFT length 24K, Pass1=32, Pass2=768, a = 7
30*2^400000+1, bit: 10000 / 400004 [2.49%]. Time per bit: 0.364 ms.
30*2^400000+1, bit: 20000 / 400004 [4.99%]. Time per bit: 0.358 ms.
30*2^400000+1 is not prime. Proth RES64: 703F8ACAB9634020 Time : 143.432 sec.

3.8.7dev-AVX for Intel and 3.8.7dev available for Linux32 and Linux64:

sllr32_dev387.7z
sllr32_dev387_avx.7z
sllr64_dev387.7z
sllr64_dev387_avx.7z


[add]
non-AVX versions
____________
Best wishes. Knowledge is power. by jjwhalen

I ran rroonnaalldd'ss Linux 64-bit AVX 3.8.7 build vs. the barely-a-month-old 3.8.6 AVX (32-bit) build. Any runtime difference I see is "in the noise"... far less than 1%, and sometimes 3.8.6 was faster. Basically, a tie, so far I as I've seen. This is with PPS Low and SGS; all residues matched.

--Gary
____________
"I am he as you are he as you are me and we are all together"

87*2^3496188+1 is prime! (1052460 digits)
4 is not prime! (1 digit)

It looks like I've been successful in building a 64-bit Windows version of 3.8.7.

So far I've done exactly one test with it, and it seems to be about 10% faster than the 32 bit version.

I'll make it available for testing once I've done a bit more testing with it.

This is NOT an AVX build.
____________
My lucky number is 75898⁵²⁴²⁸⁸+1

A Windows 64 bit build of LLR 3.8.7-dev can now be downlaoded here.

The source code is unchanged from what Jean Penne distributed in the 3.8.7. dev release.

The distribution file includes the executable (cllr.exe) as well as an app_info.xml file which contains entries for PPS-LLR and TRP-LLR. It should be usable, with the correct entries in app_info, with the other LLR projects. (There's also an entry in that app_info for GeneferCUDA.)

Note that this build of LLR can use the 32-bit Boinc wrapper without penalty. There's no need for a separate 64 bit wrapper.

This should also be usable with PRPNet, although I have not tested it.

This build should be usable on any 64 bit Intel or AMD CPU, although it will NOT make use of AVX instructions. It has only been tested so far on a single Core2Quad CPU, but the code is unchanged and I wouldn't expect there to be problems.

Note that there are some factoring features of LLR that do NOT build in the 64 bit windows version due to the source apparently being lost and only 32 bit object files being available. Therefore, a 32 bit build of LLR has slightly more functionality than the 64 bit build, but I don't believe that affects current projects on PRPNet or Boinc.
____________
My lucky number is 75898⁵²⁴²⁸⁸+1

Well, I've tested on i7-920 Win 2008 R2 x64 and it's about 10% slower comparing to stock app.

I'll try on i5-2500 running VMware (where AVX version has no use).

On another note - PG folder and slots are growing and growing - over 400MB.

I've manually cleaned and adjusted client_state or old apps can be deleted. I guess there is no need to have several LLR wrappers and several CLLR versions.

Too bad this x64 app can't be packed using UPX. Default app shrinks from 26 to 1MB.
____________
My stats

Well, I've tested on i7-920 Win 2008 R2 x64 and it's about 10% slower comparing to stock app.

I'll try on i5-2500 running VMware (where AVX version has no use).

Well, I've tested on i7-920 Win 2008 R2 x64 and it's about 10% slower comparing to stock app.

That's definitely unexpected. It's about 12% faster on my computer (C2Q Q6600).

Boinc IS supposed to delete old versions under certain circumstances. I don't know enough about the mechanics involved to guess why you might have so many obsolete files.

VMware blocks or better masks enhanced CPU features only after a manual intervention (EVC).
This is sometimes needed for VMotion between hosts with different CPU features.

I suppose the slowdown could be due to more cache misses caused by moving more data around, but 10% seems like an awfully big drop for that -- especially considering that it would be offset by the speed gains from faster math.

If this is what's happening, then people may see wildly different results depending upon which specific CPU they're using AND how many cores are in use.

Which brings me to the next question: Can you repeat that test with all the other cores idle? If it is indeed a cache problem, running just one core may show a dramatic increase in speed relative to the 32 bit stock version.
____________
My lucky number is 75898⁵²⁴²⁸⁸+1

Maybe the difference is due to Hyperthreading on the i7 if it is turned on given that the Q6600 doesn't have HT? LLR behaves not very well with HT in some cases.

Which brings me to the next question: Can you repeat that test with all the other cores idle? If it is indeed a cache problem, running just one core may show a dramatic increase in speed relative to the 32 bit stock version.

Which brings me to the next question: Can you repeat that test with all the other cores idle? If it is indeed a cache problem, running just one core may show a dramatic increase in speed relative to the 32 bit stock version.

Sure.
cllrx64.exe -q"8661*2^678147+1" -d
8661*2^678147+1 is prime! Time : 556.670 sec.

cllrx86.exe -q"8661*2^678147+1" -d
8661*2^678147+1 is prime! Time : 558.832 sec.

cllr.exe -q"8661*2^678147+1" -d
Starting Proth prime test of 8661*2^678147+1
Using all-complex Core2 type-3 FFT length 64K, Pass1=256, Pass2=256, a = 7
8661*2^678147+1 is prime! Time : 648.074 sec.

cllrx86.exe -q"8661*2^678147+1" -d
Starting Proth prime test of 8661*2^678147+1
Using all-complex Core2 type-3 FFT length 64K, Pass1=256, Pass2=256, a = 7
8661*2^678147+1 is prime! Time : 731.731 sec.

Jean Penne must own a DeLorean. I suspect the flux capacitor came from eBay.

One thing to check that isn't visible in what you posted: make sure both programs are choosing the same FFT type.

Tested the 64 bit version with Win7 on an E350 processor.

llr Test>cllr -q"3117*2^314958+1" -d
Fatal error at setup : Number sent to gwsetup is too large for the FFTs to handle.

side note: the llr version supplied with the prpclient 5.0.5 produces the same error.

Andy

So you're getting the same error with the 32 bit version, right?

Yes, that is right.

C:\GeneferCUDA test\From others\llr 3.8.7 dev\64\llr387devsrc>llr\cllr___Win64_Release\cllr -q"3117*2^314958+1" -d
Starting Proth prime test of 3117*2^314958+1
Using all-complex Core2 type-1 FFT length 24K, Pass1=32, Pass2=768, a = 7
3117*2^314958+1 is not prime. Proth RES64: 4E6DB6FACE0861F5 Time : 120.099 sec.

An Zacate E350 is a dual core cpu from AMD with 1,6 GHz clock, an integrated gpu on chip and a tdp of 18 watts. Its not fast, but enough for a home computer. I didn't mention my original post in

http://www.primegrid.com/forum_thread.php?id=3350&nowrap=true#48082

sorry for that. The stock llr test doesn't run in version 3.8.6 and 3.8.7. BUT the avxllr version DOES run and the E350 has no avx built in.

Andy

I'm not running 5.0.5, so I'm not sure which version of llr that is.

Rogue posted your answer in message #48539.
"I asked George last week and he indicated that it will be a few weeks before gwnum v27.3 is ready."
____________
Best wishes. Knowledge is power. by jjwhalen

Rogue posted your answer in message #48539.
"I asked George last week and he indicated that it will be a few weeks before gwnum v27.3 is ready."

Jenne Penne has just released an updated 3.8.7 that includes a fix for a memory leak.

You can download the Windows 64 bit executable file here.

Please update your version of the cllr.exe if you downloaded the earlier version from yesterday.
____________
My lucky number is 75898⁵²⁴²⁸⁸+1

The first post has been updated with the latest builds available.
____________

Update for linux32/64 from the latest code:

sllr32_dev387.tar.bz2
sllr32_dev387_avx.tar.bz2
sllr64_dev387.tar.bz2
sllr64_dev387_avx.tar.bz2
____________
Best wishes. Knowledge is power. by jjwhalen

Thomas11 found another mem-leak for non-base-2 tests and Jean fixed this today in his sunday source...
Updates for linux32/64 from the latest code:

sllr32_dev387.tar.bz2
sllr32_dev387_avx.tar.bz2
sllr64_dev387.tar.bz2
sllr64_dev387_avx.tar.bz2


[add]
all executable files are packed with UPX
____________
Best wishes. Knowledge is power. by jjwhalen

Latest version of the Windowsx64 non-AVX is available, featuring Jean's Sunday code.

This should operate identically to the one Rebirther posted. Mine's built with VS 2005 and his is built worth VS 2010, so it might be worth doing a timing test on them. Chances are there's no measurable difference since the important parts are in gwnum, which is precompiled assembler.
____________
My lucky number is 75898⁵²⁴²⁸⁸+1

64 bit windows non AVX version
In BOINC
from average 535 ----> 460 seconds.

AVX version also works fine, but both (32 and 64 bit) have some kind of delay.
When Boinc start to compute in non AVX version all 4 task ( on quad core) start crunching in same time
On AVX version, only one task start, and then after ten seconds start second WU , and then after ten seconds start 3WU and 4WU task...
But crunching time is aprox same....
____________
92*10^^1585996-1 NEAR-REPDIGIT PRIME :) :) :)
4 * 650^⁴⁹⁸¹⁰¹-1 CRUS PRIME
2022202116^¹³¹⁰⁷²+1 GENERALIZED FERMAT
Proud member of team Aggie The Pew. Go Aggie!

Latest version of the Windowsx64 non-AVX is available, featuring Jean's Sunday code.

This should operate identically to the one Rebirther posted. Mine's built with VS 2005 and his is built worth VS 2010, so it might be worth doing a timing test on them. Chances are there's no measurable difference since the important parts are in gwnum, which is precompiled assembler.

I wonder what is happening as I do not see any difference here. Perhaps just Windows not being consistent.

I wonder what is happening as I do not see any difference here. Perhaps just Windows not being consistent.

There is no difference in the computation times.
Both patches only fix memory leaks for base-2 and non-base-2 tests.

No! One is an old prpnet distributed 32 bit version and the other is this fast 64-bit version that is as slow as the 32bit version running under exactly same conditions on the same host! In fact I tend to see the opposite of rogues' statement that

it means that a 64-bit build of llr should be faster than a 32-bit build of llr.

Updated 32/64bit with the latest code:
llr32bit-AVX-win
llr64bit-AVX-win
llr64bit-win

I wonder what is happening as I do not see any difference here. Perhaps just Windows not being consistent.

>llr_reb.exe -q"7515*2^726237+1" -d Resuming Proth prime test of 7515*2^726237+1 at bit 33761 [4.64%] Using all-complex Pentium4 type-3 FFT length 64K, Pass1=256, Pass2=256, a = 7 7515*2^726237+1 is prime! Time : 535.005 sec. >llr_prp5.exe -q"7515*2^726237+1" -d Starting Proth prime test of 7515*2^726237+1 Using all-complex Pentium4 type-3 FFT length 64K, Pass1=256, Pass2=256, a = 7 7515*2^726237+1 is prime! Time : 535.180 sec.

cllr387dev-win-x64.7z (VS2005) by Michael

P:\()_test\Non-AVX\Windows 64\Michael>cllr -q"7515*2^726237+1" -d
Starting Proth prime test of 7515*2^726237+1
Using all-complex Pentium4 type-3 FFT length 64K, Pass1=256, Pass2=256, a = 7

7515*2^726237+1 is prime! Time : 319.480 sec.


llr64bit-win (VS2010) by Rebirther

P:\()_test\Non-AVX\Windows 64\Rebirther>llr -q"7515*2^726237+1" -d
Starting Proth prime test of 7515*2^726237+1
Using all-complex Pentium4 type-3 FFT length 64K, Pass1=256, Pass2=256, a = 7

7515*2^726237+1 is prime! Time : 319.638 sec.

Windows 32 bit llr32bit-AVX-win by Rebirther

P:\()_test\AVX\Windows 32>llr -q"7515*2^726237+1" -d
Starting Proth prime test of 7515*2^726237+1
Using all-complex AVX Core2 type-3 FFT length 64K, Pass1=256, Pass2=256, a = 7

7515*2^726237+1 is prime! Time : 232.644 sec.


Windows 64 bit llr64bit-AVX-win by Rebirther

P:\()_test\AVX\Windows 64>llr -q"7515*2^726237+1" -d
Starting Proth prime test of 7515*2^726237+1
Using all-complex AVX Core2 type-3 FFT length 64K, Pass1=256, Pass2=256, a = 7

7515*2^726237+1 is prime! Time : 232.633 sec.

Tested the 64 bit version with Win7 on an E350 processor.

llr Test>cllr -q"3117*2^314958+1" -d
Fatal error at setup : Number sent to gwsetup is too large for the FFTs to handle.

side note: the llr version supplied with the prpclient 5.0.5 produces the same error.

Andy

MacIntel 32&64 bit non-AVX and AVX builds added to first post.
____________

gwnum v27.3 has been released. Please see George's comments here. It can be retrieved here: ftp://mersenne.org/gimps/source273.zip

It is unknown at this time whether this resolves the AMD Bulldozer issue.
____________

gwnum v27.3 has been released. Please see George's comments here. It can be retrieved here: ftp://mersenne.org/gimps/source273.zip

But according to George, it's potentially slower on AVX computers...

An early beta prime95 version 27.3 is available. This version supports 64-bit optimized AVX FFTs. 32-bit AVX FFTs are also a little bit faster. I haven't done full benchmarks so I'm not sure how much faster it is than versions 27.2 or 26.6.

The good/bad news is these FFTs are so fast that they are limited by memory bandwidth -- standard Sandy Bridge CPUs will experience a slow down when running all 4 cores. I'd like to hear from Sandy Bridge-E users to see if they also suffer slow downs when all 4 cores are running.

I don't think he means it will be slower...just that there will be a slowdown when running on 4 cores.

Hmm, but this is like before I think. Rebirther tested it some weeks ago with the gnum 27.2 pfgw-avx build on SR5@prpnet. If he running all 4 cores, it slows down a lot in comparison to 2 cores running simultaneously and 2 cores on another project.

And AMD BD is ready for testing :)
____________
92*10^^1585996-1 NEAR-REPDIGIT PRIME :) :) :)
4 * 650^⁴⁹⁸¹⁰¹-1 CRUS PRIME
2022202116^¹³¹⁰⁷²+1 GENERALIZED FERMAT
Proud member of team Aggie The Pew. Go Aggie!

Well, if someone compiles LLR with the newer gwnum, I'd be happy to test on both i7-2600 and i5-2500. :)

Still no joy on Bulldozer.

Intel i5-2500 stock speed, Win 2008R2 x64, running only one at a time.
Results from Rebirther's recent app, using GWNUM 27.3
llr -q"8661*2^678147+1" -d
8661*2^678147+1 is prime! Time : 234.014 sec.

llr64 -q"8661*2^678147+1" -d
8661*2^678147+1 is prime! Time : 197.413 sec.

pfgw32 -q"8661*2^678147+1" -d
8661*2^678147+1 is 3-PRP! (260.8109s+0.0007s)

pfgw64 -q"8661*2^678147+1" -d
8661*2^678147+1 is 3-PRP! (222.5442s+0.0006s)

LLRAVX is previous 3.8.6 version
llravx -q"8661*2^678147+1" -d
8661*2^678147+1 is prime! Time : 241.185 sec.

Note: those tests are using 50k FTT, recent live test from BOINC (n~752k) FFT length: 64K
____________
My stats

Same host, several instances or LLRAVX64:
1 instance: 197 secs
2 instances: 197 secs
3 instances: 199 secs
4 instances: ~205 secs

On a side note - I noteced that during initial phase, app uses more than single core. In the end, BOINC time is a bit lower compating to TaskManager.
____________
My stats

Update for Linux32/64 with gwnum27.3:
sllr32_dev387_gwnum273.tar.bz2
sllr64_dev387_gwnum273.tar.bz2
____________
Best wishes. Knowledge is power. by jjwhalen

Is anyone able to provide LLR builds for the following:

• LLR 3.8.6 with gwnum 26.6 - http://jpenne.free.fr/llr3/llr386src.zip
  
• LLR 3.8.6dev with gwnum 26.6 - http://jpenne.free.fr/Development/llr386devsrc.zip
  
• LLR 3.8.7dev with gwnum 26.6 - http://jpenne.free.fr/Development/llr387devsrc.zip
  

ftp://mersenne.org/gimps/source266.zip
____________

All apps for Linux are listed at http://primegrid.pytalhost.net/Mirror.htm or you use the following links:
sllr32_386src_gwnum266, no 64bit possible!
sllr32_386devsrc_gwnum266, no 64bit possible!

sllr32_dev387_gwnum266
sllr64_dev387_gwnum266
____________
Best wishes. Knowledge is power. by jjwhalen

All apps for Linux are listed at http://primegrid.pytalhost.net/Mirror.htm or you use the following links:
sllr32_386src_gwnum266, no 64bit possible!
sllr32_386devsrc_gwnum266, no 64bit possible!

sllr32_dev387_gwnum266
sllr64_dev387_gwnum266

Whatever was changed in 27.4, it didn't fix the Bulldozer problem.

27.4 does fix the bug mentioned in http://www.mersenneforum.org/showpost.php?p=289888&postcount=63

Whatever was changed in 27.4, it didn't fix the Bulldozer problem.

Whatever was changed in 27.4, it didn't fix the Bulldozer problem.

George told me that it should be fixed. What problem are you seeing with v27.4?

Whatever was changed in 27.4, it didn't fix the Bulldozer problem.

George told me that it should be fixed. What problem are you seeing with v27.4?

Every test fails with "Fatal error at setup : Number sent to gwsetup is too large for the FFTs to handle."

Are you certain that it is a build that is linked with gwnum v27.4?

Update for Linux32/64 with gwnum27.4:
sllr32_dev387_gwnum274.tar.bz2
sllr64_dev387_gwnum274.tar.bz2

boinc@vmware2k-3:~/Cuda/llrCPU$ ./sllr64_dev387_gwnum274 -d -q"30448908048555*2^666666-1"
Starting Lucas Lehmer Riesel prime test of 30448908048555*2^666666-1
Using zero-padded Core2 type-1 FFT length 72K, Pass1=96, Pass2=768
30448908048555*2^666666-1, iteration : 10000 / 666666 [1.50%]. Time per iteration : 1.527 ms.
^C
Caught signal. Terminating.

boinc@vmware2k-3:~/Cuda/llrCPU$ ./sllr32_dev387_gwnum274 -d -q"30448908048555*2^666666-1"
Error reading z7896541 intermediate file.
Starting Lucas Lehmer Riesel prime test of 30448908048555*2^666666-1
Using zero-padded Core2 type-1 FFT length 72K, Pass1=96, Pass2=768
30448908048555*2^666666-1, iteration : 10000 / 666666 [1.50%]. Time per iteration : 1.756 ms.
^C
Caught signal. Terminating.

I updated the code with official one:

Download