You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
in order to make gearshifft more versatile, we could think about comparing the input and the output buffer after a iFFT(FFT(input) roundtrip. This way gearshifft can not only be used for benchmarking but also for hardware checks on the memory subsystem. This is can be very useful.
The text was updated successfully, but these errors were encountered:
this is already done in benchmark_executor.hpp and benchmark_data.hpp.
One could argument, that an error of a single transform might be not visible if it becomes "corrected" on the inverse transform. For real hardware checks a second evaluation path executed on a different memory system must be considered, i.e. result of forward and inverse transform on device A must be compared with results gathered on device B.
Since your suggestion is already implemented in gearshifft, we could rephrase it to a feature request where gearshifft should provide an interface to get the results of each transform to enable comparison.
ok, that sounds reasonable. for a first try, I would however not open
the API more. I think an automated way to cross check the transform
results would be enough for now after all repetitions are done. the
error bound should be configurable though (through a compile flag IMHO
is enough)
ah I knew I forgot a code line: the error bound and the number of runs can be changed in application.hpp. At the moment these are template values, so required at compile-time.
I will come back to your feature request at a later time. I also noted to extend the README on how error checking works in gearshifft. The idea to use a gearshifft wiki becomes stronger ...
in order to make gearshifft more versatile, we could think about comparing the input and the output buffer after a
iFFT(FFT(input)
roundtrip. This way gearshifft can not only be used for benchmarking but also for hardware checks on the memory subsystem. This is can be very useful.The text was updated successfully, but these errors were encountered: