| waltman | /dev/random also blocks, which makes it a really bad choice for benchmarking. | 00:49 |
|---|---|---|
| teddy-dbear | Morning peoples, critters and everything else | 09:46 |
| ChinnoDog | Here is my new crude CPU benchmark: dd if=/dev/urandom bs=1M count=1024 | sha256sum | 13:35 |
| ChinnoDog | It has the benefit of being able to use the dd output stats for measurement. I get 82.6MB/s | 13:36 |
| waltman | I'm still confused about what it is you think you're measuring. That pipeline uses 3 cpus. | 13:44 |
| waltman | dd + sha256sum + one to run the RNG code | 13:45 |
| ChinnoDog | One to run the rng code? I assumed dd usage would be insignificant since it is only copying bits in memory. | 13:54 |
| ChinnoDog | I guess generating random numbers could be expensive. hmm | 13:54 |
| ChinnoDog | I measured it. It is expensive. | 13:58 |
| ChinnoDog | I would need to make it run single threaded to get the number I wanted. However, both systems I am comparing have 2+ CPUs so I think it is ok for now. | 14:00 |
| waltman | Surely there are existing benchmarks to measure whatever it is you're interested in. | 14:07 |
| ChinnoDog | I couldn't find any convenient CPU benchmark tools in the default RHEL repositories which is all I have to work with. | 14:07 |
| waltman | Once you write a pipeline you're using multiple CPUs. | 14:08 |
| ChinnoDog | There must be a way to constrain all child processes from my command to a single CPU. | 14:09 |
| ChinnoDog | I could wrap it in a "sh -c" if I had to. | 14:10 |
| waltman | I really doubt it. | 14:11 |
| ChinnoDog | That sounds like a challenge. | 14:37 |
| waltman | It's kind of the point to take advantage of multiple CPUs for this. | 14:38 |
| waltman | If you want to be sure things are constrained to a single CPU, you're far better writing an actual program than trying to rely on shell tricks, especially since you don't seem to understand them well. | 14:39 |
| ChinnoDog | I understand them and I knew that there would be some parallelization, I just thought that they would be insignificant relative to the sha2 algorithm | 15:51 |
| ChinnoDog | I mean sha256. The RNG does take about 1/4 of the time of the sha256 calculation time though so I would expect if done right the command will take 25% longer when single threaded. | 15:52 |
| waltman | You fundamentally can't test just single-threaded CPU performance in a pipeline. Find a program. | 15:53 |
| waltman | Pipelines run on multiple CPUs. If you're accessing /dev/urandom, that's causing the kernel to run the random number generator and it's going to affect your results. | 15:54 |
| waltman | Also as you've discovered it's easy to guess wrong about what's going to take the time. | 15:55 |
| waltman | https://linuxconfig.org/how-to-benchmark-your-linux-system | 15:56 |
| ChinnoDog | I made it run on one core. taskset -a -c 0 sh -c "dd if=/dev/urandom bs=1M count=1024 | sha256sum" | 16:10 |
| ChinnoDog | Although I'm not letting the scheduler select the core I think the number it produces is accurate since the scheduler will just send the other processes to other cores. | 16:10 |
| ChinnoDog | Incidentally, it actually runs /faster/ when it is confined to one core. | 16:11 |
| ChinnoDog | I verified by running it with a large count for DD and verifying with top that the CPU time for dd + sha256sum <= 100% | 16:13 |
| waltman | What exactly is it you're trying to do? | 16:53 |
| waltman | Even if you confine that to a single CPU, you've still got process switching involved. | 16:54 |
| ChinnoDog | That is ok! My intent was to come up with a way to compare CPU performance on different systems. That is all. I don't need an exact measure since I only need to know if there was something wrong with one of the systems. | 17:24 |
| ChinnoDog | I used the earlier multi-threaded version to confirm that the performance of the server in question was similar to my laptop so it did not have a CPU issue. It is suffering from the usual cause of slowness. Bad programming. | 20:36 |
| ChinnoDog | No matter how fast computers get people still make them run slow by doing Bad Things | 20:38 |
| waltman | I mean, you do you, but I still think your methodology is bogus. | 20:39 |
| waltman | :) | 20:39 |
| ChinnoDog | I don't understand why. I ran a command that was restricted to one CPU and received a measurement of how fast it ran. Is that not what a benchmark is? | 20:39 |
| ChinnoDog | It took nothing into account except the raw performance of a couple common CPU intensive algorithms so it isn't great for comparing diverse hardware but that wasn't part of the design criteria. | 20:41 |
| waltman | You've got too many variables. You've got several algorithms running different processes so you've also got task switching to consider. Not to mention you're reinventing the wheel. | 20:45 |
| waltman | Any, I've given up on trying to convince you. Have fun. | 20:45 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!