A binary coder for Swift • Hacker News Board

Re: A binary coder for Swift

#21

Post by codys » Sat, Jul 29, 2017, 10:46 PM UTC

DSMan195276 wrote: post #9

userbinator wrote: post #5

the numbers are byte-swapped to be endian agnostic Regardless of how fast it is, it seems wasteful to do all this byte-swapping when the vast majority of systems today, outside of more specialised applications, are little-endian.

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…

"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

#22

Post by DSMan195276 » Sat, Jul 29, 2017, 11:00 PM UTC

codys wrote: post #21

DSMan195276 wrote: post #9

Earlier quoted context omitted.

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…

"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.

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

#23

Post by stephencanon » Sat, Jul 29, 2017, 11:02 PM UTC

codys wrote: post #21

DSMan195276 wrote: post #9

Earlier quoted context omitted.

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…

"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.

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.

Re: A binary coder for Swift

#24

Post by mikeash » Sat, Jul 29, 2017, 11:16 PM UTC

codys wrote: post #20

mikeash wrote: post #17

Earlier quoted context omitted.

Big endian is traditional and it doesn't really matter much either way. A more sophisticated version of this coder would expose that choice as a configuration option when creating the encoder/decoder objects.

A choice is the often _worst_ possible solution, assuming it is encoded into the format (which it may not be in this case). With a choice, when reading every platform has a conditional swap rather than some platforms having an unconditional swap (and the others having no swap at all). A choice will only be beneficial if writes happen more often than reads (as providing a choice means that platforms can do no swapping…

This coder doesn't really have a format, it's more a way of defining a format. It should be flexible enough to work with many existing binary formats, and endianness configurability would need to be a part of that.

Performance is not really a concern for this implementation. I would guess that the indirection from calling through all the Swift protocol methods will completely swap any cost of having extra branches (which will be predicted correctly about 99.99% of the time if there's a lot of them).