On Thu, 2009-08-27 at 17:47 +0300, Boaz Harrosh wrote: > On 08/27/2009 05:30 PM, James Bottomley wrote: > > On Thu, 2009-08-27 at 17:20 +0300, Boaz Harrosh wrote: > >> On 08/27/2009 04:41 PM, James Bottomley wrote: > >>> > >>> The general rule is not to confuse coding styles, so the correct way to > >>> add stuff is to use the existing conventions in the file. You can > >>> optionally convert the entire style if necessary. However, for these > >>> get_cpu_be macros, there's no real benefit other than saving typing, so > >>> a global conversion effort simply isn't worth it. > >>> > >> > >> This is not right. The get_cpu_be macros are ten fold faster and smaller > >> on all the platforms we ever use. I'm talking about 16-96 to 1 for a 64 bit > >> operation. > > > > Assembly comparisons didn't bear this out the last time I looked; what > > changed? > > > > I'm not sure what test you made. But for instance on x86_64 which has unaligned > cpu support, the get_unaligned_be64 is a simple SWAB instructions as opposed to > 8 "or" + 8 "shift". Not to mention BE systems which do nothing (memcpy) Well, what I saw on x86 is that gcc optimises the shifts to exactly the same code as get_unaligned_be. What does the assembly comparison look like on x86-64? However, regardless, this is hardly critical path affecting stuff. James -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
