Avoiding 64-bit calculations in 32-bit application

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxx/ 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?



[Index of Archives]     [ALSA User]     [Linux Audio Users]     [Pulse Audio]     [Kernel Archive]     [Asterisk PBX]     [Photo Sharing]     [Linux Sound]     [Video 4 Linux]     [Gimp]     [Yosemite News]

  Powered by Linux