Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A binary coder for Swift

mikeash.com

Post reply on HN
Print view View original

11–20 of 24 posts

Re: A binary coder for Swift

#11

Post by unkown-unknowns »

invokestatic wrote: post #7
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.

Most network protocols, including TCP and UDP, are big endian, so little endian really isn't that ubiquitous. And I imagine a big use case for the binary coder will be for networking.

But even though the protocols are big endian, is it generally the case that you always make the data itself big endian? (Asking out of ignorance, not rhetorically or sarcastically.)

Re: A binary coder for Swift

#12

Post by unkown-unknowns »

heifer2822 wrote: post #10
penpapersw wrote: post #8

Earlier quoted context omitted.

In my experience, it's difficult to go through because it's so comprehensive and thorough, and I guess it has to be because it has to assume the lowest common denominator audience. Personally I'd like a shorter guide that assumes you know a few languages (C#, ObjC, JS, Java) and skips a bunch of the tedium of how programming languages work in general and gets right to what's different about Swift. It may seem like it…

I agree but Swift is a new enough language that I'm not sure such a resource exists yet. When I learned Swift I just skimmed through the parts that weren't interesting and that worked for me. It was a good overview of the language. As an aside, the book, Advanced Swift, by the objc folks is fantastic but assumes you already know Swift. It's not what you're looking for, but something to move onto after you grasp the b…

Maybe there is room for a publisher that makes books for people that already know how to program?

Re: A binary coder for Swift

#13

Post by userbinator »

invokestatic wrote: post #7
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.

Most network protocols, including TCP and UDP, are big endian, so little endian really isn't that ubiquitous. And I imagine a big use case for the binary coder will be for networking.

TCP/UDP/IP are BE, but that's largely an artifact of the time they were invented (when the LE/BE split was more even), hence networking hardware is probably where BE is still commonplace.

Most application protocols I've worked with are LE; serialisations like Avro, BSON, capnproto, protobufs, etc. come to mind, as well as numerous other proprietary ones. ASN.1 is a notable exception, but it's also much older.

Re: A binary coder for Swift

#14

Post by nemo1618 »

unkown-unknowns wrote: post #11
invokestatic wrote: post #7

Earlier quoted context omitted.

Most network protocols, including TCP and UDP, are big endian, so little endian really isn't that ubiquitous. And I imagine a big use case for the binary coder will be for networking.

But even though the protocols are big endian, is it generally the case that you always make the data itself big endian? (Asking out of ignorance, not rhetorically or sarcastically.)

It's up to the programmer. In the systems I've worked on, we always sent the data itself in little endian.

Re: A binary coder for Swift

#15

Post by cgb223 »

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…

> 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

Re: A binary coder for Swift

#16

Post by mikeash »

cgb223 wrote: post #15
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…

> 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

#17

Post by mikeash »

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.

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.

Re: A binary coder for Swift

#18

Post by userbinator »

cgb223 wrote: post #15
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…

> 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

Little-endian ARM, to be precise. AFAIK Apple's only big-endian products were those based on the 68K and PowerPC.

Re: A binary coder for Swift

#19

Post by dep_b »

victor106 wrote: post #3

How stable are swift releases now? What are some good resources to start learning swift?

1.x was rough every point release broke major stuff

2.x was stable all through, but a lot of work to migrate from 1.x

3.x minor changes but a big renaming effort leading to a lot of work in accepting proposed changes in Xcode. Laborious more than difficult

4.x most projects I've tested just compile. On the road to a stable ABI

Re: A binary coder for Swift

#20

Post by codys »

mikeash wrote: post #17
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.

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 on write). This can only be the case if some written data is never read.

Also, conditionals in general are not good from a performance perspective, so even more writes than reads doesn't make it clearly better to have a choice.

Post reply on HN