What to expect from GTX1080 for ECM?

[fivemack]

A GTX970 wants to run 416 curves at a time, and at B1=6e8 each block takes 24 hours.

A GTX1080 has more execution units, so will run 640 curves at a time, and is clocked at 1607MHz vs 1050MHz for the 970 - does that mean it's reasonable to anticipate that it will do a 640-curve block in 16 hours?

[diep]

Originally Posted by fivemack

A GTX970 wants to run 416 curves at a time, and at B1=6e8 each block takes 24 hours.

A GTX1080 has more execution units, so will run 640 curves at a time, and is clocked at 1607MHz vs 1050MHz for the 970 - does that mean it's reasonable to anticipate that it will do a 640-curve block in 16 hours?

If ECM is using FP64 resources i wouldn't count on GTX1080 being faster at all.

[ATH]

GTX 970 also has poor FP64 performance so I doubt it uses FP64.

GTX 950, 960, 970, 980, 980Ti and Titan X all have FP64 = 1/32th of FP32.

[bsquared]

Originally Posted by ecm-gpu.h

#ifndef ECM_GPU_NB_DIGITS
#define ECM_GPU_NB_DIGITS 32 //by default
#endif

#ifndef ECM_GPU_DIGITS
#define ECM_GPU_DIGITS 0
#endif

#if (ECM_GPU_DIGITS==0)
#define ECM_GPU_SIZE_DIGIT 32
typedef unsigned int digit_t;
typedef int carry_t;
#endif

It appears to use 32-bit unsigned ints as its bignum digits, as expected.

I see the memory clock and bandwidth also scale up, but not by quite as much (7 Gb/s --> 10 Gb/s, 224 GB/sec --> 320 GB/sec). So whether GPU-ECM is compute or memory bound I think it's reasonable to expect the performance to improve by a factor of 1.4-1.5.

[diep]

if i look at graphs at number of gflops (double precision) that LLR-cuda type software gets out of gpu's then this is very bad indeed. Seems to scale with bandwidth. Not having too many fp64 resources is no big deal then to them. They need a different transform to implement... ...right now they burn big watts for nothing seemingly.

...

Yet objectively if you look to fp64 resources and the gtx1080 i doubt it has many. they can clock it way higher when not using them. What would stop 'em to do that?

[danaj]

Some sources are claiming much better double precision, albeit these are more like "educated rumors" right now. E.g. this says "For starters the company is bringing back double precision floating point compute performance to the forefront. Where only one double precision CUDA core existed for every 32 standard CUDA cores in Maxwell, Pascal is built with one double precision CUDA core for every two standard CUDA cores."

The Wikipedia article also cites two sources for it's claim of "Half precision FP16 operations executed at twice the rate of FP32, while FP64 operations run at 1/2 the speed respectively."

It wouldn't surprise me if the press completely misinterpreted this and it was still crippled on the consumer models. The sources seem to be discussions of the Pascal architecture, which is targeted to both Tesla and consumers.

[diep]

If you no good in GPU programming then you scale with bandwidth.
GTX980 has versions with 224GB/s going up to versions with 336 GB/s bandwidth.
Initial released GTX1080 has bandwidth 320GB/s.

So if it's software that's not so very well programmed and bandwidth oriented rather than CPU oriented then it'll be a lot slower.

edit: GTX980ti = 336 GB/s

[diep]

Danaj that 2 units per fp64 is only true of course for the Tesla P100.

Nvidia is bunch of very clever guys. they aren't gonna sell for 600 euro a card that they wanna sell to you for 120k dollar (with 8 in 1 node).

Tesla P100 is a very impressive card. It'll dominate HPC machines that get built right now i bet.

So they aren't gonna offer you reduction of factor 100 in price for a gamers card that's nearly same performance like 1/3 of a tesla as they won't sell a single tesla then.

[diep]

If card has fast 32x32 == 64 bits multiplication then we can consider taking look at producing FFT that uses only integers.

Maybe a NTT using CRT to put more bits an unit and be able to scale to larger transforms. Those gpu's so fast now and you got so many resources. That would be worth investigation.

Overhead of NTT is pretty big compared to what Woltman is doing at CPU. Calculating modulo is not fast at GPU. Lots of instructions for each unit compared to ideal double precision transform.

[bsquared]

Originally Posted by fivemack

A GTX970 wants to run 416 curves at a time, and at B1=6e8 each block takes 24 hours.

A GTX1080 has more execution units, so will run 640 curves at a time, and is clocked at 1607MHz vs 1050MHz for the 970 - does that mean it's reasonable to anticipate that it will do a 640-curve block in 16 hours?

Out of curiosity, are these timings for half size or full size (1018-bit) inputs?

[xilman]

Originally Posted by fivemack

A GTX970 wants to run 416 curves at a time, and at B1=6e8 each block takes 24 hours.

A GTX1080 has more execution units, so will run 640 curves at a time, and is clocked at 1607MHz vs 1050MHz for the 970 - does that mean it's reasonable to anticipate that it will do a 640-curve block in 16 hours?

Curious. My 970 runs 832 curves at once. This with stock GMP-ECM, meaning kilobit arithmetic.

Input number is 3739842974907858397552172903385764902385045463835258551832047737904189157686320432379794586053438820815117446826957517100181574651282354947806538316031297323554516867664691768863509608671071081 (199 digits)
Using B1=11000000, B2=0, sigma=3:3799984916-3:3799985747 (832 curves)
GPU: Block: 32x32x1 Grid: 26x1x1 (832 parallel curves)
Computing 832 Step 1 took 59050ms of CPU time / 2989511ms of GPU time

pcl@horus /opt/cuda/sdk/bin/x86_64/linux/release $ ./deviceQueryDrv
./deviceQueryDrv Starting...

CUDA Device Query (Driver API) statically linked version 
Detected 1 CUDA Capable device(s)

Device 0: "GeForce GTX 970"
  CUDA Driver Version:                           7.5
  CUDA Capability Major/Minor version number:    5.2
  Total amount of global memory:                 4095 MBytes (4294246400 bytes)
MapSMtoCores for SM 5.2 is undefined.  Default to use 128 Cores/SM
MapSMtoCores for SM 5.2 is undefined.  Default to use 128 Cores/SM
  (13) Multiprocessors, (128) CUDA Cores/MP:     1664 CUDA Cores
  GPU Clock rate:                                1216 MHz (1.22 GHz)
  Memory Clock rate:                             3505 Mhz
  Memory Bus Width:                              256-bit
  L2 Cache Size:                                 1835008 bytes
  Max Texture Dimension Sizes                    1D=(65536) 2D=(65536, 65536) 3D=(4096, 4096, 4096)
  Maximum Layered 1D Texture Size, (num) layers  1D=(16384), 2048 layers
  Maximum Layered 2D Texture Size, (num) layers  2D=(16384, 16384), 2048 layers
  Total amount of constant memory:               65536 bytes
  Total amount of shared memory per block:       49152 bytes
  Total number of registers available per block: 65536
  Warp size:                                     32
  Maximum number of threads per multiprocessor:  2048
  Maximum number of threads per block:           1024
  Max dimension size of a thread block (x,y,z): (1024, 1024, 64)
  Max dimension size of a grid size (x,y,z):    (2147483647, 65535, 65535)
  Texture alignment:                             512 bytes
  Maximum memory pitch:                          2147483647 bytes
  Concurrent copy and kernel execution:          Yes with 2 copy engine(s)
  Run time limit on kernels:                     Yes
  Integrated GPU sharing Host Memory:            No
  Support host page-locked memory mapping:       Yes
  Concurrent kernel execution:                   Yes
  Alignment requirement for Surfaces:            Yes
  Device has ECC support:                        Disabled
  Device supports Unified Addressing (UVA):      Yes
  Device PCI Bus ID / PCI location ID:           1 / 0
  Compute Mode:
     < Default (multiple host threads can use ::cudaSetDevice() with device simultaneously) >
Result = PASS

600/11 * 2990/3600 * 1216/1050 * 416/832 = 26 hours. Assuming that I placed the numerators and denominators in the correct order, that's consistent with your timings once the density of primes < B1 has been taken into account.