On Sat, Jun 29, 2024, at 14:22, Dean Rasheed wrote: > However, I really don't like having these magic constants at all, > because in practice the threshold above which the Karatsuba algorithm > is a win can vary depending on a number of factors, such as whether > it's running on 32-bit or 64-bit, whether or not SIMD instructions are > available, the relative timings of CPU instructions, the compiler > options used, and probably a bunch of other things. ... > Doing a quick test on my machine, using random equal-length inputs of > various sizes, I got the following performance results: > > digits | rate (HEAD) | rate (patch) | change > --------+---------------+---------------+-------- > 10 | 6.060014e+06 | 6.0189365e+06 | -0.7% > 100 | 2.7038752e+06 | 2.7287925e+06 | +0.9%
Does the PostgreSQL community these days have access to some kind of performance farm, covering some/all of the supported hardware architectures? Personally, I have three machines: MacBook Pro M3 Max Intel Core i9-14900K AMD Ryzen 9 7950X3D In addition I usually spin up a few AWS instances of different types, but this is scary, because one time I forgot to turn them off for a week, which was quite costly. Would be much nicer with a performance farm! If one exists, please let me know and no need to read the rest of this email. Otherwise: Imagine if we could send a patch to a separate mailing list, and the system would auto-detect what catalog functions are affected, and automatically generate a performance report, showing the delta per platform. Binary functions, like numeric_mul(), should generate an image where the two axes would be the size of the inputs, and the color of each pixel should show the performance gain/loss, whereas unary functions like sqrt() should have the size of the input as the x-axis and performance gain/loss as the y-axis. How to test each catalog function would of course need to be designed manually, but maybe the detection of affected function would be automated, if accepting some false positives/negatives, i.e. benchmarking too many or too few catalog functions, given a certain patch. Catalog functions are just a tiny part of PostgreSQL, so there should of course be other tests as well to cover other things, but since they are simple to test predictably, maybe it could be a good start for the project, even if it's far from the most important thing to benchmark. I found an old performance farm topic from 2012 but it seems the discussion just stopped for some reason not clear to me. Regards, Joel
