Two's Complement - Strong ARM

Episode Date: March 18, 2024

Ben and Matt discuss their transition to using ARM-based Apple Silicon laptops for their day jobs. Ben rewrites Bash into Java because it makes his tests run faster. Matt tries to teach VSCode something and winds up writing JSON instead.

I'm Matt Godbolt. And I'm Ben Rady. And this is Two's Compliment, a programming podcast. Hey, Ben. Hey, Matt. You've got a new microphone. I do. I do.

I have a lot of new things. I have so many new things today. And we're going to find out in the edit whether or not this microphone actually works or not. So we're going to talk for like 45 minutes. And hopefully there's just more than silence on your side when we come to look at the recording. I mean, I'd say, you know, one chance in three. I'll take those odds. Yeah.

Yeah, I have a whole new setup in lots of ways i have a new podcasting set up here with the microphone uh i have a new work laptop that i for the for the first time in well since 2010 my primary work computer is not a linux computer wow this is this is like a whole new world for me that's i'm still deciding if i like it or not but that is an interesting an interesting we have to do i have to dig into that because well yeah i also have switched to a mac oh wow uh a few months back uh But that was out of sort of a practical consideration of, like, I didn't like being one of the strange people at the company who didn't have a Mac.

And so begrudgingly, I accepted the corporate Mac and, you know, all the things that come with the manageability. The corporate machinations? Oh. I'm sorry, I'll leave now. now yeah no no but all of the you know i understand why if you're a company particularly one like ours with the kind of uh intellectual property considerations and things you want to have a machine that isn't just kind of a free-for-all

and so there's a certain amount of manageability and ensuring of encrypted hard disk nurse and all that kind of stuff which you know ubuntu lags behind understandably compared to you know a full operating system like mac sorry not that it's not a full operating system but like a corporate friendly operating system a corporate friendly friendly operating system which is weird because it didn't it didn't used to be like that right right it used to be sort of like like so the last time that i didn't have a linux computer as my main computer was 2009 right when i was consulting and basically my choices back then if i wanted to as a consultant sort of go into a random company that i had no idea who they were going to be and have any sort of hope of like you

know connecting to their local network and you you know, being able to share a presentation. The choices were a Windows laptop, which absolutely not, and a Mac. And so that's really the last time that I have used a Mac as my sort of primary laptop, my primary work laptop and that was you know for consulting reasons got it um and uh you know fast forward 13 years and now i'm kind of back to that but but yeah like you i had this sort of you know because we started at our current company sort of very early on and it's like you know what's the policy on work laptops it's like well you should have one you should have one do you do you own one already well maybe use that one for now and then we'll get you a real one later

that's right and we both yeah got managed to sort of wangle essentially a pick your own adventure laptop from like here's a budget go get a computer we're like sure fine. We both... No, well, I ended up with one of the Lenovo Carbon X series, which I've been very happy with. But I think you had something different, didn't you, from that point of view? No, I had that one for a good long while. Oh, okay. And then about...

I had some problem with it. And then about six months ago, nine months ago, I switched over to like a Dell Inspiron, which was fine. It's a perfectly reasonable laptop. I enjoyed using it. And then, you know, like you, I was like, yeah, you know, this is like, I'm kind of grandfathered in here and I don't want to like spend a whole bunch of time reconfiguring everything but you know i probably should switch at some point and then someone on my team went and took the project that we're working on and built it on a mac and ran the test and the test ran in half the time and i said we're switching right now so true to form it was testing that got you to switch computers. Whereas for me, it was just, yeah. 50% of the original, like twice as fast, sold.

Where do I sign up? So we're going to have to talk about how on earth that could be the case and how you're even able to do that. Because like my stuff, so like the way that I use my computer is a very, very much glorified thin client to a real linux machine that lives in a data center somewhere and has all the cpus and all the ram and all the network connectivity for all the weird things i need it to to have yeah i can't get on a laptop and i can't even get on wi-fi for some of the things that i'm i have to be able to run and debug and whatever so it makes sense to

have a machine somewhere else and it's kind of nice to be able to run a debug and whatever. So it makes sense to have a machine somewhere else. And it's kind of nice to be able to say, can I have more RAM? And someone clicks a button and I have more RAM as opposed to someone coming around with a stick of RAM and sort of saying we need to power down your machine. So that's cool. That's cool. There's manageability aspects there.

But then the Mac to me is just a sort of an encumbrance that once I've got it configured correctly, doesn't get too much in the way for my full screen linux desktop that i'm actually working on but so so i never do anything locally i have like two or three things installed locally and um that's it but you're now saying that you're running on a mac yes yes so this is different yes And I have kind of used the sort of like Mac as a dumb terminal in some situations in the last few years.

And I think it works okay. It works fine. It is like kind of like, it makes me a little sad that you've got this incredibly powerful machine that you're basically just using to shuffle pixels back and forth right um but it it uh but aside from that like it works great um but the thing so the thing that i the

things that we were seeing um is with the tests that we were running i'm gonna have to explain a little bit of context here yeah it really make this make sense but i guess that's the point of this podcast um wait we have a point i thought the point was just you know every friday afternoon we you and i get to hang out and not feel too guilty about it news to me right like wait there's trying to do something um so the the thing with the tests in this project is that they are at a very particular sort of like phase in the project. So as I, the way that I think about as software projects grow, you know, you measure them by things like, you know, complexity and two ways, I think, and capability and two ways to sort of measure those things.

Like how many lines of code do you have and how many tests do you have? And sort of like if you're, you know, building things at least the way that I espouse them to be built, you wind up being able to run your tests, you know, hundreds of tests per second, right? And so what that gets you are some sort of like interesting metrics that you can look at and see, where are we in the lifetime of this project? Because when you're in very early stages and you've got 100 tests or 200 tests, they should be able to run basically instantaneously, on a single thread. You should have to do no additional work, no special tricks to get your tests to run in a second or less right and this is because of all the things that you talk about in terms of uh making tests uh targeted so one test in your instance might be something like take a list add an element to the list is that element

in the list yes okay that's one whole test right and then you've got a different test and another test and another test so that you can you know it's isolated this isn't a test of like the test is do a comprehensive try of every possible combination of operations on a list that's not a test that's that's right yeah right if you were running a test like that you would be running it in a different environment probably you'd be running it in ci and honestly like and that's more of a sort of property-based test type thing yeah yeah but you're talking about even a test where you're like yes exactly like even a test where you're like spinning up a database or something and doing all those kinds of tests i write them very infrequently first of all and even if i did i wouldn't run them in this way got it this is very much yeah i'm with you keep going yeah yeah so

you've got like you know hundreds of these small focused fast tests right and then you the software gets bigger and bigger and bigger and then you eventually have like tens of thousands of these tests maybe you have like 10 000 and at that point even with very well written tests that you're sort of crossing a boundary there i think we've talked about on the show before sort of the rule of eights yes and one of the earlier episodes in fact yes exactly and you know you've got like you know when you're in that early, early phase and you've got like 100 or so tests, maybe they'll run in like 800 milliseconds. And that, you know, might as well be instantaneous for the purposes of developer workflow. Right. And then when you start to get up into like the thousands of tests, even if they're well written, they start getting closer to that like eight second range, even 10

seconds, 20 seconds. And you start, you stop being able to work interactively, right? So, as you make the transition from 0.8 to eight, you can still work interactively. As you get beyond that phase, as you get beyond the sort of 10,000 test phase, you stop being able to work interactively. Now you can put that off a little bit longer by running your tests in parallel. Right. Right. Uh, cause at that point, the overhead of distributing the work of the tests is worth it. And so you, cause right now, if I run my tests in parallel on this project, it gets slower because the overhead of distributing them across multiple cores. Is actually greater than the fact that each test takes less than a couple of hundred microseconds even, right?

Exactly, exactly. And the overhead of doing all that just slows it down so much that it makes it slower. But once you get up into the sort of 10,000, 20,000, 30,000 test range, then you can scale across multiple cores and still sort of be in that eight second feedback loop range. Right. Yeah. So, and you can keep going with this and that might even be a whole other episode talking about the other levels beyond that. But where we are right now with this project is the tests run fastest on a single core. Right. And so I was talking to a bunch of our infrastructure folks and I was like, Hey, so, um, our tests are, you know, taking like 10 seconds now,

can we just throw hardware at this problem and make it faster? And they're like, yeah, we can give you as many cores as you want. And I'm like, well, yeah, but that doesn't help. So we, we ran some tests. So on our sort of like remote desktop setups, the tests that we currently have take 12 seconds. I think we've got, and that's including some integration-y style tests, but they take about 12 seconds. On my Linux laptop, they took nine seconds.

So they're actually faster on the Linux laptop. That is very interesting. Yeah. On the MacBooks, they take five seconds. That is impressive. And so this is basically like doubling the lifetime that we get to live in this, you know, not quite honeymoon phase, but this like very interactive, simplistic world where all of our tests run in a single thread. You run all of them on every change. They're nice and fast and you get to work in this iterative style. And so we've been working on this project for about, you know all of them on every chain, they're nice and fast, and you get to work in this iterative style. And so we've been working on this project for about 15 months now.

And basically by doing this, I'm kind of buying myself another 15 months. I guess so. You double the speed, unless you increase the size of the team and the output, or whatever. If anything, you would have maybe asymptotically slowed down or something. Yeah. But then there's also, and this is especially true with Java, there's sort of a fixed overhead for running sort of like any non-trivial number of tests, right? You're probably going to spend, you know, somewhere in the order of a second or two,

just like loading all the classes and starting up the JVM. Right. All of those types of things. And I suppose that's definitely worth saying, right? So that was a thing I was going to ask you about is like, how are you able to take the tests that you're going to be running in our big fat infrastructure that's all x86-y, is all big server class machines, run it, first of all, on your laptop, like natively,

and secondly, then switch your laptop out for a completely different type of computer, and you've kind of given it away there. You've moved to Java, or you've this is all well this is this project has always we i mean a long long time ago we had a big old discussion on this very podcast about when you should pick c++ when you should pick java when you should have python or whatever and i think you know although um although something like python which a lot of the code base that our company has is written in, is processor agnostic. Every library that Python uses is not agnostic.

So we would probably have difficulty running, even like if it was Python, the kind of quanti-mathy Python code that our folks write wouldn't run on a laptop without, sorry, an ARM-based laptop like the apples are but java just does it's yeah right exactly yeah all the work that i've been doing i've basically spent this whole week you know this is uh i'm gonna give away our time here but like we're sort of at the end of the year you know things are a little slow we finished everything that we needed to do for the year i'm like like, all right, I'm going to take this week. I'm going to move things over.

And none of the Java code had to change at all. Actually, that's not true. There was one thing. There was one thing that I needed to change, which is some extended socket options that I had on a TCP socket, which were not supported on the Mac. Right, but that's presumably a very straightforward yeah if statement or whatever you kind of accept that now yes my i remember talking in fact when we were talking in the

episode uh c++ versus java i think we were talking a little bit about some of the previous attempts that uh we had had um and other companies where i'd worked with folks who were like hey yeah if if it's in java then i could run it on my my mac was was exactly what happened there this is but before it was arm based whatever and i'm like sure but the the first time that there is a bug in the native code that doesn't compile on your mac because it's a different operating system whatever then i'm i'm tapping out of this because i don't have the time to support two operating systems however similar they are and you know obviously mac os and linux are fairly similar as they go it would be very different maybe if it was windows

um and that was enough i think to put off my friend from moving to to java or at least didn't come he didn't come and bother me about that kind of thing all right obviously you just found your first but it was trivial how far down that road do you think you will go maybe you won't have as many issues as we would have in like a more trading system focused thing where we have even more weird uh yeah options and things i don't yeah i think i think the nature of the problem that we're solving with this means that it's very unlikely that we're going to run into something like that. Because this project runs entirely in AWS and Google Cloud, first of all. Right. So the whole concept of any sort of customized hardware is just like, that's just

not a practical solution for us, period. Yeah. Right. And in addition to that, one of the things that I've certainly seen is there's it's not conway's law but there's some sort of weird you know conway's cousin's law or something like that where it's like you know the operating system that you develop on affects the architecture of your system yeah no for real and so if the model that we have which we're going to have is one where we are developing primarily on Macs, occasionally on Linux. And my intention here is to kind of support both for development purposes.

But if we're developing on Macs and deploying on Linux, then we're going to be very reluctant to change the architecture in a way that's not compatible with that model right it's not to say that we won't but there's going to be a sort of pressure right to be like you know can you just design this so that it also runs okay on a mac right um and that means we're going to be doing so like a lot of what i've been doing this week has basically been taking our very sort of like ubuntu and linux specific scripts and tools and you know all thespecific scripts and tools. Bash scripts and things like that. All the places where we've got some path that's got Linux-64 in it and doing $uname.

Exactly. Stuff like that. Once we've made that switch, and combined with the fact, again, that we're running in the cloud anyway, I think would be very unlikely that we would wind up in a situation where it's like, oh, yeah, we've got this weird proprietary binary thing that we have to plug into the middle of this. I think the key in that is that you're all going to be doing this. Yes. that you're all going to be doing this yes whereas with with the situation i was in before it's like one developer was like yeah this would make my workflow really really easy if i could just do it locally so i'm going to do it locally and everyone else is like well good luck with that yeah and then they were like you know hey i've just hacked the code it's six ways to heaven so

that it works on my funny setup and it's like no no this is like the person who comes in and like reformats all the code because it looks better in their editor and you're like no no this is like the person who comes in and like reformats all the code because it looks better in their editor and you're like yeah i don't care no no or whatever you know or like you know yeah yeah every file has like a dot emax rc in it you're like stop putting dot you know stop it you know nothing against emax or vi but like you know there are certain things that you don't want to like say well there's a a tax and a cost that i'm prepared to impose upon my colleagues and that should be extremely minimal especially if it's only benefiting me or a very small subset of people that's just sort of general yeah yeah absolutely and i mean this is i for me that is a really important thing to do is as a team decide these

are the tools we're going to support as a team. And these are the tools that unfortunately just, I know that you're a Vim expert, but we're not going to be writing this Java code in Vim, right? Right, right. And I think it's really, it's like a really important aspect of team cohesion is to be able to come together as a group and decide that and really like be okay with it and mean it and commit to it.

That's a really interesting aspect of this is that whole cohesion around a team that you get around a set of principles and be those principles as simple and i realize we're now we're going off in a completely different direction here but those principles are do we vaguely agree on how to name things do we vaguely agree on the code format do we enforce it perhaps do we have like yeah yeah bits that are in some formats bits or another is that okay or do we want a unified stuff do we use the same tools do we allow people to choose the tool that's right for them where it makes sense or do we just say no you just have to use you know visual source save for your code

your source code yeah um and that can make or break a team oh absolutely uh yeah i mean like i if somebody prior to me choosing to move to the mac if someone had told me as indeed they did at a previous employer of ours you have to use a mac for everything that's a very big uh quality of life for me as a developer change i'm i'm built i've been built i'm built to use linux right that's my yeah you know i'm only get away with this mac because my keyboard has a button i can hit that flips it between the control and all being the wrong way around to the right way around but as i go in and out of the mac itself yeah and the linux machine i'm um uh controlling remotely but um yeah some of those things could be break you know could break you i could imagine yeah yeah so you decide that this as a team that this is something you're going to go forward with and

therefore it's you know makes sense obviously you're also the lead which gives you a certain amount extra uh vote but you know if you could if you made everyone else miserable you wouldn't have a team anymore right no and i mean this one is particularly easy we had someone join our team back in october and they had come in and they had you know gotten their standard issue macbook and they had installed intellij on it and all these other tools and then clearly you know like had used a mac before and really liked it and it's like yeah so show me how to load up the code and edit and intelligent i'm like oh yeah you need to do this on linux and i could see her face fall oh i'd be like oh okay i was like oh so presumably this is again to give away what time we're recording this if we're releasing this in

what march or whatever um that's a nice christmas present for her to have like congratulations you can now edit on the machine that you're running on and use all your keyboard shortcuts and whatnot right right right but yeah i mean it's so it's not a hard sell for me and the other folks on my team are definitely like oh yeah no this is great um and me too of course it's like you know i've worked this way before like i can it's going to take some time for my fingers to adjust to the keyboard shortcuts, but we'll, it'll, it'll all work. But yeah, I mean, I think that, that whole aspect of team cohesion, you know, we've talked

about inner subjectivity on this podcast before. It's really hard to have inner subjectivity if you don't have the same tools. Yeah. Like, like obviously like the build tools and the testing tools and, and, and those things are important, but also just like, oh yeah, when I was refactoring this thing, I extracted this thing over here and then I clicked this button. I did that. And then, and someone might be like, oh yeah, no, I wouldn't do it like that. It's like, well, why not? It's like, well, cause that would be really hard with my editor. Honestly, that is really, really interesting.

So I, I, on our team, which is a C plus plus team, uh, that we're about 50 50 vs code versus sea lion and vs code is a fine ide but it is a little bit less batteries included um which means it's a lot more responsive although you know sea lion is getting better as well you know obviously there are trade-offs and both and i i find i use both of them for different reasons. But yeah, I do find that like my working environment, when I can just refactor things without thinking about it, when I can put my cursor in a test and say, run the test, please. I mean, it goes, oh, you mean the test that your cursor is in right now? And I'm like, yes. And that's just control shift F10. And it's so different when I go and look at my colleague next to me who's in VS Code, and I'm like, oh, just run that test.

He's like, I don't even know how to do that. And I'm like, oh, is there not a button to do it? And it's like, all right, well, let's just debug it. And he's like, well, I can't. He files up GDB in a console next to him. I'm like, I'm sure there's a way to teach VS Code, and there is, and you can configure it and stuff, but it's like it's not a one-button thing.

It's like, oh, you have to create a little bit of JSON that explains what this particular thing is doing. And I'm like, why would I want to write... And all those things, right? And you realize, yeah, we have a fundamentally different development experience. And obviously there are things that are positive about some and the other.

It's like, you need to be able to know how to run GDP. You need to know how to run these things from the command line. But if you can do it in an IDE with a single click uh go for it you know like coverage the other day i was like i just ran with coverage because there's a button in my ide that just says oh yeah i know the right flags to pass the c make to make it do all the coverage things so if you want to get coverage on that test you just ran and then i'll pause the output and color the lines that way i just click a button i love it

yeah but yeah anyway so we digress which is well i mean this whole thing's a digression that's the whole point of it but uh yeah it is um it is important to have some commonality yeah i mean i think the more of a cohesion yeah i i i value that a lot. And it's sort of like, I really want the people on my team to agree on the tools that they're going to use and the techniques that they're going to use. And we just not say we can't change it. We're doing that this week, right? Yeah, yeah, for real. going to change we all change together and we change for a reason that we all agree with and understand we don't we don't necessarily all love although in this case i think everyone kind of does but like being able to commit to it and be like this is maybe slightly less optimal for me but it's more optimal for the team and it's more optimal for the company and therefore i'm committed to doing it yeah right and i think that kind of uh consistency and sort of commitment is one of the things that defines what a team is, right? Because they're all committed to succeeding and failing together, right?

Like it's much harder to make that commitment when it's like, okay, well, yeah, I sort of see in an abstract way how this helps the company. But like at the end of the year, they're going to be looking at what I did and they're going to be looking at what these other people did and they're going to be comparing them in different buckets. Yeah. And it makes it really hard for me to be like, all right, I guess I'll just use this thing that I'm not very productive in. Right. And, and take the time and energy that it takes to learn. That is a fascinating observation. Yeah. So like, you know, you need to have to have people who succeed and fail together in order to be able to have this cohesion. Otherwise it's, I find it to be very sort of difficult to maintain, but if you have it, then it's like, you know, someone joins my team and it's like, when you're working in Java, you're going to be using IntelliJ. Full stop.

Right. Like there's no option here. Right. Like that's how all the tools are set up. That's how all the techniques are set up. That's how the whole environment is set up. That's what you're going to use. And if you don't know how to use it, that's fine. You'll learn. Yeah. Right. It is. Yeah. Yeah. Yeah. what you're going to use if you don't know how to use it that's fine you'll learn yeah right it is yeah yeah yeah no that's that's that's cool the whole team cohesion and succeeding or failing

together is very interesting a lot deeper than i was thinking when you were just basically you said to me before we started recording i got my mac let's talk about why i got my mac and then here we are and i'm like wow i've had such a like a moment of like it uh what feels very you know uh affecting an insight into like what makes a team is like yeah we're in it together and that means we either succeed together or we fail together and we only succeed if we choose jet brains products is that what you're saying we're not sponsored not Not sponsored by JetBrains. You know. Although you will find my ugly mug on the sea lion.

Yeah, that's right. JetBrains is sponsored by you. That's right. Oh, dear. Yeah, that is funny. So anyway, you've got a Mac. Yeah, I've got a Mac um they're impressive pieces of engineering oh they they really are they really i wish i knew i honestly wish i knew more about like sort of went into what went into it in the architecture of the chip and everything

i do too i mean we have we have a mutual friend who is very secretive and works for apple and keeps hinting at the amazing things that he's doing i don't think it's anything to do with this but it like this gives you the idea of like what level of thing can go down in a big company like apple like the amount of engineering effort that they can focus on something like essentially ground rebuilding uh a processor you know they as far as i know they they license the architecture for arm but nothing else they like this is like essentially it's like um you know get it paying for getting the vhs compatibility or the dvd sticker uh that says you know this is a dvd uh this is dvd compatible but you're like i don't buy any of the parts from like you know jvc or toshiba or whoever

i've built one from scratch and from like literally from the component up it's compatible with arm chips but it's not made by arm and i don't use any of their blueprints i didn't license their blueprints i didn't buy any of their pieces or their intellectual property i just made my own arm chip it's like the most bonkers thing to do. And that's because they believe strongly that they could do it better than ARM could. And I was going to ask you about this because of all the people that I know, I figured you would be the one

who would understand it better than anyone else that I could talk to on an afternoon. Well, yeah, but I just mean to say, I'm sure our listener is screaming into their headphones now going, headphones, right? It doesn't work like that. No, exactly.

But so I sort of was confused because when I heard that Apple was building headphones now going headphones right it doesn't work like that no exactly but but so so it's i sort of was confused because when i heard that apple was building a their own processor yep i also heard that it was an arm process exactly wait a second isn't there a company that does that and so what you're saying is is that they basically license like the like the the op codes effectively yes the yeah the the the the architecture is copyrighted if you like and they license that and it says that like yeah if we emit bit streams that look like this we will interpret it this way and that means that it's you know that's what arm is now arm do license and sell you uh so arm have never physically made chips themselves. That's not what they do.

They've always been IP-based. So they have always given, essentially they give out the plans to the ARM chip. Back when they were part of Acorn, they were just making it for themselves, right? They had written Verilog or VHDL or whatever they've written the processor in, which is like a completely bonkers thing to even say out loud the processor is written in code which it is right

um the result of compiling that is literally the floor plan of where all the transistors go and then you get you know your your essentially multi-level uh you know svgs of each layer and you send them off to the fab and the fab i mean this is extremely simplified and not quite right but you know the fab takes each layer and then they just burn it one after another onto a layer of silicon with all sorts of clever washes of set of things and bombardment in between to like layer on all the different bits and pieces and then you get back a chip hooray but you know you didn't make that chip you just had the design for the chip and you gave it which is you know that's fine that's how most people do this now intel do actually make their own chips right um i don't know actually i'm not sure amd do but this is why partly this is why the whole uh taiwan thing is such a big deal because almost everyone who isn't making their own chips goes to

tsmc which is a taiwanese company that make the world's chips and you know for all the political reasons that's that's kind of a problem for some places um you know for the us in particular they've realized that if all the chips that are being designed in the us get sent to one place a long long way away to be made and then come back and they're hopefully the same thing that you sent them out as then that's maybe a problem for security like if your military is depending anyway we're getting completely off track here but so arm have always sold intellectual property you could license the chip from them and they would say here's the source code to the chip and here's some like areas that have been pre-laid out if you like um and then you can go and edit the code yourself. And so that's how the various manufacturers

for the system on the chip places are like, oh, I'm going to add on like analog to digital converters. I'm going to add on embedded RAM. And then I'm going to send that off to the fab myself. And then they're going to come up with an arm that has two megabytes of RAM on it and an army of analog to digital converters and all this kind of stuff.

And now you've got a Raspberry Pi, right? That's the kind of thing that you're doing. Again, I'm probably missing. In in fact i am getting it completely wrong but like something like this um and then um but so those companies that were producing arm machines were likely likely using some of arm's reference implementations of their chips to to go to market so what you think of as an arm chip like inside my my android phone i'm holding up to the camera right now um the the uh oh crikey now i can't remember the name of the chip in it but you know the the the cortex or whatever it's in it um has been probably come from arm modified by whoever's manufactured it and then sent off to be fabricated.

Whereas my understanding is Apple have gone, that's nice and all. We're going to do it from scratch. We're going to build it from scratch. Like it'll be compatible. Right. And in order to be compatible and for us to say that it's compatible, we need to license it for all the reasons,

which I mean, I have no idea how absurdly expensive that idea is. You know, like we're doing it all ourselves ourselves but in order to call it a car uh even though we haven't like licensed the car from anyone else we have to pay all this fees to the car manufacturer and then we it's like it's got four wheels that we built ourselves and like it's just yeah sorry i'll keep switching analogies here uh yeah but they've done an amazing amazing job job. It runs so fast, as you've discovered. Yeah, yeah. It runs cold. We're doing video conferencing at the moment, you and I,

and I've got my hand on top of it, and there's no fan that I've ever heard come in on it. It's absolutely amazing. I mean, right, okay, small nerd thing here. So ARM chips have always been extraordinarily power uh efficient it was never really i believe the the intention that that would be the case but it just they observed that what their design was very low power uh and uh the legend is the the very first arm chip the arm one that was delivered to acorn in i guess the late 80s uh yeah sometime in the 80s uh they plugged in and it was plugged into a bbc micro

of course because that was how this thing was going to go down and they'd written a bit of code to print out hello world and so they connected it all up and they turned it on. And first of all, it worked first time, which is miraculous, right? The fact that the board comes up and it just worked first time. And the little Hello World got printed across the parallel port, or sorry, the tube, the connector that came from it. And then, having celebrated the fact that it worked first time, they realized they hadn't plugged it in yet.

And that caused an awful lot of confusion the power rails were not connected but the parasitic um like this all of the the other things that were plugged into it for like the clock and all the other bits and pieces were enough to power the circuitry because it was and they were like oh my golly this is super this how low power is this when it is like hasn't been fully plugged in and it's still there just because it's plugged into a secondary computer that's like reading the lines and stuff so that's incredible again i've probably butchered that story as well again you know comments welcomed to correct me in the appropriate places but but uh yeah so ARM have always been efficient. Ah, wow.

I mean, I was going to say, like, one of the great things I've noticed about my MacBook is that the battery life is ridiculous. And I kind of had this. I also have an iPad, which is an M1 chip. And I think I basically never charged that iPad. Like, I bought it, like, you know, a year ago. It's just been slowly 1% every three or four weeks goes down. Yeah. Apparently it's absorbing energy from the surrounding.

Maybe it is. Maybe it is. It's like one of those really high end wristwatches that are, you know, like self winding by the very motion. Yes. It's incredibly, incredibly efficient. So it's like, and that was actually one of my complaints with the, with the Dell laptop that I had, is that it would really chew through the battery.

I actually had a few times where I took it over a weekend, didn't plug it in, and I would come into work Monday morning and the battery would be dead. And it had been sleeping the whole time. But even the sleep power draw was so much that it couldn't last more than 48 hours. Yeah, I've never been that sure about how good Linux is at putting it into really into sleep mode as well. You know, there's so many, there's this delicate dance between the BIOS and the operating system for

negotiating how, which bits of Ram to keep powered up and which bits not to, and things like that. And then when to wake it back up again, how to wake it up. I remember, you know, the, the having to go into a bios on my one of my lenovo's and sort of have to put it into legacy mode so that it could talk to linux

rather than windows which of course is the default for these things right so who knows what who's really to blame there but no it's definitely the case that uh with my lenovo which i use for my personal stuff that i'll often have it on my lap uh with my lenova which i use for my personal stuff that i'll often have it on my lap in in the other room and then i will find my lap is on fire because something somewhere is taking up all the cpu and i don't know what it is probably chrome yeah that is a fair point yeah cry which is not really close for either it's also the 330 tabs i have open well yeah one of them is possibly you know doing something stupid right like still in the google meet from two hours ago that's right

yeah it's like showing the conference room video and the audio yeah yeah it is like oh right i should probably it is worth you know just just taking a moment and we should probably stop in a second because we're getting to time here but but I'm currently looking at you on a screen, on a 4K monitor. You're several miles away from me, and Magic is both compressing the video on my side and sending it to you, decompressing your video that's been sent to me, then compositing it into a window on a 4K monitor. I have another 4K monitor next to me that has like a waveform of this recording

going on and i know that if i pick up my mouse and grab the window i can move it around essentially at 100 frames a second there's not any lag between the movement of the mouse and me moving this picture of you right around and you just have to think how much data is being moved around yeah whimsically by me like wiggling the mouse by holding down the way like oh my gosh i remember rendering an mp3 audio file to an uncompressed format so i could listen to it because my computer wasn't fast enough to decode mp3 oh yeah uh and yet now i get annoyed when there's like 18 people in a room you know in a meeting room and like sometimes they it drops out a bit or the fan comes on and i'm like oh really do we have to

like i'm decoding like 12 different video streams and compositing them and i'm running chrome in the background oh yeah we're very we're very blessed we live in a blessed time for this kind of stuff or you could also say spoiled that works that works too yeah yeah it's yeah it's sort of a weird variation on um risk compensation psychology which is another thing we've talked about in the podcast it's sort of the whole thing of like as you have more safety mechanisms people just use those and the level of safety that they actually achieve remains constant because they just do more dangerous things they have because they have a seat belt on and now they drive faster right yeah and it's the same thing with with computing power is the more of it you give people the more

of it they're going to use well that's i mean yeah we we don't we definitely don't want to start a new topic now but we had a dinner table conversation with my family the other day about exactly that that with with the idea like all apps nowadays are you know chrome repackaged as a binary running a javascript program that's communicating with a dom that's being rendered and then drawn back to the screen rather than using like the operating system widgets that would do it it's kind of natively um but you know it's convenient why would you spend all this time to to you know squeeze everything down into uh into 512k of ram or whatever one used to have to be able to do something right

when you're like ah just make an array of big enough how big is big enough i don't know four gig you don't really think about it it's like that's fine yeah yeah yeah well i guess we should uh we should call it at that point otherwise we, we're going to have the longest podcast ever. I guess it's not too bad. I'm going to go back to converting my bash scripts, calling uname in all the various places. Actually, so one of the interesting things that I think is going to fall out of this is I'm actually going to shift more stuff into AWS that used to run locally.

Oh, interesting. Because I sort of have this problem now of like, okay, if these things are running on the laptop, then as you were saying, like we normally have this stuff like very, you know, it's running in a data center. Yep. Oh, interesting. remote execution in AWS in lieu of doing it locally. Because locally is much more local than it used to be. Yeah, that makes sense. So I'm going to go back to that and hopefully get it done.

Well, good luck with that, Ben. And I guess I'll chat to you I was going to say next time, as if we don't talk to each other in between these podcasts. Yes. Well, as we've alluded to several times it's about to be christmas we're at the end of the year here so happy holidays to you and i'll see you in 2024 when this video with this video when this podcast comes out right exactly you've been listening to two's compliment a programming podcast by ben rady and matt godbolt

find the show transcript and notes at www.twoscompliment.org contact us on mastodon we are at twos compliment at hackyderm.io Theme music is by Inverse Phase.