|
[QUOTE=kriesel;494138]Apparently -tf 0 will do nothing for a worktodo record that's only the exponent value, or maybe for an exponent already under way in primality testing.
[/QUOTE] TF needs a starting bit-level information. This starting point is contained in the PRP or TF task line. If the PRP is just a single exponent, without the "factored up to" information, then TF doesn't know where to start and thus does not attempt TF. So just add a starting bit-level, like so if you don't have AID: PRP=N/A,1,2,332345953,-1,79,0,3, I could also add a simple syntax for just exponent+bitlevel, if there's such a need; e.g.: 332345953,79 |
terminate rather than continue after completing primality test
[QUOTE=preda;494107]Thanks for reminding me -- somehow I forgot about this issue. But now it should be fixed, please re-checkout the latest commit. And the other compilation issue too.[/QUOTE]
Now on Windows it terminates on completion of the first worktodo entry, after creating a worktodo-tmp.tmp, but that still has the completed exponent in it just like worktodo.txt during the run did and still does after the exponent completes. There are no entries in the event logs to indicate a permissions problem. Removing the tmp.tmp file and retrying reliably produces the error quickly (100% of attempts). [CODE]"gerbicz":0}} 2018-08-19 10:00:07 condorella-rx480 Bye C:\msys64\home\ken\v38test>g38 C:\msys64\home\ken\v38test>openowl-V38-3aa5452-W64.exe -user kriesel -cpu condorella-rx480 -device 0 2018-08-19 10:03:38 condorella-rx480 gpuowl-OpenCL 3.8-3aa5452 2018-08-19 10:03:38 condorella-rx480 FFT 2560K: Width 512 (64x8), Height 512 (64x8), Middle 5; 18.50 bits/word 2018-08-19 10:03:38 condorella-rx480 Note: using short carry kernels 2018-08-19 10:03:39 condorella-rx480 Ellesmere-36x1266-@28:0.0 Radeon (TM) RX 480 Graphics 2018-08-19 10:03:43 condorella-rx480 OpenCL compilation in 4196 ms, with "-DEXP=48500017u -DWIDTH=512u -DSMALL_HEIGHT=512u -DMIDDLE=5u -I. -cl-fast-relaxed-mat h -cl-std=CL2.0 " 2018-08-19 10:03:44 condorella-rx480 PRP M(48500017), FFT 2560K, 18.50 bits/word 2018-08-19 10:03:46 condorella-rx480 OK loaded: 48481600/48500017, blockSize 400, 7e6ff6da93febba7 2018-08-19 10:03:47 condorella-rx480 OK initial check: 7e6ff6da93febba7 2018-08-19 10:03:50 condorella-rx480 OK 48482400/48500017 [99.96%], 2.20 ms/it [2.18, 2.22]; ETA 0d 00:01; 07f85c06a544623a (check 1.23s) (saved) 2018-08-19 10:04:07 condorella-rx480 48490000/48500017 [99.98%], 2.21 ms/it [2.18, 2.23]; ETA 0d 00:00; 2c692e47de442145 2018-08-19 10:04:29 condorella-rx480 48500000/48500017 [100.00%], 2.21 ms/it [2.18, 2.23]; ETA 0d 00:00; ae8d3d8692744ce6 2018-08-19 10:04:29 condorella-rx480 CC 48500017 / 48500017, a55622cc6528af94 (raw d007392f8e6e2c3b) 2018-08-19 10:04:31 condorella-rx480 OK 48500400/48500017 [100.00%], 2.69 ms/it [2.69, 2.69]; ETA 0d 00:00; 4c12eee68f51ddbf (check 0.92s) 2018-08-19 10:04:31 condorella-rx480 {"exponent":48500017, "worktype":"PRP-3", "status":"C", "program":{"name":"gpuowl", "version":"3.8-3aa5452-OpenCL"}, "times tamp":"2018-08-19 15:04:31 UTC", "user":"kriesel", "computer":"condorella-rx480", "residue-type":1, "fft-length":"2560K", "res64":(masked by me)", "errors":{ "gerbicz":0}} 2018-08-19 10:04:31 condorella-rx480 Bye C:\msys64\home\ken\v38test>[/CODE][CODE]C:\msys64\home\ken\v38test>dir work* Volume in drive C has no label. Volume Serial Number is 3E40-A384 Directory of C:\msys64\home\ken\v38test 08/19/2018 10:04 AM 49 worktodo-tmp.tmp 08/17/2018 05:42 PM 2,230 worktodo.h 08/18/2018 02:35 AM 49 worktodo.txt[/CODE]worktodo-tmp.tmp incorrectly contains the completed exponent. [CODE]48500017 87000833 PRP=0,1,2,376059389,-1,81,2 [/CODE]We need something like copy worktodo.txt worktodo-tmp.tmp except omit first line (completed exponent) entirely for primality completion case (Dunno if tf completion should also update tf status, I assume so) delete worktodo.txt rename worktodo-tmp.tmp worktodo.txt resume work from new worktodo.txt first entry What I'm seeing is the sequence copy worktodo.txt worktodo-tmp.tmp unchanged duplicate no update of worktodo.txt or date/time stamp change (first completion was~4:55am) repeat first worktodo item from last save point to completion again display and log result program does orderly termination with message Bye (why?) As a test I modified worktodo.txt from bare exponent to PRP= format for the first entry and retried. Same outcome. [CODE]PRP=0,1,2,48500017,-1,74,2 87000833 PRP=0,1,2,376059389,-1,81,2 [/CODE] worktodo-tmp.tmp is the same 67 byte count as worktodo.txt after the program repeats the last few iterations of 48500017 again and terminates with Bye. Also, wondered about my use of 0 AID versus N/A, so did a quick test: [CODE]C:\msys64\home\ken\v38test>g38 C:\msys64\home\ken\v38test>openowl-V38-3aa5452-W64.exe -user kriesel -cpu condorella-rx480 -device 0 2018-08-19 10:51:33 condorella-rx480 gpuowl-OpenCL 3.8-3aa5452 2018-08-19 10:51:33 condorella-rx480 worktodo.txt: "PRP=N/A,1,2,48500017,-1,74,2" [U][B]ignored[/B][/U] 2018-08-19 10:51:33 condorella-rx480 FFT 4608K: Width 512 (64x8), Height 512 (64x8), Middle 9; 18.44 bits/word 2018-08-19 10:51:33 condorella-rx480 Note: using short carry kernels 2018-08-19 10:51:34 condorella-rx480 Ellesmere-36x1266-@28:0.0 Radeon (TM) RX 480 Graphics 2018-08-19 10:51:38 condorella-rx480 OpenCL compilation in 4305 ms, with "-DEXP=87000833u -DWIDTH=512u -DSMALL_HEIGHT=512u -DMIDDLE=9u -I. -cl-fast-relaxed-mat h -cl-std=CL2.0 " 2018-08-19 10:51:39 condorella-rx480 PRP M(87000833), FFT 4608K, 18.44 bits/word 2018-08-19 10:51:43 condorella-rx480 OK loaded: 227200/87000833, blockSize 400, 1bcb19cdba66ca70 2018-08-19 10:51:45 condorella-rx480 OK initial check: 1bcb19cdba66ca70 2018-08-19 10:51:50 condorella-rx480 OK 228000/87000833 [ 0.26%], 3.82 ms/it [3.82, 3.82]; ETA 3d 20:05; 973e1b2a77f21360 (check 2.11s); (4 errors) (saved) 2018-08-19 10:51:58 condorella-rx480 230000/87000833 [ 0.26%], 3.82 ms/it [3.82, 3.82]; ETA 3d 20:04; 3f15bb81c3c99f8e 2018-08-19 10:52:36 condorella-rx480 240000/87000833 [ 0.28%], 3.85 ms/it [3.82, 3.88]; ETA 3d 20:45; 1e36ea09984d9e20 [/CODE]I use a little batch file rather than the command line, for consistency and convenience. As I recall, on Windows, permissions can differ, between interactive launch and run of a batch file, and interactive at the command line. But a quick test at the command line interactively after modifying the worktodo.txt back to 0 AID for the first line rules that out as a cause. It also seems inconsistent with the program's orderly exit with message Bye. |
same on v38-5d10342
[QUOTE=kriesel;494213]Now on Windows it terminates on completion of the first worktodo entry, after creating a worktodo-tmp.tmp, but that still has the completed exponent in it just like worktodo.txt during the run did and still does after the exponent completes. There are no entries in the event logs to indicate a permissions problem. Removing the tmp.tmp file and retrying reliably produces the error quickly (100% of attempts).
[CODE]"gerbicz":0}} 2018-08-19 10:00:07 condorella-rx480 Bye C:\msys64\home\ken\v38test>g38 C:\msys64\home\ken\v38test>openowl-V38-3aa5452-W64.exe -user kriesel -cpu condorella-rx480 -device 0 2018-08-19 10:03:38 condorella-rx480 gpuowl-OpenCL 3.8-3aa5452 2018-08-19 10:03:38 condorella-rx480 FFT 2560K: Width 512 (64x8), Height 512 (64x8), Middle 5; 18.50 bits/word 2018-08-19 10:03:38 condorella-rx480 Note: using short carry kernels 2018-08-19 10:03:39 condorella-rx480 Ellesmere-36x1266-@28:0.0 Radeon (TM) RX 480 Graphics 2018-08-19 10:03:43 condorella-rx480 OpenCL compilation in 4196 ms, with "-DEXP=48500017u -DWIDTH=512u -DSMALL_HEIGHT=512u -DMIDDLE=5u -I. -cl-fast-relaxed-mat h -cl-std=CL2.0 " 2018-08-19 10:03:44 condorella-rx480 PRP M(48500017), FFT 2560K, 18.50 bits/word 2018-08-19 10:03:46 condorella-rx480 OK loaded: 48481600/48500017, blockSize 400, 7e6ff6da93febba7 2018-08-19 10:03:47 condorella-rx480 OK initial check: 7e6ff6da93febba7 2018-08-19 10:03:50 condorella-rx480 OK 48482400/48500017 [99.96%], 2.20 ms/it [2.18, 2.22]; ETA 0d 00:01; 07f85c06a544623a (check 1.23s) (saved) 2018-08-19 10:04:07 condorella-rx480 48490000/48500017 [99.98%], 2.21 ms/it [2.18, 2.23]; ETA 0d 00:00; 2c692e47de442145 2018-08-19 10:04:29 condorella-rx480 48500000/48500017 [100.00%], 2.21 ms/it [2.18, 2.23]; ETA 0d 00:00; ae8d3d8692744ce6 2018-08-19 10:04:29 condorella-rx480 CC 48500017 / 48500017, a55622cc6528af94 (raw d007392f8e6e2c3b) 2018-08-19 10:04:31 condorella-rx480 OK 48500400/48500017 [100.00%], 2.69 ms/it [2.69, 2.69]; ETA 0d 00:00; 4c12eee68f51ddbf (check 0.92s) 2018-08-19 10:04:31 condorella-rx480 {"exponent":48500017, "worktype":"PRP-3", "status":"C", "program":{"name":"gpuowl", "version":"3.8-3aa5452-OpenCL"}, "times tamp":"2018-08-19 15:04:31 UTC", "user":"kriesel", "computer":"condorella-rx480", "residue-type":1, "fft-length":"2560K", "res64":(masked by me)", "errors":{ "gerbicz":0}} 2018-08-19 10:04:31 condorella-rx480 Bye C:\msys64\home\ken\v38test>[/CODE][CODE]C:\msys64\home\ken\v38test>dir work* Volume in drive C has no label. Volume Serial Number is 3E40-A384 Directory of C:\msys64\home\ken\v38test 08/19/2018 10:04 AM 49 worktodo-tmp.tmp 08/17/2018 05:42 PM 2,230 worktodo.h 08/18/2018 02:35 AM 49 worktodo.txt[/CODE]worktodo-tmp.tmp incorrectly contains the completed exponent. [CODE]48500017 87000833 PRP=0,1,2,376059389,-1,81,2 [/CODE]We need something like copy worktodo.txt worktodo-tmp.tmp except omit first line (completed exponent) entirely for primality completion case (Dunno if tf completion should also update tf status, I assume so) delete worktodo.txt rename worktodo-tmp.tmp worktodo.txt resume work from new worktodo.txt first entry What I'm seeing is the sequence copy worktodo.txt worktodo-tmp.tmp unchanged duplicate no update of worktodo.txt or date/time stamp change (first completion was~4:55am) repeat first worktodo item from last save point to completion again display and log result program does orderly termination with message Bye (why?) As a test I modified worktodo.txt from bare exponent to PRP= format for the first entry and retried. Same outcome. [CODE]PRP=0,1,2,48500017,-1,74,2 87000833 PRP=0,1,2,376059389,-1,81,2 [/CODE] worktodo-tmp.tmp is the same 67 byte count as worktodo.txt after the program repeats the last few iterations of 48500017 again and terminates with Bye. Also, wondered about my use of 0 AID versus N/A, so did a quick test: [CODE]C:\msys64\home\ken\v38test>g38 C:\msys64\home\ken\v38test>openowl-V38-3aa5452-W64.exe -user kriesel -cpu condorella-rx480 -device 0 2018-08-19 10:51:33 condorella-rx480 gpuowl-OpenCL 3.8-3aa5452 2018-08-19 10:51:33 condorella-rx480 worktodo.txt: "PRP=N/A,1,2,48500017,-1,74,2" [U][B]ignored[/B][/U] 2018-08-19 10:51:33 condorella-rx480 FFT 4608K: Width 512 (64x8), Height 512 (64x8), Middle 9; 18.44 bits/word 2018-08-19 10:51:33 condorella-rx480 Note: using short carry kernels 2018-08-19 10:51:34 condorella-rx480 Ellesmere-36x1266-@28:0.0 Radeon (TM) RX 480 Graphics 2018-08-19 10:51:38 condorella-rx480 OpenCL compilation in 4305 ms, with "-DEXP=87000833u -DWIDTH=512u -DSMALL_HEIGHT=512u -DMIDDLE=9u -I. -cl-fast-relaxed-mat h -cl-std=CL2.0 " 2018-08-19 10:51:39 condorella-rx480 PRP M(87000833), FFT 4608K, 18.44 bits/word 2018-08-19 10:51:43 condorella-rx480 OK loaded: 227200/87000833, blockSize 400, 1bcb19cdba66ca70 2018-08-19 10:51:45 condorella-rx480 OK initial check: 1bcb19cdba66ca70 2018-08-19 10:51:50 condorella-rx480 OK 228000/87000833 [ 0.26%], 3.82 ms/it [3.82, 3.82]; ETA 3d 20:05; 973e1b2a77f21360 (check 2.11s); (4 errors) (saved) 2018-08-19 10:51:58 condorella-rx480 230000/87000833 [ 0.26%], 3.82 ms/it [3.82, 3.82]; ETA 3d 20:04; 3f15bb81c3c99f8e 2018-08-19 10:52:36 condorella-rx480 240000/87000833 [ 0.28%], 3.85 ms/it [3.82, 3.88]; ETA 3d 20:45; 1e36ea09984d9e20 [/CODE]I use a little batch file rather than the command line, for consistency and convenience. As I recall, on Windows, permissions can differ, between interactive launch and run of a batch file, and interactive at the command line. But a quick test at the command line interactively after modifying the worktodo.txt back to 0 AID for the first line rules that out as a cause. It also seems inconsistent with the program's orderly exit with message Bye.[/QUOTE] Exponent completes, worktodo-tmp.tmp created, worktodo.txt not updated. Bye. |
cudaowl build no joy yet
[QUOTE=preda;494196]I fixed those concerned with "uint". OTOH I don't have an easy fix the u128 one -- I do use the 128-bit integer in the host code.
I added a couple of alternative definitions in common.h [CODE]// try one of these for a 128bit integer. typedef unsigned __int128 u128; // typedef uint128_t u128; // typedef __uint128_t u128; [/CODE]If at least one of those is supported by the compiler.. -- otherwise, I don't have a simple solution.[/QUOTE] as above:[CODE]C:\users\ken\documents\gpuowl-cuda-build>nvcc -O2 -DREV=\"5d10342\" -o cudaowl-V 38-5d10342-W64.exe CudaGpu.cu Gpu.cpp common.cpp gpuowl.cpp -lcufft CudaGpu.cu c:\users\ken\documents\gpuowl-cuda-build\common.h(16): error: expected a ";" c:\users\ken\documents\gpuowl-cuda-build\LowGpu.h(53): error: identifier "u128" is undefined c:\users\ken\documents\gpuowl-cuda-build\LowGpu.h(60): error: identifier "u128" is undefined detected during instantiation of "<error-type> LowGpu<Buffer>::residue FromRaw(const std::vector<int, std::allocator<int>> &, int) [with Buffer=int *]" c:\users\ken\documents\gpuowl-cuda-build\CudaGpu.h(379): here c:\users\ken\documents\gpuowl-cuda-build\LowGpu.h(68): error: identifier "u128" is undefined detected during instantiation of "<error-type> LowGpu<Buffer>::residue FromRaw(const std::vector<int, std::allocator<int>> &, int) [with Buffer=int *]" c:\users\ken\documents\gpuowl-cuda-build\CudaGpu.h(379): here 4 errors detected in the compilation of "C:/Users/Ken/AppData/Local/Temp/tmpxft_ 00003db0_00000000-12_CudaGpu.cpp1.ii".[/CODE]Next, for [CODE]// try one of these for a 128bit integer. //typedef unsigned __int128 u128; typedef uint128_t u128; // typedef __uint128_t u128; [/CODE]I get [CODE]C:\users\ken\documents\gpuowl-cuda-build>nvcc -O2 -DREV=\"5d10342\" -o cudaowl-V 38-5d10342-W64.exe CudaGpu.cu Gpu.cpp common.cpp gpuowl.cpp -lcufft CudaGpu.cu c:\users\ken\documents\gpuowl-cuda-build\common.h(17): error: identifier "uint12 8_t" is undefined 1 error detected in the compilation of "C:/Users/Ken/AppData/Local/Temp/tmpxft_0 0003634_00000000-12_CudaGpu.cpp1.ii".[/CODE]Next, for [CODE]// try one of these for a 128bit integer. //typedef unsigned __int128 u128; //typedef uint128_t u128; typedef __uint128_t u128; [/CODE]I get [CODE]C:\users\ken\documents\gpuowl-cuda-build>nvcc -O2 -DREV=\"5d10342\" -o cudaowl-V 38-5d10342-W64.exe CudaGpu.cu Gpu.cpp common.cpp gpuowl.cpp -lcufft CudaGpu.cu c:\users\ken\documents\gpuowl-cuda-build\common.h(18): error: identifier "__uint 128_t" is undefined 1 error detected in the compilation of "C:/Users/Ken/AppData/Local/Temp/tmpxft_0 0003d84_00000000-12_CudaGpu.cpp1.ii".[/CODE] nvcc is a recent install from NVIDIA toolkit 9.2.1248. It's using MS Visual Studio 2017 Community Edition (15.8)'s cl.exe. So both appear to be the latest available. CL.exe identifies itself as Microsoft (R) C/C++ Optimizing Compiler Version 19.15.26726 for x64. The IDE displays v15.8.0. [CODE]C:\users\ken\documents\gpuowl-cuda-build>nvcc -V nvcc: NVIDIA (R) Cuda compiler driver Copyright (c) 2005-2018 NVIDIA Corporation Built on Tue_Jun_12_23:08:12_Central_Daylight_Time_2018 Cuda compilation tools, release 9.2, V9.2.148[/CODE]Visual Studio check for updates takes a while, then indicates there's an 83MB update to 15.8.1 available, for which the release notes describe a completely different issue. Apply it anyway. [URL]https://docs.microsoft.com/en-us/visualstudio/releasenotes/vs2017-relnotes#15.8.1[/URL] Same results as above, all 3 typedef cases. |
uint128, __ etc
[QUOTE=preda;494196]I fixed those concerned with "uint". OTOH I don't have an easy fix the u128 one -- I do use the 128-bit integer in the host code.
I added a couple of alternative definitions in common.h [CODE]// try one of these for a 128bit integer. typedef unsigned __int128 u128; // typedef uint128_t u128; // typedef __uint128_t u128; [/CODE]If at least one of those is supported by the compiler.. -- otherwise, I don't have a simple solution.[/QUOTE] At [URL]https://stackoverflow.com/questions/6759592/how-to-enable-int128-on-visual-studio#6761962[/URL] it says int128 and __int128 are not supported in MS VS. (So presumably neither are uint128, __uint128.) It's kind of strange; I remember using single, double, and quad precision in VAX VMS Fortran decades ago, computing hyperbolic tangents for xray lithography mask out of plane distortions. It's not like int128 is new. And one of the initially hidden comments indicates LLVM might help. Whether I can get it set up right and nvcc and VS and LLVM will all get along is another question. [URL]https://llvm.org/builds/[/URL] If there was a no-TF branch with the uint fix on your git repository, that would be another approach. No TF, no uint128 to exceed what's supported by MS VS. |
[QUOTE=kriesel;494219]Exponent completes, worktodo-tmp.tmp created, worktodo.txt not updated. Bye.[/QUOTE]
Please try again with a fresh checkout. This is what was happening: after completing the task, the program attempts to find the task line to delete from worktodo.txt. If it doesn't find the line, it exits. Now I added explicit log about this situation (so it will be clear if it occurs), also attempted a fix. |
[QUOTE=kriesel;494243]
If there was a no-TF branch with the uint fix on your git repository, that would be another approach. No TF, no uint128 to exceed what's supported by MS VS.[/QUOTE] u128 is used right now in LowGpu.h, which is a class involved in PRP not TF. (TF is anyway "empty" on CUDA). So the 128-bit was not introduced by TF, it was there before. I'm investigating working around it. |
[QUOTE=preda;494251]u128 is used right now in LowGpu.h, which is a class involved in PRP not TF. (TF is anyway "empty" on CUDA). So the 128-bit was not introduced by TF, it was there before. I'm investigating working around it.[/QUOTE]
OK, I got rid (I hope) of u128 in the PRP code. The CUDA compilation (which doesn't have TF) should not require u128 at all now. On the OpenCL side, there is a new makefile target "openowl-notf" which builds openowl with the TF disabled and without u128. |
GHz-days/day on Vega64
I recently added GHz-days/day display to GpuOwl. On my Vega64:
PRP: 160 GHz-days/day, TF: 1300 GHz-days/day. [CODE] 2018-08-20 14:15:43 vega0 10440000/332345953 [ 3.14%], 7.91 ms/it [7.91, 7.92] (162.4 GHz-day/day); ETA 29d 11:43; c3ac31e63e4e396b 2018-08-20 14:17:03 vega0 10450000/332345953 [ 3.14%], 7.91 ms/it [7.91, 7.92] (162.4 GHz-day/day); ETA 29d 11:42; b29119a93473260c 2018-08-20 14:37:40 vega0 TF 332345953 80-81 0.03%, class 2 ( 11), 4.212s (1312 GHz), ETA 0d 13:28, FCs 5809428287 (19.1839%) 2018-08-20 14:37:44 vega0 TF 332345953 80-81 0.03%, class 3 ( 15), 4.215s (1311 GHz), ETA 0d 13:29, FCs 5809404755 (19.1838%) [/CODE] The power draw of the GPU is under 220W. |
gpuOwL-openCL V3.8-91c52fa build for Win x64
[QUOTE=preda;494249]Please try again with a fresh checkout.
This is what was happening: after completing the task, the program attempts to find the task line to delete from worktodo.txt. If it doesn't find the line, it exits. Now I added explicit log about this situation (so it will be clear if it occurs), also attempted a fix.[/QUOTE] That seems to have done it; finished the 48.5M (again) and progressed to the next work this time. [CODE]g++ -DREV=\"91c52fa\" -O2 -c gpuowl.cpp -o gpuowl.o g++ -O2 -c OpenGpu.cpp -o OpenGpu.o g++ -O2 -c common.cpp -o common.o g++ -O2 -c clwrap.cpp -o clwrap.o g++ -O2 -c OpenTF.cpp -o OpenTF.o g++ -o openowl-V38-91c52fa-W64.exe OpenGpu.o common.o gpuowl.o clwrap.o OpenTF.o -lOpenCL -static[/CODE] Win x64 executable attached. On the CUDA side though: [CODE]C:\users\ken\documents\gpuowl-cuda-build>nvcc -O2 -DREV=\"91c52fa\" -o cudaowl-V38-91c52fa-W64.exe common.cpp gpuowl.cpp CudaGpu.cu NoTF.cpp -lcufft common.cpp gpuowl.cpp c:\users\ken\documents\gpuowl-cuda-build\checkpoint.h(126): error C2039: 'to_string': is not a member of 'std' c:\users\ken\documents\gpuowl-cuda-build\common.h(18): note: see declaration of 'std' c:\users\ken\documents\gpuowl-cuda-build\checkpoint.h(126): error C3861: 'to_string': identifier not found c:\users\ken\documents\gpuowl-cuda-build\checkpoint.h(236): error C2039: 'to_string': is not a member of 'std' c:\users\ken\documents\gpuowl-cuda-build\common.h(18): note: see declaration of 'std' c:\users\ken\documents\gpuowl-cuda-build\checkpoint.h(236): error C3861: 'to_string': identifier not found c:\users\ken\documents\gpuowl-cuda-build\checkpoint.h(247): error C2039: 'to_string': is not a member of 'std' c:\users\ken\documents\gpuowl-cuda-build\common.h(18): note: see declaration of 'std' c:\users\ken\documents\gpuowl-cuda-build\checkpoint.h(247): error C3861: 'to_string': identifier not found c:\users\ken\documents\gpuowl-cuda-build\timeutil.h(6): fatal error C1083: Cannot open include file: 'sys/time.h': No such file or directory[/CODE]Change in timeutil.h[CODE]#include <time.h> // #include <sys/time.h> [/CODE]Add in checkpoint.h[CODE]#include <string>[/CODE]gets it down to[CODE]C:\users\ken\documents\gpuowl-cuda-build>nvcc -O2 -DREV=\"91c52fa\" -o cudaowl-V38-91c52fa-W64.exe common.cpp gpuowl.cpp CudaGpu.cu NoTF.cpp -lcufft common.cpp gpuowl.cpp c:\users\ken\documents\gpuowl-cuda-build\timeutil.h(13): error C2079: 'tv' uses undefined struct 'Timer::timeMicros::timeval' c:\users\ken\documents\gpuowl-cuda-build\timeutil.h(14): error C3861: 'gettimeofday': identifier not found[/CODE]And then there's this: [URL]https://blog.habets.se/2010/09/gettimeofday-should-never-be-used-to-measure-time.html[/URL] |
[QUOTE=preda;494260]I recently added GHz-days/day display to GpuOwl. On my Vega64:
PRP: 160 GHz-days/day, TF: 1300 GHz-days/day. [CODE] 2018-08-20 14:15:43 vega0 10440000/332345953 [ 3.14%], 7.91 ms/it [7.91, 7.92] (162.4 GHz-day/day); ETA 29d 11:43; c3ac31e63e4e396b 2018-08-20 14:17:03 vega0 10450000/332345953 [ 3.14%], 7.91 ms/it [7.91, 7.92] (162.4 GHz-day/day); ETA 29d 11:42; b29119a93473260c 2018-08-20 14:37:40 vega0 TF 332345953 80-81 0.03%, class 2 ( 11), 4.212s (1312 GHz), ETA 0d 13:28, FCs 5809428287 (19.1839%) 2018-08-20 14:37:44 vega0 TF 332345953 80-81 0.03%, class 3 ( 15), 4.215s (1311 GHz), ETA 0d 13:29, FCs 5809404755 (19.1838%) [/CODE]The power draw of the GPU is under 220W.[/QUOTE] Interesting; 1312/162.4=~ 8.08. On CUDA code I typically see a ratio of 12-15. Higher primality test efficiency would drive the ratio lower. |
| All times are UTC. The time now is 23:05. |
Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.