• SETI.Germany News RSS-Feed

    von Veröffentlicht: 19.04.2019 18:10
    1. Kategorien:
    2. Projekte

    Der März brachte erwartungsgemäß wieder weniger Primzahlfunde als der Februar, unter den 128 Funden war jedoch immerhin die erste Top-100-Primzahl von PrimeGrid in diesem Jahr. 22-mal sind Mitglieder von SETI.Germany als Erstfinder in Aktion getreten, 6-mal als Doublechecker.

    Der Top-100-Fund gelang bei GFN-19 und wurde bereits in den Projektnachrichten bekanntgegeben:
    • 2733014^524288+1, 3374655 Dezimalstellen, gefunden von Yair Givoni (Team: The Planetary Society) aus Israel am 18.03.2019 um 08:26:42 MEZ


    Es gab acht weitere Megaprimzahlfunde:
    • Die 1087414-stellige Proth-Primzahl 1005*2^3612300+1 wurde am 01.03.2019 um 13:02:33 MEZ von 288larsson (Sicituradastra.) aus Schweden mit einem Intel Core i7-4770K gefunden, wobei für den Primalitätstest mit LLR auf 4 Threads etwa 18 Minuten benötigt wurden. Die Bestätigung erfolgte am 01.03.2019 um 18:03:19 MEZ durch usverg aus Russland mit einem Intel Core i5-3470, wobei für den Primalitätstest mit LLR etwa 3 Stunden 2 Minuten benötigt wurden.

    • Die 1018006-stellige verallgemeinerte Fermat-Primzahl 58447642^131072+1 wurde am 03.03.2019 um 03:51:27 MEZ von DeleteNull (SETI.Germany) aus Deutschland mit einer NVIDIA GeForce GTX 1070 Ti in Verbund mit einem Intel Core i7-6700K gefunden, wobei für den PRP-Test mit Genefer 7 Minuten 31 Sekunden benötigt wurden. Die Bestätigung erfolgte am 03.03.2019 um 03:54:29 MEZ durch Robert Hoffman aus den Vereinigten Staaten mit einer NVIDIA GeForce GTX 1080 Ti in Verbund mit einem Intel Core i9-7980XE, wobei für den PRP-Test mit Genefer6 Minuten 41 Sekunden benötigt wurden.

    • Die 1018006-stellige verallgemeinerte Fermat-Primzahl 58447816^131072+1 wurde am 03.03.2019 um 04:05:20 MEZ von DeleteNull (SETI.Germany) aus Deutschland mit einer NVIDIA GeForce GTX 1080 in Verbund mit einem Intel Core i7-7820X gefunden, wobei für den PRP-Test mit Genefer 6 Minuten 52 Sekunden benötigt wurden. Die Bestätigung erfolgte am 03.03.2019 um 05:40:14 MEZ durch Medijate (The Knights Who Say Ni!) aus den Vereinigten Staaten mit einer NVIDIA GeForce GTX 1080 in Verbund mit einem Intel Core i7-8700K, wobei für den PRP-Test mit Genefer 6 Minuten 51 Sekunden benötigt wurden.

    • Die 1018080-stellige verallgemeinerte Fermat-Primzahl 58523466^131072+1 wurde am 05.03.2019 um 11:52:41 MEZ von Dad (Storm) aus Australien mit einer NVIDIA GeForce GTX 1070 Ti in Verbund mit einem Intel Core i7-8700K gefunden, wobei für den PRP-Test mit Genefer 9 Minuten 28 Sekunden benötigt wurden. Die Bestätigung erfolgte am 05.03.2019 um 12:26:50 MEZ durch [AF>EDLS]GuL (L'Alliance Francophone) aus Frankreich mit einer NVIDIA GeForce GTX TITAN Black in Verbund mit einem Intel Core i7-4790K, wobei für den PRP-Test mit Genefer 11 Minuten 38 Sekunden benötigt wurden.

    • Die 1087935-stellige Proth-Primzahl 95*2^3614033+1 wurde am 06.03.2019 um 15:28:59 MEZ von LucasBrown (XKCD) aus den Vereinigten Staaten mit einem Intel Core i7-6700K gefunden, wobei für den Primalitätstest mit LLR etwa 50 Minuten benötigt wurden. Die Bestätigung erfolgte am 06.03.2019 um 22:11:43 MEZ durch royanee (PrimeSearchTeam) aus den Vereinigten Staaten mit einem Intel Core i7-6700, wobei für den Primalitätstest mit LLR etwa 2 Stunden 8 Minuten benötigt wurden.

    • Die 1018145-stellige verallgemeinerte Fermat-Primzahl 58589880^131072+1 wurde am 08.03.2019 um 02:01:21 MEZ von vko (University of Maryland) aus den Vereinigten Staaten mit einer NVIDIA GeForce GTX 1080 Ti in Verbund mit einem Intel Core i9-7940X gefunden, wobei für den PRP-Test mit Genefer 5 Minuten 59 Sekunden benötigt wurden. Die Bestätigung erfolgte am 08.03.2019 um 02:12:29 MEZ durch Robert Hoffman aus den Vereinigten Staaten mit einer NVIDIA GeForce GTX 1080 Ti in Verbund mit einem Intel Core i9-7980XE, wobei für den PRP-Test mit Genefer 6 Minuten 22 Sekunden benötigt wurden.

    • Die 1089299-stellige Proth-Primzahl 485*2^3618563+1 wurde am 22.03.2019 um 15:35:16 MEZ von ext2097 (SETIKAH@KOREA) aus der Republik Korea mit einem Intel Xeon E3-1231 v3 gefunden, wobei für den Primalitätstest mit LLR auf 4 Threads etwa 18 Minuten benötigt wurden. Die Bestätigung erfolgte am 22.03.2019 um 17:37:46 MEZ durch beijinghouse mit einem Intel Xeon E5-2680 v2, wobei für den Primalitätstest mit LLR etwa 2 Stunden 41 Minuten benötigt wurden.

    • Die 1018697-stellige verallgemeinerte Fermat-Primzahl 59161754^131072+1 wurde am 31.03.2019 um 18:43:47 MEZ von Frank aus den Niederlanden mit einer NVIDIA GeForce RTX 2080 in Verbund mit einem AMD Ryzen 7 2700X gefunden, wobei für den PRP-Test mit Genefer 4 Minuten 20 Sekunden benötigt wurden. Die Bestätigung erfolgte am 31.03.2019 um 19:27:03 MEZ durch pons66 (SETI.Germany) aus Deutschland mit einer NVIDIA GeForce GTX 970 in Verbund mit einem Intel Core i7-5820K, wobei für den PRP-Test mit Genefer 14 Minuten 25 Sekunden benötigt wurden.


    Auch ein erweiterter verallgemeinerter Fermatzahl-Teiler wurde gefunden:
    • Die 461652-stellige Proth-Primzahl 1303*2^1533564+1 ist ein Teiler der erweiterten verallgemeinerten Fermat-Zahl xGF(1533561,8,5)=8^2^1533561+5^2^1533561. Sie wurde am 12.03.2019 um 15:15:46 MEZ von yank (Aggie The Pew) aus den Vereinigten Staaten mit einem Intel Core i7-7700 gefunden, wobei für den Primalitätstest mit LLR etwa 17 Minuten benötigt wurden. Die Bestätigung erfolgte am 12.03.2019 um 19:51:02 MEZ durch BenCovert (Parker Square) aus den Vereinigten Staaten mit einem Intel Core i3-7100U, wobei für den Primalitätstest mit LLR etwa 32 Minuten benötigt wurden.


    Die weiteren 118 Primzahlfunde verteilen sich wie folgt auf die Subprojekte:
    • Proth Prime Search (PPS): 1 Fund: 569*2^2711451+1 (816231 Dezimalstellen)
    • Proth Prime Search Extended (PPSE): 22 Funde im Bereich 1532479 ≤ n ≤ 1534801 (461326-462025 Dezimalstellen), darunter ein Erstfund und ein Doublecheck von Patrick Schmeer, je ein Erstfund von Flow und ID4 sowie ein Doublecheck von pan2000
    • Sophie Germain Prime Search (SGS): 51 Funde im Bereich 4309361479185 ≤ k ≤ 4358030432787 (388342 Dezimalstellen), darunter zwölf Erstfunde und drei Doublechecks von DeleteNull sowie ein Erstfund von JayPi
    • Generalized Fermat Prime Search (n=15): 26 Funde im Bereich 116322280 ≤ b ≤ 119482198 (264296-264678 Dezimalstellen), darunter drei Erstfunde von boss sowie ein Erstfund von Patrick Schmeer
    • Generalized Fermat Prime Search (n=16): 16 Funde im Bereich 57955358≤ b ≤ 59282734 (508763-509407 Dezimalstellen)
    • Generalized Fermat Prime Search (n=17 low): 2 Funde: 14613898^131072+1 (939101 Dezimalstellen), 14790404^131072+1 (939784 Dezimalstellen)


    von Veröffentlicht: 19.04.2019 11:00
    1. Kategorien:
    2. Projekte

    Außer dem kürzlich erwähnten Artikel wurde im letzten Jahr noch eine weitere Arbeit zum Gravitationswellenereignis GW170817 bei Astronomy & Astrophysics eingereicht. Demnach ergeben sich in den Simulationen tendenziell eher kurze Zeiträume zwischen Abschluss der Entstehung der ursprünglichen Doppelsterne und der Verschmelzung der daraus hervorgegangenen Neutronensternpaare (als Verzögerungszeit bezeichnet), was derzeitig zu Abweichungen zwischen Simulationen und Beobachtungen führt.

    Weiterer Artikel über GW170817
    Bitte entschuldigt die späte Benachrichtigung!

    Weitere Forschungsergebnisse über die berühmte Quelle GW170817, welche mit Universe@Home erhaltene Daten verwenden, wurden im vergangenen Jahr veröffentlicht. In dieser Studie wurde gezeigt, dass die Verschmelzungsraten von Doppel-Neutronensternen (aus einer direkten Beobachtung berechnet) weiterhin den Erwartungen aus den Beobachtungen von Doppelpulsaren in der Milchstraße widersprechen. Grund dafür ist die Verzögerungszeitverteilung, welche kürzere Verzögerungszeiten bevorzugt. Die Studie betont das Problem, auf welches Wissenschaftler beim Versuch stoßen, die Entwicklungsvorhersagen und die Beobachtungen der ersten Neutronensternverschmelzung zu verknüpfen.

    Der Originalartikel ist hier zu finden:
    https://arxiv.org/abs/1812.10065 (engl.)
    19.04.2019, 6:25:22 MEZ

    Originaltext:
    Zitat Zitat von https://universeathome.pl/universe/forum_thread.php?id=413
    Another paper on GW170817
    Sorry for late notification!

    Another research on the famous GW170817 source, which used data obtained from the Universe@Home project, have been published last year. In this study, it was shown that the merger rates of double neutron stars (calculated from one direct observation) stay in contradiction with these inferred from the observations of double pulsars in our Galaxy. The reason behind this tension is the delay time distribution which favours short delays. The study highlights the problem that scientist encounter trying to connect evolutionary predictions and the observations of the first double neutron star merger.

    The original paper can be found here:
    http://adsabs.harvard.edu/abs/2018arXiv181210065B
    19 Apr 2019, 5:25:22 UTC
    von Veröffentlicht: 19.04.2019 10:25
    1. Kategorien:
    2. Projekte

    Seit gestern können die Ergebnisse des Subprojektes CMS Simulation nicht mehr auf den Hintergrundspeicher geschrieben werden. Aus Teilnehmersicht fällt das nicht sofort auf, aber das Projekt bittet darum, vorerst keine neuen Aufgaben dieses Subprojektes zu bearbeiten.

    Problem beim Schreiben der Ergebnisse von CMS-Aufgaben; bitte meidet CMS-Aufgaben, bis wir den Grund gefunden haben
    Seit irgendwann in der letzten Nacht scheinen die CMS-Aufgaben ihre Ergebnisse nicht mehr auf den CERN-Speicher (DataBridge) schreiben zu können. BOINC-Aufgaben sind nicht betroffen, sie laufen weiterhin und Credits werden vergeben, soweit ich das sehen kann. In der Übersicht werden die Aufgaben jedoch als fehlerhaft angezeigt, daher die großen roten Bereiche in den Grafiken zu den Aufgaben.
    Bis wir das Problem lokalisiert haben, ist es am besten, keine neuen Aufgaben zuzulassen oder CMS-Aufgaben anderweitig zu umgehen. Ich lasse euch wissen, wenn alles wieder normal läuft.
    18.04.2019, 16:44:45 MEZ

    Originaltext:
    Zitat Zitat von https://lhcathome.cern.ch/lhcathome/forum_thread.php?id=4998
    Problem writing CMS job results; please avoid CMS tasks until we find the reason
    Since some time last night CMS jobs appear to have problems writing results to CERN storage (DataBridge). It's not affecting BOINC tasks as far as I can see, they keep running and credit is given. However, Dashboard does see the jobs as failing, hence the large red areas on the job plots.
    Until we find out where the problem lies, it's best to set No New Tasks or otherwise avoid CMS jobs. I'll let you know when things are back to normal again.
    18 Apr 2019, 15:44:45 UTC
    von Veröffentlicht: 10.04.2019 08:25
    1. Kategorien:
    2. Projekte

    Geplante Wartung am Donnerstag, 11. April

    Zusammenfassung
    Wir aktualisieren das Betriebssystem auf unseren Servern am Donnerstag, den 11. April, um 16:00 Uhr MESZ.
    ---
    Wir werden am Donnerstag, den 11. April, um 16:00 Uhr MESZ ein wichtiges Betriebssystem-Update auf unseren Server durchführen. Wir gehen davon aus, dass die Arbeit etwa drei Stunden dauern wird.

    Eine Zeit lang können die Teilnehmer keine neuen Arbeiten hochladen oder herunterladen und die Webseite ist nicht zugänglich.

    Die Teilnehmer müssen keine besonderen Maßnahmen ergreifen, da ihre Geräte nach Abschluss der Wartungsarbeiten ihre Verbindungen automatisch wiederherstellen.

    Wir bedanken uns für Ihre Geduld und Ihre Teilnahme.
    09.04.2019

    Originaltext:
    Zitat Zitat von https://www.worldcommunitygrid.org/about_us/viewNewsArticle.do?articleId=592
    Planned Maintenance on Thursday, April 11

    Summary
    We are updating the operating system on our servers on Thursday, April 11, beginning at 14:00 UTC.
    ---
    We will be applying an important operating system update to our servers on Thursday, April 11, beginning at 14:00 UTC. We anticipate that the work will take approximately three hours.

    During some of this time, volunteers will not be able to upload or download new work, and the website will not be accessible.

    Volunteers will not need to take any particular action, as your devices will automatically retry their connections after the maintenance work is completed.

    We appreciate your patience and participation.
    9 Apr 2019
    von Veröffentlicht: 10.04.2019 08:15
    1. Kategorien:
    2. Projekte

    Fast drei Monate hat es gedauert bis zum ersten Megaprimzahlfund dieses Jahres, der die Top 100 der größten bekannten Primzahlen erreicht und daher mit einer eigenen Meldung in den Projektnachrichten gewürdigt wird.

    GFN-524288-Megaprimzahl!
    Am 18. März 2019 um 08:26:42 MEZ hat PrimeGrids Generalized Fermat Prime Search eine verallgemeinerte Fermat-Megaprimzahl gefunden:

    2733014^524288+1

    Die Primzahl hat 3374655 Dezimalstellen und erreicht Chris Caldwells Datenbank der größten bekannten Primzahlen auf Platz 3 für verallgemeinerte Fermat-Primzahlen und Platz 26 insgesamt.

    Die Entdeckung gelang Yair Givoni aus Israel mit einer NVIDIA GeForce GTX 960 in Verbund mit einem Intel Core i5-6600 @ 3,30 GHz mit 16 GB RAM unter Windows 10. Diese GPU brauchte etwa 2 Stunden 57 Minuten für den PRP-Test mit GeneferOCL3. Yair ist Mitglied des Teams The Planetary Society.

    Die Primalität dieser PRP wurde mit einem Intel Xeon E3-1240 v6 @ 3,70 GHz mit 4 GB RAM unter Debian-Linux bewiesen. Dieser Rechner brauchte etwa 26 Stunden 43 Minuten für den Primalitätstest mit LLR im Multithread-Betrieb.

    Für weitere Einzelheiten siehe bitte die offizielle Bekanntgabe.
    10.04.2019 | 1:28:50 MEZ

    Originaltext:
    Zitat Zitat von https://www.primegrid.com/forum_thread.php?id=8545
    GFN-524288 Mega Prime!
    On 18 March 2019, 07:26:42 UTC, PrimeGrid’s Generalized Fermat Prime Search found the Generalized Fermat mega prime:

    2733014^524288+1

    The prime is 3,374,655 digits long and enters Chris Caldwell's The Largest Known Primes Database ranked 3rd for Generalized Fermat primes and 26th overall.

    The discovery was made by Yair Givoni of Israel using an NVIDIA GeForce GTX 960 in an Intel(R) Core(TM) i5-6600 CPU @ 3.30GHz CPU with 16GB RAM, running Windows 10. This GPU took about 2 hours 57 minutes to probable prime (PRP) test with GeneferOCL3. Yair is a member of The Planetary Society team.

    The PRP was confirmed prime by an Intel(R) Xeon(R) CPU E3-1240 v6 @ 3.70GHz with 4GB RAM, running Linux Debian. This computer took about 26 hours and 43 minutes to complete the primality test using multithreaded LLR.

    For more details, please see the official announcement.
    10 Apr 2019 | 0:28:50 UTC
    von Veröffentlicht: 07.04.2019 19:00
    1. Kategorien:
    2. BOINC Pentathlon

    Back to the Pentathlon pages



    BOINC Pentathlon 2019

    BOINC Pentathlon 2019


    Dear Volunteer Computing enthusiasts all over the world,

    here we go again. From 05 May to 19 May, the tenth BOINC Pentathlon will impose the known, but also new challenges, and SETI.Germany warmly invites all enthusiast teams to join.

    While the basic concept of five disciplines at five projects of course remains untouched, there are again some innovations: Javelin Throw is a fresh and new discipline and requires the teams to cleverly split their resources, as the rankings are not based on the sum of all points, but only on each team's third best day out of five (not necessarily consecutive) days. This year's Marathon will take place at a subproject of the World Community Grid chosen by the project administrators. The preferences of the participating teams are taken into account, with some limitations, for choosing the projects for the other disciplines.

    Until 27 April, the teams can sign up and vote for their favorite projects. So, don't be shy and join:

    It will be exciting again at the BOINC Pentathlon!



    BOINC Pentathlon 2019


    Chers enthousiastes du calcul partagé du monde entier,

    C'est reparti! Le dixième BOINC Pentathlon proposera des défis connus et nouveaux du 05 au 19 mai et SETI.Germany invite cordialement toutes les équipes enthousiastes à y participer.

    Le concept de base - cinq disciplines sur cinq projets - est bien sûr maintenu, mais cette année aussi il y aura quelques nouveautés: Le Lancer de javelot est une discipline toute nouvelle qui demandera une répartition judicieuse des forces de la part des équipes, car ce ne sera pas le total des points obtenus, mais seulement la troisième meilleure journée de cinq jours (pas forcément consécutifs) qui décidera du classement. Cette année, le Marathon aura lieu sur un sous-projet de World Community Grid choisi par les administrateurs du projet. En ce qui concerne le choix des projets pour les autres disciplines, les préférences des équipes participantes seront prises en compte dans le cadre d'une présélection.

    Les équipes peuvent s'inscrire jusqu'au 27 avril et voter pour leurs projets préférés. N'hésitez pas et participez car:

    Le BOINC Pentathlon sera encore captivant!



    BOINC Pentathlon 2019


    Liebe Volunteer-Computing-Enthusiasten in aller Welt,

    es geht wieder los. Der zehnte BOINC Pentathlon wird vom 05. bis 19. Mai bekannte und auch neue Herausforderungen bieten, zu denen SETI.Germany alle Enthusiasten-Teams herzlich einlädt.

    Das Grundkonzept von fünf Disziplinen bei fünf Projekten bleibt natürlich erhalten, jedoch gibt es auch in diesem Jahr einige Neuerungen: Das Speerwerfen ist eine frische, neue Disziplin und verlangt eine geschickte Kräfteeinteilung von den Teams, da nicht die Summe aller ercrunchten Punkte, sondern lediglich der jeweils drittbeste von fünf (nicht unbedingt aufeinanderfolgenden) Tagen über die Platzierungen entscheidet. Der Marathon findet in diesem Jahr bei einem Subprojekt des World Community Grid nach Wahl der Projektbetreiber statt. Bei der Auswahl der Projekte für die übrigen Disziplinen werden die Vorlieben der teilnehmenden Teams im Rahmen einer Vorauswahl berücksichtigt.

    Bis zum 27. April können sich die Teams anmelden und dabei für ihre Lieblingsprojekte abstimmen. Zögert nicht und seid dabei, denn:

    Es wird wieder spannend beim BOINC Pentathlon!
    von Veröffentlicht: 06.04.2019 07:00
    1. Kategorien:
    2. Projekte

    Die Entwicklung der GPU-Anwendung hat zu einer signifikanten Optimierung der CPU-Anwendung geführt, wodurch nun im Umkehrschluss die typische GPU nur noch so schnell wie zwei bis drei CPU-Kerne und daher weniger effizient ist.

    Neuigkeiten zur GPU-Anwendung
    In der letzten Woche hat es einige neue Entwicklungen gegeben. Sie sind sowohl gut als auch schlecht.

    Zuerst einmal etwas Geschichte. Der Grund, warum ich so lange gewartet habe, um eine GPU-App zu entwickeln, ist, dass die Berechnung stark von Multipräzisionsbibliotheken (gmp) und zahlentheoretischen Bibliotheken (pari/gp) abhängig war. Beide verwenden dynamisch zugewiesenen Speicher, was bei GPUs ein großes Tabu ist. Ich fand online eine Multi-Präzisionsbibliothek, die ich verwenden konnte, indem ich die Genauigkeit bis zum maximal erforderlichen Wert (ca. 750 Bit) fest kodierte und so die Abhängigkeit von Speicherzuweisungen beseitigte. Das nächste Teil des Puzzles bestand darin, eine polynomale Diskriminanzfunktion zu kodieren. Danach konnte ich endlich einen Kernel für die GPU kompilieren. Das ist die Historie für die aktuelle GPU-App. Sie ist etwa 20 bis 30 mal schneller als die aktuelle CPU-Version (abhängig von WU und CPU/GPU-Geschwindigkeiten).

    Aber dann dachte ich nach.... mein GPU polynomialer Diskriminanzalgorithmus unterscheidet sich von dem in der PARI-Bibliothek (ihrer funktioniert für jeden Grad und meiner ist auf Grad 10 spezialisiert). Um also einen direkten Vergleich zu machen, habe ich den PARI-Algorithmus durch meinen in der CPU-Version des Codes ersetzt. Ich war schockiert von dem, was ich fand.... die CPU-Version war jetzt etwa 10x schneller als früher. Ich hätte nie gedacht, dass ich in der Lage wäre, einen Algorithmus zu schreiben, der 10x schneller wäre als eine gut etablierte Bibliotheksfunktion. WTF? Jetzt trete ich mir in den Hintern, weil ich das nicht früher gemacht habe!

    Das bringt gemischte Emotionen mit sich. Auf der einen Seite ist es toll, dass ich jetzt eine CPU-Version habe, die 10x schneller ist. Aber es bedeutet auch, dass mein GPU-Code totaler Mist ist. Mit all der Leistung in einer heutigen GPU würde ich erwarten, dass sie mindestens 10x schneller ist als die entsprechende CPU-Version. Im Vergleich zur neuen CPU-Version ist die GPU nur 2 bis 3 mal schneller. Das ist inakzeptabel.

    Der neue Plan sieht also wie folgt aus:
    1. Neue CPU-Ausführungsdateien bereitstellen. Da sie um das 10-fache schneller sind, muss ich die Credits um den Faktor 10 reduzieren. (Die Credits pro Stunde bleiben für die CPU gleich, fallen aber für die GPU offensichtlich ab).
    2. Entwicklung neuer und verbesserter GPU-Kernel.

    Ich kann es den GPU-Benutzern nicht verübeln, dass sie an dieser Stelle das Schiff verlassen haben. Offen gesagt, die Ineffizienz der aktuellen GPU-App macht es einfach nicht wert (für sie oder das Projekt).

    Wie dem auch sei, ich hatte openCL-Versionen gebaut. Die Nvidia-Version funktioniert perfekt. Die AMD-Version ist aus irgendeinem Grund fehlerhaft, ebenso wie die Windows-Version. Da ich die Kernel sowieso ändern werde, hat es keinen Sinn, sie noch zu debuggen.
    06.04.2019, 00:40:01 MEZ

    Originaltext:
    Zitat Zitat von https://numberfields.asu.edu/NumberFields/forum_thread.php?id=366
    GPU app status update
    So there have been some new developments over the last week. It's both good and bad.

    First of all, some history. The reason I waited so long to develop a GPU app is because the calculation was heavily dependent on multi-precision libraries (gmp) and number theoretic libraries (pari/gp). Both of these use dynamically allocated memory which is a big no-no in GPUs. I found a multi-precision library online that I could use by hard coding the precision to the maximum required (about 750 bits), thereby removing the dependence on memory allocations. The next piece of the puzzle was to code up a polynomial discriminant function. After doing this, I could finally compile a kernel for the GPU. That is the history for the current GPU app. It is about 20 to 30 times faster than the current cpu version (depends on WU and cpu/gpu speeds).

    But then I got thinking... my GPU polynomial discriminant algorithm is different from the one in the PARI library (theirs works for any degree and mine is specialized to degree 10). So to do a true apples-to-apples comparison, I replaced the PARI algorithm with mine in the cpu version of the code. I was shocked by what I found... the cpu version was now about 10x faster than it used to be. I never thought I was capable of writing an algorithm that would be 10x faster than a well established library function. WTF? Now I'm kicking myself in the butt for not having done this sooner!

    This brings mixed emotions. On one side, it is great that I now have a cpu version that is 10x faster. But it also means that my GPU code is total crap. With all the horsepower in a present day GPU I would expect it to be at least 10x faster than the equivalent cpu version. Compared with the new cpu version, the gpu is only 2 to 3 times faster. That is unacceptable.

    So the new plan is as follows:
    1. Deploy new cpu executables. Since it's 10x faster, I will need to drop the credit by a factor of 10. (Credits/hour will remain the same for the cpu but will obviously drop for the GPU)
    2. Develop new and improved GPU kernels.

    I don't blame the GPU users for jumping ship at this point. Frankly, the inefficiency of the current GPU app just makes it not worth it (for them or the project).

    For what it's worth, I did have openCL versions built. Nvidia version works perfectly. The AMD version is buggy for some reason, as is the windows version. Since I will be changing the kernels anyways, there is no point in debugging them yet.
    5 Apr 2019, 23:40:01 UTC
    von Veröffentlicht: 31.03.2019 22:15
    1. Kategorien:
    2. Projekte

    NFS@Home verwendet nun die neueste Version der BOINC-Serversoftware. Anders als bei anderen Projekten mit aktueller Serversoftware wurden die erweiterten Datenschutz-Optionen nicht aktiviert, sodass die Statistikseiten weiterhin Daten aller Teilnehmer erhalten.

    Aktualisierungen
    Die letzte Projektnachricht ist schon eine ganze Weile her, aber die Arbeit schritt voran. Auf den Statusseiten (hier und hier [engl.], Anm. d. Übersetzers) könnt ihr die zahlreichen vervollständigten Faktorisierungen verfolgen. Außerdem habe ich gestern die BOINC-Serversoftware auf die neueste Version aktualisiert.
    28.03.2019, 22:03:04 MEZ


    Die auffälligste Änderung ist somit, dass Benutzer ihr Konto nun löschen können, falls gewünscht:

    Möglichkeit zum Löschen des Benutzerkontos ist nun aktiviert
    Wie von der aktuellen BOINC-Serversoftware unterstützt, habe ich die Option aktiviert, dass ihr euer NFS@Home-Benutzerkonto auf Wunsch löschen könnt. Bitte nehmt zur Kenntnis, dass dies endgültig ist, wenn ihr das tut. Gelöschte Benutzerkonten werden aus der Datenbank entfernt und können nicht wiederhergestellt werden.
    29.03.2019, 8:16:15 MEZ


    Originaltexte:
    Zitat Zitat von https://escatter11.fullerton.edu/nfs/forum_thread.php?id=740
    Updates
    It's been quite a while since the last news post, but work has been continuing. On the status pages you can follow the many completed factorizations. Also, I yesterday I updated the BOINC server code to the latest version.
    28 Mar 2019, 21:03:04 UTC
    Zitat Zitat von https://escatter11.fullerton.edu/nfs/forum_thread.php?id=741
    Option to delete your account is now enabled
    As supported by the current BOINC server software, I have enabled the option to delete your NFS@Home account if you wish. Please note that if you choose to do so, it is permanent. Deleted accounts are removed from the database and cannot be recovered.
    29 Mar 2019, 7:16:15 UTC
    von Veröffentlicht: 28.03.2019 21:55
    1. Kategorien:
    2. Projekte

    Genau ein Jahr nach der ersten Vorwarnung steht das Erreichen der optimalen Siebtiefe für den aktuellen Suchbereich des Subprojektes Generalized Cullen/Woodall Prime Search nun unmittelbar bevor. Ab dem 1. Mai werden bis auf weiteres keine neuen GCW-Sieve-WUs mehr erzeugt.

    GCW-Sieve wird am 1. Mai abgeschaltet
    Dies ist die offizielle 30-Tage-Warnung.

    Am 1. Mai werden wir die WU-Erzeugung für das Subprojekt GCW-Sieve abschalten. Wir erwarten, dass bis dahin alle Basen die optimale Siebtiefe erreicht haben werden.

    Falls ihr noch weitere Punkte für ein Abzeichen oder Stunden für WUProp braucht, ist es jetzt an der Zeit, sich diese zu sichern.

    Für weitere Informationen und die Diskussion siehe bitte diesen Thread.
    28.03.2019 | 21:40:06 MEZ

    Originaltext:
    Zitat Zitat von https://www.primegrid.com/forum_thread.php?id=8528
    GCW Sieve is shutting down May 1st
    This is the official 30 day warning.

    On May 1st we will turn off the work generator for the GCW Sieve project. We expect all bases to have reached optimal sieving depth by then.

    If you need extra credit for a badge or hours for WUProp, now is the time to get it.

    For more information and discussion, please see this forum thread.
    28 Mar 2019 | 20:40:06 UTC
    von Veröffentlicht: 25.03.2019 09:00
    1. Kategorien:
    2. Projekte

    Eine vorläufige Fassung eines Fachartikels über die Suche nach kontinuierlichen Gravitationswellen von drei Supernova-Überresten wurde auf arXiv hochgeladen.

    Neuer Artikel über E@H-Ergebnisse auf arXiv verfügbar
    Ein neuer Artikel über die Ergebnisse der O1MD1-Suche von Einstein@Home ist jetzt auf dem Vordruck-Server arXiv unter https://arxiv.org/abs/1903.09119 (engl.) verfügbar. Während keine astrophysikalischen Signale gefunden wurden, beschreibt der Artikel "Results from an Einstein@Home search for continuous gravitational waves from Cassiopeia A, Vela Jr. and G347.3" (engl., Ergebnisse einer Einstein@Home-Suche nach kontinuierlichen Gravitationswellen von Cassiopeia A, Vela Jr. und G347.3) die Suche und setzt eine Obergrenze für die Amplitude kontinuierlicher Gravitationswellen von diesen drei Supernova-Überresten mit einer bisher unerreichten Empfindlichkeit. Der Artikel wird nun bei einem Journal zur Begutachtung und Veröffentlichung eingereicht.

    Die drei Objekte wurden aufgrund des geschätzten Alters und der Entfernung zu den Supernova-Überresten mittels einer Optimierungsroutine, die wir in den vergangenen Jahren entwickelt haben, ausgewählt. Während wir Röntgenstrahlung von diesen Objekten sehen können, wurden bisher keine zugehörigen Pulsationen in Radiowellen oder einem anderen Teil des elektromagnetischen Spektrums beobachtet. Das bedeutet, dass die Eigendrehungsfrequenz dieser Objekte unbekannt ist und wir daher einen sehr großen Bereich von Frequenzen und möglichen Frequenz-Entwicklungen durchsuchen mussten. Nur mit der Hilfe der massiven Rechenleistung der Freiwilligen von Einstein@Home konnten wir diese Ergebnisse erreichen.

    Während sich unsere Methoden, die Rechenleistung und die Empfindlichkeit der Detektoren verbessern, setzen wir die Jagd nach kontinuierlichen Gravitationswellen fort und laden die E@H-Freiwilligen ein, uns weiterhin bei dieser spannenden Forschungsaufgabe zu unterstützen.

    Im Auftrag von M. Alessandra Papa für das Einstein@Home-Team
    24 Mar 2019 18:40:02 UTC

    Originaltext:
    Zitat Zitat von https://einsteinathome.org/content/new-eh-results-paper-available-arxiv
    New E@H results paper available on arXiv
    A new paper describing the results of the O1MD1 Einstein@Home search is now available on the arXiv preprint server at https://arxiv.org/abs/1903.09119. While no astrophysical signals were found, "Results from an Einstein@Home search for continuous gravitational waves from Cassiopeia A, Vela Jr. and G347.3" describes the search and sets upper limits on the amplitude of continuous gravitational waves from the three supernova remnants at an unprecedented level. of sensitivity. The paper will now be submitted to a journal for peer review and publication.

    The three targets were chosen based on the estimated age of and distance to supernova remnants, based on an optimisation procedure that we developed in the past years. While we can see those objects in X-rays, no associated pulsations in radio waves or any other part of the electromagnetic spectrum have been detected so far. This means that the spin frequency of these objects is unknown, and hence we have to search over a very broad range of frequencies and possible frequency evolutions. It is only with the help of the massive computing power provided by the volunteers of Einstein@Home that we were able to achieve these results.

    As our methods, computing power and the sensitivity of the detectors improve, we continue the hunt for continuous gravitational waves and we invite the E@H volunteers to continue to support us in this exciting science quest.

    On behalf of M. Alessandra Papa for the Einstein@Home Team
    24 Mar 2019 18:40:02 UTC

    Seite 1 von 96 1 2 3 11 51 ... Letzte
Single Sign On provided by vBSSO