On Sun, Nov 29, 2015 at 5:28 AM, barret rhoden <[email protected]> wrote:
> They do come from the original plan 9 code, but we can still change > them to be more descriptive (and inlines). > > One thing though is that we do want to keep the Plan 9 implementations > of those functions that do not use ifdefs: > 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. 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). 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). Fourth, *(int)ptr? Really? ☺ Those should be using u16, u32, u64, and not short, int, long, etc... For encoding/decoding a few tenths on bytes coming into a file API, maybe you can get along with the fully open coded version. But say, if you are decoding packed docdata, or a posting list payloads, the three lines of code more per function will make a difference. -- 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.
