Re:A binary coder for Swift
by DSMan195276 on Saturday July 29, 2017 @12:29PM
(#14881915)
You can do byte-swapping in one instruction on x86, so it really isn't something worth worrying about. There aren't many big-endian systems out there, but it doesn't really matter that much. If you wanted to, you could change this so it always stores the numbers in little-endian (and does a swap on big-endian systems) but a lot of the uses of this will likely be for networking, and people generally expect big-endian in that situation.
[ Parent
| on HN ]
> You can do byte-swapping in one instruction on x86
Well considering the vast majority of swift code runs on Apple's ARM chips (iDevices) rather than x86 processors (Mac), I think that's kind of a moot point
Moot twice, since ARM also has a single instruction for byte swapping.
Re:A binary coder for Swift
by userbinator on Saturday July 29, 2017 @01:51PM
(#14882254)
Little-endian ARM, to be precise. AFAIK Apple's only big-endian products were those based on the 68K and PowerPC.
"1 instruction on x86" doesn't really tell us much about the cost of executing that instruction. x86 has a wide variety of instructions that take varying processor resources to execute.
Re:A binary coder for Swift
by DSMan195276 on Saturday July 29, 2017 @07:00PM
(#14883418)
Yes, you're technically correct, but I can assure you that byte-swapping is fast.
It seems I should have just left out the fact that byte-swap is a single instruction on x86, I was trying to make the point that it is fast but I suppose the point missed its mark and the fact that it's a single instruction really doesn't matter. You can do the swap with a few shifts and it still takes no time at all. If speed really becomes such a factor that this is too slow doing the encoding and decoding, you'll likely be looking at replacing this framework with a more hardcoded solution, not removing byte-swaps.
Re:A binary coder for Swift
by stephencanon on Saturday July 29, 2017 @07:02PM
(#14883424)
1 or 2 uops, 1 or 2 cycles (depending on data size). So quite fast. There's also the newish MOVBE (load/store big endian), which currently performs fairly similarly to MOV + BSWAP per Agner, but could be made into a single uop in the future.