I'm going to be updating the stock applications in the next few days because I've discovered a bug in them when running the latest searches.


I just updated the OSX applications (to version 0.30). I had to modify the checkpointing a bit, so let me know if they are checkpointing correctly.


I'll be updating linux and windows tonight.

---

Hi,

O.K., it's not the new app for CUDA which you mentioned, but I hope it's the correct thread for to write this.

I have a GTX260-216 and BOINC DLed the stock CUDA app for MilkyWay.

BOINC got:
milkyway_0.24_windows_intelx86__cuda23.exe
cudart.dll
cutil32.dll

But the strange is that cudart.dll is version 6.14.11.2020, this mean it's V2.2 and not V2.3 .
Is there something wrong?
Or is the file only wrong marked?

At SETI@home the difference between CUDA V2.2 and V2.3 mean ~ 30 % speed difference.

Best regards.

---

Somewhat related, the just released 257.21 GeForce driver release notes mention that the driver "Adds support for CUDA Toolkit 3.1 which includes significant performance increases for double precision math operations." I imagine this probably refers to new instructions/functions rather than a significant speed-up for existing ones, unless they decided to remove the double precision operations cap for the 400 series cards. Even so, it might be worth checking out.

BTW.

The current available optimized CPU app have a version number of 0.21 .

This 'old' optimized CPU app will calculate well the 'new' WUs (after mod of the app_info.xml file) and will match well with the results of the new apps (wingman)?

---

Not sure if its' related to the upgrade to .30 but I am running.30 on Mac OSX 105.8 and I am getting a strange result.

According to the properties display the checkpoints are being taken, but the percentage complete has been stuck at 0.0% since it started. So far two WU's have over 11 & 13 hours of CPU time

http://milkyway.cs.rpi.edu/milkyway/result.php?resultid=143137141
http://milkyway.cs.rpi.edu/milkyway/result.php?resultid=143137142

I have tried rebooting the system, but that had no impact on the numbers.

While it is currently in "waiting to run" status (probably because is completion deadline is 20 minutes later and the others are running as high priority). the WU ( http://milkyway.cs.rpi.edu/milkyway/result.php?resultid=142461244 ) does have a progressing completion percentage.

Hi,
It seems there is an issue with checkpointing on Mac OS X.
Percentage complete has been stuck at 0.0% since tasks are started (18 hours)
As my MacPro is running 12 h a day, WU is running since 2 days.
below copy of astronomy_checkpoint file of same WU before and after machine restart

After 6 hours of machine uptime:
background_integral: 0.00000000000000000000
stream_integrals[3]: 0.00000000000000000000, 0.00000000000000000000, 0.00000000000000000000
prob_sum: 0.00000000000000000000, num_zero: 0, bad_jacobians: 0
current_star_point: 0
current_integral: 0
number_integrals: 1
mu[min,max,steps]: 135.000, 240.000, 1600
nu[min,max,steps]: -1.250, 1.250, 640
r[min,max,steps]: 16.000, 22.500, 1400
mu_step: 1317, nu_step: 107, r_step: 0
background_integral: 0.00231811528309438597
stream_integrals[3]: 1259.58644129462277305720, 967.01620570881334515434, 3198.81638506128138033091

After few minutes of machine uptime:
background_integral: 0.00000000000000000000
stream_integrals[3]: 0.00000000000000000000, 0.00000000000000000000, 0.00000000000000000000
prob_sum: 0.00000000000000000000, num_zero: 0, bad_jacobians: 0
current_star_point: 0
current_integral: 0
number_integrals: 1
mu[min,max,steps]: 135.000, 240.000, 1600
nu[min,max,steps]: -1.250, 1.250, 640
r[min,max,steps]: 16.000, 22.500, 1400
mu_step: 4, nu_step: 105, r_step: 0
background_integral: 0.00231991176126485499
stream_integrals[3]: 1263.15242429980276028800, 967.01718327095272798033, 3200.90837238598305702908

---

Nope - checkpointing is not working on OSX. The work unit has been working for 15 hours, shows 10 hours to go, and shows 0% progress.

I looked into my WU this afternoon and can report the exact same thing as everybody else. It just sits there and does not actually progress.

Looks like time for 0.31.

---

I found the problem, I should have the OS X applications updated tonight.

-Travis

---

Should we cancel?
or is it actually dong valid work but not using the checkpoint/% complete functions correctly?

I just suspended my 7 units and will install the new app when it comes out.

---

V .30 for Mac is terrible. The Boink manager "Progress" and the "Time to Completion" don't work.

V .30 for Mac is terrible. The Boink manager "Progress" and the "Time to Completion" don't work.

Should be fixed now in version 0.31

---

Does CP's op ap need updating as well?

Does CP's op ap need updating as well?

Yeah, there's a bunch of updates that we need to get done so we can swap over to the assimilator/validator that doesn't generate files for each WU and for each result.

Hopefully he gets settled at his new post doc and can work with us or send us the code so we can update it.

---

Does CP's op ap need updating as well?

Yeah, there's a bunch of updates that we need to get done so we can swap over to the assimilator/validator that doesn't generate files for each WU and for each result.

Hopefully he gets settled at his new post doc and can work with us or send us the code so we can update it.

I will start my post doc position in two weeks.

Has anything changed since this post here and your summary there?
That version from april was already compatible with parameters given in the command line and wrote the integrals and likelihood also separately to the stderr.txt. Changes to the likelihood calculation should be really easy, as it is done on the CPU, not the GPU.

I will try to update the ATI app to use the newer Stream SDK (I was still using the outdated SDK 1.3 so far) this evening. Some changes will be needed, as SDK 1.3 didn't support multiple GPUs or the CPU release during the GPU kernels, I implemented that as some kind of small hack to the old SDK (it is open source). But the newer SDKs have official support for those features (that's why I want to use it), but it works of course a bit different than my version. I will see if all fits nicely or if some more changes are needed.

I've done also some changes to the boinc_api to fix some problems there, I don't know if it is still necessary or if Berkeley has fixed those issues (like the suspend/resume problem when using critical sections) since the last time I looked at it. But I will detail it when I send the code.

And be warned already, I never had time to clean it up, so it may look a bit convoluted. After all, it still bases on the 0.07 code, I only adapted it to stay compatible with the newer versions without investing any effort to increase the readability.

Some update from my side:

It runs now with the newer SDK version, but unfortunately I had to recognize, that a lot of nasty bugs or "features" survived. Heck, I complained about wrong indexing when using double precision constant buffers 18 months ago, I even sent a test case to ATI's stream developer team back then! That makes it more or less impossible to write the ATI GPU code completely in a high level language, one needs to correct the code on the underlying CAL/IL level. I can only hope that the OpenCL compiler was more in the focus of ATI lately. It really looks like nobody actually tested the double precision stuff within their compilers as there are plenty of problems with it but generally it works with single precision.

@Travis:
I hope you don't want to rewrite the integration kernels from scratch (I would almost suggest looking at OpenCL if that need arises, or alternatively CAL++ for ATIs, if you want more speed). But as I said before, changes to the likelihood stuff are no problem at all.

Edit:
I've just seen you added the possibility to use another "background profile" in the MW3 0.05 code (besides quite some other changes). If used, one would need to rewrite the GPU kernels. I will see, if I can look into it tomorrow.

Actually we've been trying to port everything into openCL. We've moved the code over to GitHub, and Matt Arsenault has been working on making a nice build system (in cmake) which should make changes and compiling much simpler.

http://github.com/arsenm/milkywayathome_client

The changes are pretty simple, I think the only GPU kernel that would need to be modified is the likelihood one. If you look at evaluation_optimized.c:

http://github.com/arsenm/milkywayathome_client/blob/master/milkyway_separation/cpu/evaluation_optimized.c

The big changes are that we're also calculating separate likelihoods for each stream and the background, lines 680-710 or so, in addition to full likelihood. We're also using kahan summation in the CPU code too, so I'm hoping that will bring the values closer.

Matt's also been working on a test system, so after cmake has made the makefiles to compile, it can also automatedly run the set of tests we have so far. I'm gonna direct Matt here because he knows more about it.

So really the only big change is calculating the stream and background likelihoods separately in addition to the full likelihood. The input to the program is a little different as well (all through the command line and we can specify the name of the input star and parameter file there).

It would be really great if we could get the ATI code merged into the code on github (I think we can do this via OpenCL) so there's one nice place for everyone to work on it.

---

Actually we've been trying to port everything into openCL.

I think OpenCL is really the best option at this point. I'm hoping to work on fixing it later in the summer if I get a chance. I'm working mostly now on getting the N-body stuff into a useful state, and I have lots of reading to do on OpenCL first. It would be great if you want to help work on that.

We've moved the code over to GitHub, and Matt Arsenault has been working on making a nice build system (in cmake) which should make changes and compiling much simpler.

Well, it is a major improvement over the old giant Makefile, but it isn't exactly as nice as it should be yet.

Matt's also been working on a test system, so after cmake has made the makefiles to compile, it can also automatedly run the set of tests we have so far. I'm gonna direct Matt here because he knows more about it.

The tests right now are only semi-useful, but eventually it will be nice.