Posts by Eric Driver

21) Message boards : News : GPU status update (Message 2451) Posted 27 May 2019 by Eric Driver Post: The Nvidia windows version seems to be doing pretty well. Many successful results from multiple users. Only 2 compute errors. I am going on a road trip (vacation) for a week. I will have cell phone coverage, but unable to do any major project maintenance. I will look into the above compute errors when I return. I found the bug that was causing the compute errors. It's minor and affects less than 1% of the WUs. I will get a fix out there later this evening.
22) Message boards : Number crunching : Tasks get ridiculously long (Message 2450) Posted 26 May 2019 by Eric Driver Post: You can blame any credit issues on CreditNew. Credits seem to start higher and then drop off over time as the stats stabilize. There are a mixure of both fast and slow WUs. The slower ones average about 2 hours on a newer 4GHz processor (slower with hyper-threading).
23) Message boards : Number crunching : How do I get WUs (Message 2441) Posted 17 May 2019 by Eric Driver Post: Thanks for telling me that. I will run them when you have them. I would run CPU wus except that I have heat problems that I can't overcome. AT Hiker Another thing to keep in mind is this app requires openCL 1.2, and it looks like your video driver only supports 1.1. You might be able to upgrade the driver.
24) Message boards : News : GPU status update (Message 2440) Posted 17 May 2019 by Eric Driver Post: The Nvidia windows version seems to be doing pretty well. Many successful results from multiple users. Only 2 compute errors. I am going on a road trip (vacation) for a week. I will have cell phone coverage, but unable to do any major project maintenance. I will look into the above compute errors when I return.
25) Message boards : News : GPU status update (Message 2437) Posted 16 May 2019 by Eric Driver Post: Feel free to send me the openCL Windows app via mail. Would like to give it a try. :) I just sent you the AMD version, since I now have confidence in Nvidia version. Thanks!
26) Message boards : News : GPU status update (Message 2436) Posted 16 May 2019 by Eric Driver Post: I just deployed the windows Nvidia version as a beta app. Please test and report any suspicious behavior.
27) Message boards : News : GPU status update (Message 2435) Posted 16 May 2019 by Eric Driver Post: Thanks to the successful testing by Speedy51, I will be able to deploy the Windows Nvidia OpenCL app. I should get to that in the next couple hours. In the meantime, has anyone with an AMD card on linux tried to test that version? I deployed it ~12 hours ago and no tasks have been sent out yet. My own system cant seem to download tasks for it either, so I think something might be wrong with how I setup the plan class.
28) Message boards : News : GPU status update (Message 2434) Posted 16 May 2019 by Eric Driver Post: There must be something different. When using the ROCm driver I can run Einstein@home, but Milkway@home will instantly stop with a computation error. I think the ROCm driver should be preferred since AMD is moving everything to opensource instead using the opencl bits from closed pro driver. I agree. From what I've read ROCm is the way to go. When I get a chance I will look into that again.
29) Message boards : Number crunching : How do I get WUs (Message 2428) Posted 16 May 2019 by Eric Driver Post: Seems like I tried everything but to no avail. Anybody have a clue as to what I need to do to get work units? Thanks AT Hiker Not sure what the problem is, as its working for me. Have you checked your NumberFields@home preferences for selecting which apps to run? I have seen users return after a long time and had the GetDecics box unchecked (probably a holdover from the days of the Bounded app)
30) Message boards : News : GPU status update (Message 2426) Posted 16 May 2019 by Eric Driver Post: How about writing the AMD GPU app so it works with the ROCm opencl driver. The ROCm driver works great for Einstein@home. As far as I know, it has nothing to do with the app. The openCL code works perfectly on Nvidia and with AMD on Ubuntu. I think what you are suggesting is I try the ROCm driver on my Fedora system. I did try that early on with no success, but perhaps I should try again now that I have more experience with video drivers.
31) Message boards : News : GPU status update (Message 2424) Posted 15 May 2019 by Eric Driver Post: It's been over a month since our last update, but I now have some good news. I have made some improvements to the GPU code and am ready to start deploying the new GPU apps. I will start with the AMD OpenCL version for Linux. This will be a beta version. I have had a hell of a time with the AMD implementation of openCL, and this app still doesn't work on my Fedora system, and I believe strongly it's due to the graphics driver. But I have had the help of a volunteer named Wiktor and it runs fine for him (I believe he runs Ubuntu). Please keep in mind that AMD officially only supports RHEL and Ubuntu, so I will be interested to hear if this app works for anyone with an "unsupported" linux distro like myself. I also have openCL Windows apps that were cross compiled using mingW. I have no means of testing these, so I am not ready to deploy them just yet. But if anyone would like to take them for a spin offline, please let me know, and I can send them to you.
32) Message boards : News : Subfield 5 entering final phase (Message 2422) Posted 10 May 2019 by Eric Driver Post: Has the "Estimated computation size" been increased accordingly? Mine still say 1,000 GFLOPS, which is what I remember as it always saying. So I think that I'm downloading more than I should be, given that they now take longer. I believe it only uses that value initially. For a given host, after enough WUs have been processed, it starts using a moving average. Because the runtime went up, the average will lag behind, and in the short term you will download more WUs. Shouldn't take too long to correct. If you have more WUs than you can finish, you can always abort some of them.
33) Message boards : Number crunching : Optimized app available for MacOS (Message 2419) Posted 7 May 2019 by Eric Driver Post: For all mac users - The optimized app is finally available. It requires MacOS 10.13 or higher. It works in my virtual machine, so I believe it is good. But please report any issues.
34) Message boards : News : Subfield 5 entering final phase (Message 2418) Posted 7 May 2019 by Eric Driver Post: I know that i havent been much active here since i am working on my own stuff, but its good to hear that this project is moving forward! Quick heads-up: SF6 will give us (at least) 58M tasks, so there will be work for quite a long time~ (an other heads up: total amount of all workunits from the Decic Search is now at 88,411,891; we are getting closer to 100M. No doubt we are going to get over 100M :D Fun fact, said number is prim. ^^) But I´d like to ask when we will get the remaining Batches from SF3, like 13x270. That could be loaded together with SF6 after SF5 is fully done, or? Actually, I thought we would tackle the rest of SF4 first. It should be quicker than SF3.
35) Message boards : Number crunching : Technical problem with the BOINC executable for NumberFields (Message 2415) Posted 6 May 2019 by Eric Driver Post: Things look good from the server side, meaning you have tasks "in progress". So this seems like a client problem. I have had annoying things in my own client where it wont run the tasks that I expect it to, or that I want it to (I have a test project that I run simultaneously with NumberFields). What works for me is using the client functions for suspending tasks or suspending an entire project. It sounds like your client is running tasks that it feels are higher priority (maybe you have Einstein tasks that are due within a day, and NumberFields tasks aren't due for several days?) A test you could do is to suspend Einstein temporarily to see if the client will even start the NumberFields tasks. That will at least narrow down the problem.
36) Message boards : News : Subfield 5 entering final phase (Message 2411) Posted 4 May 2019 by Eric Driver Post: Subfield 5 is now on it's final batch (16x12). This is the first batch of WUs generated since the app was optimized. As a result, run times will be going up. These WUs average 2 hour run times on my AMD Ryzen 2990WX. Note there are 1.6 million of them; with the unoptimized app it would have required 16 million, so this is a huge improvement. I will be mixing in some subfield 6 WUs with this batch. These were generated a while ago for the unoptimized app, so will run very quickly by comparison. If I were to run them independently, it might put too much of a strain on the server, so I figured this is a good way to get them done (without having to re-generate them which can be tedious).
37) Message boards : News : Septic Results Paper Accepted for Publication (Message 2410) Posted 25 Apr 2019 by Eric Driver Post: Here is the link to the abstract: https://www.sciencedirect.com/science/article/pii/S0022314X19300988 Unless you have academic affiliations, I think they charge for the full paper. I will post the full pdf, but first I need to check if that violates some kind of copyright agreement with the journal. So I am not allowed to post the "official" version of the paper. But I can post an unofficial version. Several things were reworded and some typos were fixed, but otherwise the content is essentially the same.
38) Message boards : News : GPU app status update (Message 2409) Posted 23 Apr 2019 by Eric Driver Post: I just deployed the new cpu apps. Version 3.00. Feel free to abort any WUs associated with the older versions (2.xx). My 32-bit Linux machine is still using version 2.12. Are there plans to release version 3.00 apps for this platform (and 32-bit Windows)? I felt sorry for those poor old 32 bit machines slowly plodding along... so I went ahead and rebuilt the code for them. Version 3.00 is now available for linux-i686 and win32. These are cross-compiles so I cannot extensively test them, so keep an eye on them.
39) Message boards : News : GPU app status update (Message 2408) Posted 22 Apr 2019 by Eric Driver Post: Hi Do you have any plans to update to version 3.00 for computers running Mac? I would like to eventually. I used to have a "hackintosh" VM, but it stopped working. So I first need to get access to a mac (possibly another VM), before I can port the code again.
40) Message boards : News : GPU app status update (Message 2404) Posted 16 Apr 2019 by Eric Driver Post: How did you specialize it? Do you think the technique could be generalized so that more efficient specialized algorithms could be produced for any fixed degree? The first step of the algorithm is to remove the "content" from the polynomial and it's derivative, which means the gcd of all the coefficients. Our polys are monic so the content is 1 and no gcd calculation is necessary. For the derivative, the leading coeff is 10 (i.e. the derivative of x^10 is 10*x^9) so the content will be one of {1,2,5,10}, so we just need to determine if 2 and 5 divide each coeff. This turns out to be much simpler than computing a general gcd of all the coefficients. Since we are only interested in the absolute discriminant, I don't need to keep track of the sign, so that saves on operations. Also, the last part of the test divides out all factors of 2 and 5; and then checks that what remains is a square. This means we don't care about square factors, which allows us to further reduce the number of operations. The final result is not the true discriminant, so this kind of improvement can't be used in a general discriminant algorithm. To answer your question; yes, specialized algorithms could be used for each degree. You could use a switch statement to call the appropriate algorithm. But the general algorithm does have it's advantages, for example the code is much more compact and easier to maintain. And if you are only computing a small number of discriminants, you wouldn't notice the speed difference. It only became an issue here since we are ultimately computing many trillions of them. By the way, I did talk with the folks at PARI. They confirmed their algorithm is more general and designed to be more efficient for higher degrees and coefficients that are much larger.

Previous 20 · Next 20