cdleary
commented
3 years ago Note that now that we have more APFloat support (courtesy of @RobSpringer) we can at least do things like shmoo the mantissa of the APFloat by tuning, say, some common-module-level-constants that the application level APFloat computations can key off of.
For the JPEG decoder example I expect we'll want some of the capability to play with numerical precision (i.e. quantization) and determine its impact on final result accuracy, since for the IDCT you can reduce the precision -- it's not specified precisely by the standard or anything (to make room for different possible implementations of IDCT).
What could be good is if in the DSL you can make parametric code independent of numerical type and then easily instantiate different ones to observe error bars, and sweep some corpus (using native JIT presumably) to observe the tradeoff space. This will tie into @RobSpringer's work on parametric floats, but we'll need to extend to fixed point library as well, and want (compile-time) polymorphism to enable the operators to work across these disparate types. If we do IDCT as a systolic array (since it's a little matmul), as I expect we will, we'd want accumulator and multiplier width to be parametric, and want to ensure earlier accumulators were getting culled down in size from the maximum accumulation width via range analysis.
Najjar's group paper on this I had read in the past which is likely relevant/interesting: https://www.cs.colostate.edu/cameron/Publications/bins_spie99.pdf