Optimizing Loops In Go | Prime Reacts

I've been working on a pet project recently that I just can't get running fast enough okay the Crux of the problem is that I need to do multiple Loops over 3D space and do some calculations on each is this a matrix problem is this just yet yet another Matrix Video position within the space after spending a lot of time in PPR optimizing the calculations I got to wondering if there was a way to optimize the loop by the way the fact that it oh I see what's happening here XX okay y y okay I see what's happening here okay so it's an array of an array of an array it's a three it's a three-dimensional array arrays itself here's the basic looping structure I'm talking about it's pretty easy to understand what's going on there but there are a few different ways this could be structured so I derived this simple test program to try out different mechanisms the first one benchmarks go range instruction and it's probably the most common way that people Loop over arrays concise to write and easy to understand the second by the way that range operation's really nice I I languages with basic range items very very very comfortable you know what I mean I like a nice range I don't like a 4 each with a function but I like a nice range it feels good test is a more classic set of Loops that iterate over the array offsets and address the requested element directly within the loop I assume that one's worse the third experiment is an optimization and I thought might speed things up by reducing the calls to the length instruction entally casing those values my expectations were that the third method would be faster than the second but I didn't know if go optimize range enough to make it the fastest of the three or not which before I I haven't seen this before anything I my assumption is that the middle one and the last one will be the same but the first one will be the fastest that's my assumption's part of the reason for the experiment after running the tests it's obvious that the go compiler has some optimiz ation around the range statement such that it's not only the clearest to read but also the fastest to execute for those that can't see um there you go there's like this extra so here's here's my here's my guessing why that's happening is that the range statement is pulling out the array it kind of seems like how it's aligned in memory is that each one of these things are are its own rows it's not like a big ond array it's like a bunch of individual arrays and so you're getting these blocks of contiguous memory and so the final one you're just reading one block of contiguous memory whereas with with this one you're doing like look at this you're doing an access an access and an access and so it's like you have to do a bunch of hopping is my guess what's going on I don't know if go optimizes that I'm not exactly sure how they would optimize that you know I don't you know I I assume that if you really thought about it you could optimize it but that'd be a very difficult you know thing to do so that's that's my assumption of what's going on here why that's why I assumed range would be better so I'm curious if if he talks about it the thing that really surprised me was that caching the results of Len actually made the loops slower the best I expected was that they'd be the same yeah I don't really understand that I'd also like to know how he's testing that but that is shocking I I I I cannot understand why that's the case speed but apparently the compiler has some genius in it that recognized the second structure and can create a highly optimized set of instructions from it at this point I thought I had my answer and that the by the way never try to fight the compiler general rule of thumb is that the compiler writes better code than you and so you should just just write like the more you write standard code the more likely you're generally doing well if that makes sense very few times when you get cutesy does it actually make it better and that's because most of the time you just don't you don't know what you're doing and the compiler is just it's optimized for whatever like the common case is and so then you just get all effed up right uh it's almost always good to write your code simple and straight to the point and it it just works result was always compiler and so just write reactjs and you'll be fine everything will be creamy smooth you'll have a job your server components will be serving components range statements but then I had an idea for a few more optimizations to attempt by putting all the data in a single array I would need to calculate offsets to locate an individual position 3D space but huh can you imagine that contiguous memory is in fact faster I assume one of the things that is happening right now is that when you have an array of an array of an array uh or a list of a list of a list because this is go right that's it's a list it's not an array it's it's some sort of moving underneath the hood list of memory is that you actually have three different locations that you're hopping to but by making one big ass one you only have one contiguous block of memory and I always assume reading contiguous memory is just generally better than reading uh non-contiguous memory like that's just like a standard but often I mean the nice part is is that for the most part in in regular programming you don't have to think about that that's just not typically something you have to run into though it is nice to know iterating through the entire list should be faster why is accessing slower if the lists are stack allocated I don't know if they're stack allocated I don't are lists in go stack allocated I don't think they're stack allocated I just always assumed I don't I don't see how they could be stack allocated like an array can uh in C because you're like hey this array is length three it's right here we didn't call Malik or anything it's like right here right that makes sense there's no concept of Stack versus Heap and go yeah but there is stack and Heap and go there is a concept of stack and Heap and go and they talk about it some things they they there's like a whole set of rules about what stays on the stack versus the Heap and all that but you don't technically like do anything with it you know I mean I mean you could also Alec alak and see yeah go moves all the values onto the stack and stores pointers uh to the first elements I really don't know if any of that is true it sounds false it sounds false to me too just because the hard part you can't move memory on the stack like in the sense that You' screw up all the return addresses and all the other in between right like you can't just can't just move things it's a stack like that it's in its name you can't just move plates out of a middle of a stack of plates and then create more plates on top it just just you see what I'm saying it just do that anyways okay a go will uh let's see will shortlived uh static things on the stack regardless of their type okay interesting I wonder how that works that sounds really interesting anyways let's keep on going let's let's let's back this up for a moment in 3D space but iterating through the entire list should be faster however the speed was roughly equivalent to the three-dimensional array another issue with this test yeah it's all very very hard to say which one was faster there is that I sometimes have to iterate through the dimensions in reverse order so I wrote another test to simulate that use case and boy was my mind blown I created one more experiment in an attempt to understand what was going on but it didn't clear anything up at this stage I don't even have a guess as to why the fifth test performed so well after all this experimenting it seems to me that most codes should just use range statements a 100 millisecond improvement over an array of 1 billion elements wow that got really quiet at the end it said one uh 100 millisecond improvement over a 1 billion array at the end isn't much it's certainly not enough Improvement to have any impact on my current problems okay I like that it's I you know I really do like when people when people document um just like what they're trying to do and what they're trying to figure out uh I also really like uh his confidence dropped his confidence dropped severely on that one you couldn't hear it I I think one thing that I really like about this entire situation that went on there is that by the way this is literally a video that this channel dropped this morning and yet here it is showing up right there um I really am happy that range statements performed well I really really like that because at the end of the day I really hate when you have to write stupid code and you're trying to like avoid performance pitfalls like the the original JavaScript was just you write the stupidest code right do you guys remember this one uh do you remember back in the day you would write things like this like uh you do you know VAR a equals this uh dap that get the hell out of here and then you do a length uh length equals zero to reset it not a equals this cuz it was actually just like it would slow your program down you do things like that to avoid it all or you do uh you do uh a uh a.length equals some new item to push you wouldn't call a. push right you would not call a. push like you would just never do that one uh dude okay shut up I shut up typescript there does that make you happy okay I'm happy now but it's funny like you just do these dumb things and you had to be like clever about it what about a range in Python we all know Python's greatest enemy is a for Loop okay it doesn't matter what it is whether you're ranging or comprehending or whatever if you're doing anything in P python involving a loop you're using the wrong language okay Python's not for Loops python is that you you use you use pandas for Loops okay you use pandas and nump of which I don't know how to use very well so I don't use them because I suck at python I'm I'm I'm terrible I'm terrible generator help okay that's good to know pirate software would never he would never anyways uh Real Talk great I love this I actually really liked this video cuz I love the fact that go just works well it's good enough for exactly exactly what he wants skill issues oh yeah skill issues trust me I I suffer from python skill issues because the thing is is that I have two Dynamic languages really strongly underneath my belt which of course is Lua and JavaScript I really don't want a third one you know what I mean I use Python to graph things but it's like very light and I just do just enough to get kind of out out of the way there I like that let's subscribe let's do that great one software chats great software chat I love this style of video this this live blogging I'd love to see more of that people just kind of just talk about stuff they're learning it's good stuff the name the primagen

Channel: ThePrimeTime

Views: 82,316

Keywords: programming, software engineer, software engineering, developer, web design, web development, programmer humor

Id: OPasPxPip8g

Length: 10min 33sec (633 seconds)

Published: Sat Feb 17 2024