log in |
Message boards : Number crunching : Shortest processing time ever
Author | Message |
---|---|
3.817,81 seconds (1 hour 3 minutes 37,81 seconds). <app_config>
<project_max_concurrent>8</project_max_concurrent>
</app_config> (repeat this process for all single-threaded CPU projects) | |
ID: 2968 · Reply Quote | |
It will be interesting to see if following tasks on that host crunch in the same shorter time. | |
ID: 2971 · Reply Quote | |
It could just be a smaller task. I had one such today that ran for almost 8,000 seconds rather than the usual 20,000-21,000 seconds. | |
ID: 2972 · Reply Quote | |
It could just be a smaller task. It was a "normal" task. | |
ID: 2977 · Reply Quote | |
it was just an outlier with a limited parameter set that lead to a shorter cruching time. The major factor that made this task that fast is there was nothing else running on that host at that time, so the single core turbo could kick in. Previously I had some random restarts when the folding@home was running on that host. After a week I've figured out that it's PSU-related: there are not enough power cables for the CPU and the GPU, so I've swapped the PSU. Since then it seems to be running fine at 4.7GHz on all p-cores. The processing time is around 4.100-4.300 seconds (7 TN-Grid tasks + 1 Folding@home task). (The e-cores are not that great for crunching) | |
ID: 2978 · Reply Quote | |
If you don't want to reduce the number of tasks queued on your host by limiting the number of CPU cores generally in BOINC, you can use the app_config.xml file to limit the number of simultaneous tasks for each project.A little correction: this method (just like setting a global limit on the usable CPU cores in BOINC) limits the number of tasks queued. (I've set up my host like that to verify it). The main message of this experiment is that one should not crunch (single-threaded apps) on the "virtual" (hyper-threaded) cores to achieve short runtimes. (Running too many of these tasks makes them wait for each other's FP operations, it could also easily fill up the last level cache of the CPU, resulting in increased cache misses and much slower memory transfers.) | |
ID: 2979 · Reply Quote | |
If you don't want to reduce the number of tasks queued on your host by limiting the number of CPU cores generally in BOINC, you can use the app_config.xml file to limit the number of simultaneous tasks for each project.A little correction: this method (just like setting a global limit on the usable CPU cores in BOINC) limits the number of tasks queued. (I've set up my host like that to verify it). If you don't turn off hyperthreading in the BIOS how do you guarantee only one thread per physical CPU core. The OS doesn't know the difference and will schedule threads on whatever is available. If you truly want to only run one thread on a core you have to turn off hyperthreading. | |
ID: 2980 · Reply Quote | |
If you don't turn off hyperthreading in the BIOS how do you guarantee only one thread per physical CPU core.I wrote a little batch program (for Windows) to set process affinities in order to assign tn-grid tasks to different CPU cores, but it made a very little difference. The OS doesn't know the difference and will schedule threads on whatever is available.Every recent OS knows the difference between CPU cores and threads. (On Windows you can check it in task manager, on the CPU tab you'll see how many cores and how many threads your CPU has). The recent OSes even know the difference between the "performance-cores" (p-cores) and the "efficiency-cores" (e-cores) of the recent Intel CPUs (the latter doesn't have HT, or FPU). The Ubuntu Linux 22.04 I use scedules tasks for each CPU core (and leaves it running on that core), until it runs out of cores. Windows use a different approach (spreading a high CPU load process evenly between cores to make the cores heat up evenly - probably that makes tasks run slower on Windows), but it won't use the same core for two high CPU load process until it runs out of cores. If you truly want to only run one thread on a core you have to turn off hyperthreading.That'll surely force the OS not to schedule tasks on the same core, but it's necessary only for old OSes. | |
ID: 2981 · Reply Quote | |
I've tested a PC with an i5-13600K CPU at 5.1GHz (RAM is dual chanel DDR4 at 3600MHz) under Linux. | |
ID: 3062 · Reply Quote | |
Vitis vinifera workunits: ~2110 sec (~35m 10s) | |
ID: 3169 · Reply Quote | |
Depends on computer a bit as well. | |
ID: 3171 · Reply Quote | |
I've assembled a Ryzen 9 7900X for a friend, and I'm testing it with TN-Grid. RAM non-overclocked: 4800MHz CL40 [8,3ns] 1.1V,
RAM overclocked: 5600MHz CL36 [6,43ns] 1.25V, The overclocked access time is 77% of the non-overclocked RAM, while the overclocked runtime is 91% of the non-overclocked RAM.So the Ryzen 9 7900X per core performance was around the per core performance of my i7-11700F, after the upgrade to kernel 5.19 it reached the per core performance of my i5-12400, by overclocking the RAM it's only 7% slower per core than my i9-12900F, but the Ryzen only has "performance" cores, 50% more of them than the i9-12900F, so it does 40% more work in total. You can check the runtimes here. | |
ID: 3259 · Reply Quote | |
I also recommend to enable ECO-mode, 65 watt TDP limit, via BIOS. (Part of AMD PBO settings) | |
ID: 3260 · Reply Quote | |
Message boards :
Number crunching :
Shortest processing time ever