Download Y-cruncher NEW!
Sara Ruballos
On the other hand, an ARM port is a possibility. Given that the entire project has never been compiled for anything outside of x86, I expect this to be a long and difficult journey that may be too much of a distraction from the main project goals. While I don't believe it is difficult to get y-cruncher to compile and run correctly for ARM, making it performant is another story.
The minimum performance target is to beat x86 emulation on Windows. From what I've heard, running y-cruncher with fast x86 emulation (no total store ordering) isn't terrible in performance - though sketchy from a correctness standpoint. (y-cruncher makes fairly extensive use of lockless programming, the fact that it runs at all without total store ordering surprises me.)
Because of the memory-intensive nature of computing Pi and other constants, y-cruncher needs a lot of memory bandwidth to perform well. In fact, the program has been noticably memory bound on nearly all high-end desktops since 2012 as well as the majority of multi-socket systems since at least 2006.
Don't be surprised if y-cruncher exposes instabilities that other applications and stress-tests do not. y-cruncher is unusual in that it simultaneously places a heavy load on both the CPU and the entire memory subsystem.
y-cruncher has a lot of settings for tuning parallel performance. By default, it makes a best effort to analyze the hardware and pick the best settings. But because of the virtually unlimited combinations of processor topologies, it's difficult for y-cruncher to optimally pick the best settings for everything. So sometimes the best performance can only be achieved with manual settings.
Large pages used to not matter in the past, but they do now in the post-Spectre/Meltdown world. Mitigations for the Meltdown vulnerability can have a noticeable performance drop for y-cruncher (up to 5% has been observed). It turns out that turning on large pages can mitigate the penalty for this mitigation. (pun intended)
Anyway, I noticed mainly that in the y-cruncher HWBOT Submitter, under the "Clock" column, it would list "HPET" if it was enabled. As an example, this submission shows that HPET in that column, but this one and this one do not. (I only referenced those ones, mainly because those were a couple of the scores I was chasing after). Should the sample screenshots be updated to show the HPET in that column?
Poking through a handful of the top scores, it seems like a number of the submissions from the submitter also don't have the platform clock enabled (because it's really easy to forget the rule and not enable it, and heck, even a couple of my submissions are technically missing it too), at least according to that column. It would appear the rule for the HPET being enabled for y-cruncher has been in place for awhile.
Question 1
is Y-CRUNCHER - Pi-1B constrained to use Y-cruncher v0.78.9507 and Benchmate y-cruncher 0.710 (if ycruncher 0.8.2 is used then it is not a valid result, submissions will need to be monitored and reported)
I have y-cruncher running on my desktop. Unfortunately, I cannot figure out how to write the calculated pi to a specific number of digits onto a .txt file. The program write an output text file with the last digits, calculation time, etc, but I would like to have the file as pure triviality. Is there any way to do this? -cruncher/
Yo guys,yesterday I started running AIDA64 cache and memory benchmark when all of sudden the screens went black. I couldn't get any response of a keyboard input, the debug code of the mainboard shows up "00", even the rest button was out of order.I had to shut down the power supply to get the system down.A new start went through like everyday.All the other benchmarks I know (3DMark, Cinebench 15, 20, 23, karhu) did not cause these issues but y-cruncher does the same.What can I do about it?PPT=200TDC=140EDC=180+200 MHz.
This is the pattern of CPU utilization in a typical swap computation with 32 threads with AVX2 for a world record on y-cruncher v0.7.8.9506. I captured this from a computation of mine. You can see that at the start of the computation, the CPU is almost fully utilized since the initial steps are run on RAM, but after the program offloads to swap secondary storage, there is a clear difference between when the CPU is utilized fully, and when it is utilized less than 25% because of I/O bottlenecks. As a computation extends in time to store more digits than before, the zone where the CPU is underutilized is stretched more and more. As the time where the CPU is fully utilized is significantly less than the I/O bottlenecked time, the number of cores is not very important in conserving computation time.
First if you are running in Linux (the Windows version has all the features embedded inside as default and does not require additional installations), I recommend using the dynamic version (especially in multisocket environments) which requires the system dependencies in Ubuntu 18.04 (or distros based on this version, but Ubuntu 18.04 prevents unexpected errors) and also requires installing numactl as of y-cruncher v0.7.8.9506 and versions before that. CentOS 8 is also reported to work without any other tweaks as long as you installed numactl, you should be generally have no problems. This does not mean that your host requires only the Ubuntu 18.04 OS or CentOS 8 to run the dynamic version, instead you can run this on any recent Linux distros on the static version, but you have to be careful if you want to use the dynamic version.
If you get errors related to libcilkrts.so.5 and/or libtbb.so.2 when executing y-cruncher after this configuration (common if you run it as a remote command or with bash -c), add the full path of the Binaries directory of the y-cruncher download to the LD_LIBRARY_PATH, delimiting each directory with a colon also.
The y-cruncher program will then automaticaly choose the recommended frameworks for each component to be used based on the number of cores and you will not be restricted on the selections as long as you have the dynamic version.
Every computer is different, so they must be tuned to get its maximum throughput to decrease time dramatically. The y-cruncher program has some tools to check them. The first tool is the stress testing application, which proves that your build can initially withstand certain Fast Fourier Transform operations and other heavy computations. The second and perhaps the most important tool is the I/O Performance Analysis if you are (likely) computing with swap secondary storage like SSDs or HDDs. After getting the results you have seen with running this benchmark, you have to tweak the Far Memory Tuning configuration based on what you get. An explanation of how to do this will come up later.
For more information on speed optimization and management methods to prevent any silent corruptions in y-cruncher, read everything from the Performance Tips section of y-cruncher and every link and text under that thoroughly, which includes Algorithms and Internals, the FAQ, Multi-Threading, Memory Allocation, Swap Mode, and Custom Formulas for people who need to use this function.
Seit 2009 werden die meisten Berechnungen mathematischer Konstanten auf Weltrekordniveau mit y-cruncher durchgeführt. Die fachliche Herausforderung besteht dabei nicht (mehr) in der Berechnung an sich, sondern an der Bereitstellung einer Umgebung, die eine entsprechend zügige Durchführung ermöglicht.
The author of the y-cruncher benchmark, Alexander Yee, announced in a tweet that the upcoming version of the benchmark will see a major boost for AVX-512 hardware, especially AMD's Zen 4 core which features support for AVX-512.
y-cruncher benchmark is a popular tool to evaluate the CPU's performance for how fast it can compute PI. It's a very scalable & multi-threaded benchmark that is being used by the industry for years now and has been available for more than a decade. We also use the same benchmark in our CPU reviews.
Alexander has issued a new changelog for the upcoming y-cruncher 0.8x which is expected to be available soon and is an attempt to clean & modernize the project. Over 400,000 lines of code will be modified and that actual work on this began three years ago but little progress was made until this year. In a performance chart showing the speedup over v0.7.10, you can see that almost all of the CPUs except the older Nehalem and Ivy Bridge chips see a gain in performance in the newer build.
For our test we run y-cruncher v0.7.6 through all the different optimized variants of the binary, single threaded and multi-threaded, including the AVX-512 optimized binaries. The test is to calculate 250m digits of Pi, and we use the single threaded and multi-threaded versions of this test.
Apparently, TanteKaethe has found that very, rare sample of Intel Core i9-12900K. The enthusiast managed to overclock the processor to an impressive 6619.34 MHz and completed the y-cruncher Pi-1b benchmark with 13 sec 612 ms, which corresponds to the first place in the model score of the CPU of the same name, as well as gold in the model score of chips with eight cores.
Prawdopodobnie to będzie wina ustawionego na auto VDDQ, które wynosiło 1.25V. Obniżyłem RAM na 3800MHz i testowałem bez zmiany napięcia VDDQ i wywalało błędy, ale po wbiciu napięcia VDDQ na 1.38V i test y-cruncherem VST leciał ponad 2,5 godziny bez błędów. Będę musiał potestować jeszcze parę razy, ale z RAMem na 3900MHz tak jak miałem i zobaczę czy to faktycznie była wina zbyt niskiego napięcia VDDQ.
df19127ead