On 2015-11-29 at 6:59 'Davide Libenzi' via Akaros wrote: > On Sun, Nov 29, 2015 at 5:28 AM, barret rhoden <[email protected]> > wrote: > > http://commandcenter.blogspot.com/2012/04/byte-order-fallacy.html > > (at least I think we do). > > > > I dispute almost every single point he makes there, but I kept my > inlines the slow, fully open coded version ☺ > First, is more code? Yes, but, in many CPUs (like, Intel, which is > what matter most) is much faster.
Is the final output actually faster? Or does the compiler realize what's going on and emit the same code? I originally had the cpu_to_le32() style helpers, but held off on using more of those once we started bringing in the 9ns stuff. If the compiler isn't being smart, then maybe we get rid of the open coded ones. We'd need to see the asm. > Second, you can have a swap32() and swap64() APIs, which in Intel > turns into dedicated, single insn operation (would not matter for LE, > the most common case). That's a good point (the arch-specific instructions). > Third, alignment? Define an HAVE_FAST_UNALIGNED_ACCESS in the arch/ > domain, and use that to select the proper behavior (#if LE && > FAST_UNALIGNED -> Use single insn load/store). Seems reasonable. > Fourth, *(int)ptr? Really? ☺ Those should be using u16, u32, u64, and > not short, int, long, etc... Absolutely. =) Even the Plan 9 helpers are GBIT32, not GBITSHORT. =) Barret -- You received this message because you are subscribed to the Google Groups "Akaros" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. For more options, visit https://groups.google.com/d/optout.
