Panel
Mike Ash (github blog)
Rod Schmidt (twitter github infiniteNIL)
Andrew Madsen (twitter github blog)
Pete Hodgson (twitter github blog)
Jaim Zuber (twitter Sharp Five Software)
Ben Scheirman (twitter github blog NSSreencast)
Discu…
ANDREW: Is the mixer in the background of my audio bad?
BEN: I can hear somebody talking…I don’t know who that –`
ANDREW: Well, that was my wife…
BEN: Oh! [Laughs]
ANDREW: She’s making cupcakes, and I can’t really –
BEN: Well, carry on then!
[Laughter]
[Intro Music]
BEN: Hello and welcome to Episode 24 of iPhreaks! This week on our panel, we have Rod Schmidt.
ROD: Hello from Salt Lake!
BEN: Andrew Madsen.
ANDREW: Hi from Salt Lake also!
BEN: Pete Hodgson.
PETE: Hi from San Francisco!
BEN: Jaim Zuber.
JAIM: Hello from Minneapolis!
BEN: And this week, we also have a very special guest, it’s Mike Ash.
MIKE: Hi from government the government shutdown DC area.
ROD: [unclear]
BEN: And I will be your host today, Ben Scheirman from Houston. Chuck is unfortunately absent today.
PETE: Ben, you did an awful job. You knew the episode number and you didn’t ask Mike how to pronounce his name.
BEN: We joked about that on the [inaudible].
PETE: Okay [chuckles].
BEN: Yeah. It’s kind of a hard one to just –
PETE: [Laughs]
ROD: Makeyl.
PETE: Makeyl Asshh.
JAIM: Alright. Someone, take it out.
BEN: Oh, cool! So, Mike welcome to the show!
MIKE: Thank you!
BEN: Do you think you could give us a quick background on you for those who don’t know you?
MIKE: Yeah! Let’s see…I’ve been programming for a long time, started out on ARM64 then Apple 2GS then Mac before the whole next and Steve Jobs retake over. Write a blog, Friday Q&A that some people seem to know about. I like to do lots of little level crazy stuff, Objective C Runtime assembly what have you all over the place.
BEN: I think most people, at least from my circle, know you from the Friday Q&A blog. And just astounding level of like deep dives that you go there, I think that that’s kind of lacking in the blog as we are these days; just like those really, really deep dives.
MIKE: It’s tough. I take a certain amount of knowledge so I try to fill them in the hole a little bit.
PETE: How much prep do you have to do? Or how much work are those posts? Is it a bunch of research or is it just stuff that’s all just sitting in your head and you just have to write it down?
MIKE: It really depends on the individual post. I go from 0-done in 2 hours to spending a couple of weeks writing stuff ahead of time. So it all depends. Like the reason one on “ARM64” was a lot, I had to go through and basically learn the whole thing from scratch because I really didn’t know about ARM64 beforehand, and do some experiments on my device and all that.
PETE: It was a really good post.
MIKE: Thank you!
BEN: One of them that I really liked was the “Let’s Build NSInvocation Part I and II”.
MIKE: That was a [unclear] job, too. Sometimes, the writing is easy, but the code that I have to do beforehand is a big job; that was one of those. Actually, writing the article was pretty quick, but I had to spend a long time actually getting the NSInvocation reimplementation done first.
BEN: Do you always release this on Friday so you’re like on a clock?
MIKE: Yup! It used to be every week, and then that got a little overwhelming so now it’s every 2 weeks, and I keep that up pretty consistently.
BEN: That’s really cool. I also got a lot of help out of the “Let’s Build Key-Value Coding” just to see how things work internally.
MIKE: Oh, yeah. The Let’s Build stuff, that’s my favorite kind, I think. It’s always fun to just go into something that’s interesting and a little complicated, but not too hard, I just re-implement it. You have a nice clear goal and something to compare it to.
BEN: Right.
MIKE: And so many of these things, people treat them as if they’re magical. It’s like, “Oh, Apple does their special sauce and pours in their unicorn tears, and everything comes out.”
PETE: [Chuckles]
MIKE: When you get crack it open, it’s really not that complex; it’s fun to show that sometimes.
BEN: Were you the one who created the Zeroing Weak Pointer before there was –
MIKE: Yup, that was me.
BEN: There’s just all kinds of stuff we can talk about. And I bet, significant chunk of the apps in the App Store actually using some of your codes as well from PLCrashReporter, wasn’t that yours as well?
MIKE: I’ve worked on PLCrashReporter a little, but that was mostly Landon Fuller who wrote them, my colleague. But some of my work on PLCrashReporter is in there. I have zeroing weak reference libraries or runtime libraries whatever, a fair number of apps out there that use those. It’s kind of fun; pop up in their license section every so often.
PETE: And PLCrashReporter is like the thing that powers a bunch of these commercial tools as well, right?
MIKE: Yes, that’s right. Hockey, Flurry…I think just about any solution out there that does CrashReporting will use that. I think there might be one that did their own, but PLCrashReporter basically is kind of the gold standard. I’m biased, but it works really well, it’s open source, so everybody can take advantage of it.
BEN: Yes. One of those things that you just can’t get wrong because once an exception happens and you want to like make a network call –
MIKE: Yeah.
BEN: They’d be darn careful that you also don’t throw an exception.
MIKE: Yeah. The actual CrashReporting code is very difficult to work with. The constraints that you have to work under, it’s just very painful. And yes, if it crashes, when you crash or when you’re trying to report a crash, that’s just no good.
JAIM: No bugs.
MIKE: [Chuckles] I try.
BEN: [Laughs]
MIKE: Try harder than usual.
PETE: Is that call kind of super sensitive CrashReporting code kind of stable at this point? Or, does it need to get updated when the runtime reps?
MIKE: Fortunately, it’s pretty much immune to operating system updates and whatever. Basically, the same kind of thing because the OS X for the main binary compatible with old software; basically, you can’t change too much. The CrashReporting stuff is basically all fixed things like how the stack is laid out; you can’t change that across OS revisions because all your old software would break; how to look up symbols and things like that, that’s all pretty much fixed. Where does change is for example, processor architectures, we had to do a bunch of work for the iPhone 5S because walking the stack for ARM64 is completely different. Fortunately, most of that worked as it was; we’ve got enough to [unclear] code in there where we’d basically plugin a little bit of architecture specific knowledge, and then it works. But we actually had to test it on the real device once it’s finally came out, and fix a few bugs that we couldn’t catch ahead of time.
PETE: Did you guys have some advanced notice that you needed to do this work? Or, were you just kind of raising to do it once the announcement –
MIKE: Pretty much what happened was Apple did their big announcement and we said, “Oh, boy! We’d better get this ready.” And then we realized, “Oh, Apple is not giving any pre-orders. So I guess if we want the actual hardware on the day of release, we’d better go wait in line.”
BEN: That’s certainly scary to imagine.
MIKE: Yeah.
BEN: I think, for the most part, it’s not like switching to Intel, or anything like that.
MIKE: Right.
BEN: But it seems like I haven’t heard of any kind of horror stories about launched a 64-Bit devices like causing problems –
MIKE: Yeah. The good news is that, because the 5S fully supports 32-Bit app also, so there’s really no big rush to convert your app over to 64-Bit. You get some performance and crazies and things like that, but your stuff works perfectly fine. So for app developers, there wasn’t a big rush to get your 64-Bit version posted. Apple was pushing that for some reason; I couldn’t quite understand that. But your 32-Bit version would work fine on launch day. But we wanted to get our library ready because app developers are going to want it a bit, and –
PETE: That’s pretty good dedication to open source; going and queuing up in line so that you can help up.
MIKE: [Laughs]
BEN: Taking one for the team and buying the new device.
PETE: Yeah [laughs].
BEN: So that was tough.
PETE: Right [chuckles].
MIKE: That’s what I told to everybody – how much of a sacrifice I was making by buying a new 5S for myself.
BEN: So someone naïve on the 32-Bit, 64-Bit, at the surface level, I know it enables you to address more memory, but what other types of considerations would ever it got? Like all things being considered seems like 64-Bit might actually be slower just because all your registers have to be wider and that sort of thing, pointers have to be bigger, I’m not really sure what other considerations there are.
MIKE: As far as pure just like 64-Bit or just 32-Bit in abstract world where there’s no other changes besides the size of things. Register Size, that’s actually an advantage. It means that hardware is a little more expensive, but it doesn’t make it any slower. It does mean you can do like 64-Bit into the arithmetic without having to do more complicated stuff to make it work with 32-Bit operations. Larger pointers mean to use more memory, it means to use more cache; doesn’t mean you’re on a little bit slower. So it’s a tradeoff there in the abstract world. But when it comes to ARM64, specifically, there’s a bunch of improvements that are made over ARM32; it’s not just the exact same thing made wider. The instruction set is cleaner, which means it can run faster, there’s a bunch more registers available which means you don’t have to access memory as often. Overall, it’s a pretty good performance.
BEN: And if you ship like a 64-Bit version of your app, you will have to create like a fat binary that contains 32-Bit also, right? So when any device downloads your app, they’d be able to run it?
MIKE: Yup, exactly right. Unfortunately, there’s apparently some bug in the operating system when it comes to this support. Right now, I believe, fat binaries only work on iOS 7 so you basically have a choice. You can either support 64-Bit, or you can support iOS 6, but you can’t do both. Apple is supposed to be fixing that so you’d be able to support back to iOS 6 as well as supporting 64-Bit.
BEN: I recall that being something similar when the ARM, the S processor or whatever, that came up –
MIKE: Yeah, ARM7s?
BEN: Right.
MIKE: I don’t really remember details of that, but it’s ultimately the same kind of thing that we faced before. There was ARM6 and ARM7 then ARM7f. Now, there’s ARM64. And yeah, you bundle up a fat binary, maybe there’s some weird constraints with the tool. But for the most part, Xcode will rebuild it twice, and off you go.
BEN: It’s kind of unfortunate that like all of your apps are going to be like twice as big, not getting Assets I guess.
MIKE: The good news is that Assets are usually the big part, so it’s not generally going to be too bad, I think. I would have to go look and see what change it makes. But my guess would be that something like probably like 500 kilobytes-megabyte extra…
PETE: It’s presumably older shared frameworks that’s still shared; that’s when you think of –
MIKE: Actually, no. I don’t think so. The frameworks all have to dual architecture as well, but that’s on operating system; you don’t actually have to ship that in your third-party apps.
PETE: Right.
MIKE: But yeah, the operating system on disc is probably quite a bit larger as well. Apple basically has to do a fat binary build of all their stuff.
BEN: So like just an app developer that just uses other libraries, what type of considerations when we have to account for it? For instance, I’m maybe using NSInteger versus int, or I don’t know…does that matter?
MIKE: Yeah, occasionally. It’s not too much of a big deal. If you worked on a Mac before you’ve gone through this already, it should be familiar. If you haven’t, it’ll all be new to you. The good news is that most Objective C code, the way most people write it isn’t really affected. Your pointers get bigger, but you’re just treating them as pointers and you’re not doing anything to them most of the time, so that’s fine. What you really get into trouble is when you try to do funny tricks like you put a pointer into an integer and then you manipulate it, and then you move it back. And you’re using a 32-bit integer for that network find before, but now you’re stripping off a ton of the pointer information, everything explodes. Most of us don’t do that. Where it really matters is with stuff where you’re getting values back from the framework that used to be 32-Bit, and then now 64-Bit so that’s where NSInteger comes in for example. Usually, it won’t matter. For example, if you ask an array for its size, you use count that gives you back an NSUInteger. So that’s 32-Bit before, it’s 64-Bits now. But it doesn’t really matter if you’re putting that into an int because int tops out about 2 billion, and you’re not going to have any race in your app that have 2 billion objects in them. So even though the data type size changes, in the real world, you’re not going to hit that constraint. So the compile converts it for you and everything; life goes on. One case where it gets a little fun is if you ask for an index or something like that. It’d be like array indexOfObject or string indexOf, or range of string, whatever. You get NSNotFound in the back; and on 64-Bit, NSNotFound is a really big 64-Bit integer. If you shove one of those values into a 32-Bit int and then try to compare it for NSNotFound, it’ll always be false, so you can suddenly break some code that way.
PETE: [Unclear] trying the reference set, and you’d be often in the middle of nowhere.
MIKE: What happen is basically it comes back as an NSNotFound, and you drop some of it off. You compare and you say, “Oh, it was found,” then you’re going and ask the array for the object to index 2 billion or something. It’s like, “I don’t know what this is,” so it falls over. So for the most part, you just want to make sure you can form this APIs – know what you’re calling, know what kind of data that it returns, and just to make sure, your code matches that. If it returns an NSInteger, then there is no reason not to use some NSInteger variable in your own code. If it returns a certain value, you just got to make sure that you can tolerate that. So don’t just choose int and say, “Oh, that’ll work” – always got to know what you’re working with.
BEN: A lot of people, like you mentioned, they were on the Mac before, they’ve already gone through this. I wasn’t a Mac programmer before this; I was a .NET developer before I went to iPhone. I recall people are running through this one, they migrated from VB6 to VB.NET. There was this joke that like a long in VB.NET was longer than a long – or something like that so you’d have to worry about that when you’re calling like a Win32 API, so similar type of transition. [Crosstalk]
MIKE: The data type is getting a little interesting. The C-standard doesn’t say exactly how big all these data types have to be; they basically use minimums and then it’s up to the implementation. On the Mac and on iOS for example, on a 64-Bit system long, it’s 64-Bits, and then long long, it’s also 64-bit. On Windows, Microsoft decided to go to the other way. So long is still 32-Bits, and then long long, it’s a 64-Bit data type. So everything is confusing and weird. [Chuckles]
PETE: It seems like they would have saved a lot pre-process for Mac Pros if they’ve had just done with all of that stuff.
MIKE: Yeah, probably. They kind of try, but you’ve got the fixed-width integer types – int32_t, int64_t, and so forth. So if you really want, you can ask for a specific width, but that’s all added on top of the privilege in the language so it’s sort of the best and worst of both worlds at the same time.
PETE: I wonder what they’re reasoning was. I wonder if there was like a Microsoft people who will never need more than X amount of memory type thing.
BEN: [Laughs]
MIKE: Yeah, it’s hard to tell. I’m sure you could go look up the rationale somewhere, but I’m not familiar with it. It pretty much just comes down to what that existing code basis codes are like and what they think is going to break the least of. Maybe, long is more commonly used in Microsoft where stuff it was necessarily 32-Bits somehow.
BEN: What do you think the main reason for the ‘why now’ if we are not going to have an iPhone anytime soon that has got like 4 gigs of memory? What might be the main driver for doing this now?
MIKE: The performance advantages are definitely worth it. You get the extra registers and you get the better instruction set; it just makes everything faster without necessarily consuming a lot more power. So really, I think looking at it as 64-Bit is kind of the wrong end of the stick – that’s easier way to summarize it. But what it really is, is it’s a new process for architecture that’s considerably faster and more efficient? That happens to be 64-Bit.
BEN: That’s a good way to put it. I think you know like the tech press kind of runs with these headlines that Apple gives on the keynote…
MIKE: Right.
BEN: Like, “Hey, it’s 64-Bit,” and then the next time it says “Hey, it’s twice as fast,” and then people associate the two.
MIKE: Yes, that’s always fun. Twice number of bits doesn’t mean twice as fast; it maybe a coincidence that they are, but yeah.
BEN: It just means you can run like Zelda 64 now, right?
MIKE: [Laughs] Sure.
JAIM: That’s why I’ve been waiting for my 128, the devices, when does that come?
BEN: [Laughs]
MIKE: Well, with 128-Bit devices, you can memory map the entire internet…
PETE: [Laughs]
MIKE: And you don’t have to worry about sockets anymore.
JAIM: Okay, when is that released?
MIKE: Just in case anybody took that seriously, that’s completely made up and stupid. [Laughter]
PETE: I guess Samsung is coming out with an Android of 128-Bit. Not really, I’m just kidding.
MIKE: [Chuckles]
PETE: Maybe, they’re probably out. I would be that surprised.
BEN: But they did release a gold Galaxy S4…you see that?
PETE: [Laughs]
ANDREW: Yeah, within a couple of days of violence.
PETE: While we’re talking about the 64-Bit stuff, the stuff that I found really interesting was the detail around the reference counting like the optimization is there. Do you want to talk about that in a little more detail because I think that low-level kind of optimization stuff is super, super interesting the way they squeeze all those last bits of performance out.
MIKE: Yeah, the reference counting changes are really great; they’re probably my favorite change that came out of all this. Objective C is pervasively reference counted and there’s tons of retainers and the [unclear] calls going on everywhere. Since you’re doing it all the time, it has to be pretty fast, but historically, it really hasn’t been. There’s this weird artifact from the next days where basically, every object has reference count, but it wasn’t actually stored in the object, and they stored it in this external hashtable. The idea there I think, as far as I understand, was that the vast majority of objects have a reference kind of 1, and then they go to 0, and they die. Most objects don’t get retained by other stuff. So you optimize that case from a memory perspective by representing as reference 1 as not having an entry in the table. So by moving everything out into an external table, you make it so the most objects don’t actually take up any room to store their reference counted on; you save a little bit of memory. That’s not very useful these days, but back when they were working on 32 megs system or whatever, I little byte help. That legacy that’s kind of stuck in there forever moved to the Mac from the next days, and we kept the external table and we moved to Intel, and we kept it when moved to ARM and we kept. So finally, with ARM64, they move the reference count out of this external table and into the object itself, basically by taking advantage of some extra space. So the first chunk of an object is a pointer to its class that’s how everything knows what an object is.
BEN: That’s basically is a pointer?
MIKE: Exactly. So this object is a instance of this class; it’s what it means. So that first chunk of every single Objective C object in the system points to the class that it’s an instance of and that’s how you do method dispatch and everything else by looking up on that class. So the idea with the changes here is you’ve got a 64-Bit is a pointer because all your pointers are 64-Bits. But most of those pointer, a lot of those bits on actually used because the address base is not actually 64-bits; it’d be a little bit wasteful because if you don’t really need that much, most of these architectures cut it down. Intel 64-Bit is actually 48-Bits of virtual address space and ARM64 is somewhat smaller than that. Anyway, we have all these extra bits leftover that you can do other stuff with, as long as you’re careful when you get the pointer out. So what they did is they borrowed 19 of those bits and put the reference count in there. So that first chunk that used to be just a class pointer is now a class pointer plus a reference count plus couple of other flags that they tossed in. What that means is when you retain and release an object on ARM64, it’s way faster because instead of going out to this external reference table and doing all these manipulation to look up the object’s reference count, it’s just right there, and it’s a really quick manipulation.
PETE: That’s awesome.
MIKE: That will make everything faster. I don’t know how much but – Objective C program is called ‘Retain and Release’ all the time. You tap on the screen and it’s like a million calls to retain and release so that’s a big deal.
JAIM: So we can see our retains, our releases, as part of the pointer?
MIKE: Yeah. That’s actually stored inside the object now, inside that disc or pointer.
JAIM: Is that you told for the bugging if you’re going to rid [unclear]?
MIKE: Well, there were always calls that you could get the retainCount out anyway. You just call ‘retainCount’ and it’ll just go and look it up for you. So it’s not really any easier now for debugging; it’s really just a performance optimization –
PETE: That global table –
BEN: These just go down of the same path of like when you should use retainCount, right
MIKE: Yeah, exactly.
BEN: When do you use retainCount on that call?
MIKE: It just never, yes.
[Laughter]
PETE: So what’s more efficient now?
MIKE: Yeah, that call you should never use as much faster.
BEN: What about I need to X, no. That’s almost like it was a good idea in this case. No, still don’t.
MIKE: Yeah.
JAIM: It’s definitely useful in debugging. You really got to take this as ‘never use retainCount in your actual code that you’re going to ship’. But if you’re trying to track down problems, it’s still handy; it’s just you got to be aware of all the caveats they give you. It’s not always that’s surely going to be what you would think even when things are working right.
ANDREW: I think most of the people who need to be directed to that site don’t know.
JAIM: Yes.
ANDREW: They don’t know how to actually use it –
JAIM: When I give advice like this, I always take the stance of leaving off some of the more advanced exceptions to things because I figure, once I get to that stage, they can ignore me anyway.
BEN: There’s kind of like the shoe hurry of martial arts in learning where first you got to go through the steps and don’t deviate from the rules at all.
MIKE: Right.
BEN: And then you start to understand more and more rules and when you might break them, and then all of a sudden, you can book to trying to do your own thing once you understand. [Crosstalk]
MIKE: Once you’re good to break the rules, you don’t need someone to tell you that it’s okay to break the rules now.
PETE: If you need to ask, then it’s not okay.
MIKE: Right.
PETE: [Laughs]
BEN: One thing I like about pairing is anytime that I want to do something – take a shortcut –
MIKE: [Chuckles]
BEN: I think it’s a little bit clever or crazy that you self-justify it with your pair. To me, that’s the best littleness test of “Was this a good idea or kind of stupid?” and you’re already asking me question; if you could convince your pair this is a good idea, then it’s probably good enough.
PETE: I always wanted to figure out a way to have like the angel on your shoulder and the devil on your shoulder. Somehow, it’s like ‘just pair with the angel then I would need to find someone else to pair with. You guys see the Angels, right?
BEN: [Laughs]
MIKE: I only have the one; looks he’s the mean guy…I don’t know.
BEN: [Laughs] So let’s talk about Core Data and Binding.
[Laughter]
MIKE: That’s probably what killed the other one.
PETE: I think the thing that shocked me the most reading about this awesome description you had about the way that retain camp used to work, the global hashtable kind of makes sense. But then, realizing that you have to have a global lock on that table across the entire process, that seems like that’s going to be the biggest win here – that you don’t have the Objective C equivalent of like a global interpreter exclusively.
MIKE: I think on more recent runtimes, I know there’s code in there, I don’t know if it’s enabled, but the tables are striped so there’s actually like 32 different tables, and then the pointer gets assigned to a different table depending on its offset and things like that. So each table is locked separately so that helps a lot with that.
PETE: Okay.
MIKE: But if you’re doing a lot of retaining and releasing and heavily multi-threaded program, that can definitely be a bottleneck, so that will definitely help there and [unclear], they’re going more and more multicore as technology marches on so that becomes a bigger deal.
PETE: Is there a connection there between – we’re talking earlier about why Apple decided to go 64-Bit – is 64-Bit make it easier to work in this kind of many chord well, or is that kind of all [unclear].
MIKE: I think it doesn’t matter too much. The ability to steal extra bits out of the pointer like that can help in certain esoteric cases like this. But for the most part, I don’t think it’s too much related.
ROD: Do you think we’ll see an ARM64 Mac?
MIKE: Good question! Everybody is speculating about it. I don’t really know. My guess would be ‘no’ because I think Macs need to be powerful enough, but Intel processors are really going to be necessary there. ARM is good for low-power consumption, but they’re not as fast. I think Intel is catching up on the power consumption front faster than RMS catching up on the performance front.
BEN: That’s what I was going to say. I think we may see a world where we have those the Adam Chips [inaudible]…
MIKE: Right, that could happen. But I have a feeling, it’s all going to converge to an extent Intel is going to end up making low-power processors that are going to be in some phones, and ARM is going to end up making high-power processors that end up in some proper computers. So there’s going to be some mixing, I would guess, eventually.
BEN: You put it into a podcast, must have been accidental-type podcast, and [unclear] was talking about how Intel is like a generation that have everybody in terms of fabrication. So it’s an Apple’s best interest if they can fab the lower-powered chips. But it’s not necessarily and Intel’s best interest to not produce their own, right? Or, not partner with Apple to get the iPhone’s on the Adam Chips.
MIKE: I think that Intel would love to have Adams in iPhones. But probably what’s happening is Adams aren’t quite there yet as far as power consumption. And what Apple would really love if they could have their way would be to have Intel make ARM chips for them, and that’s never going to happen. But I’m sure, it says that would they love to see – to drop $100 million on their corporate headquarters.
BEN: [Laughs] Well, if anybody could do it, Apple.
MIKE: Yup!
ANDREW: Mike, I’m kind of curious to hear, I’ve read your blog for as long as I can remember since before the iPhone was a thing, and I’m a Mac programmer, but I’m curious to know what you do day-to-day. You work for Plausible Labs now, right?
MIKE: Yeah, that’s right. We mostly do consulting here, so my day-to-day really depends on what kind of job I’m on right now. I’m doing a lot of iOS programming for a client that’s getting a major release out for iOS 7 so there’s a lot of stuff in there as far as some backend reworking to take advantage of iOS 7 technology, and a bunch of frontend work for the UI. A couple of weeks, I’m probably be off to something else, but mostly, these days iOS and Android programming, some Mac still; it all depends on what’s going on any given day.
PETE: I think the really interesting thing that’s possible is the TLD; it’s not .com, it’s .coop. Do you want to talk about that? Or, is that just totally off topic? I have things really interesting, but it might be a totally off topic for a podcast about iOS.
MIKE: I’m fine with it, but I don’t know about you guys.
PETE: I’m fine with it!
[Laughter]
MIKE: Alright.
ANDREW: Yeah, talk about it.
MIKE: Sure! So it’s not just a funny TLD, it’s the later company that I actually organized. We’re organized as a cooperative, which means that everybody who works for Plausible own a chunk of the company, we all make decisions together, and there’s no real hierarchy or anything like that. We are forced by the government to name a CEO, and that’s Landon Fuller, but he doesn’t really actually have any power; he just gets the title, and some of the underlying responsibility that comes with the. But whenever we make decisions about the direction of the company or whatever, we just try to all get together and hash it out. It’s kind fund. It’s a different way to do things and it’s a great bunch of people, and we don’t really get into major disagreements or whatever; we all manage to work things out come to an agreement. Technically, it would be by majority of votes. If it came down to it, we always manage to have everybody on the same page in the end. We all share in power, we all share an ownership; we do profit sharing at the end of the year. If we have money a new money left over and just kind of one big happy family.
JAIM: So the people that started it, like the principals, do they get kind of the bigger share, and the junior guys get lesser share, or is it all kind of one big happy family?
MIKE: Nope. That’s all. The only real thing like that is for the first 6 months that somebody is with us, they’re basically in like a provisional status; they’re not full members. But then once that 6 months is over and if we’re happy with them and they’re happy with us and we want to keep going, they come on and they’re just as equal as everybody else.
PETE: Really cool. Does that actually make that much impact? The fact that you’re a coop, does that actually make that much impact in the day-to-day? Or, is it just kind of something that comes up every now and then?
MIKE: I don’t think day-to-think is too much. We all kind of have our various jobs, we don’t know what we’re doing, and there isn’t much corporate governance to do day-to-day. But anytime we’re looking at out a new contract or anything like that – consulting contracts, things like that – we all come together. There’s no commandments handed down from on a hive where someone says, “Hey, we’re all doing this now. Congratulations! Have fun!”
PETE: That’s interesting. I’ve had that coops before, but I don’t think I’ve ever heard of any of tech coops. Are you guys out there on your own? Or, is this like an established thing?
MIKE: We occasionally hear from another one somewhere so we’re not the only ones, but it’s not that common definitely.
ROD: I don’t think Valve is coop, but they operate in a similar fashion I think.
MIKE: Compared to any other company, Valve looks very flat. Compared to us, Valve has a little bit more structure, but similar concept they make.
BEN: I guess I’d shift the conversation a bit, you’ve done a fair amount of like audio programming, right?
MIKE: Yeah. I worked for Rogue Amoeba for 6 years and did a lot of work; they do lots of audio software, worked on sort of stuff there; lots of internals on their apps.
BEN: So what is the audio programming world like?
MIKE: It’s different. The fun thing about audio programming is that it’s so latency constrained. It’s a very real time environment; you can’t have random delays and pauses. If your audio code stops for 10 milliseconds, the user can hear that. Even like animations, visual animations, if you’re code have occasional pauses, it’s typically not too big of a deal; you drop one frame every few seconds. It’s a little bit annoying, but most people don’t notice. Or, if they notice, it’s not that painful. With audio, if you drop a little bit every few seconds, that’s very clear annoying change in what’s coming out of the speaker. So everybody knows it; everybody says, “Oh, gee, that sounded awful,” there was this terrible pop for the sound like weird.
BEN: I always thought because like just by the way our eyes are wired that eyes maybe are more sophisticated to internally interpolate between 2 states. So if you have a frame skips, we’ve kind of like can fill in the blanks in our brain. But with audio, all the audio stops.
MIKE: I think it’s a bit like that. What it really comes down to is your eyes are basically sensing in a special domain; basically, it’s a grid and you’re seeing. It’s kind of like a video camera; you’ve got frame and then next frame, next frame, and then next frame. The way your ears work, it’s more on the frequency domain. Obviously, there’s change overtime. But your ears are really fundamentally detecting different frequencies and the incoming sound. It’s not like a one-after-the-other kind of thing, but it’s kind of sampling spectrum at once. The way of the anatomy of your ears work is it filters out the sound as it comes in. It directs different frequencies into different spots that gets sensed by your internal parts. So whenever you have a skip like that, in a visual sense, that’s like this frame after frame after frame, pause, frame frame frame, not too much of a difference. But if you’re sensing all that stuff in a frequency domain, when you get a pause like that, it radically changes all of the frequencies that come out of that sequence. I think that’s really fundamentally what it comes down to; it’s just that it’s of really different ways sensing things.
BEN: That’s interesting. I think of it kind of like I write for my day job. I would write applications for businesses, and then I would go home and I’d then do like game programming because it would exercise sort of a different part of my brain. You have totally different set of challenges there. If you want to run it 60 frames a second, you have like 16 milliseconds per frame.
MIKE: Yeah.
BEN: So it seems like it’s something similar to that.
MIKE: Yeah, it is definitely. It’s similar, but I would say a little bit harder because if a lot of action happens on screen, all of a sudden, you can drop frames that you don’t want to. But you can and get away with it if you need to. With audio, you really can’t. You have to make sure –
BEN: With audio, you would maybe proactively know that this is going on and maybe change to as lower quality or something.
MIKE: Pretty much what you just have to do is make your processing chain be consistent. Typically, audio comes in, you do the exact same amount of work on it no matter what, and then ship it back up. that’s the advantage of it. One thing that does a little easier than, for example, game programming, if you’re writing a game, you might suddenly have 100 enemies come on screen at the same time, and suddenly, you’re doing way more work with the animation and you may have to take more time. With the sound, there really isn’t that kind of event typically; you’re not suddenly dropping 100 times more work.
PETE: I guess the [unclear] I’ve done is a garbage collector makes that easier as well.
MIKE: Yeah, garbage collection and real-time audio processing really don’t get along. Garbage collection really want to be able to stop your code every so often I can go poke around and look at things. Even, generally, on audio code, you try to avoid even just Objective C in general because it’s not quite as predictable if you’d want it to be. The Core low-level of audio code just tends to be straight C or C++.
PETE: What makes a Objective C stuff less [unclear]? They now would do referencing and –
MIKE: It’s basically the message send mechanism. It’s really, typically, but there are very slow paths in it. When you send a message to an object, typically what happens is the runtime looks up for the method in a cash which is really fast, and then it jumps to it and off you go. That’s a few nanoseconds of take it that all done. But if you’re calling a method for the first time for example, then that’s not in the cache. And then I asked [unclear], he’s like really slow path or goes on look stuff up. If it’s the first message to a class and have actually goes off and calls off classes initialize method and to taking locks to make sure that multiple threads don’t collide on this stuff. It’s the kind of thing where it’s usually really, really fast, but every so often, it’s really slow. And that kind of inconsistency is really, really trying to avoid.
PETE: That sure makes sense.
ANDREW: That’s one of the things I think that core audio so hard. I worked on music audio software from my day job and we definitely have to build this kind of thing. It’ makes writing our audio engines much more difficult than colliding our new code or something like that.
MIKE: A lot of the stuff you take for granted, you just can’t really do anymore.
BEN: So have many times have you read Chris Adamson’s book on core audio?
MIKE: There’s a story [laughs].
BEN: [Laughs]
MIKE: I could tell stories about that. I’ve actually only write it once –
BEN: It’s a hard one to get through, right. I tend to read before bed if I read it off. That one is not a good one to read before bed [laughs].
ANDREW: Yeah. I actually worked with Chris Ferge just a worthwhile, so I’m on directly from the source. But a lot of core audio is reading the headers and just figuring things out.
MIKE: Core audio is a funny beast. Some of it that’s just inherently hard because you can’t use any of its nice features and it has to run consistently, and all that. But there’s a lot of it where it’s like setup code. You’re saying, “Hey, I want to talk with this speaker and I’m going to play the sound in this way, and I’m using this font,” there’s no reason that API couldn’t be a nice, say, Objective C API kind of like I’d make the AVFoundation or something like that, but there’s a lot of holdover in there from kind of the old Mac way of doing things before Mac OS X. So it’s kind of a half and half API; some of it is hard because it has to be, and some of it, it’s just kind of hard just because…So it can be a little annoying to work with when you get into one of those. It was like, “Man! This ought to be easier.”
BEN: I started looking at the documentation and the WWDC videos on like audio I guess back a couple of years ago, when I started writing the iPhone App for DeliRadio. And I was like, “Oh, there’s a sync called AVAudioPlayer, it sounds really awesome.” It has like a Play/Pause method, it’s got a volume method or volume properties, you can like wrap the volume up or down from 0 until like for fade things in and out, and whatever.
MIKE: Exactly. That kind of like hard level setup stuff, there’s no reason that can’t be Objective C; that all works very nicely.
BEN: Especially for that API at the time that documentation said nothing about the file that you give it; it has to be a local file URL.
MIKE: Oh, of course.
BEN: I guess streaming is a lot different. I had this really Frankenstein approach where you’re just kind of covering to get a prototype that would shuffle bytes into a mutable NSMutableData. Once I got to some sufficient size, I would hand off that not yet complete NSDataArray to the AVAudioPlayer.
MIKE: Good boy [laughs].
BEN: It worked under good conditions.
MIKE: Yeah.
BEN: Didn’t work so much when you [unclear] –
MIKE: Yeah, you’re going to have some problems with the packet boundaries in there; you need to slice up the data at the right point.
BEN: Yeah. So we eventually move to AVPlayer and eventually AVQ Player so we could take advantage, me and my friend, the next rack.
MIKE: Yeah, there you go.
BEN: From this point on, we’re like, “Okay, if we don’t like what Apple is giving us, we don’t really have to [unclear] all over and got to drop way down into core audio.
MIKE: Yeah, I’ve done that. I guess one of the frustrating things Apple is moving to URLs for everything. There’s a lot of good about it, but only thing is they often just don’t bother to mention, like can this URL be HTTP or does it have to be a file? So many of these things are just implied, it’s like, “Hey, guest! Try it out, see if it works.”
BEN: Right. And then it’ll work for one audio format but not another.
MIKE: Right [laughs].
PETE: It’s just an example of the leaky obstruction like, “Use anything that you want, except by the way, you need to know really what’s under the cover because it won’t work.”
MIKE: Yup, exactly.
BEN: It’s funny because we use a 64k high efficiency AACs for streaming audio format. But our Android app, refuses to buffer that I guess until all the way at the end , and then there was like, “Oh, I’ll play this.?” But if you give it a number 3, it will play at no problem. The AVPlayer fanlike glasses has much worst performance playing MP3s and it does the AACs so it’s kind of like, “Oh, I would like to have one set of audio files for both that.”
MIKE: Too bad!
[Laughter]
BEN: Looks like we’re coming close to the end here so I’d like to get into picks unless there are any last questions.
PETE: I’ve got one random, really random question or semi-random question, Mike, you’ve kind of like going through all of your Let’s Build things on your blog; you like kind of build most of the runtime at mostly [unclear] runtime, have you actually been attempted to build your own language or build your own kind of toy runtime or anything like that?
MIKE: I’m sure we all pass at that phase at one point like build my own compiler in whatever way a long time ago, not so much these days. It’s fun to build the pieces, but I don’t think there’s too much point in putting it all together into like separate language. It would be so much work to fill in the gaps that I’d love to open. And it would be fun, but it’s not that all rewarding I think in the end because it would be so much work.
PETE: Yeah, so the 80/20 [unclear]?
MIKE: It was like in 5 years, I’d have something that kind of works or I could just go use an existing language now. It’s fun to think about, but I’ll stick with Objective C and whatever other languages out there despite their faults – Practical considerations.
BEN: Okay, cool! Well, let’s go ahead and get into the picks then. Rod, why don’t you start this off?
ROD: I just have 1 pick today and it’s a blog by Dave DeLong who used to be in Utah area, now he works for Apple. I think he’s a developer evangelist actually. He had a blog called “Fun With Objective C” and he would get into runtime stuff and all kinds of checks you can do with the runtime and things like. It was very interesting. That’s my pick!
BEN: Cool! Andrew, what are your picks?
ANDREW: I’m going to repeat a pick, I did this a few weeks ago, but it’s “Mac Dev Weekly” and it’s sort of iOS dev weekly, the email newsletter except for Mac developers. The first issue came out this week, and one of my projects is actually in the first issue so I was sort of excited to see that. My second pick is, I hope it’s okay to pick Mike Ash article; I know he have done a lot, but he’s on the show…
BEN: [Laughs]
MIKE: I object.
ANDREW: [Laughs]
MIKE: That guy is no good.
ANDREW: Yeah, well, I’m picking it anyway. This is an article Mike wrote about “Obtaining and Interpreting Audio Data” on his Friday Q&A. I just started a new audio app that’s doing some kind of interesting audio processing stuff, and this article is a bit introduction to it. I wanted the basics of audio data and how that all works. And then my third pick is the “Objective C Language List”. It seems like these lists have sort of fall on importance since the advent of iOS, but Apple actually maintain quite a few email reflectors for developers to discuss various topics, and the Objective C Language List is where people discuss sort of more level details of the Objective C language. It can sometimes be a contentious place but it’s always interesting to read. And then my last one is a non-developer pick, but I think everybody will like it. That’s The Verge article about “Atari Box Art”. They did this article about the Box Art, it was on old Atari games. If you know what that looks like, it’s sort of like this hand drawing, really colorful, sort of paperback novel art. And then the games release primitive 8-Bit Games, so interesting article. Those are my picks!
BEN: Cool! Mr. Zuber?
JAIM: Who here is good at naming their classes?
ANDREW: I think I am.
BEN: [Laughs]
JAIM: Okay. Well, I’ve seen your code.
[Laughter]
JAIM: Everyone is writing connection factory, manager factory, stuff like that, but how do you get away from that? We all know that we don’t want to name our classes like that…
BEN: Switch away from Java?
PETE: [Laughs]
JAIM: We can switch away from Java even if it’s infecting our iOS code. I’ve seen it; it’s happening. It’s not just Andrew, but you can go to “Classnamer.com”, go through it, it’ll give you a bunch of sample kind of class names and you still get a call something like connection manager or something, but at least you tried.
BEN: I’m going to go create my virtual connection interpreter.
MIKE: I just keep a book of baby names open next to my keyboard.
[Laughter]
BEN: I object. This site is not realistic. There are no 2-letter prefixes.
PETE: [unclear] Apple complied…
ROD: Cloneable transaction visitor.
[Laughter]
PETE: Did you guys ever read that? The Daily WTF Coding thing that was like there was one of those a long time ago, 4 or 5 years ago, about the guy who inherited a codebase and the guy who had been writing this code and named all of his classes and variables after kind of like fantasy characters so there was like dragons, but like absolutely unrelated as far as this guy could tell to the actual code. So it was like obfuscated with like fantasy language of this.
BEN: I usually do that with like test suites so my subjects are usually characters from Breaking Bad or Game of Thrones or something.
PETE: [Laughs]
ANDREW: I had a coworker who told me one day that he wrote this, it was an assembly language program for his boiler controller and he had used beer names for all of the labels so like Coors and Miller Light and all this stuff. He said it and then he said it made into the patent on the boiler control because he didn’t know it was going to be patent; it’s all lifted on the patent office’s website. And sure enough, there are all those beer labels.
PETE: [Laughs]
BEN: Jaim, was that your only pick?
JAIM: That was it!
BEN: Okay, cool! Pete!
PETE: I like Jaim’s picks because they’re like very…he sells them.
BEN: Yes.
PETE: Now, I’m feeling performance anxiety. My first pick is the, we already mentioned it, but the “Valve’s Employee Handbook”. This is kind of the Valve, the gaming company, their handbook got leaked online a few years ago, and then they published it online. It’s really interesting that they run their company in a very cool way, very flat in their hierarchy, very self-organizing. It’s a very fun read. I recommend reading it if you want to get inspired for how your company could be. My second pick is a beer. I have recently been enjoying “Back in the Saddle” which is a rye pale ale from Mavericks. One of the things I like about this beer is it is very low-alcohol; it was like 3.7% or something like that. So this is my current thing with beer; it’s a session beer, it’s like low-alcohol beer, and this one is super duper tasty, it’s got some of that spicy kind of rye going on…
ROD: You should go to Utah.
PETE: Yeah, right!
ROD: [Laughs]
PETE: When I get to drink Heineken.
BEN: [Laughs]
MIKE: So they have this low-alcohol beers?
PETE: Yeah! [Crosstalk]
PETE: That happened to me when I went to Utah. I was very confused.
[Laughter]
PETE: And then my third pick is a little bit random, it’s a talk from Rich Hickey called “Simple Made Easy”. Rich Hickey is the guy behind Clojure and generally one of the smartest software guys I know of; very, very, deep thinker. He did this really awesome presentation called Simple Made Easy about what makes a good language. It’s more than just about languages, it’s about what makes a good software and a good philosophy towards building software. If you haven’t watched it, you absolutely must watch it. It’s not an optional thing, you have to watch it. That’s it!
BEN: Alright. So we all have homework? Actually, I think I’ve seen that one.
PETE: Watch it again! The reason I picked it is because I watched it again the other day. My geek crush for Rich Hickey kind of elevated up another one.
BEN: [Laughs] Yeah, I also need to —
JAIM: Is that 2 weeks in a row?
PETE: [Laughs]
JAIM: 2 Rich Hickey picks in a row? [Crosstalk]
PETE: Did someone pick that last week? Maybe that’s why I watched it.
BEN: I think it’s a different one.
ROD: I’ve mentioned him in the past, I didn’t pick the particular talk, but yeah.
PETE: Okay. I was at Strangeloop a few weeks ago, and I went to use the WiFi, and the list of available networks, there was Rich Hickey’s iPhone, and Guy Steele’s iPhone, and I’m like at [unclear] get this garlic; I almost took a screenshot of my iPhone, I was so excited.
ROD: I bought Nicholas’ work.
PETE: I don’t think he was that…[laughs]
BEN: Okay I just have 2 picks. We already mentioned the “Learning Core Audio Hands-On Programming Book” by Chris Adamson and the name of the other author who escapes me right now, Kevin Avila. That’s like the only good reference that I found for core audio, and it’s something that I think is really essential if you’re doing any audio programming even if you’re just using AVFoundation because it’s good to know what you’re building on top off. And then my other pick, I got a theme going on for like guitar-related picks, I’m trying to get back into like electric guitar; I played acoustic for a long, long time. Getting back into electric, I bought an amp that I picked the last time. I can’t always play with my amp because I have a small house and kids in the house, and they’re usually sleeping by the time I get to play guitar. So also have a “Line 6 POD HD” and I just upgraded actually to the “HD 500” which is like the floor-board model. It’s got like whole effects chains, you can do amp modeling and all kinds of crazy stuff. Anyway, you can plug headphones into that or USB through Logic if you want to record. It’s a great way like sort of family friendly way to practice electric guitar. Those are my picks! And Mike, going at you, end us off with your picks!
MIKE: Sure! I’ll start with probably my favorite blog which is “The Old New Thing”. It’s always a little bit of an odd ones since I’m so much into the Apple platform. It’s a guy who works for Microsoft and gets into a ton of low-level stuff about Windows and things like that. Very rarely, are any of these articles actually useful for me because I don’t do any Microsoft platform programming, but they’re always really interesting and fun. And he gets into lots of things like why various crazy backwards compatibility things were done in Windows and how they worked. That’s always a great deal of fun. The second one is “The Aggregate Magic Algorithms”. This is occasionally practical and is always interesting. It’s a lot of really crazy ways to do basically integer manipulations, it has concise [unclear] for passcode for doing things like reversing the bits of an integer or taking the average of 2 integers and multiplications. A lot these techniques aren’t too useful, they’re like really super low-level optimizations for things we’re not really doing too much of. But if you just understand how they work, and it get really enhances your ability to understand how the computer works in general.
BEN: Oh, cool! Well, thanks a lot for coming on the show today, Mike. I really appreciate it. I think that was super interesting.
MIKE: My pleasure!
BEN: But I think the rest of the panel as well. Is there anywhere like you’re speaking or anybody can see you hanging around? Maybe at our user group or anything like that…
MIKE: I go to NSCoder Night DC most weeks. Other than that, I don’t have any current speaking engagements, but I do pop up every so often, so keep your eye out I guess.
BEN: Alright, with that, I guess we’ll wrap it up! Thanks guys!
