Mysticial

Figured I'd drop an update. Right now I'm planning on v0.8.6 being the first version that will have additional settings. (So 2 versions away from now.) But instead of being fully configurable like the example in the opening post, it will likely be a list of built-in profiles that you can choose from. So for example, the 22-ZN4 binary defaults to the 7950X profile. But it may have additional profiles for 8c Phoenix, 96c TR, or 128c Bergamo. You will not be able to specify low-level things like the memory hierarchy or the algorithm parameter tables. At least not in this first iteration. We'll see how this goes first. -------- Long story short, while I am able to"package all the editable settings in a way that can be imported from an external source, the problem is that there are way too many of them. And many of those settings are not human consumable - meaning that it's difficult to understand how the setting affects performance. For example, there are several very large tables of values that are not too dissimilar to weights of a neural network AI. So exposing them without also exposing the tools to generate (train) those weights is kind of useless.

Please delete: https://hwbot.org/submission/5355456_mysticial_y_cruncher___pi_25b_core_i9_7940x_14min_9sec_662ms I forgot to include CPUz.

The version information is already embedded in the datafile as metadata. Assuming HWBOT keeps its datafiles, you can retroactively go back and parse that information on all existing submissions. In fact, the entire validation file that y-cruncher generates (which contains everything you need to know) is also embedded in the datafile. At least for submissions using the HWBOT Submitter. I dunno about the BenchMate submissions. So the data is there if you need it. Though it may not be convenient to access. If you want the version information in a different place, I can do that.

Apparently this was discussed in Discord. Posting a few key points here. To be clear, I have no preference on what HWBOT decides to do. I'm not a competitive overclocker and thus cannot make an informed decision. I'm just happy to see that people like the program as a benchmark. But as the developer, I can confirm that I will not and cannot maintain multiple versions of y-cruncher. This is simply not a feasible task given how volatile modern environments are with operating systems, development toolchains, etc... Therefore, development will only be on the latest version. So support for future technologies like AVX10 and APX will only be on the latest version and not backported to old versions. Likewise I cannot fix issues with old versions even if they break in a way that makes them unusable. As mat has correctly mentioned, y-cruncher is a scientific program first, benchmark second. The goal is to compute many digits of Pi as efficiently as possible by any means necessary - both hardware and software. Competitive overclocking is only the half the equation. I can also confirm this. There are many optimizations that I omitted when I rewrote the core algorithm in v0.8.1. If and when I feel like re-adding them, you can expect the program to get faster again. And of course this says nothing about future (unknown) optimizations. Right now, there's 1b, 2.5b, and 10b. And I think 5b and 25b will be added soon. That's 5 categories. If we then split this up by version, we're looking at 10 categories or more if future versions get faster. So I can see how this can get cluttered under the current HWBOT system that lacks version tracking/filtering.

Yeah, that "bug" with y-cruncher running in low priority is because it explicitly sets its own priority to below average on program launch. Thus it overrides whatever environment setting there is to launch it as. Only the built-in priority option can change this behavior. I didn't realize this was a big deal until I watched one of Buildzoid's streams and he spent a silly amount of time trying to work around this. And he couldn't add extra parameters to the command line.

Is it possible to allow the user to edit the command line that's used to launch a benchmark? For example, you can't add "-TD:24", or "priority:2" without running outside of Benchmate and submitting separately.

Here ya go! pi-10b-v0.7.10.hwbot pi-10b-v0.8.1.hwbot pi-10b-v0.8.2.hwbot

Developer here. I just noticed that I'm unable to submit y-cruncher benchmark with the old versions (v0.7.10). If I include the screenshot attachment, I get access denied. Did something change server side?

Since it looks like 30+ people voted to keep as one benchmark, I'm going re-add the HWBOT submitter app for v0.8.2 and will be backward compatible with v0.8.1. Since v0.8.2 is (likely) getting released next month, I won't bother re-releasing v0.8.1 with the HWBOT submitter app. If staff wants me to hold off, let me know.

FWIW, I expect v0.8.2 to go out in the September time-frame. Way ahead of schedule. What I thought would take months ended up taking only 3 weeks. I don't expect any major perf changes this time. (though there's a potential it will reclaim some of the perf loss on the oldest chips) Nearly all the work has been in swap mode which is not used in competitive.

How often does the driver change relative to the rest of BenchMate? Can they be separated so that BenchMate can be updated without touching the driver?

Bumping this so it doesn't fall off the radar. Since nobody can submit v0.8.1 scores anywhere yet.

y-cruncher always doubles up the # of threads/tasks if the core count is not a power-of-two. Is this backfiring only on the Zen4 7900X? Or is it backfiring on older chips as well. This is something I added many years ago to help get around load balancing issues of running DnC algorithms on non-power-of-two core chips. But I've never re-evaluated whether that is still helpful. upL_t BasicParallelism::default_tds(){ upL_t tds = Environment::GetLogicalProcessors(); // If it's not a power-of-two, double it up to help alleviate load imbalance. if ((tds & (tds - 1)) != 0){ tds *= 2; } return std::min(tds, (upL_t)YMP_MAX_THREADS); }

This is fundamentally not solvable. You would need something similar to what the Nintendo Switch does with a dedicated security chip that does the encryption/decryption. The chip itself has the key burned into it and all use of the key is inside the chip itself. I'm not sure if TPM can be utilized to make this possible. The main problem here is getting the BenchMate key into the TPM in a way that cannot be eavesdropped by a listener. You could probably do it using public-key encryption, but you can't easily stop someone from impersonating the TPM and tricking BenchMate into sending it the encryption key which can then be decrypted and recovered.

How difficult would it be to change the 2.5b submission keys to keep everything consistent? /cc @Leeghoofd I can give both of you the formula I used to generate the keys for all y-cruncher submissions - of all sizes.