Posts by Sergei Chernykh

1) Message boards : Number crunching : Maximum Prime Size for Large Prime Workunits (Message 1137) Posted 1 day ago by Sergei Chernykh Post: The largest prime will be 5E18 (1E20 / 20) because numbers of the form N*P where N < 20 and P is prime can't be amicable.
2) Message boards : News : GPU version bugfix release (Message 1126) Posted 8 Apr 2019 by Sergei Chernykh Post: GPU version is limited by CPU now, so it's not correct to compare two powerful GPUs here. You're basically comparing CPUs.
3) Message boards : News : GPU version bugfix release (Message 1122) Posted 8 Apr 2019 by Sergei Chernykh Post: GPU versions for all platforms were updated to fix "Error -58" computation error when resuming stopped task.
4) Message boards : Bug tracker : Computation Error Upon Suspension and Resumption of GPU WU (Message 1121) Posted 8 Apr 2019 by Sergei Chernykh Post: Yes, I fixed it a few minutes ago: https://github.com/SChernykh/Amicable/commit/806085804dc51e48aef2527cd18861ad3a986bc0 I'll update GPU versions today.
5) Message boards : Number crunching : Computation error (Message 1119) Posted 8 Apr 2019 by Sergei Chernykh Post: It looks like I fixed this error: https://github.com/SChernykh/Amicable/commit/806085804dc51e48aef2527cd18861ad3a986bc0 I'll test it some more and update GPU versions today.
6) Message boards : Number crunching : Computation error (Message 1110) Posted 1 Apr 2019 by Sergei Chernykh Post: I don't really know what causes error -58 (CL_INVALID_EVENT). It's triggered at this line: https://github.com/SChernykh/Amicable/blob/boinc-opencl-version-128-bit/Amicable/OpenCL.cpp#L1017 - but it's always set properly in the preceding call to clEnqueueNDRangeKernel on the last iteration of "for" loop. My guess is that OpenCL driver runs out of resources occasionally.
7) Message boards : Number crunching : Computation error (Message 1099) Posted 26 Feb 2019 by Sergei Chernykh Post: clEnqueueWriteBuffer returned error -5 This is CL_OUT_OF_RESOURCES error. Try to reduce kernel size in computing preferences: https://sech.me/boinc/Amicable/prefs.php?subset=project
8) Message boards : Number crunching : Computers list is gone? (Message 1096) Posted 22 Feb 2019 by Sergei Chernykh Post: You didn't lose credit, it's saved separately in your user account.
9) Message boards : Number crunching : GPU Utilization (Message 1086) Posted 17 Feb 2019 by Sergei Chernykh Post: Reduce kernel size, run as many WUs per GPU as possible. 8 WUs per GPU should be good enough to load it.
10) Message boards : Number crunching : Computing Preferences (Message 1068) Posted 21 Jan 2019 by Sergei Chernykh Post: I changed nothing server-side recently. Option to not use CPUs should be available on preferences page: https://sech.me/boinc/Amicable/prefs.php?subset=project
11) Message boards : Random stuff : Project Status Page (Message 1066) Posted 21 Jan 2019 by Sergei Chernykh Post: Both CPUs are still in that list. 15 Reference CPU: Intel Core i7-5960X (8 cores, 16 threads, 3.0 - 3.5 GHz) 1.236 2,537.0 73 Reference CPU: Intel Core i7-4770K (4 cores, 8 threads, 3.9 GHz) 0.577 5,435.7
12) Message boards : Number crunching : Why are the RTX Graphics Cards now really Poor at running this Project. (Message 1063) Posted 19 Jan 2019 by Sergei Chernykh Post: Why are the tasks not just ran on the CPUs? Because they are GPU tasks? The actual search is still done on GPU, it just needs a list of prime numbers in given interval to proceed, and this is done on CPU.
13) Message boards : Number crunching : Why are the RTX Graphics Cards now really Poor at running this Project. (Message 1060) Posted 18 Jan 2019 by Sergei Chernykh Post: The bottleneck is prime sieving at this stage because it's done on CPU. The only solution is to run as many tasks per GPU as possible - reduce kernel size to fit more tasks.
14) Message boards : Bug tracker : GTX 465? (Message 1049) Posted 2 Jan 2019 by Sergei Chernykh Post: CL_DEVICE_MAX_MEM_ALLOC_SIZE is less than 256 MB Your GPU drivers can't allocate 256 MB of memory for OpenCL applications in one go, so Amicable Numbers can't run.
15) Message boards : Number crunching : GPU version requirements for the search up to 10^20 (Message 1048) Posted 2 Jan 2019 by Sergei Chernykh Post: It was done. Current requirement is 800 MB GPU memory to run a task.
16) Message boards : Number crunching : Amicable Numbers has slowed down (Message 1014) Posted 9 Dec 2018 by Sergei Chernykh Post: I checked "good" and "bad" WUs in profiler, and got this for "good" WU: InitialCheck128() = 22.36% of execution time CheckPairInternal() = 72.05% of execution time and this for "bad" WU: InitialCheck128() = 83.53% of execution time CheckPairInternal() = 15.37% of execution time It looks like some number ranges require much more time to switch from slow 128-bit trial divisions to fast 64-bit code. There is nothing wrong with the code itself, it's just my assumption that all "large prime" ranges are the same turned out to be wrong. What's interesting is that OpenCL version doesn't suffer from this problem - probably because they're 32-bit natively and difference between 64 and 128-bit code is much smaller there.
17) Message boards : News : The search up to 10^20 (Message 1008) Posted 2 Dec 2018 by Sergei Chernykh Post: I think it makes sense now to start the search up to 10²¹ once current search completes. We can start it from "rich" ranges of numbers and find 2-3 millions new amicable pairs within first year, according to my estimations.
18) Message boards : Number crunching : Countermeasures for Increased CPU Time (Message 1003) Posted 27 Nov 2018 by Sergei Chernykh Post: i see increasing gpu memory use to 3900-4000 mb And gpu load fall litle bit to 85-90% always on kernel 23 Don't use kernel size 23 with multiple tasks, kernel size=21 will do just fine. Memory usage shouldn't be increasing at this stage of the search, it mainly depends on kernel size you select.
19) Message boards : Number crunching : Amicable Numbers has slowed down (Message 973) Posted 2 Nov 2018 by Sergei Chernykh Post: All CPU tasks should be balanced to roughly the same execution time, they were generated with primesieve performance taken into account. it's only OpenCL version that will slowdown eventually.
20) Message boards : Bug tracker : Amicable Jobs not throttled? (Message 971) Posted 2 Nov 2018 by Sergei Chernykh Post: There was a rare random bug (validation errors) that disappeared when I turned off throttling for CPU tasks. I'll double check it when I prepare new app versions with updated primesieve this month.
21) Message boards : Number crunching : Amicable Numbers has slowed down (Message 970) Posted 2 Nov 2018 by Sergei Chernykh Post: Oh my... I guess I'll need to update primesieve in all versions soon. This month probably because it's also used in OpenCL versions and will become a bottleneck as numbers grow larger.
22) Message boards : Number crunching : Amicable Numbers has slowed down (Message 964) Posted 1 Nov 2018 by Sergei Chernykh Post: My only guess is as numbers grow larger, internal buffers don't fit in CPU cache anymore. Hence the slowdown.
23) Message boards : Number crunching : Problem with valid wus count on All Tasks page? (Message 958) Posted 30 Oct 2018 by Sergei Chernykh Post: Old WUs get deleted 1 week after they are verified.
24) Message boards : Number crunching : Probability (Message 955) Posted 29 Oct 2018 by Sergei Chernykh Post: This page shows it: https://sech.me/boinc/Amicable/server_status.php ETA at current speed (search up to 10²⁰) Mar 2019
25) Message boards : Number crunching : Probability (Message 953) Posted 28 Oct 2018 by Sergei Chernykh Post: There are 4,197,265 known amicable pairs below 10²⁰ or approximately 1 pair per 23.825*10¹² numbers. So the probability is low, very low if you just check numbers one by one. If you search them in more clever order, it can be much higher for some ranges. This project was founding thousands pairs per day at some stage, but now it's chewing through last ranges which are unlikely to have new pairs.
26) Message boards : Number crunching : Work unit errors (Message 943) Posted 4 Oct 2018 by Sergei Chernykh Post: It can happen if: - this is an old work unit which expired for someone else - then it was sent to you - then this "someone else" finally sends it to the server - the server validates it and cancels all remaining "in progress" tasks (including yours) P.S. But your 3 errors are just computing errors, they didn't happen immediately after start.
27) Message boards : Number crunching : Work unit errors (Message 941) Posted 4 Oct 2018 by Sergei Chernykh Post: I see only 3 errors out of 925 work units for your PC. Time limit for work unit is 3 days from the time it was sent to client.
28) Message boards : Number crunching : GPU version: kernel size tuning and less UI lags (Message 934) Posted 29 Sep 2018 by Sergei Chernykh Post: From what I heard, RTX series has separate integer and FP units, and this project is integer only. This is probably why RTX gets such boost.
29) Message boards : Number crunching : Calculations made (Message 928) Posted 24 Sep 2018 by Sergei Chernykh Post: Calculations here are integer only, so no flops. One work unit runs in ~40 minutes on Ryzen 7 1700 @ 3.6 GHz as far as I remember, so it translates to ~7*10¹³ integer operations. You can take it as 1 task = 70,000 GFLOP in your terms.
30) Message boards : Number crunching : Calculations made (Message 925) Posted 24 Sep 2018 by Sergei Chernykh Post: Divide your total credit by 6836.19: 1968824 / 6834.19 = 288 tasks completed so far.
31) Message boards : Number crunching : All work is ending in Error (Message 919) Posted 17 Sep 2018 by Sergei Chernykh Post: Try to reduce "Kernel size for NVIDIA GPU", 23 might be too high.
32) Message boards : Number crunching : All work is ending in Error (Message 916) Posted 13 Sep 2018 by Sergei Chernykh Post: It looks like it's fixed now. New GPU versions didn't give any errors so far, and almost 100 WUs are already finished.
33) Message boards : Number crunching : All work is ending in Error (Message 915) Posted 13 Sep 2018 by Sergei Chernykh Post: I've updated Windows & Linux OpenCL versions, can you check that they run fine? MacOS version will follow soon. P.S. MacOS OpenCL version is now updated.
34) Message boards : Number crunching : All work is ending in Error (Message 913) Posted 13 Sep 2018 by Sergei Chernykh Post: Sorry, will fix it ASAP.
35) Message boards : Number crunching : All work is ending in Error (Message 908) Posted 12 Sep 2018 by Sergei Chernykh Post: It's fixed now.
36) Message boards : Number crunching : All work is ending in Error (Message 907) Posted 12 Sep 2018 by Sergei Chernykh Post: I've found the bug, will update CPU version later today.
37) Message boards : Number crunching : All work is ending in Error (Message 906) Posted 12 Sep 2018 by Sergei Chernykh Post: I can confirm it started crashing on latest work units, but I don't know why yet. I'll try to fix it today.
38) Message boards : Number crunching : GPU - Double Precision? (Message 903) Posted 10 Sep 2018 by Sergei Chernykh Post: It's more than 3-4x because you need to: 1) Do 4 multiplications 2) Add 4 results together, doing 3 64-bit additions In total, it translates to ~12 low level 32-bit operations. I tried it before, it doesn't improve speed.
39) Message boards : Number crunching : GPU - Double Precision? (Message 901) Posted 10 Sep 2018 by Sergei Chernykh Post: It doesn't make sense to rewrite 64-bit multiplication as 4 32-bit multiplications because this is what OpenCL compiler already does for GPUs with weak FP double performance.
40) Message boards : Number crunching : GPU - Double Precision? (Message 899) Posted 10 Sep 2018 by Sergei Chernykh Post: They're not vectorizable - the algorithm requires 64x64 bit multiplications. But if you can optimize this GPU code, do a pull request.
41) Message boards : Number crunching : GPU - Double Precision? (Message 897) Posted 10 Sep 2018 by Sergei Chernykh Post: You can look at the GPU code here: https://github.com/SChernykh/Amicable/blob/boinc-opencl-version-128-bit/Amicable/kernel.cl It uses 64-bit integer arithmetic which is kind of equivalent to FP double arithmetic when it comes to performance. Yes, GPUs with a lot of double GFlops capability will be much faster.
42) Message boards : Bug tracker : Validation not working? (Message 893) Posted 8 Sep 2018 by Sergei Chernykh Post: "Workunits waiting for validation 1385" The server is clogged now because amicable pairs cache backend crashed yesterday and it's reloading all data from disk now (> 700 GB of data). The issue should resolve itself as soon as cache is fully loaded. It's still about 12 hours to go.
43) Message boards : Random stuff : Cross-Project stats page broken. :( (Message 890) Posted 29 Aug 2018 by Sergei Chernykh Post: Well, the page is broken because http://boinc.netsoft-online.com returns error 403 when the server asks it for data.
44) Message boards : Random stuff : Cross-Project stats page broken. :( (Message 888) Posted 26 Aug 2018 by Sergei Chernykh Post: There are no http links on that page, background picture is also https. I'll look into the bug itself tomorrow.
45) Message boards : Bug tracker : Amicable doesn't respect usage limits (Message 884) Posted 3 Aug 2018 by Sergei Chernykh Post: Don't mix Tmax and Tjmax. Tjmax for i7 2600k is 100C. It starts throttling at 90C. 75C is totally safe. If your processor reports 75C, it's a temperature of its internal sensor, temperature at the heat spreader (which must not be higher than Tmax) will be much less than 75C.
46) Message boards : Bug tracker : Amicable doesn't respect usage limits (Message 882) Posted 31 Jul 2018 by Sergei Chernykh Post: 75°C is normal temperature for CPU, nothing bad will happen to it. Amicable runs at the lowest possible priority, so even if it uses all cores, the system should be responsive.
47) Message boards : Bug tracker : Amicable doesn't respect usage limits (Message 880) Posted 28 Jul 2018 by Sergei Chernykh Post: This was already answered in the second post of this thread. CPU time limitation done by BOINC doesn't work well with Amicable, there was a lot of invalid results.
48) Message boards : Bug tracker : Amicable doesn't respect usage limits (Message 878) Posted 26 Jul 2018 by Sergei Chernykh Post: You have 4 cores per WU, but you also need to set "Max # jobs" to 1. Otherwise BOINC will start 2 WUs that will take all 8 cores. P.S. Your CPU shouldn't overheat when running Amicable even at 100% on all cores. It doesn't even use SSE, it's only integer math on Amicable. Check your CPU cooler.
49) Message boards : Bug tracker : Amicable doesn't respect usage limits (Message 876) Posted 26 Jul 2018 by Sergei Chernykh Post: If I reduce the available core, it crash. This crash is fixed already, try again.
50) Message boards : Bug tracker : All CPU WU finished in error !!! (Message 874) Posted 24 Jul 2018 by Sergei Chernykh Post: All CPU versions have been updated.

Next 50