Hey guys,

Currently, there is an issue getting the boinc libraries to compile with our code in the win32 version. I had a pretty sketchy fix to it over last summer, but in the end it ended up not working on all computers.

Thank you,

Jake W.

Hey guys,

This release does not fix the win32 issues, I'm sorry. It should be possible for you guys to compile your own version of milkyway@home for win32 if you are interested. The issue with us releasing a version is it has to work with all computers running win32 even with some outdated hardware, which has proven itself to be very difficult. If you can get it running on your machine though it is possible to still get work units and run them for credits.

Jake W.

GPU missing since I upgraded nvidia drivers to 335.23 release date 3/10/2014

I suppose when MW@Home updates they will re-appear?

Any ideas on why is this computer using SSE2 instead of SSE3 for the GPU app? The CPU is SSE3 capable, runs the SSE3_AMD optimized SETI app and I'm using the current stable version of BOINC (6.12.34) and as I have seen on other hosts using that version, they are using SSE3, so should be new enough.

Whenever I check out validate errors, more than 95+% of the time it's because the result is missing. The workunit succeeded and everything, but the result is simply not in the output. We get results back from the stderr for quite a while (this wasn't true about a year ago), and I don't many other projects do this.

There are two issues (at least one is with BOINC) which I'm aware of which results in this. First, there seems to be an arbitrary cutoff where you lose part of the stderr log if it's large, but that is much less frequent.

Second, there seems to be a (more frequent) problem where sometimes for no reason some of the stderr is lost (the important part with the result). There are strange things that happen with CAL and OpenCL where stderr/stdout don't get flushed correctly on program end. I've sort of noticed this for a long time, and recently were mentioned on the AMD OpenCL forums as a AMD known issue.

I think I know!!

They get all invalid :-(

I return to stock app.

When I use the app_info.xml, must there also be an entry for the N-body in it?

... and the AMD/ATI HD cards that don't do DP (well enough):

6850
6790
6670
6570
6450

5770
5750
5670
5570
5470

4770
4670
4650
4550
4350

Just the past week a 'optimized' stock app was released. I am down to 9-10 hours on my P4 Xp for the de_separation_13_3s tasks. A large improvement over the previous app. Still seems slightly slower than the old Opti apps.

This is supposed to be science, not a race to see who can accumulate the most points.

Using anything other than the project approved software is BS and you're being childish and threatening the integrity of the projects. If you don't understand WHY, you don't belong here.

Without using an opti app Cpu performance and credits are poor. Is there any plans to put out better cpu apps?

I know that the stock app is pretty much unusable on a CPU.
FWIW, it seems that i can reduce crunching times to less than ~5h on a XEON(5365@3 Ghz, core 2 based)...

Anyway, i do know that that's far away from what the previous opt app did...

I'd be interested to know some crunch times on different CPUs with the stock app (cpu:time:credits), before using a LUT for the INT EXP part...
(wich i know for a fact that the previous optimized CPU app used and i allready suggested to Matt for the GPU BUT it'll greatly speed up the stock CPU app as well)

Is this from using compilation flags, or changing the code?

If any of the changes are things we can do on our end, we'd be more than happy to implement them.

The next CPU release will be faster for most people

ing the likelihood calculation...well gipsels app did that on the CPU as well.

So even if you move it to the GPU, you're still not getting the performance of Gipsels app.. it'll still be at least 20% slower(copmpared to those,running stock without tuning gipsels app for maximum output).

Those are painful to watch. I'm so bad at talking.