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