Which version of BOINC are you using? The available memory is provided by BOINC to the app.

FWIW, init_data.xml says:

<m_nbytes>2627551232.000000</m_nbytes>

I can't see how the app would print that message unless the API somehow manages to parse that string as some small number that rounds to 0.000000 .

I found the problem with the memory size and share memory issue. It was due to using different alignment flags to compile the app and the boinc libraries. I'm running i686-linux version 8.02 on the test workunit and will release it later today.

Intel Mac versions will also probably go out today. Maybe even a windows 32bit as well.

---

I've just noticed that I'm getting the rather ugly, and unnecessary, "Message from task: 0" in the Event Log on completion of each task.

I'm getting this also on a Win7 (x64) running 7.6.22, both on main and beta, WxWidgets 3.0.1.

---

I don't buy computers, I build them!!

The new v8s are out (windows_intelx86, i686-linux, i686-darwin, x86_64-darwin). But we're out of v8 work while Jeff runs some tests of v7 comparisons.

---

The new v8s are out (windows_intelx86, i686-linux, i686-darwin, x86_64-darwin). But we're out of v8 work while Jeff runs some tests of v7 comparisons.

LoL, as they say хвост вытащишь - нос увязнет :))

---

News about SETI opt app releases: https://twitter.com/Raistmer

Hadn't heard that one before but it sounds about right.

---

On a cold, rainy Monday, with perhaps a bit too much time on my hands, I decided to try to do a broad comparison of task run times between the 3 iterations (thus far) of the i686-pc-linux-gnu app.

Since there hasn't been much overlap of ARs between the three, there's not much direct comparison, but I've tried to assemble a general selection of a range of ARs that I've crunched thus far on my T7400. I've highlighted a few ARs that approximately match.

Also, although I was initially just looking at the ARs to try to make comparisons, I came to realize that the ARs alone don't seem to account for the variations in run times I've seen, so I've added the function choices, also. Frankly, function choices aren't something I've ever paid attention to before, so I was surprised at the variation I found.

Anyway, I don't know if any of this is significant, or useful, but I found it quite interesting to put together. I can probably do something similar for the x86_64-pc-linux-gnu apps, if anyone's interested.

i686-pc-linux-gnu
v7.01
Task 21466871 (AR=2.724691) : Run Time 2:30:31 | v_vGetPowerSpectrum; sse2_ChirpData_ak8; v_vTranspose4; AK SSE folding
Task 21424453 (AR=1.180592) : Run Time 2:19:22 | v_vGetPowerSpectrumUnrolled; sse2_ChirpData_ak8; v_pfTranspose2; AK SSE folding
Task 21468513 (AR=1.150180) : Run Time 2:09:05 | v_vGetPowerSpectrumUnrolled; sse1_ChirpData_ak8e; v_vTranspose4; BH SSE folding
Task 21419173 (AR=1.150180) : Run Time 2:35:50 | v_vGetPowerSpectrum; sse2_ChirpData_ak8; v_pfTranspose2; AK SSE folding
Task 21479484 (AR=0.989370) : Run Time 4:05:14 | v_vGetPowerSpectrumUnrolled; sse2_ChirpData_ak8; v_vTranspose4; AK SSE folding
Task 21424035 (AR=0.891534) : Run Time 4:36:54 | v_vGetPowerSpectrumUnrolled; sse2_ChirpData_ak8; v_vTranspose4; AK SSE folding
Task 21425836 (AR=0.414850) : Run Time 5:59:24 | v_vGetPowerSpectrumUnrolled; sse3_ChirpData_ak8; v_vTranspose4; AK SSE folding
Task 21420092 (AR=0.407224) : Run Time 6:23:06 | v_vGetPowerSpectrumUnrolled; sse2_ChirpData_ak8; v_vTranspose4np; AK SSE folding
Task 21471478 (AR=0.290859) : Run Time 6:46:08 | v_vGetPowerSpectrumUnrolled; sse1_ChirpData_ak8h; v_vTranspose4; AK SSE folding
Task 21471479 (AR=0.290859) : Run Time 6:56:04 | v_vGetPowerSpectrumUnrolled; sse2_ChirpData_ak8; v_vTranspose4; AK SSE folding
Task 21422404 (AR=0.290859) : Run Time 7:15:46 | v_vGetPowerSpectrumUnrolled; sse1_ChirpData_ak8e; v_pfTranspose2; AK SSE folding

v8.00
Task 21487495 (AR=8.930791) : Run Time 2:22:17 | v_vGetPowerSpectrumUnrolled; sse2_ChirpData_ak8; v_vTranspose4; AK SSE folding
Task 21487498 (AR=8.930791) : Run Time 2:11:25 | v_vGetPowerSpectrumUnrolled; sse2_ChirpData_ak8; v_vTranspose4; AK SSE folding
Task 21412439 (AR=2.724749) : Run Time 2:18:05 | v_vGetPowerSpectrumUnrolled; sse2_ChirpData_ak8; v_vTranspose4; AK SSE folding
Task 21409582 (AR=2.724708) : Run Time 2:15:10 | v_vGetPowerSpectrumUnrolled; sse2_ChirpData_ak8; v_pfTranspose4; AK SSE folding
Task 21407583 (AR=2.724696) : Run Time 1:55:36 | v_vGetPowerSpectrumUnrolled; sse2_ChirpData_ak8; v_vTranspose4; AK SSE folding
Task 21407135 (AR=2.724696) : Run Time 2:10:11 | v_vGetPowerSpectrumUnrolled; sse2_ChirpData_ak8; v_vTranspose4; AK SSE folding
Task 21405640 (AR=2.724691) : Run Time 2:07:01 | v_vGetPowerSpectrum; sse2_ChirpData_ak8; v_vTranspose4; AK SSE folding
Task 21404490 (AR=2.724691) : Run Time 2:26:35 | v_vGetPowerSpectrumUnrolled; sse2_ChirpData_ak8; v_vTranspose4; AK SSE folding
Task 21399458 (AR=2.597554) : Run Time 2:33:01 | v_vGetPowerSpectrumUnrolled; sse3_ChirpData_ak8; v_vTranspose4; BH SSE folding

v8.01
Task 21488113 (AR=8.930791) : Run Time 2:31:55 | v_vGetPowerSpectrumUnrolled; sse3_ChirpData_ak8; v_pfTranspose4; AK SSE folding
Task 21488753 (AR=8.111272) : Run Time 2:17:42 | v_vGetPowerSpectrumUnrolled; sse1_ChirpData_ak8h; v_vTranspose4; BH SSE folding
Task 21490757 (AR=7.590275) : Run Time 2:43:33 | v_vGetPowerSpectrumUnrolled; sse2_ChirpData_ak8; v_vTranspose4; AK SSE folding
Task 21491186 (AR=7.590275) : Run Time 2:49:13 | v_vGetPowerSpectrum; sse2_ChirpData_ak8; v_vTranspose4; BH SSE folding
Task 21491941 (AR=7.213332) : Run Time 3:01:53 | v_vGetPowerSpectrumUnrolled; sse1_ChirpData_ak8e; v_vTranspose4; AK SSE folding
Task 21489138 (AR=6.083767) : Run Time 2:21:29 | v_vGetPowerSpectrumUnrolled; sse1_ChirpData_ak8h; v_vTranspose4; AK SSE folding
Task 21493672 (AR=3.366734) : Run Time 2:36:10 | v_vGetPowerSpectrumUnrolled; sse2_ChirpData_ak8; v_vTranspose4; AK SSE folding
Task 21497666 (AR=2.726771) : Run Time 2:11:42 | v_vGetPowerSpectrumUnrolled; sse2_ChirpData_ak8; v_vTranspose4; AK SSE folding
Task 21497749 (AR=2.726771) : Run Time 2:21:59 | v_vGetPowerSpectrumUnrolled; sse1_ChirpData_ak8e; v_vTranspose4; AK SSE folding
Task 21497932 (AR=2.726771) : Run Time 2:33:40 | v_vGetPowerSpectrumUnrolled; sse2_ChirpData_ak8; v_vTranspose4; AK SSE folding
Task 21489816 (AR=2.168620) : Run Time 2:44:03 | v_vGetPowerSpectrumUnrolled; sse2_ChirpData_ak8; v_vTranspose4; AK SSE folding
Task 21495301 (AR=0.010413) : Run Time 5:07:55 | v_vGetPowerSpectrumUnrolled; sse2_ChirpData_ak8; v_vTranspose4; BH SSE folding
Task 21495792 (AR=0.010413) : Run Time 5:15:21 | v_vGetPowerSpectrumUnrolled; sse2_ChirpData_ak8; v_vTranspose4np; BH SSE folding
Task 21494429 (AR=0.008366) : Run Time 5:25:51 | v_vGetPowerSpectrumUnrolled; sse2_ChirpData_ak8; v_vTranspose4; BH SSE folding
Task 21494566 (AR=0.007925) : Run Time 5:27:14 | v_vGetPowerSpectrumUnrolled; sse1_ChirpData_ak8e; v_vTranspose4; BH SSE folding
Task 21494652 (AR=0.007925) : Run Time 5:21:37 | v_vGetPowerSpectrum; sse2_ChirpData_ak8; v_vTranspose4; BH SSE folding
Task 21495207 (AR=0.007925) : Run Time 5:17:26 | v_vGetPowerSpectrumUnrolled; sse1_ChirpData_ak8e; v_vTranspose4; BH SSE folding

All in all, although I initially thought (and posted) that I was seeing increased run times for v8.01 i686-pc-linux-gnu over the v8.00 iteration, it now appears to me that the function choices have more of an impact than the app version.

The new v8s are out (windows_intelx86, i686-linux, i686-darwin, x86_64-darwin). But we're out of v8 work while Jeff runs some tests of v7 comparisons.

The good news is the Linux i686 seems faster than the last version.
The bad news is the Darwin x86_64 is so slow I'm afraid to calculate.
So, 20% of a shorty in 47 minutes? Hmmm, the v7 App was finished in about 47 minutes.
http://setiathome.berkeley.edu/results.php?hostid=6796479&offset=320

But hey, the graphics work...

But hey, the graphics work...

Nice to see those again ;)

4 i686-darwin at 66% at 90 minutes.

2 VLARs up next, will have to wait and see how they do..

Some indication the Windows v8.01 is noticeably (~10%) slower than v8.00, but with identical results. I'll check the APRs when a decent sample has run through.

Ah, guppi VLARs again, I see. I didn't even try to compare those in the original v7.99 batch with the recent 06ap11ag VLARs because they were soooooooo slooooooow!

I've just noticed that I'm getting the rather ugly, and unnecessary, "Message from task: 0" in the Event Log on completion of each task.

I'm getting this also on a Win7 (x64) running 7.6.22, both on main and beta, WxWidgets 3.0.1.

It did turn out to be a BOINC client error. David has coded a fix, and it's working in a private build. Should appear in v7.6.23 in due course.

So far I've successfully processed Windows 433 V8 CPU tasks with no errors, but I don't seem to get any from the Green Banks. How do I tell the difference from tasks split from Aercibo and Green Banks? And, when will GPU tasks be ready for testing?

I really would like to see GPU testing for VLARS on my twin GTX750Ti. With the newer families of GPUs this should be thoroughly investigated. I remember running VLARs on my GTX460SC cards and the run times seemed to be comparable with AP GPU tasks.

---

I don't buy computers, I build them!!

How do I tell the difference from tasks split from Aercibo and Green Banks?

By the task name. The Arecibo recordings are identified by date (ddmmyy) as previously. The GBT tasks we've seen so far have task names staring guppi_, but the splitters have been made as general-purpose as possible - there may be other data sources in future.

And, when will GPU tasks be ready for testing?

The tasks, as always, are undifferentiated. It doesn't matter what sort of (co-)processor they're crunched on. But the first step is to get the CPU apps returning consistently accurate results, across all platforms. Once the reference point is established, GPU apps can be tested for compatibility.

How do I tell the difference from tasks split from Aercibo and Green Banks?

By the task name. The Arecibo recordings are identified by date (ddmmyy) as previously. The GBT tasks we've seen so far have task names staring guppi_, but the splitters have been made as general-purpose as possible - there may be other data sources in future.

And, when will GPU tasks be ready for testing?

The tasks, as always, are undifferentiated. It doesn't matter what sort of (co-)processor they're crunched on. But the first step is to get the CPU apps returning consistently accurate results, across all platforms. Once the reference point is established, GPU apps can be tested for compatibility.

Jason is still gearing up to build the new apps.

From one of my Mac results :

<stderr_txt>
dyld: DYLD_ environment variables being ignored because main executable (/Library/Application Support/BOINC Data/slots/1/../../switcher/switcher) is setuid or setgid
setiathome_v8 8.00 Revision: 3251XCode LLVM 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.57) x86_64

libboinc: 7.7.0
libboinc: 7.7.0

Work Unit Info:
...............
WU true angle range is :  0.008366
Optimal function choices:
--------------------------------------------------------
                            name   timing   error
--------------------------------------------------------
                v_BaseLineSmooth (no other)
     v_vGetPowerSpectrumUnrolled 0.000047 0.00000 
              sse3_ChirpData_ak8 0.004032 0.00000 
             v_vTranspose4x16ntw 0.001142 0.00000 
                  AK SSE folding 0.000644 0.00000 

What is wrong with the first version of the 64bit Mac app :
-dyld line ?
-libboinc version is written twice.
-no avx algorithm choosen.
-libfftw build without AVX support.
-speed is factor 2 too slow.

So, there is some more work necessary ... will turn -verbose mode on now.

---

_\|/_
U r s

How do I tell the difference from tasks split from Aercibo and Green Banks?

By the task name. The Arecibo recordings are identified by date (ddmmyy) as previously. The GBT tasks we've seen so far have task names staring guppi_, but the splitters have been made as general-purpose as possible - there may be other data sources in future.

And, when will GPU tasks be ready for testing?

The tasks, as always, are undifferentiated. It doesn't matter what sort of (co-)processor they're crunched on. But the first step is to get the CPU apps returning consistently accurate results, across all platforms. Once the reference point is established, GPU apps can be tested for compatibility.

Jason is still gearing up to build the new apps.

Raistmer has got some of his into pre-alpha testing, but they're tested off-line first.

Things are checking out pretty nicely, so there probably won't be any more changes to the science analysis at this point.

---

...What is wrong with the first version of the 64bit Mac app :
-dyld line ?
-libboinc version is written twice.
-no avx algorithm choosen.
-libfftw build without AVX support.
-speed is factor 2 too slow.

So, there is some more work necessary ... will turn -verbose mode on now.

Here's an interesting comparison. Two almost identical processors, the one now in the Mac is 200mhz faster. The other one shipped as stock in the very same Mac but is now running Linux.
Intel E5472;
Computer ID: 63959
Run time: 3 hours 40 min 26 sec
CPU time: 3 hours 40 min 16 sec
WU true angle range is : 2.729899

Intel E5462;
Computer ID: 76256
Run time 55 min 50 sec
CPU time 55 min 47 sec
WU true angle range is : 2.726771

I'd say it was a bit more than just twice as slow.

I rely on a volunteer for Intel MacOS compiles. I can suggest compiler settings, but I can't enforce them, and the time between versions is going to be longer.

---