[QUOTE=tServo;500158]kriesel,
What company is promising all this?
The reason I ask is that here in Champaign-Urbana, we have had 2 different attempts
to provide everybody with fiber, exactly as you described.
The most recent had also had a web page where you could see how many of your neighbors have signed up, blah blah blah.
They also kept delaying it saying not enough have signed up for it, etc etc etc.

They finally crashed and burned; the whole thing looking like a scam
Bad feelings all around.
Some government started corporation was handed the contract to actually do it.
I don't know their status. I will look into it.
Meanwhile, evil Comcast still has my business.[/QUOTE]
Was your experience part of this? [URL]http://www.wandtv.com/story/29018456/fiber-optic-internet-installation-underway-in-champaign-urbana[/URL]

Here, it's TDS Fiber, part of the same company as US Cellular. [URL]https://en.wikipedia.org/wiki/Telephone_and_Data_Systems[/URL]
Same MO, maps of various zones in the area with deadlines and rollout date projections, and number of households needed yet per zone. My zone has been stuck at the same number needed yet, for months. Regression fit indicates > 2 years to reach the required number, and that extrapolation continues to slide later by the day.

The company they contracted with to do utility marking is USIC, the same company that mismarked for Verizon a Sun Prairie WI gas line by 25 feet (7.6m, the width of a house, or in this case the sidewalk instead of the middle of the street), leading to explosions at multiple addresses and multi-structure fire in the downtown, the death of a firefighter and injuries of several others, and the evacuation of several dozen structures including homes. Several structures both sides of the street were classified destroyed and the street was shut down for days. It was a 4" gas line that got hit by another contractor because of the badly misplaced marking. I guess I should be glad it was only the telco cable that got cut in my neighborhood when they were passing cable through here to hook up a more distant neighborhood, not a gas or sewer line cut. [URL]https://www.jsonline.com/story/news/politics/2018/07/11/sun-prairie-firefighter-killed-explosion-destroyed-his-own-bar/774919002/[/URL]
[URL]https://chicagoareafire.com/blog/tag/sun-prairie-fire-department/[/URL]

[QUOTE=tServo;500156]krisel,
I suggest you avoid GMP and use MPIR instead. It's a rewrite of GMP for windows, designed to be compiled by Visual Studio and, I believe, yasm.
It's not trivial to install ( each person must compile it for themselves ), but it avoids all the GMP headaches. However, each version is then optimized for THAT machine.
One of its authors, Brian Gladman, posts here occasionally.
Be sure to use the 'generate GMP headers' option, which is specifically for porting code from GMP to windows.
I have used MPIR extensively, but have never ported anything from GMP.
It is at mpir.org[/QUOTE]
What makes an MPIR install specific to a machine? Optimization for cpu type? Can it be statically linked in and copied to another similar machine without doing the build fresh on each box? It would get tedious installing the build environment on every system I'd want to run the end product on.

[QUOTE=kriesel;500160]Was your experience part of this? [URL]http://www.wandtv.com/story/29018456/fiber-optic-internet-installation-underway-in-champaign-urbana[/URL]

[/QUOTE]

Yes, that's us. In fact, I know Jenny referenced in the article. She never got her fiber.

The nonprofit that was formed from the ashes of that failure looks like its a failure, too.
In fact, its website ( uc2b.net ) looks just like the previous failures: ie, it has a map, sign up form, etc. But if you look at reports, meeting notes, & blog entries, they are all 2 to 4 years old. In other words, it's dead.

The bottom line here is these things fail at an alarming rate. Buyer beware !

The technology I've seen that might be a game changer is 5G cell.

[QUOTE=kriesel;500161]What makes an MPIR install specific to a machine? Optimization for cpu type? Can it be statically linked in and copied to another similar machine without doing the build fresh on each box? It would get tedious installing the build environment on every system I'd want to run the end product on.[/QUOTE]

Yes, it's quite flexible. If you goto mpir.org and look at section 2.1 of the documentation, "Install Options", it gives that info. One can just use C & avoid assembler for the most generic binary, one can choose to make a build of one's oldest architecture, cross platform builds can be done, and a fat binary that has several binaries can be built.

I was actually looking at MPIR yesterday, myself. As I understand it, it's just a fork of GMP mostly because the GMP authors refuse to have anything to do with Windows.

One of the supported build methods for MPIR can make generic non-hardware specific libraries, which is what I'm planning to do.

Also, I believe that, since most of the heavy lifting is done in CUDA rather than on the host, the need for optimised host code is less important, and we should have no problem linking in said generic build.

[QUOTE=aaronhaviland;500182]I was actually looking at MPIR yesterday, myself. As I understand it, it's just a fork of GMP mostly because the GMP authors refuse to have anything to do with Windows.

One of the supported build methods for MPIR can make generic non-hardware specific libraries, which is what I'm planning to do.

Also, I believe that, since most of the heavy lifting is done in CUDA rather than on the host, the need for optimised host code is less important, and we should have no problem linking in said generic build.[/QUOTE]
As I understand it, gmp is used for the gcd on one host cpu core, while the gpu idles. That is typically a small fraction of total run time, but not trivial. I've seen it take the better part of an hour on higher exponents, per gcd.

Any chance you'll make a Windows executable available?
I estimate I'll finish my current limits testing of CUDAPm1 v0.20 in a week or two.

[QUOTE=kriesel;500185]As I understand it, gmp is used for the gcd on one host cpu core, while the gpu idles. That is typically a small fraction of total run time, but not trivial. I've seen it take the better part of an hour on higher exponents, per gcd.

Any chance you'll make a Windows executable available?
I estimate I'll finish my current limits testing of CUDAPm1 v0.20 in a week or two.[/QUOTE]

Just to add my GCD timing on i7-7820X, with GMP using one CPU core, for 332M exponent the GCD takes 282s, while for a 89M exponent it take 56s.

While "waiting" for the GCD, the GPU doesn't have to be idle. It could continue, "optimistically" assuming that the GCD found no factor (and stop if the GCD turns out positive).

[QUOTE=kriesel;500185]As I understand it, gmp is used for the gcd on one host cpu core, while the gpu idles. That is typically a small fraction of total run time, but not trivial. I've seen it take the better part of an hour on higher exponents, per gcd.

Any chance you'll make a Windows executable available?
I estimate I'll finish my current limits testing of CUDAPm1 v0.20 in a week or two.[/QUOTE]
I agree it's not trivial, but still minor in proportion to the length of time spent in gpu-land, I don't know if this could be moved to GPU as well, but it's on my list. From a quick scan, it looks like the GMP code is too widely used on the host-side, not just during GCD, so it may not be that simple.

And yes, once I figure out the whole GMP/MPIR thing. (This is the whole reason I'm looking at MPIR in the first place).

[QUOTE=preda;500193]While "waiting" for the GCD, the GPU doesn't have to be idle. It could continue, "optimistically" assuming that the GCD found no factor (and stop if the GCD turns out positive).[/QUOTE]
Seems like a good idea, but may be more difficult in practice. It's not a multi-threaded program currently. Still worth investigating if we need to stay in CPU-land too long.

[QUOTE=aaronhaviland;500202]Seems like a good idea, but may be more difficult in practice. It's not a multi-threaded program currently. Still worth investigating if we need to stay in CPU-land too long.[/QUOTE]
Not sure if you're aware, but Preda has implemented some multithreading in gpuowl. Given the odds of factoring success in a stage, it's about 98% likely to be useful.
Other approaches I've thought of are having a second app running tf alongside (TF has a very small gpu ram footprint), or using a foreground/background tasks approach in CUDAPm1. Foreground is the first worktodo entry, background is the next. That's definitely more complicated and has memory requirement implications. Task switch times need to be short to be useful. Another possibility might be to use multiple cpu cores when available to speed the gcd.

It's more than the gcd's that are causing gpu stalls. I think the disk writes of checkpoint save files are also, with larger exponents being more noticeable.

I've seen in recent testing that sometimes CUDAPm1 significantly underutilized gpu memory in stage 2. Not sure what that's about, or if it's still present in your modified version.

Success compiling with MPIR.

64-bit binary attached
Requires CUDA 10, and a GPU with Compute Capability >= 3.5. Unsure of other requirements, I'm not too familiar with Windows dependencies.

[CODE]Microsoft Windows [Version 10.0.17134.407]
C:\Users\Aaron\Documents\Visual Studio 2017\Projects\CUDAPm1\x64\Release>CUDAPm1.exe 7990427 -b1 986 -b2 124000
CUDAPm1 v0.21
Assuming exponent is trial factored to 63 bits
------- DEVICE 0 -------
name GeForce RTX 2070
Compatibility 7.5
clockRate (MHz) 1710
memClockRate (MHz) 7001
totalGlobalMem 8589934592
totalConstMem 65536
l2CacheSize 4194304
sharedMemPerBlock 49152
regsPerBlock 65536
warpSize 32
memPitch 2147483647
maxThreadsPerBlock 1024
maxThreadsPerMP 1024
multiProcessorCount 36
maxThreadsDim[3] 1024,1024,64
maxGridSize[3] 2147483647,65535,65535
textureAlignment 512
deviceOverlap 1

No GeForceRTX2070_fft.txt file found. Using default fft lengths.
For optimal fft selection, please run
./CUDAPm1 -cufftbench 1 8192 r
for some small r, 0 < r < 6 e.g.
CUDA reports 6723M of 8192M GPU memory free.
No GeForceRTX2070_threads.txt file found. Running benchmark.
CUDA bench, testing various thread sizes for fft 448K, doing 15 passes.
fft size = 448K, square time = 0.0436 msec, threads 32
fft size = 448K, square time = 0.0449 msec, threads 64
fft size = 448K, square time = 0.0336 msec, threads 128
fft size = 448K, square time = 0.0335 msec, threads 256
fft size = 448K, square time = 0.0356 msec, threads 512
fft size = 448K, square time = 0.0438 msec, threads 1024

Best square time for fft = 448K, time: 0.0335, t = 256

fft size = 448K, ave time = 0.0408 msec, Norm1 threads 32, Norm2 threads 32
fft size = 448K, ave time = 0.0407 msec, Norm1 threads 32, Norm2 threads 64
fft size = 448K, ave time = 0.0408 msec, Norm1 threads 32, Norm2 threads 128
fft size = 448K, ave time = 0.0412 msec, Norm1 threads 32, Norm2 threads 256
fft size = 448K, ave time = 0.0419 msec, Norm1 threads 32, Norm2 threads 512
fft size = 448K, ave time = 0.0433 msec, Norm1 threads 32, Norm2 threads 1024
fft size = 448K, ave time = 0.0402 msec, Norm1 threads 64, Norm2 threads 32
fft size = 448K, ave time = 0.0402 msec, Norm1 threads 64, Norm2 threads 64
fft size = 448K, ave time = 0.0405 msec, Norm1 threads 64, Norm2 threads 128
fft size = 448K, ave time = 0.0406 msec, Norm1 threads 64, Norm2 threads 256
fft size = 448K, ave time = 0.0408 msec, Norm1 threads 64, Norm2 threads 512
fft size = 448K, ave time = 0.0428 msec, Norm1 threads 64, Norm2 threads 1024
fft size = 448K, ave time = 0.0394 msec, Norm1 threads 128, Norm2 threads 32
fft size = 448K, ave time = 0.0394 msec, Norm1 threads 128, Norm2 threads 64
fft size = 448K, ave time = 0.0397 msec, Norm1 threads 128, Norm2 threads 128
fft size = 448K, ave time = 0.0400 msec, Norm1 threads 128, Norm2 threads 256
fft size = 448K, ave time = 0.0411 msec, Norm1 threads 128, Norm2 threads 512
fft size = 448K, ave time = 0.0423 msec, Norm1 threads 128, Norm2 threads 1024
fft size = 448K, ave time = 0.0401 msec, Norm1 threads 256, Norm2 threads 32
fft size = 448K, ave time = 0.0394 msec, Norm1 threads 256, Norm2 threads 64
fft size = 448K, ave time = 0.0395 msec, Norm1 threads 256, Norm2 threads 128
fft size = 448K, ave time = 0.0403 msec, Norm1 threads 256, Norm2 threads 256
fft size = 448K, ave time = 0.0408 msec, Norm1 threads 256, Norm2 threads 512
fft size = 448K, ave time = 0.0423 msec, Norm1 threads 256, Norm2 threads 1024
fft size = 448K, ave time = 0.0417 msec, Norm1 threads 512, Norm2 threads 32
fft size = 448K, ave time = 0.0416 msec, Norm1 threads 512, Norm2 threads 64
fft size = 448K, ave time = 0.0417 msec, Norm1 threads 512, Norm2 threads 128
fft size = 448K, ave time = 0.0424 msec, Norm1 threads 512, Norm2 threads 256
fft size = 448K, ave time = 0.0428 msec, Norm1 threads 512, Norm2 threads 512
fft size = 448K, ave time = 0.0425 msec, Norm1 threads 512, Norm2 threads 1024

Best time for fft = 448K, time: 0.0394, t1 = 128, t2 = 256, t3 = 64
Using threads: norm1 256, mult 128, norm2 128.
Using up to 4119M GPU memory.
Starting stage 1 P-1, M7990427, B1 = 986, B2 = 124000, fft length = 448K
Doing 1452 iterations
M7990427, 0x32318b15f9d83ab6, n = 448K, CUDAPm1 v0.21
Stage 1 complete, estimated total time = 0:01
Starting stage 1 gcd.
M7990427 Stage 1 found no factor (P-1, B1=986, B2=124000, e=0, n=448K CUDAPm1 v0.21)
Starting stage 2.
Using b1 = 986, b2 = 124000, d = 420, e = 4, nrp = 96
Zeros: 4430, Ones: 8530, Pairs: 2981
Processing 1 - 96 of 96 relative primes.
Initializing pass... done. transforms: 1987, err = 0.02539, (0.71 real, 0.3550 ms/tran, ETA NA)
Transforms: 9204 M7990427, 0x456fdf3be182449c, n = 448K, CUDAPm1 v0.21 err = 0.02734 (0:03 real, 0.2873 ms/tran, ETA 0:02)
Transforms: 8928 M7990427, 0x2acd8bf807caa816, n = 448K, CUDAPm1 v0.21 err = 0.02734 (0:02 real, 0.2912 ms/tran, ETA 0:00)

Stage 2 complete, 20119 transforms, estimated total time = 0:05
Starting stage 2 gcd.
M7990427 has a factor: 10509037975912491881 (P-1, B1=986, B2=124000, e=4, n=448K CUDAPm1 v0.21)


C:\Users\Aaron\Documents\Visual Studio 2017\Projects\CUDAPm1\x64\Release>[/CODE]