4 ms·

This is a very nice article, and I think the three initial objectives are fully attained (simple enough, accurate enough, fast enough). Some of the performance

by stncls 5y ago

This is a very nice article, and I think the three initial objectives are fully attained (simple enough, accurate enough, fast enough). Some of the performance claims have a caveat, though: Lookup tables and micro-benchmarks don't mix well. At all. I just added a simple loop that thrashes the L3 cache every 500 iterations (diff here: https://goonlinetools.com/snapshot/code/#sm4fjqtvjyn36dyedncxh https://goonlinetools.com/snapshot/code/#sm4fjqtvjyn36dyednc...). Now the method recommended at the end (cos_table 0_001 LERP) is slower than glibc's cos() (while still having an accuracy that is more than 10^8 times worse)! Time benchmark output: cos_table_1_LERP 0.0038976235167879 cos_table_0_1_LERP 0.0042602838286585 cos_table_0_01_LERP 0.0048867938030232 cos_table_0_001_LERP 0.0091254562801794 cos_table_0_0001_LERP 0.0139627164397000 cos_math_h 0.0089332715693581 Lookup table sizes: cos_table_1_LERP 64 bytes cos_table_0_1_LERP 512 bytes cos_table_0_01_LERP 5040 bytes cos_table_0_001_LERP 50280 bytes cos_table_0_0001_LERP 502664 bytes

adgjlsfhk1 5y ago
How long does the cache thrashing loop take compared to 500 iterations? I'm not sure how much you can trash the cache while still being performance bottle-necked by a table-based implementation of a trig function.
- stncls 5y ago
  Yes of course the cache thrashing takes a lot longer. But I modified the code to time only the cos() functions (see diff), using the rdtsc instruction. That's why it had to be every 500 iterations: If it was after each iteration, then rdtsc itself would become the bottleneck!
  - adgjlsfhk1 5y ago
    My point wasn't about how you were timing the code, what I meant is in the real world, I don't think there are programs where this will be an issue because if they are thrashing their caches too much, they won't be bottlenecked on trig. The advantage of table based functions is that they are really fast if you are calling a lot of them at once, but that's also the only case where they need to be fast. If only 1/10000 instructions is trig, it's OK if the trig is a little slower.
    - gpderetta 5y ago
      The trig call might just be a small component of a piece of cide that is called very often and wants the cache for its own needs. I think that the grandparent concerns are very legitimate.

by stncls 5y ago

adgjlsfhk1 5y ago

How long does the cache thrashing loop take compared to 500 iterations? I'm not sure how much you can trash the cache while still being performance bottle-necked by a table-based implementation of a trig function.

stncls 5y ago
Yes of course the cache thrashing takes a lot longer. But I modified the code to time only the cos() functions (see diff), using the rdtsc instruction. That's why it had to be every 500 iterations: If it was after each iteration, then rdtsc itself would become the bottleneck!
- adgjlsfhk1 5y ago
  My point wasn't about how you were timing the code, what I meant is in the real world, I don't think there are programs where this will be an issue because if they are thrashing their caches too much, they won't be bottlenecked on trig. The advantage of table based functions is that they are really fast if you are calling a lot of them at once, but that's also the only case where they need to be fast. If only 1/10000 instructions is trig, it's OK if the trig is a little slower.
  - gpderetta 5y ago
    The trig call might just be a small component of a piece of cide that is called very often and wants the cache for its own needs. I think that the grandparent concerns are very legitimate.