New Google Colab Notebooks For Primality Testing

[Prime95]

Originally Posted by tdulcet

This added a new 155 worktype to the manual assignment page. I am curious if the worktype would also work with the PrimeNet API, as we could trivially add support for it to our PrimeNet script if/when we add support for uploading PRP proofs.

It ought to work.

[kriesel]

Originally Posted by tdulcet

OK, I was able to compile and run GpuOwl 6.11 commit 5c5dc6669d748460c57ff1962fdbbbc599bac0d0 (the last version that successfully compiles with GCC 7) on Colab. On the Tesla V100 GPU, GpuOwl is 638 us/iter and CUDALucas is around 1,140 us/iter, so I can confirm that GpuOwl is about 78.6% faster. Here are the results from 10,000 iterations of an LL test:

2021-03-04 06:34:54 Tesla V100-SXM2-16GB-0 106928347 LL        0 loaded: 0000000000000004
2021-03-04 06:35:57 Tesla V100-SXM2-16GB-0 106928347 LL   100000   0.09%;  638 us/it; ETA 0d 18:56; 95920d6941eafe3f
2021-03-04 06:35:57 Tesla V100-SXM2-16GB-0 waiting for the Jacobi check to finish..
2021-03-04 06:36:45 Tesla V100-SXM2-16GB-0 106928347 OK   100000 (jacobi == -1)

and 10,000 iterations of a PRP test:

2021-03-04 06:37:33 Tesla V100-SXM2-16GB-0 106928347 OK        0 loaded: blockSize 400, 0000000000000003
2021-03-04 06:37:34 Tesla V100-SXM2-16GB-0 106928347 OK      800   0.00%;  638 us/it; ETA 0d 18:57; 7d85dc41e3222beb (check 0.41s)
2021-03-04 06:38:37 Tesla V100-SXM2-16GB-0 Stopping, please wait..
2021-03-04 06:38:38 Tesla V100-SXM2-16GB-0 106928347 OK   100000   0.09%;  639 us/it; ETA 0d 18:59; 4d66b4eed5ea9ab3 (check 0.42s)

That commit is from June 1 2020, somewhere between V6.11-295 and V6.11-318 (I think v6.11-307). There is somewhat more gpuowl performance to be had by reaching ~v6.11-364 to -380, from V6.11-318 upward. Also a number of fixes.

The description of Colab users running up to a dozen notebooks from one account and on large exponents seems like reaching to create a problem where little exists. Users can (a) use multiple free email accounts and spread their usage across several free Google Drive 15GB allotments, (b) run a mix of large, normal and small exponents (~56M DC could sure use the additional throughput), (c) rent additional Google Drive space, and possibly use other free cloud storage, (d) help out with P-1, which is chronically unable to keep up with the wavefront first-test demand, (e) run unusually low proof power PRP when other measures are not sufficient, (f) combine approaches.

It all seems somewhat moot though, since it's already been well established, that the automaton notebook / browser addon approach that is the subject of this thread, violates Google Colab's regularly expressed conditions of use, while GPU72 scripts as provided and used by chalsall, and notebooks provided by others, ran manually/interactively as Google intends and has clearly stated that intent, do not. I suggest a priority item missing from the to-do list is to bring the addon into (at least user-optional, if not intrinsic) compliance with the conditions of free Colab use. To continue to decline to, after notice from Google Colab, and periodic discussion here in a public forum, would leave you in what seems to me a quite vulnerable legal position should the Google legal team become interested. (Not a lawyer, but I've hired some on occasion. The need is best avoided.) I won't be using your addon while that remains unaddressed.

We would also obviously need latest version of GpuOwl to always successfully build on Colab. To achieve this, I submitted a pull request to the GpuOwl repository, which adds Continuous Integration (CI) to automatically build GpuOwl on Linux (with both GCC and Clang) and Windows on every commit and pull request. It was merged a few days ago. This allows users to now see directly on the top of the GpuOwl README if the latest version of GpuOwl builds by checking the badges. It should also eventually eliminate the need for @kriesel to have to manually build and upload binaries for Windows users. See my pull request for more info.

I don't see where the successfully built Ubuntu v20 can be downloaded for use. It's a nice feature for Preda to see quickly what builds successfully and what does not, with no dependence on users to try and report back, or overhead to try it himself on multiple OSes.

Note that from my recent limited testing, and from some others, there appears to be a speed regression in gpuowl. Getting boxed in to run only the latest commit despite earlier commits being noticeably faster is not optimal. Some users want version control for performance, stability, or perhaps other reasons.

[danc2]

it's already been well established, that the automaton notebook / browser addon approach that is the subject of this thread, violates Google Colab's regularly expressed conditions of use,

I have a couple clarifications on these statements:
1. The "notebook / browser addon approach" is not the subject of this thread. Allowing users to run full primality tests on Google Colab for research purposes is (see title). Any other discussions are important, but ancillary.
2. I think people will have to make their own choices regarding using the extension in conjunction with this project and keep in mind those very good points about potential legal consequences.
3. One can support the notebook, but not the extension.
4. The notebook by itself does not have any automation that could be construed as going against Colab's terms of service IMO.

[chalsall]

Originally Posted by danc2

I have a couple clarifications on these statements:
1. The "notebook / browser addon approach" is not the subject of this thread. Allowing users to run full primality tests on Google Colab for research purposes is (see title). Any other discussions are important, but ancillary.

Just for clarity... tdulcet (your "partner in crime" (that's meant to be funny)) did say in message number 4 of this thread that your browser add-on could be used by anyone using Colab running any Notebook.

Several of us pointed out that that /might/ not be the best idea.

Originally Posted by danc2

2. I think people will have to make their own choices regarding using the extension in conjunction with this project and keep in mind those very good points about potential legal consequences.

The "legal consequences" would be at worst a ban of that user from using Google Colab services.

Personally, I can't take that risk (I use this for other purposes as well as the GPU72 Notebook). Others might not have that constraint.

Originally Posted by danc2

3. One can support the notebook, but not the extension.
4. The notebook by itself does not have any automation that could be construed as going against Colab's terms of service IMO.

Completely agree.

You have done good work here gentlemen. And have taken constructive criticism appropriately.

It is great seeing different approaches being taken with these "free" resources. It's particularly cool that you have a Git sharing all of your code.

[danc2]

partner in crime

Maybe a double-entendre, haha. Either way, I'm glad to have that title .

tdulcet [said] that your browser add-on could be used by anyone using Colab running any Notebook.

I don't think this conflicts with what I said (the emphasis being that the extension is not the (pronounced thee) point of the project). I think Teal's word choice ("can" instead of "should" or "have to") also supports this point of view.

The "legal consequences" would be at worst a ban of that user from using Google Colab services.

I 100% agree/I think you convinced me of this when you made your point about Google only really inquiring further when consumers are high-paying or costing them lots (paraphrased). Though I am not equating low consequences being a sign that something is morally good and I am sure no one in this forum is saying that as well.

It's particularly cool that you have a Git sharing all of your code.

Thanks! I feel like Teal is a naturally humble person and always takes less credit than he deserves as a result, but he is a huge brain in this project and is responsible for a lot of the good in these projects and usually if there is a bad, it's a mistake of mine, haha. Other forum users can verify his resourcefulness as well. We were glad to contribute to this cool project and have learned and continue to learn a lot by working on it and interacting with users here!

[tdulcet]

Originally Posted by kriesel

That commit is from June 1 2020, somewhere between V6.11-295 and V6.11-318 (I think v6.11-307). There is somewhat more gpuowl performance to be had by reaching ~v6.11-364 to -380, from V6.11-318 upward. Also a number of fixes.

Yeah, my potential GpuOwl install script would need to work with the default GCC version. Colab uses Ubuntu 18.04, which includes GCC 7.5. As I said, that was the last version/commit that successfully compiles with GCC 7. The next commit unfortunately adds C++20 syntax which requires at least GCC 8. Colab is working on upgrading to Ubuntu 20.04 (see here), which includes GCC 9.3, so hopefully they will do that soon, so we would be able to use a later commit of GpuOwl v6, as well as the latest version

Originally Posted by kriesel

The description of Colab users running up to a dozen notebooks from one account and on large exponents seems like reaching to create a problem where little exists.

These situations actually apply to both Daniel and I. Particularly to Daniel, where they both apply.

Originally Posted by kriesel

It all seems somewhat moot though, since it's already been well established, that the automaton notebook / browser addon approach that is the subject of this thread, violates Google Colab's regularly expressed conditions of use, while GPU72 scripts as provided and used by chalsall, and notebooks provided by others, ran manually/interactively as Google intends and has clearly stated that intent, do not.

As Daniel said, the extension is completely separate from our notebooks and they both can be used independently. Our notebooks by themselves must be run manually/interactively, just like the GPU72 notebook and all other Colab notebooks.

Originally Posted by kriesel

I suggest a priority item missing from the to-do list is to bring the addon into (at least user-optional, if not intrinsic) compliance with the conditions of free Colab use.

Usage of the extension/add-on is completely optional. Even if people decide to use it, it will NOT run the first cell of their notebooks by default. They must explicitly enable this optional feature. (The extension does not yet have an options page, so users would actually need to set a global variable in the source code to enable it.) If there is some specific missing feature you would like added, please let us know and we will consider it for the next version.

Please note that both Daniel and I completely 100% disagree with your premise that the extension/add-on is not allowed or is somehow violating Colab's terms of service. Daniel explicitly asked for anyone to quote the terms of service to refute his arguments and no one has. The only augment that has been made centers on those popups that say, "Colab is for interactive use". As I explained in great detail, the extension is NOT designed to be used noninteractivity. The "interactive use" link in the popups just go to the Colab FAQ section on "usage limits", which only says, "GPUs and TPUs are sometimes prioritized for users who use Colab interactively rather than for long-running computations". Daniel and I take this to mean that even noninteractive use of Colab is OK, users will just get less runtime, but again, the extension is NOT designed for this. We would NOT have created the extension or be using it if we thought we were breaking any rules or risking anything.

As Daniel alluded to, there are currently three other open source Colab browser add-ons, all published on Google's own Chrome Web Store, which would have had to been reviewed and accepted by Google:

• Colab Auto Reconnect
• Colab Alive
• Colab Auto Reconnect

If Google did not want people using these types of Colab browser add-ons, they would not have accepted them to their Chrome Web Store. However, if you or anyone still feels that the extension is not allowed, then just do not use it. They can still use and benefit from our notebooks.

Note that our extension is licensed with the MPL, which protects Daniel and me from any liability from other people misusing/abusing it.

Originally Posted by kriesel

I don't see where the successfully built Ubuntu v20 can be downloaded for use.

It cannot be downloaded currently. The keyword was the "eventually" in italics. I purposely did not enable this feature in my pull request, as I was waiting until the Windows builds compile successfully. See the pull request for more info. Note that the Linux builds are not of much use since it is much more difficult to transfer the Linux binaries between different systems. The Ubuntu 20.04 builds would likely only work on 64-bit x86 systems with Ubuntu 20.04 or higher. I would highly recommend that Linux users build GpuOwl themselves, which it what my potential install script would do.

Originally Posted by kriesel

Note that from my recent limited testing, and from some others, there appears to be a speed regression in gpuowl. Getting boxed in to run only the latest commit despite earlier commits being noticeably faster is not optimal. Some users want version control for performance, stability, or perhaps other reasons.

Interesting. My potential GpuOwl install script and thus the GPU notebook were going to follow the recommended installation instructions for GpuOwl, which even going by your own post, suggests using the latest commit of GpuOwl. The latest commit also likely has important bug fixes. We are open to suggestions for alternative approaches, although letting users select arbitrary versions could easily break the install script itself and/or our PrimeNet script. It would likely be better for users to report any performance regressions, as you did, so that they can be fixed. Hopefully this performance regression in GpuOwl will be fixed soon.

[ewmayer]

Originally Posted by tdulcet

We would also obviously need latest version of GpuOwl to always successfully build on Colab. To achieve this, I submitted a pull request to the GpuOwl repository, which adds Continuous Integration (CI) to automatically build GpuOwl on Linux (with both GCC and Clang) and Windows on every commit and pull request. It was merged a few days ago. This allows users to now see directly on the top of the GpuOwl README if the latest version of GpuOwl builds by checking the badges. It should also eventually eliminate the need for @kriesel to have to manually build and upload binaries for Windows users. See my pull request for more info.

Possible issue - how to handle savefile incompatibility between client versions? This is not just an issue for gpuowl, but I got dinged by it when I upgraded my build of that client on one of my multi-GPU systems last December - on restart, every one of my partially-done PRP tests restarted from scratch. My own convention with Mlucas is that such savefile incompatibility may only possibly arise between versions having differing major-rev numbers, and even there, I try to make things upward-compatible whenever possible. E.g. v19 added some fields to the savefiles to support the Gerbicz-check, but v18 LL and DC savefiles were compatible for use by v19. v20 will add some bytes for cumulative counts of several types of errors as well as some stuff needed for p-1 run restart, but will be able to read in v19 LL|PRP-test savefiles. But it seems some kind of agreed-upon convention amongst the authors of the various clients here would be good.

In the presence of some kind of tagging system with regard to savefile-compatibility, one then needs a mechanism for handling work when a new version breaks compatibility, which keeps the older build around to finish any ongoing assignments, and then switches to the newer client.

[tdulcet]

Originally Posted by ewmayer

Possible issue - how to handle savefile incompatibility between client versions? This is not just an issue for gpuowl

Interesting problem, thanks for bringing it up. The potential new GPU notebook that uses GpuOwl would only download and build GpuOwl the first time it was run, as it would save the binary to the user's Google Drive, just as the notebook currently does with CUDALucas. If the user wanted to upgrade GpuOwl, they would likely need to delete a GIMPS/gpuowl directory from their Google Drive and rerun the notebook. This is similar to how users will probably need to delete the mlucas_v19.1 directory and rerun the Mlucas install script to upgrade to Mlucas v20.

Originally Posted by ewmayer

In the presence of some kind of tagging system with regard to savefile-compatibility, one then needs a mechanism for handling work when a new version breaks compatibility, which keeps the older build around to finish any ongoing assignments, and then switches to the newer client.

Adding an upgrade feature as you described to my three existing install scripts and potential GpuOwl install script would be very nice, but it would obviously add a lot of complexity. An agreed upon convention between GIMPS program developers would of course be the best solution. Prime95/MPrime has a "Quit GIMPS" feature, where it will not download any new assignments, but will still finish and report the existing ones. This would be trivial to add to our PrimeNet script and I think would in the meantime solve most of the problem you described, as users could then easily finish their current assignments before upgrading the GIMPS program to a version with incompatible savefiles. For GpuOwl in particular, it would also be good if someone wrote a short test suite that could be run by the CI and could check for savefile incompatibilities.

[drkirkby]

Originally Posted by kriesel

Google Colaboratory has resorted at times to requiring ostensibly human image analysis before authorizing a Colab session.

I tried to sign up to get an account on Amazon AWS today. I simply can not get past their capcha.

[danc2]

drkirkby,

This is a notebook made for Google Colab. We have not tested it with other notebook instances so there is no guarantees. Besides that, it sounds like your issue is with Amazon AWS captchas upon signup, not the notebooks. Those bother me as well...I hope you can get that resolved.

[bayanne]

Currently getting about 10 minutes at a time running gpu ...