Avoiding 64-bit calculations in 32-bit application
Alan Young
consult.awy at gmail.com
Tue Jan 3 18:10:38 CET 2023
How much do we care about avoiding unnecessary 64-bit calculations in
32-bit applications?
I think I am going to have to submit another fix to
pcm_rate:snd_pcm_rate_sync_hwptr0(). I'm not sure yet, but I think that
the fix by /mahendran.kuppusamy at in.bosch.com/ can result in, at least,
off-by-one errors in the calculated value. I have yet to determine
whether the error is ever cumulative and the consequences.
My proposed fix includes (rate->slave_hw_ptr_wrap is u_int64_t):
+ if (rate->slave_hw_ptr_wrap) {
+ /*
+ * Restrict explicit 64-bit calculations to case where rate->slave_hw_ptr_wrap
+ * is non-zero, which will only happen in 32-bit environments.
+ */
+ u_int64_t wrapped_slave_hw_ptr = slave_hw_ptr + rate->slave_hw_ptr_wrap;
+ new_hw_ptr = ((wrapped_slave_hw_ptr / slave_period_size) * period_size) % boundary;
+ slave_residual = wrapped_slave_hw_ptr % slave_period_size;
+ } else {
+ new_hw_ptr = (slave_hw_ptr / slave_period_size) * period_size;
+ slave_residual = slave_hw_ptr % slave_period_size;
+ }
so it only ever does 64-bit calculations if there has been a boundary wrap.
Is that optimization desirable (assuming my fix is necessary at all) or
would it be better just to do 64-bit calculations all the time?
More information about the Alsa-devel
mailing list