Programming Throwdown - SIMD

Episode Date: November 22, 2014

This show covers SIMD: A set of languages for fast array operations. Tools of the show: Jason: OpenEmu Patrick: Mint.com. Books of the show: Jason: Emacs Quick Reference Card: http://www.gnu.org/software/emacs/refcards/pdf/refcard.pdf Patrick: The Mote in God’s Eye http://amzn.to/1AwlOaf ★ Support this podcast on Patreon ★

Hosting provided by Host Tornado. They offer website hosting packages, dedicated servers, and VPS solutions. HostT.net. Programming Throwdown, Episode 38, SIMD. Take it away, Patrick. We're going to start off here, Episode 38, with a question from a viewer. Oh, well, we don't have viewers. Listener.

A listener question. Although today we do have viewers. This is actually the first time we have viewers. Last time we had viewer. But I don't know that it was one of our viewers who asked this question. It was definitely a listener, though. That's a good point. A listener.

And they asked uh well i should give credit to at least the first name of the person but i don't have it but it's okay you'll know who you are uh the question was do computers ever make mistakes this is a good question uh and uh some people i think this is actually posted in our google plus uh community and so actually someone had written back, and we'll share our own opinions. But one of the things when you first are introduced to computers is you're told,

the computer doesn't ever make a mistake. It only does what you tell it to do. And sometimes as programmers, we write bugs or faults. So quick interrupt, the asker was Matthew, I won't say his last name. Actually, his last name is right on G+. It was Matthew Alabastro. Thank you for the awesome question. We love it. broken or wrong um and then the the person who responded actually you know got the thing the same thing that first came to my mind when i read the question which is that there actually is sometimes the processors the thing which are the oh simply the brain of the computer but the thing

that we think about when we think about a computer you're typically thinking about the processor doing the work and it does does sometimes have logic flaws, things that it's supposed to do. And there are several famous ones. But one is that sometimes you have different lines that are supposed to correspond. Like if you do a divide by zero, then that should be a certain kind of error. But sometimes that will be actually triggerable by other stuff or won't get triggered at all. And then this can cause a problem because it means your processor doesn't do the expected behavior um and there's we talked about one i think it was last episode or two episodes ago where it turns out the estimation for pi uh in some of the intel processors isn't as accurate by several like 10 bits or something as it could be and it leads to kind of errors in trigonometric functions

near pi yeah i mean another one i'm just uh there's a link to it uh i'll put a link in the show notes but there's this f div bug in like the 90s with pentium where like they would uh i don't remember this i mean i could read the article but basically it's something to do with like the division like calculating the remainder of the division or something. But but yeah, basically they got it wrong in the processor. And, you know, it just it just means that like there are certain divisions that, you know, you can do them, but it won't give you the answer that that you want it to and uh you know sometimes through some christmas miracle you can like you can solve it in software by changing the firmware of the of the processor and things like that but i mean really you know many times it's just there's nothing that you can

do about it i mean it's just it's etched it's as if like you know you bought the wrong screwdriver or something right you're just kind of done so but surprisingly sometimes sometimes these bugs you know quote-unquote bugs linger around so like there's some quirk uh that wasn't intended but then if you like a you know if intel has like a quirk in their current line of processors amd is faced with the situation of trying to either replicate the bug or you know fixing it but then having you know compiler of trying to either replicate the bug or, you know, fixing it, but then having, you know, compiler writers trying to determine which processor is being used if they want to work around it, which is why it makes it difficult to fix that software. Yep. And I mean, a lot of this, I mean, there's one thing I didn't realize until I moved to the West Coast.

There's a ton of cross-pollination. So, you know, there's a ton of, like, Intel people who are at AMD and, you know, AMD people at Google and Google people at Facebook and Facebook, you know there's a ton of like intel people who are at amd and you know amd people at google and google people at facebook and facebook you know what i mean and so um you know obviously you can't just take the technology from one company and give it to the other but it's like if at the end of the day there's like a core group of people and they agree on a way to do floating point and then one of them leaves and goes to amd and he implements almost the exact same way and now you have the same bug on you know 99 of the world's processors i actually thought of this like in a totally different way which is

not the common way obviously because uh no one else seemed to think of it this way but also it's like it's very esoteric uh in hindsight but the first thing I thought when I saw this was in the context of like machine learning and things like that like do do computers ever make mistakes like in a sense that do they not do what you want them to do and I think that, like, this is actually, like, kind of interesting. It's really, it's, like, now we're, things are getting kind of very high level with computers. And, I mean, you're doing a lot of, like, statistical analysis and all these, like, stochastic processes and things like that. And it's not really clear um like at some point the computer will start making mistakes like

right now it's like if anything is wrong it's always our fault and in reality like there's always you know you as a programmer can change things and the computer ultimately is supposed to be like reproducible right but uh like we're getting more and more into like crazy ai things robotics things like that and so at some point i mean the computer will be kind of making mistakes i mean that's like i don't know it's if that crossover will ever happen it's kind of so i mean computers can make mistakes in certain ways depending on how you think about it uh besides just we say like um if you get sometimes my credit card i've had a couple times it detect what it thought was fraud right which is some computer there's no person saying they're looking at my credit card history but some computer determines that my current spending habit

looks a lot like someone who stole my credit card and sometimes they're right one time they were buying those like rugs the indian rugs or something yeah that's like the number one thing if someone steals your credit card um they will buy indian rugs in fact somebody when they had the whole playstation fiasco um my credit card was one of the ones stolen and sure enough capital one calls me up and says did you buy you know four indian rugs that's like the first thing they asked me that's really odd well the one i've always heard before very expensive oh maybe is that teenagers typically go buy shoes and then buy gas for them and all their friends so if you fill up like it's like me and my spouse's car and then i went to the mall and bought something or whatever and like that'll trigger it oh wow um but no i specifically

what it triggered triggered mine was i uh made a change in like my like i'd moved so i made a change in my address and then i ordered some computer parts online and apparently that also looks exactly like someone stole your credit card um which makes sense um but you know some computer made a mistake right like i didn't commit fraud um yeah right but did it really make a mistake no it probably did execute the rules it was told to but from my point of view it was a mistake i there was no fraud yeah yeah i mean that's the kind of thing like if it if you if you you know i'm assuming they built this really complicated fraud system that like projected all of your credit card purchases to some like

really high dimensional latent space i mean at some point it's like i guess like making a mistake comes down to responsibility like i mean i guess at the end of the day you're always responsible for the for the computer you know but i mean like look at like these algorithmic trading computers where like they uh they do machine learning to like predict stock market prices and things like that i mean in, in that case, like you're saying, look, the computer is doing the trading, you know, hopefully it wins more than it loses. But at the end of the day, it's like, I don't know if that's really, yeah, the responsibility thing is kind of fuzzy.

So another mistake can be, it has sort of gotten to your stochastic processes thing, but that if you are running your processor at you know high temperature or close to uh you know its power limits you can you know have glitches which are problems or you know you always hear this classic thing but it is actually true that there are you know cosmic events you know radiation cosmic rays which cause uh you know logic levels to flip or invert temporarily and can inject noise at some level into the computer. And then the computer can think a zero is a one, right? And then all of a sudden that changes everything. Yeah. You know, very large

number is now a negative, large negative number because the first bit got flipped, right? Like that can happen. Yeah. Right. You know, statistically, it's, you know, basically not going to happen, but for someone, it will happen. Yeah, there's this interesting TED Talk. It was from the security chief of Twitter, and basically, she said, like, I don't remember exactly.

I'm going to kind of butcher this, but she was saying something like, you know, if there's a one in a million chance that some crazy, you know, event would would happen like your stalker happens to find you on twitter randomly like if that's a one in a million chance then it happens 50 times an hour in twitter you know i mean like just and it's just kind of like i guess that's what i was trying to say yeah so the chance of your computer having a cosmic event change it in a meaningful way is you know one in a billion but the chance of a cosmic ray affecting someone change it in a meaningful way is you know one in a billion but the chance

of a cosmic ray affecting someone's computer in a meaningful way is you know very high in a given day yeah right right so um but yeah so yeah okay i don't know does it make any relevant uh difference today probably not but it is an interesting question. Yeah, yeah, totally. So for like kind of, do you want to do news first or do you want to cover this? Let's cover this. Okay, cool. So yeah, I don't know how I got on this, but somehow I, oh yeah. So I feel very compelled to like, I'm working with a lot of people who are just fresh out of college. And so it's kind of cool.

Like, it feels like you're looking at yourself, like, but younger or just, like, less experienced. Because, like, they did all, they're doing all the same things I did. And it's like I, you know know can't obviously fault them for it but it's like I think it's like in hindsight it's it's clear like there's like lessons that neither one of us like like no one myself nor any of these other people have learned the easy way and we're all having to learn it the hard way um actually well hopefully I can make it so that they don't have to learn it the hard way but I wanted to take a little bit of time to talk about like rookie software engineer mistakes and so the tldr of this inch of this intro is that you're getting old

i mean wise i mean wise wise you're getting wise oh there was a quora question it said uh what the old software engineers in silicon valley do or like what happens to old software engineers and the number one answer was this guy he said they become well-paid software engineers i don't know if that's true or not but uh um but it was kind of interesting it made me think that like there really aren't that many old software engineers like you don't see a lot of like 50 60 year old software engineers and there's you don't see a lot of, like, 50-, 60-year-old software engineers. And there's probably a bunch of reasons for that. Wait, I...

Okay. Anyways, I digress. Yeah. But so that's why we're thinking we're old, right? Anyways, so a couple of rookie software engineer mistakes. One of them, and this is a big one is like making assumptions and it's either because you want to you know kind of save time or save processing or you don't want to change the schema or something like that so like uh you know i purposely didn't like no one

on my team actually said any of these or anything like that but uh but this is like a like a fictitious example is you know you have some document system and you store the timestamp for all the documents and then all of a sudden you need to know whether you know document was created by an admin or not and rather than having some boolean which says you know created by admin you say oh I know what I'll do you know if the timestamp is negative i'll just flip the sign of the timestamp um if it's negative then it's an admin um and so like things like that work but the problem is you're kind of setting up a landmine for your future self you know what i mean because you're you're now like adding this cognitive overhead where you have to remember this sort of association that you only

made up because it was kind of convenient you know given the circumstances um and so you see just a ton of this kind of stuff where you know people will uh people will just kind of it's not really a shortcut because like often it's just that much time. You're overloading. Yeah, I do see this a lot. Yeah, yeah, yeah, exactly. Optimization, yeah, you're overloading a field or a value to mean multiple things, and it just makes it convoluted instead of breaking out to explicit fields. Yeah, exactly.

I mean, another case of this, it's like a little bit of a different vein, but it's where someone starts off with like current measurements, like double current measurement, and then they need the previous measurement. So they're like double previous measurement, double current measurement. And you're like, okay. But then they realize they need the last 10 measurements. And they're like previous, previous measurement. You know what I mean? And it's just like, it just grows organically. And the previous measurement you know what i mean and it's just like it just grows organically and the next thing you know you like have this ridiculous thing that could just be an array right or the other pet peeve of mine is uh even in you know i guess this is more common maybe in dynamically typed languages like python but uh and i even see people do this and see but

like you'll have some you know unsigned 8-bit integer that is getting some value uh from a function then later they also use it to get a value from a different function like later in that function you know but now these are two different things but they just reuse the same variable and it's like here the variable meant this now down here the variable means this like why don't you just create a new like the compiler will you know optimize this away there's no reason for you to reuse the same variable name twice like in a loop like if you're looping and the loops aren't related like fine like i'm okay like having the variable i counter or whatever be used but like syntactically like they don't it's just like here's one value then here's a value from a completely unrelated function

that also just happens to be of the same size and i no longer needed the other one so i'll just reuse the name it's like oh just create a new name yeah yeah that stuff is brutal um another one that i see a lot is uh people who don't put like asserts or exceptions or like to some extent tests in their code i mean everyone always complains about no tests but even just like asserts and exceptions you know i mean it doesn't take much time to as you're going through say okay you know i expect this list to have three things in it so if it doesn't have three things then blow up you know um like code a lot of the code i write like you know a few days later will blow up or a week later will blow up.

And usually it's because some other part of the system violated one of the assumptions that I wrote. Or even if it blows up a year later, it's even better. Because instead of just some really weird runtime condition that maybe you don't even notice for a long time, it's like a year later, all of a sudden it's like, boom, exception. I expected the list to be three, now it's four. And usually, you know, the exception will fire immediately after someone makes the change that causes the problem, right?

So you don't have these like really weird latent um issues that you have to like go back and play detective to figure out you know as you work in really really large systems this is where like continuous integration and unit tests become absolutely crucial so you you even if you test your code, if you've changed something that other people were assuming about your code, and they don't also have tests, or there isn't some system doing integration testing, then it can go undiscovered for a while. Yep. Yeah, totally. That's hard, right? Somebody in the chat said they don't like it when uh negative one is used to represent a failure state that is another good thing like you see that where it's like the function you

know returns an int but yet you know they want they really want to return an int and you know something else for the status but instead of returning like a pair they return an int and they're like okay this is going to be positive except it's negative one if this is negative two if like cows are flying and it's negative three if it's a if it's a monday and you're just like ah i can't deal yeah well i'm similarly yes i did have this problem with a new person on on a team i had to help try to convince them which i don't know how successful i was but they had where it uh they would call some computation function it would return a result then you needed to call another function that said whether the value returned was currently valid or not so like you know some state

is being tracked and you need to call first and say hey is this other function going to be valid if i call it or if i've called it is it currently valid and i was like why don't you just return boolean of whether it's valid and then like you know in this case it was uh c so you know and then pass a pointer in and then you'll know like if it's valid the value in the pointer is now you know the pointer the yeah right is now set to and they And they're like, I don't know. Like, why can't you just call this other function? I'm like, well, because then if someone doesn't call that function, then, like, they have no idea if, like,

you're just going to give them garbage. Yeah, I mean, this is why you're forcing them to study that. And they're like, well, they could ignore the fact that you're returning a Boolean. I'm like, yeah, but at least it's, like, more obvious to someone reviewing the code that, hey, why is this returning a Boolean and why are you ignoring it? Yeah, right, right. I mean, in some languages, you can't ignore return values, like not without the compiler getting mad at you and stuff. Which is a good thing.

Yeah, that's right. So, okay. Cool, man. Do you do exceptions in C? i don't think yeah so uh can't do anything there but i do have assertions okay that's good and typically the way i've always i see it is that you have assertions disabled when you're in release but in debug you have them yeah that makes sense um and so that that always leads to this debate should you have non-disable assertion so then you end up with debug only assertions and then regular assertions

and what is semantics around it but it gets really yeah then it depends sort of on you know do you want is your goal that the system survives anything? Or is your goal that you fail loudly? Can you even theoretically recover from this? Yeah, right. So, yeah, well. The last one, reinventing the wheel. There's a ton of good source code out there. A lot of it is very liberally licensed

you don't need to Go and like create your own hash table and things like that. There's a lot of it for you So yeah, I think this is a big one actually and I think that like actually, you know connecting up libraries is really hard I mean, especially in a lower level language like C You're wiring together libraries, you know, they might have different structs and you have to maybe do some fancy casting or you have to, you know, translate back and forth. And, you know, doing that stuff efficiently is really hard. Like it's cerebral. And, you know, coding something from scratch is much more like mechanical in a sense.'s easier. when you code from scratch,

you're going to introduce all these errors that you're going to have to debug. You're not going to write perfect code. And you're not going to write code that's as well tested as an open source library that's ubiquitous. So, yeah, so this is just another one that

I kind of tend to see a lot of so depending on your company using open source libraries may or may not get you into endless waiting with the lawyers uh yeah so it depends on the license like yes are you a lawyer am i a lawyer no yeah okay then If you work at any large company, regardless of that you know this license is safe to use, they'll first want it to be reviewed by a lawyer. Yeah, that's true. There are lawyer cats.

That just... Yeah, I guess it depends on... Usually the lawyer cats are pretty responsive. We had an issue where they didn't approve emax 24 but people were just using it nobody really thought anything of it and finally

somebody was like oh we should probably ask the lawyer cats and they sent an email and it was approved like within a couple hours yeah oh i'm not saying all lawyers are bad i just mean typically depending on your you know company they may or may you as programmers, we sometimes say, oh, I know this license is, you know, friendly or, you know, fine to use, or this is in the public domain. I'll just go ahead and use it. But, you know, there's also someone needs to be tracking everything you're using because typically you're also supposed to at least give credit or site. Oh, yeah. You're using something, right? So you have to make sure you have procedures in place so that you are keeping track of everything you're using yeah definitely actually

that's interesting that i wonder if there's like a git hook for that you know where it somehow like git can become aware of your what open source libraries you're using i don't know i don't know where i'm going with that time for the news news so i'm gonna go first okay so i got the first article and uh i'm not super uh good with markov chains so i don't know how good this description of markov chains in this article is but i thought it was a really interesting... This isn't how I traditionally see Markov chains, but it was an interesting approach that... The link will be in the show notes. But this person had read a Reddit posting

of a challenge, of a programming challenge, how do you simulate this collection of particles undergoing radioactive decay, where you get, here's the starting number of particles in various states, and here's the probability that a particle decays from one state to another state the second state to a third state so on and so forth and so they were talking about that you know if you have a million particles one way to do it is you know essentially pick a random number for each of the particles and then determine based on the the specified if that particular particle, you know, transition state or not.

And how that this, you know, obviously is very costly and slow. And then instead how that, you know, what they were saying was using Markov chains, but what amounts to creating a probability matrices and what they were calling a transfer function that you can essentially do a matrix multiplication and essentially do the same thing almost exactly. So you're not simulating each particle,

but you're simulating kind of all of them simultaneously, you know, undergoing this. And then what populations will you end up with at the end? It was a good article. So for really large numbers. You're solving like the recurrence, right? That's right's right yeah you're solving like several steps in one yeah cool and so wouldn't i i it didn't exactly i know i'm trying to remember but i you know i don't think this would work for a really small number like if you had you know three particles right like

it's random so maybe it'll work but you're gonna have some weird stuff going on but when you get into large numbers right like it it really all does it all just becomes statistical yeah yeah so that was one of those things that like kind of blew my mind i mean a while back it's like this idea where uh that that sort of i'm trying to see if i can grok this so it's like oh yeah it's like you know if you're if you have a 50 chance of something happening and and uh everyone in america has that chance then that means half the people in america have it and half don't so this idea of going from like chance to, you know, sample like populations, it's sort of like, yeah, like if you, if, if, uh, 10% of the people have a tattoo, there's like 30 million people with tattoos or something like that. Like that whole going from like percentages to like, it's like, oh yeah. You know, like at some point when the sample size is large enough percentages become fractions yeah it's your it's not exam not a statistician but it's like your confidence interval right so like if 10 have tattoos and you have five people like how many

people have tattoos it's like well if all five did that doesn't really prove anything Like it doesn't say for certain that your 10% was wrong. It just like could be that you got really a very rare, a low probability event happened. Right. But, you know, if you're like you said, 100 million people and you say 10% have tattoos, you're going to be plus or minus a few like, you know, in the 99% confidence interval, your standard, like the amount of variance you expect to see is really low. That's right. Yeah. Yeah. So this is taking that same approach. But it was an interesting thing to remind us that when you start to deal with very large numbers of something that you maybe need to step away from actually literally simulating it.

Yeah, actually, I was given an interview interview question which is exactly this problem oh really yeah the interview question was i'm totally gonna butcher this but it was something to the effect of it was something about like disk seeking so uh you know it's like you want to write data in a way where when you read the data you could read it consecutively. But you don't know for sure how you're going to read the data. But anyway, it boiled down to

treating the problem of going from one item of data you're reading to the next, treating it as a Markov chain. and it was it ended up being exactly this so uh so yeah so read this article you could you could answer an interview question uh so mine is uh my article is axis destroy your friends with math functions um it looks pretty cool um i saw the video I tried to play it but they don't have

a single player so I haven't actually played it yet but I think the idea is you know there's some islands that are you can think of them as like walls you can't hit and then there's a tank or some enemy and you have to draw some function that carves its way around these walls and hits the person and it's like that game uh scorched earth oh yeah yeah yeah where like you had the angle and the velocity of a you know basically you defined a ray and based on that ray you shot a projectile that you know arced with gravity and had to hit somebody so it's that kind of idea, but they really took it to the next level.

You come up with some crazy sine wave that dodges a wall and hits somebody. I thought it was pretty cool. Check it out. If you want to destroy us, feel free to invite us. I don't actually know...

I think the way the multiplayer works is you have to send someone a link or something. But yeah, try it out. Yeah, let us know what you think. Next article is why Python is slow. And for the sake of time, I won't go into all of the reasons enumerated in this article, but it's a very fascinating under the hood look

at the mechanics of Python. So we talk about, oh, Python is, you know, dynamically typed and interpreted. But, you know, like what is the actual thing going under the hood that causes it to be that much slower than, you know, C++ or whatever? And this guy did a really good job of breaking it down kind of piece by piece. And it gives a lot of insight, you know, that you would never think about kind of ordinarily you might at a high level say oh python you know uses an object to represent an integer but how exactly um and this article goes into that so check it out yeah it's awesome um yeah so this next one is uh the day i lost a ton of money and it's a you're censoring yourself i'm censoring yeah it's it's a ton of money um an s ton of money and uh and that's not like an s expression different kind

of s oh but basically uh uh it's from this guy who's like a day trader and she kind of blew my mind um like just like how this whole thing works and and how these people like you know try like analyze the market or don't in this case and and just lose a ton of other people's money i mean it's kind of sad but the whole thing is kind of interesting um it's has some funny pictures and stuff like that so uh i haven't read this yet but it was it is interesting i like i i was just skimming i was like what is going on here yeah so basically this guy you know it's all about his it's like your stereotypical you know rise to power and then and then you know eminent destruction so uh yes so time for on to book of the show show show my book of the show is emacs quick

reference card but it's not only emacs um In general, reference cards are pretty awesome. I have had the Emacs reference card taped to my computer monitor for, I don't know, way too long. I have one of these for GDB. Oh, do you really? Yes. Are there really that many commands in GDB? Yes. Have you used gdb before i the only thing i've done with gdb is halt the program

when there's a c++ exception so i know like two commands in gdb oh there are yes many many commands in gdb okay so uh yeah in general there's a reference card for almost everything like if if you're doing j, there's a Java reference card. I'm curious what a Java reference card has on it. Good question. Some of these things which are more muscle memory type things, it's really good to have a reference card.

Sometimes you're right there on the spot and you're like, oh, I want to move this line up two lines. I don't want to cut it and paste it. and you're like oh i want to you know move this line up two lines but like i don't want to like cut it and paste it or you know like if you're feeling kind of adventurous you can just look at the quick reference card and it might have something you can like slowly add it to your repository so for things like emacs vim you know eclipse things which have keyboard shortcuts also if like if you're learning a brand new language

um rather than just like hitting google every time it's like how do i do a for loop how do i add you know it's like have a quick reference card and it will help you through like i had this when i was learning um swift i just someone had already made a swift quick reference card or maybe even apple had made it i don't know i have to double check but i i had this quick reference card and it reminded me of you know the obvious things until i got familiar yeah so what's the java quick reference card say well first of all it's crazy like description of the collections like oh god list is a part of a collection an abstract set is you've related to a set which is part of a. Like it has this like giant map on one part. And I was like all the keywords.

So a lot of it is kind of, I don't know, maybe I consider too low level. Like here's the built-in types. Here's declaration modifiers. Yeah. I think I'd like to just get the one from like, here's a declaration modifier,

which I didn't know existed in Java strict FP. And it says strictly apply. I Tripoli seven, five, four to a class or method but i don't know like i can vaguely guess at what that means because i understand the words that are written here but i don't like i'd have to go look this up anyways are you looking at the one from nyu.edu oh i just typed in java quick reference card i typed in just java reference card i'm looking at one from oh ac.uk university of glasgow glasgow okay i'm putting in one now oh this is uh this is intense so i'm not sure that's useful the one from nyu if you search for quick reference card

java quick reference card that one actually looks pretty good it's a second link because the first one's an android app um okay but uh but yeah again like like this is really i mean this is for two things either muscle memory kind of things like like emacs you know your editor where there's like a huge deep learning curve and you just don't want to bite it all at once because a lot of it is situational right it's good for those things and it's good for you know java i'm a java programmer it's day one and uh you know i don't know how to do anything yet um so you know if you're picking up a new language uh you know duct tape the quick reference card to your head. Don't duct tape. Oh, okay. We're just moving on. Duct tape it to your monitor, and it helps a lot. My book of the show, again, not being useful, but being entertaining,

is The Moat in God's Eye. This is a book co-written by Larry Niven and Jerry Purnell. It was written in 1974. So I really am digging these, these like 1970s and 80s books because this one actually doesn't show its age as much as some of the other ones I read. But I didn't realize it was written in 1974 when I was starting to read it. I was actually listening to this one on audio. But when I was starting to read it it i didn't actually realize it was written that long ago and there were some weird mentions of like personal computers and like like having

audible like connect almost like an audible modem was being described and i'm like that's kind of weird and later i looked at but but i managed to read the whole story and not realize that it was written in 1974 and i looked it up oh now that i know it's written in 1974. And I looked it up, and I'm like, oh, now that I know it was written in 1974, I understand these weird, like, the computers they did have were very limited, and they had weird nuances to them. Yeah, right. And so now I've ruined it if you decide to read it. But it is a really good book.

In the future, we'll have microwaves. Well, so it's like you know oh the magnetic memory storage was one megabyte in size it's like that's so good no that's not exactly but you know something sort of like that yeah right no it's hilarious and but but they managed to do a really good job actually of avoiding specific technologies which has got to be hard to do yeah yeah definitely and so but anyways it's a it's a story about i don't like saying too much because i don't want to ruin anything but it's a space sci-fi adventure so cool man check it out i really enjoyed it and apparently i just found out when i was getting the link for the show notes that uh there's now there's actually a sequel that was

written in like the 90s so now i like want to read the sequel oh is it by the same person well it's two people and jerry pernell they're both science fiction authors and they got together to write this book and the sequel wow so they got together 20 years later to write the sequel so these people are like like like very prolific writer. So if you've ever heard of ring world, uh, I think that was also, hang on,

I'm going to, which one is it? But that's Larry Niven as well in the seventies wrote this ring world book. Oh, okay. Um, and I saw, I actually went to a talk that he did.

Um, and he's continuing to write books in the ring world series, even as early, like as recently as a year or two ago oh wow so that's kind of crazy uh jerry brunel also writes um to still to now i think have you ever written a short story or a book or anything when i was in high school for school assignments yeah Yeah, same here. Okay. I haven't ever written anything.

I have a friend who is an English major and she writes short stories. They actually have, kind of like we have hackathons. They have hackathons, basically, where it's like, write a book in a month. And she just writes eight hours a day

or something ridiculous. All right. Time for tool of the show. Tool of the show. My tool of the show is OpenEMU, which is pretty freaking awesome. It's Mac only, which is a shame. But it has an unbelievable UI. So OpenEMU is what's called an emulator front end. And so what that means is, they take a lot of emulators, most emulators have like a command line interface, right? So you can

just like execute the emulator, you know, they might have a little GUI, if you if you run the emulator is like a little program, it'll pop up a little GUI, usually something just really crappy, where you open a file like zsnes, right had that pop up a little GUI usually something just really crappy where you open a file like zsnes right had that like really ghetto looking GUI but if you were to like run zsnes with a you know arguments you can actually like launch zsnes and go straight to a game right so people have created front ends where the whole point is to give you a better user interface and give you a window into your library of cartridges that you legally own. So this OpenEMU is pretty epic.

So you can see from the screenshot, if you're watching the Twitch stream, it kind of looks like iTunes. pretty epic so you can see from the screenshot if you're watching the twitch stream um like this it kind of looks like itunes um it has this like it actually downloads the cover art for you so there must be some must be some open source or some repository where where they can get these all these covers so they have covers for almost everything and uh downloads the cover art it like analyzes the the you know the hash of the of the rom to figure out like what game it is and then it like corrects the file name the title all that stuff so like it's like itunes like legit like you know figures out the artist you know in this case the development you just use legit and emulation in in the sentence so this is this is pretty epic um pretty pretty exciting they even have a cool website no um and

no what they their website has my new my newest pet peeve is the equivalent of the blink tag where you scroll down and stuff animates as you're scrolling like you don't like that oh i hate that really oh so much i think it's so good no ah why i think it looks awesome no it's awful i think it's like uh it's like you should feel bad if you write it's like a movie that you can watch over and over again no the i'm watching the apple announcement i'm watching like the this is the new ipad or the new iphone they did a website like this and it's just awful so confusing it's confusing there's one direction well so this one actually doesn't scroll back until you scroll off screen that's even weirder that is weird i like it when it's like i can i can sort of relive the moment

yeah yeah um we had a website or news article like last time and after i talked about i tried to like actually like read the whole thing and i had to give up because it was like doing this i think it was coin coin did this really badly actually um well it's my new pet peeve uh yeah okay so i love your pet peeve but anyways so wait no you hate my pet peeve no um no i love your pet peeve the thing that you have a pet peeve that's not my pet peeve okay anyways um it's pretty cool another thing that these guys get right which is genius is like one of these obvious like can't believe i didn't think of that kind of things is they basically they bought one of you know the most common joysticks like if you just go on logitech and try and buy a pc joystick and also like the xbox controller and like they just bought all of these and then for each one they configured it how it should be and then if you

plug in like a logitech or xbox controller you don't have to set all the little keys, like say, oh, this is the up arrow on my controller, because they've done it for a lot of the popular controllers. That's a clever little add-on. It's pretty cool. Check it out if you're into that. So that's my tool of the show. Mine is mint.com.

I'm sure we've talked about it before, but I don't care, because I was just thinking the other day how how awesome it is okay so if you're not using my mint.com is completely broken it's still it uh i just haven't been keeping up to date i need to like reconnect it to my accounts and everything so yeah i i think this is one of those things where it actually used to work better than it does now. Oh, really? Sort of, because I think, as far as I can tell, what happens is the credit card companies have their own solutions, right, and their own things they want to go. And so they're not super keen on the idea of, like, making sure to stay compatible with Mint.com every change. Oh, I see. with mint.com every change oh and so even though like you know as a customer i want them to stay

compatible you know they want to force me into using like you know oh american express use the american my your american express app on your phone it's like well i want to use mint because i could just have one yeah right anyways so i do occasionally there's periods where stuff stops working and then they eventually fix it. Okay. So I just bear through the pain. But when it works, it works really beautiful, which is like I don't have to go to like my bank and my credit card and other stuff to like cease. I just go to Mint and it tells me like here's where you're at. And they get the graphics right where I can like go and say how I've been doing over the last year.

What has my trajectory been? Have I been spending more than I make, making more than I spend? What are the months where I spend the most? Why? All that kind of analysis, which for me, I don't stick to a fully allocated budget where it's like you have $10 to spend on coffee know coffee houses yeah that never makes sense it's usually i think what you're doing you know but i don't but what i do like is keeping tabs on where i'm spending money and like right thinking about it like hey you know that's a lot of money i should cut back on that because yeah it's amdahl's law right you get the biggest return for minimizing the biggest expense right yeah that and also just

like the fact that when you look at it in one place you say oh that's kind of a lot like i can i should cut that back and then i i have been successful in doing it that and i don't the hassle of a budget never made me stick to it yeah that's i'm exactly in the same boat right like uh like there's a few things like think about it right like cable and phone right away that's, you know, and think about it, right? Like, cable and phone. Right away, that's, like, you know, it could be up to $200 for some people, right? A month. Yep.

That is absolutely gigantic. I mean, that dwarfs your gas bill. Well, maybe, depending on how much you drive. Well, that definitely dwarfs your coffee bill. But, yeah, I mean, you're absolutely right that there's, like, a handful of things that people spend just an incredible amount of money on. And reducing even just a little bit there can make a huge difference. Like, I was finally able to get my family off text messaging. And, I mean, that's significant.

I mean, it saved us, like, $20 a month, you know. I mean, it's, like, you know know probably more than we spend in gas because I take the bus I take the shuttle to work so uh yeah we probably saved almost our entire gas bill just in getting rid of SMS nice yeah and I so I like it for you looking at the site and like I said the trends to like wow I spend how much and on clothes or whatever like oh that's kind of crazy and like your clothes spending is out of control it's like i know like which is kind of obvious i guess but like november and december we end up buying you know christmas gifts or whatever for family and so then like

spending in november and december are typically high right and so like okay like i know like to be careful the next couple months and like stuff not related to christmas spending that i can wait because i know christmas spending is going to be high yeah don't buy that shirt okay anyways you actually is clothes a large expense for you no i was just trying to say something generic and not very personal i'm just giving you a hard time that's my pet peeve is uh is when i'm not giving patrick are you saying i don't look stylish and handsome enough to uh be spending a lot on my clothes i think you look so handsome that i demanded you show your face in the podcast in the stream sim d all right so right off the top yeah so, so SimD, right off the bat, we'll spoil it for everyone.

Single instruction, multiple data. And so what that means is, you know, like a canonical example is, you know, I have three lists. I have two lists with a bunch of numbers in them. And then I have a third list that i want to hold the sum of the numbers of the first two lists but i want to be like an element wise sum so i take the first element of the two lists add them up take the second element of the two lists add them up and it's like the same exact instruction right so you could you know like you could as a like if you could just have the assembly code or what have you say you know put the first item in a register you know put the first item from both lists and two registers add

them up put that in the third list do it again do it again do it again do it again right but if you're doing something like so obvious like the same exact operation but you're just doing it on different spots of the of the memory then you can do what's called single instruction multiple data where you say something like take these ten things and add them together but because you're doing exactly the same thing to all ten you don't have to repeat yourself you just say do it to all ten and it just kind of magically works. So the way this – what this buys you is parallelism, as Jason described.

So things go faster, and that's always a good thing. People like faster. And the way it works is in the processor, you can think about – so like as Jason was saying, you're adding these element-wise, all these things in a list. So if you have each element in the list is 8 bits wide, and you have a 64-bit ALU, Arithmetic Logic Unit, so you have the ability to add 64-bit numbers, you could add two 64-bit numbers, or you could add eight 8-bit numbers.

And the only difference is you need to prevent the carry between each 8 bit number uh so typically there's a carry bit where you know if two numbers are one it has in binary it has to carry to the next digit oh so you need to be able to turn that off on the boundaries so you have eight gotcha with carries then you have a boundary between eight bits that has the ability to either carry or not depending on if it's a normal 64-bit ad or a simd 64-bit ad and when you're doing a simd 64-bit ad on each of the eight boundaries or seven boundaries each of the seven boundaries um you disable the carry bits and so what happens is then when you add to 64-bit numbers you're actually adding eight 8-bit numbers and storing the

result with no carries between them and so that allows you to do instead of saying normally you would have to move an 8-bit number into the 64-bit register move another 8-bit number into the 64-bit register add the to store them in a 64-bit register and then write that out to memory. But all the rest of that 50, well, 50. It's so late at night, 56. Oh, man, it's too late at night. 56 bits are all just going to be zero.

So you're adding zero plus zero plus zero plus, you know, 56 times. And that's just a waste. So that's how SIMD buys you an advantage. I always thought that i mean so correct me if i'm wrong like but and i'm probably wrong but what what is i always thought that it was a separate processor than the alu like i thought it was sometimes not it is these are all this is like at a fundamental architectural like they share these similarities but sometimes just like floating point unit can be a separate thing or inline.

Like it just is an architectural decision. Gotcha. Okay, that makes sense. And so what it turns out is normally the instruction set will support like 64-bit integers, but they'll have two special 128-bit registers and corresponding ALU with this option. But they'll have the ability to do it on 32-bit boundaries, 64-bit boundaries, you know, various divisions. Because you may not always, you want to do as many as possible. But typically, like, the 8-bit boundary example I gave wouldn't be very useful.

People don't want to only add 8-bits at a time. So typically, you'd have, like, a 32-bit boundary a 64-bit boundary 128-bit boundary for 256-bit wide simd would be very common gotcha um so if it's 256-bit wide simd then you can do uh what eight eight you can add eight numbers in one instruction okay got it but so typically i think most of it so we'll get to this in a minute a lot of this is used for graphics and so you're typically dealing with 32-bit numbers and you want to do we'll get to why later for 32-bit numbers and so it's very common to have 128-bit oh okay but like i said these are all just like it it's a concept right so i'm sure every variation has been done at some point.

Yeah, right. And that's kind of architecturally how it works. And like I said, the ALU is for addition, but it would also be the same supported operations for division, multiplication, reciprocals, bit masking. You know, all those kinds of things would typically be supported in a similar fashion. Gotcha. We've previously talked a little bit about GPU programming. I think we did an episode on CUDA. And a difference between this and the way GPUs work

is that in SIMD, if you have a branching logic statement, if statements, even though the GPU doesn't handle that great, it has support for handling it because each thing is running on its own minimally functional processor, but it is its own processor.

So they can be doing slightly different things. You just lose some efficiency. But with SIMD instructions, you actually cannot. So you, like we said, you're treating, it becomes 128-bit number, a 256-bit number, and it just has these weird boundaries within it. But you're responsible for shuffling the data into that number and back out and so you can't make decisions like if the second item is this and at the same time if the third item is this like you would have to do those sequentially

gotcha and so that's a that's a big difference um but the other difference is it's cheaper from a silicon perspective to implement this right so as opposed to a whole swarm of g specialized gpu processors um some of the common ones what about like performance like is it the same i mean is it worse than a gpu or different oh it's different depends on what you want to do right like it they're all different so the gpu has advantages, but it's more costly, right? So you're not going to typically... It's done in a different way. So like in a low-power, small processor,

there's no way you'll ever have a whole bunch of GPU cores. Gotcha. Because they were talking at one time about like Intel wanted to put a gpu on the on die motherboard yeah yeah oh yeah yeah on the actual core yeah yeah um so you still have to typically you would still want different memory because the access patterns are different so you'd want to move back and forth between it anyways it gets complicated oh i see they're just okay two different tools gotcha okay and so the things you may have heard of before which are implementations of simd specifically pennium if you remember way back you had heard of mmx processors i think this is

multimedia extensions and so okay you'll often hear of these as like some sort of extension because what it's saying is you have the normal instruction set, then there's some supported extension to that instruction set which allows for this extra-wide operations to take place. Also SSE. So SSE was Simultaneous SIMD Execution or Extension, one of those. Something like that. So those are penny ones.

So SSE, SSE2. So these are like penny three penny fours yeah so um you'll have heard of those before and then for arm processor getting powerful now or getting common now and arm processors also have their version of simd which is called neon um and you'll hear these a lot with multimedia. And the reason why is because, like I was saying, so graphics processing, video codecs, audio, this kind of thing, because these have a lot of, I don't know the exact right word, blind operations where you just want to blindly apply the same mathematical function to a lot of data all at the same time. Okay. And so these extensions are really good at speeding those things up. And you can get, like we were saying,

so if you can do four or eight 32-bit instructions at one time, that's like a 4x or 8x speedup for that portion of the code. Gotcha. So some examples that we want to do, we talked about you could add two numbers in a list, you could do cross products, you could do dot products, you could do averaging. So averaging would be a little bit where you start to get into some trickiness, right?

So for averaging, if you have, let's say, four 32-bit numbers you can do at a time and you have 16 items in your list, you'd want to add two sets of four twice. So you have four and four, four four and four and you do them simultaneously and then you'd have yeah two sets of four resultant then you'd add those two sets so now you've done three operations this is really hard to describe over only becomes like a pair it's like a pyramid exactly right so you'd have now you have done three operations then you will no longer be able to use simd really uh because you need to add that one last remaining set of four together and then divide by the total number of elements. But you

can see how you, depending on how many operations you have, you can get a very large speed up. Yeah, right. So just a shout out to Pano DK, who just subscribed to or followed the stream. So thanks. Nice. Oh, he also had a suggestion about earlier. We have our first follower, which is pretty awesome. So another one you'll hear a lot is a 4x4 matrix multiply. And so in graphics, this is because you have typically three-dimensional rotation matrices

and coordinates that are stored for triangles and various, and you store the fourth one to account for some mathematical quirk. I don't know if we ever talked about that before. Yeah, like the quaternions, right? Yeah. So you typically do a four-by-four matrix. I feel like we talked about it briefly,

but like, yeah, we didn't go into a lot of detail. But let's just say that there's some funky math you can do using 4D math, which has no relationship to what you're actually doing, but just mathematically gives you some niceties. Is that like a one-liner that can kind of wrap it up? And so I appreciate this. So this 4x4 matrix multiply with pretty much all these kind of SIMD instructions that works really well and gives you big speed up because you're doing that over and over and over again because you're doing coordinate transform after coordinate transform

after coordinate yeah yeah just to put this in perspective right like if you're doing let's say you're making a video game right and uh um you have some dude you know like grand theft auto style and he's running and he's holding like two uzzi's like John Woo like dual wielding Uzi's right so now it's like you want to render you know a bullet coming out of the Uzi so you need to do a transformation to go from the universe to the camera a transformation to go from the camera to the person you're looking at that's another you know matrix multiply that transformation to go from that person's frame of reference to his hand one to go from the hand to the barrel of the gun and another one to the count from the barrel of the gun out to the bullet right

you know like the spin of the bullet yeah they have to do another one for that for the spin right so you have to do like 10 of these four by four matrix multiplies just to like know where the bullet is like you haven't even drawn the bullet if you want to draw the little triangles of the bullet now you have to do one of those for each of those triangles right so you're doing a lot of them so yeah so any speed and this is why like i was saying before these typically have names like associated with multimedia or graphics is because that's where you'll see a lot of the use same thing like audio processing you know you'll want to apply some filter and typically at every point in the signal you want to look at the surrounding few points so now what you basically end up with is like you shift an element in you apply the same operations you shift the next

element in you apply the same operations you just keep doing that over and over again and this is where you can really get the kind of naive big speed ups because it's really really well suited gotcha makes sense um but this takes a lot of like you know hand power and i so i've written in several of these simd languages they're not called languages simd styles and almost extensions or extensions sure and what it amounts to is you're writing assembly code like you're not but you are because you basically need to worry about everything like i need to load up the special registers with data exactly arranged how i need it then i need to do specifically like these low-level operations then i need to get the data back out these are the kinds of things you typically worry about when

you're doing like assembly programming and this is very very similar i find it and so you typically kind of wrap it in a function you stick that function somewhere and you call in with uh very nice data classes or objects i pass them in then you do this very kind of horrendous uh but fast uh you know assembly level kind of programming and then you kind of pass it back out in a nice class um oh gotcha that's the way i've got what happens if you get it wrong like i mean it probably doesn't throw an exception right i mean like do you end up with weird numbers or does it like literally well it depends on what you mean by mess it up i well let's say like you uh have some kind of out of bounds or something like that like do you get weird numbers it does the whole typically like wraps or overflows or underflows

or oh i see yeah it depends but but yes this is the general flow of it um and so obviously that's painful but the good news is uh if you're writing a graphics library and you optimize some part of that, right, people are calling into your API, not to your, they're not going to try to write these SIMD instructions themselves. Yeah, that's true. I mean, for most people out there, you know, you're just relying on, you know, if you're using Unity or whatever for the game engine, you're relying on them to do this stuff for you.

But actually, you can write code which does SIMD and not even know it. What? I know. That's automatic vectorization, which I actually remember when this came out.

I remember when GCC 4.7 came out, and I just remember my mind being blown because I don't really stay up to date on compilers, like research or anything like that. So I didn't realize that this was an effort. And then all of a sudden it's like, oh, yeah, SIMD for free. It's just like, what? and then all of a sudden it's like oh yeah simd for free it's like what um but yeah basically you know the compiler the guys who write the compiler are very bright um they analyze your

for loops and uh if the for loop looks like it's doing something trivial enough that they can you know capture all of the side effects and isolate it, then they will try to replace your code with some decode, which does the same thing but much faster. It's pretty freaking amazing. In GCC 4.7, it was very, very simple. So even like you couldn't use a vector. If you had a vector of floats, the way that like vector, you know, when you actually do the bracket on an STL vector, it passes it through this inline function. And most of the time it does nothing. But if you're

in debug mode, it'll like check or do a couple other things and just the fact that that function was in the way caused like all stl vectors to not be supported and you have to you actually had to like create a pointer of the vector and just like you know so you basically have to do it yourself but um but since then it's come a long way and now even if like you know you add two vectors of floats and c++ it'll it'll vectorize it. If it could make some guarantees about the size and things like that. Which is pretty cool. It's also coming to Java. It's not there yet.

But that's one of these kind of amazing things. If they build automatic vectorization into the Java virtual machine, then like it's just going to completely change the runtime profile of every Java program ever. I mean, like who knows what's going to happen, right? Yeah, I guess it depends on how they support it. I don't know the exact specifics, but yeah. The other thing like we're saying is like if your library like unity or whatever supports that you get it um also there are of course libraries and i didn't write any down here because i'm not up to date on these right now but where you could get a package of like here's common operations you'd want to do and here they are implemented in ways that are very

uh amenable to gcc doing auto vectorization or already have some instructions themselves right so you may have like a wrapper that you pass in st like for instance like jason was saying the stl vectors and c++ didn't work well but you could have someone else well probably and you can find it because i've seen these before have written code that says like you know here's how to do four by four matrix multiply in simd that takes in the vector the stl vector and outputs stl vector right and then yeah exactly it wouldn't be vector it'd be the matrix but um you know takes a matrix and outputs a matrix uh and then it handles the exact massaging into the right form and back out and And that's the only thing that gets you right.

And those are obviously very useful because it saves you a lot of time. Yeah, one thing that I realized, I just searched on our programming throwdown sort of agendas of all time. We've never talked about BLAS. Do you want to talk about BLAS? I think we should save it for a tool of the... Okay. Why don't you give the high-level? I think we should save it for a tool of the... Okay.

Why don't you give the high-level summary, and then we'll save it for... So I don't know too much about it. Okay. This is why you're telling me to do it. So BLAS stands for Basic Linear Algebra System. And the idea is, if you want to add two matrices or invert a matrix

or do these kind of mathematical operations that you do in MATLAB or one of these other tools. But you're not using MATLAB, you're using Python or C++ or something. There's this library, this set of libraries that are Blas libraries. And basically, it's what Patrick is saying. These guys have just killed themselves making the most epic matrix inversion code ever, the most epic add two vectors together code ever. And you can just use the BLAS library whenever you want to do one of those things. Yep, and they do some pretty clever stuff.

And there's some pretty clever stuff about how to determine like because there's no one right optimal way to do something it's going to vary by your l1 and l2 cache size by your number of hyper threaded cores and by the number of your processor clock speed and like every variable of your computer system. And so I made the mistake one time of compiling Atlas, which is a Blas implementation. I didn't want to use the one that was like built into Ubuntu. And I was like, I'll just build my own.

And it took something like eight hours to build. And basically it's like, you know, trying every possible, you know? Yeah. Yeah. It's like trying every possible

way to build this library just to give you an extra one percent because i don't know well we can talk about later i don't know if they do something intelligent like gradient descent or something or if they just straight out like try every permutation yeah i don't know if they do like something intelligent or if it's just yeah like you said it's a raw parameter suite um but but uh okay but yeah it takes a really really really long time and uh you know most most os's will have it built in and it'll be you know 90 something percent i'm making up a percentage as as fast as it can be but if you compile it yourself they do some really clever things to make it as fast as can be yeah that's right like the one you get from ubuntu isn't made for your machine

it's made for you know someone's machine who's building the ubuntu distribution um and so yeah patrick's right like if you build it from scratch after the eight hours you will have something that is like one percent faster but every more maybe yep yeah so everything's on the web now and everybody's trying to do graphics on the web so of course simd is coming to the web yeah that's pretty wild right i mean um so if you're going to do gaming like i said this is all about like doing graphics processing audio processing video processing all things that have a very legitimate reason these days to be done in a web browser um and if you're going to do that you're going to want to take advantage of cindy because it does give like you know it's very conceivable

to have like an 8x 10x improvement by implementing this stuff and that's that's big yeah yeah totally i mean uh me and some buddies wrote an emulator um in effectively javascript uh wrote in dart actually we talked about it on one of our shows and uh the emulator you know like rendering all the pixels actually only takes like one or two percent of the time but just executing the nintendo cpu which is just you know like a one megahertz cpu or something ridiculous, takes over 90% of the time. And it's because a lot of times you're doing simple operations, but on the web they're just so painfully slow. And so this SIMD is part of a bigger effort to sort of fix that problem.

Yep, so this SIMD is going to be added to Dart, or so it said a year ago. So I assume it's already there. Oh, man, you're right. This is a year old. I didn't even notice. So you're starting to see a lot of these things. And, again, you will continue as more and more people do stuff in the browser.

Yeah, yeah, totally. I mean, I think that it's only a matter of time before we get like we already have n script in and some of these technologies for taking you know like desktop applications and and basically compiling them for the web and it just kind of magically works but it's still like very early stages um and so this is like sort of building more of that scaffolding so that we can one day get to a place where you could just build something for your desktop and the web and it would just kind of magically do what you want well i think that's a wrap yeah cool um thanks everyone for the for following us on the stream and uh and uh you. We got some good feedback there.

Pretty cool. It's been a while since we did a show, but as you can expect with the vacation, I was on vacation, Patrick's on vacation, Thanksgiving's coming up. So it's that time of year where it's hard to find time. Yeah, we'll try to do one before Christmas,

but it may end up being January. Yeah, it's possible. but we should be able to grab some time I think we can pull it off but if not we'll see you guys in January but anyways it's always fun to do the show and

you know I'm trying to think do we have anything news worthy like meta anything i didn't look up like how many reviews you have or anything so yeah i don't think we have much meta to say um this is a pretty cool one i definitely want to cover rust um that programming language we got some other requests for languages so we'll be uh covering that we get a lot of actually the majority of our feedback is still on Google+, which is awesome. I mean, we have the Facebook and the Twitter.

A couple of people asked for those. But still, the majority of the content is happening on the G+, so definitely check that out. And send us email. We read all of them. Sometimes we read them on the show. Sometimes we say your full name and embarrass you. I don't think we've ever read

anybody's name who told us not to. No, I'm totally kidding. If you want to remain anonymous, we will do that. If you want to remain anonymous with your anonymity... Keep your anonymity in tech

all right it's late so we're gonna call it a wrap all right see you guys later stopping recording the intro music is axo by biner pilot programming throwdown is distributed under a creative commons attribution share alike 2.0 license. You're free to share, copy, distribute, transmit the work, to remix, adapt the work, but you must provide attribution to Patrick and I and sharealike in kind.