Actualités en direct des projets (non traduites)
Nouvelles en VO
LHC@home - Unexpected Downtime
- Détails
The outage was caused by the global PHP issue which also affected us. Our team has applied the necessary patches to the servers, and all project services are now back up and running.
Thank you for your patience and ongoing support! Please let us know in this thread if you notice any remaining issues or error messages.
Source
SRBase - base S60 Megaprime
- Détails
The prime 853*60^613855+1 has 1.091.530 digits and entered the T5k PrimePages.
Source
NumberFields@home - New Faster Apps Coming Soon
- Détails
First, a thank you to Alperen for optimizing the current apps. Yes, he used Claude, but that's not necessarily a bad thing. I don't have the experience required or the time to learn the AVX tricks that were used here. So without Alperen and Claude, this probably never would have happened.
I have spent many hours going through the new code. The original code was basically left untouched, and the change was in the addition of a new subroutine that pre-filters the polynomials prior to the normal processing chain. This leaves just the one subroutine that needs validation. From a theoretical perspective, the method is sound. The method can be decomposed into 2 parts:
- 1. The first part was a simple trick (I wish I had seen this myself!) that allows us to deal with the polynomial discriminant modulo a small set of primes. This eliminates the need for the multi-precision integers that were growing to ~1000 bits, and gives the first speed improvement. This was simple enough I could independently code it up myself using Pari's built-in functions. In some offline tests I was seeing a speed improvement of between 2 and 3, just for this simple change.
2. The second improvement was in the coding of the resultant modulo q. This was essentially done in parallel using AVX2, which allows resultants to be computed for several primes simultaneously. This is the part that is very tricky and hard for me to follow. I welcome any expert in this kind of optimization to look at the code. Alperen has made it public here:
https://github.com/alplix/passiflora
So the method in general is sound, but the second part was hard for me to validate. For this reason, I will use sufficient testing to validate the new apps. The idea is to test each new app version on ~1000 old cases which can be taken as truth. This will be done using the "testDecics" app that was recently created. When an app is deemed good, it will be transitioned into an official app.
I will be creating a new app called fastGetDecics where the new validated apps will go. This will still allow me to keep the results separate. It will also allow me to create new WUs for the fast apps that will not put a burden on the server, while retaining older style WUs for the legacy apps. This will give me time to test and migrate the fast apps in pieces rather than all at once. App versions for the original GetDecics will be deprecated once the corresponding fast version has been deemed trustworthy.
Source
SRBase - base R235 Megaprime
- Détails
The prime 3788*235^455521-1 has 1.080.075 digits and entered the T5k PrimePages.
Source
SRBase - base S52 Megaprime
- Détails
The prime 25492*52^638823+1 has 1.096.227 digits and entered the T5k PrimePages.
Source


