The MOST IMPORTANT Considerations in Programming! // Code Review

Click this link sponsr.is/boot... and use my code CHERNO to get 25% off your first payment for boot.dev
Support ► / thecherno
Instagram ► / thecherno
Twitter ► / thecherno
Discord ► / discord
Code ► github.com/Nic...
Send an email to [e-mail] with your source code, a brief explanation, and what you need help with/want me to review and you could be in the next episode of my Code Review series! Also let me know if you would like to remain anonymous.
Hazel ► hazelengine.com
🕹️ Play our latest game FREE (made in Hazel!) ► studiocherno.i...
🌏 Need web hosting? ► hostinger.com/...
💰 Links to stuff I use:
⌨ Keyboard ► geni.us/T2J7
🐭 Mouse ► geni.us/BuY7
💻 Monitors ► geni.us/wZFSwSK
This video is sponsored by Boot.Dev

[@TheCherno]

What do you guys think? Let me know below! 👇 Also don't forget to check out Boot.Dev! Click this link sponsr.is/bootdev_cherno and use my code CHERNO to get 25% off your first payment for boot.dev

[@johnhsu5459]

Please do continue this series. Sometimes it's more important to review one code in depth rather than review multiple codes shallowly.

[@ty.davis3]

I agree. I feel like a good amount of these code reviews have become discussions of syntax and style preferences, and it's nice to dig a bit deeper, though I definitely would've like to see more code in this video

[@salockin9515]

Hello, I am the author of the code. Again, Thank you so much for reviewing it is incredible to see my favorite coding KZbinr look at something that I am very proud of. Also for anyone wondering, I removed both of my global using namespaces, the change is in one of the latest commits of the branch I'm currently working on.

[@Honorius-i1t]

I'm impressed with what I've seen so far. When it comes to coding, (as with most things), there's always something new to learn and to improve on. Focusing on efficiency, economy and well structured and documented code will see you well for the future. Despite what some may tell you, it is important. It's something that is lacking from most professional coders these days because they've not had to learn 8-bit assembly where it mattered a lot. (If any Windows developers read this, I'm looking especially at you!!) EDIT: This is in no way a dig at you Cherno by the way. You haven't said anything of the sort. I admire your skills.

[@salockin9515]

@ thank you. I do need to leave more comments.

[@namiflowers00]

there are two types of programmers: 1. the type who writes a chess engine and claim it's some of the best code ever. 2. the type who creates a website in php, gets arrested, gets 2 life sentences, get pardoned.

[@Brad_Script]

3. Rust programmers who are too cowardly to write in skillful languages like C/C++

[@Moonix7]

@@Brad_Script Bud, I have experience in both languages, and boy would I have to say is that, Rust is harder than C/C++, and the only reason I say that is because rust is extremely strict, Lifetimes, Atomic reference counters.... C/C++ developers have the luxury of writing whatever they want in whatever way, rust programmers are forced to adhere to the rules of memory safety. C++ and C are also pretty minimal languages it's not like you have to learn thousands of keywords, the only hard thing about them is learning the standard library. I would say that rust is more skilful, because in rust your really have to know memory safety and all this lifetime stuff. In C/C++ you can get a way with that.

[@leonm8906]

Then there is me, wishing I had the kinda money that would get me arrested for 2 life sentences and then pardoned.

[@themakabrapl2248]

​@@Moonix7I would argue that strictness of Rust makes it easier because it will tell you that you are doing something very wrong, it takes away from knowing how to write memory safe code by just not letting you make unsafe code. It just requires more knowledge to write basic code

[@Kerojey]

@@Moonix7 bro, get a life

[@ferdynandkiepski5026]

Storing the board in bitboards is the correct approach, though your point in general is correct. Because of tzcnt, lzcnt and pext instructions and their equivalents on other architectures it is possible to make it very fast. Also bit manipulation in general is very fast. Way faster than additional memory accesses.

[@siddhantbiradar1791]

Please continue the series. In-depth code reviews will be very informative.

[@ralph_d_youtuber8298]

Cherno missed a killer line. "Theory can only take u so far" -Oppenheimer

[@ABaumstumpf]

At work we had some classes that cause more performance degradation than they should have - given the simple operations that were done on them. Certain member were read more often, others were needed for indexing, and again others were modified. For one particularly often used one we invested a lot of work to get it as fast as we could: Adding indirection and intentionally ballooning the class, moving members around etc. we ended up with a 3 layered class where the basis only had 32 byte - the data needed for iteration and identification, an index to some meta-data that is used often, and pointers to the rest of the data. It was several times faster in our application despite now being larger and needing pointers to access anything useless - simply by the fact that now memory-access was predictable, altering the members no longer invalidated the cache needed for finding the objects, and the data needed for searching and identification was nicely aligned and easy on the memory controller. Small is good, good layout is better.

[@btarg1]

TL;DR - "this code focuses too much on optimising on an extremely low level when realistically your grandma's 486 can run this at 9000 fps" don't prematurely optimise based on theory, when you don't exactly *know* you're making a difference

[@dimitri0404]

For anyone interested in chess engines in particular, check out Sebastian lagues videos on the topic. He made some videos where he made one himself, and then made a challenge to his community to make the best chess engine. He then made a video checking out these chess engines. The challenge wasn't just about making a chess engine, but making a tiny chess engine.(Meaning there was a limit on the amount of tokens of the code)

[@tilikshinkurt]

damn new sponsor expected brilliant 😂😂

[@MrHerbalite]

30 yearrs ago I followed a book on programming chess in BASIC. What I learned from that book is that because of the moves of the knight to check the moves is a abord of 12x12 (true field can be moved to, false cannot be moved to) it was much faster to processs illegal moves off the board because of the 12x12 board. 2 additional rows on each side of the board. The processing of data was a more important consideration for speed purposes

[@akim6575]

I agree with you that we can't make an inform decision just looking at the data representation but I was expecting in a 20min video that you actually inspect the code. Here some of my guesses based on my experience on Ultimate Tic Tac Toe Bitboard representation works well to accelerate all basic operations if you are able to use bit operator Example - To get empty cells : ~(b1|b2|...|b12) - Count the number pieces : __builtin_popcount(b1|b2|...|b6) - __builtin_popcount(b7|b8|...|b12) - etc Usually you perform the same operation on the 12 words (b1,...,b12) This the perfect situation where you can use SSE to get all the results with only one instruction Bit representation also helps with the hashing of the board. (see zobrist) I don't know if he used a transposition table to accelerate his minimax but this representation is still memory efficient for a lot reasons I won't develop here I hope for a part 3 where you actually dive into the heart of the code (minimax, getPossiblesMoves, evaluate). Those are the hotspots where a good programmer need to know the subtility of C++ PS : sorry for my english

[@nepp9574]

I feel like this as well. Seemed like the whole video explained one rather easily explained statement which then got explained in 3 different ways but was the same exact thing. Seems like most videos are like that tho, focused on the absolute beginner that hasn’t touched a line of code before whilst code reviewing 10 lines per video. I really liked a lot of cherno’s videos before, but the focus has switched to the ultimate beginner and other series just get abandoned.

[@Jasruler]

This was SO good. You balance introducing the low level concepts in a very practical way that means learning the WHY behind a decision that was made in context of the options.

[@ast_rsk]

Lots of great examples in just a small explanatory section of dev comments, wow! Definitely would love to see this continued.

[@CaptTerrific]

8:34 aligning to 64 bits is probably a lot faster! The amount of data is so tiny, there's almost no way the entire board state isn't living in L1, but certainly always in L2. The registers will be a lot happier working with 64 bit information. You really shouldn't be worried about calls to memory when you're using such small amounts of data, and your biggest concern is efficiency of CPU operations.

[@mr.anderson5077]

Yeah but think of data as megabytes how would you pack it in memory. That's the art we want to learn

[@ABaumstumpf]

@@mr.anderson5077 "That's the art we want to learn" Most of the time then you are already doing it wrong. And having the memory aligned still is the better idea. Even when requesting large amount of data - if it is not aligned then you are still trashing your cache, the CPU needs to do extra work, loads and stores can be stalled and perfectly fine data be marked as dirty cause it shared a cacheline.

[@irrelevant_noob]

32 bit data is still going to align fine... What's obscure imo is the way these piece-specific bit-boards will need to be used, e.g. when checking if a rook move is valid all the squares in between the two locations will need to be checked to be free... in all the 12 bit boards, instead of just once in the board-state representation. But whatever, there might be *_some_* benefit that isn't very apparent rn. Plus, it's not just piece locations that will need to be known for a "board state"... There's the castling checks (has the king or the rook moved?), the stalemate check (number of non-pawn moves since the last capture), whether any pawn can be captured en-passant, etc. These will mess the bit count a smidge. :-)

[@ABaumstumpf]

@@irrelevant_noob "32 bit data is still going to align fine..." Memory loads are 64 bit. Math-operations can be done on >=64 bit. This way of representing the chess-board has been used for decades at this point cause it can do a lot of checks or moves in a single operation. "when checking if a rook move is valid all the squares in between the two locations will need to be checked to be free... in all the 12 bit boards" With bitboards that is 12 sequential loads and simple bit-operations(most likely in cache, but otherwise still prefetched). with an 8x8 byte array that it could be as little as just 3 loads, but also many more with branching and random loads. In general fast implementations will have not just that but other representations in memory and update them based on the bit-boards to get faster results.

[@galacticminx]

I learned a lot about these kinds of optimisations when developing a Rubik's cube solver. Almost everything was a compromise between speed and memory usage. I could make it faster but it used more memory. I could make it use less memory but it was slower. The optimum design was machine dependent.

[@onejdc]

To put a slightly finer point on what he was getting to here (and has said before) is this: When you need to write particularly performance-intensive code, consider Data-Oriented Design. Recall that the computer is a physical thing, and when you store data optimally, it keeps the data as close to the cpu operations as possible (L1 cache), while being cognizant of the fact that the default Type for a variable means data in memory will have both size and alignment. That means if you use a uint32_t for a 1 byte piece of information, you're not only using up a full 4 bytes instead of 1, but it means you're more like to introduce cache misses. Why is this important? Well ... cache is *fast*. if the computer has to go "all the way out" to main memory (or even worse...disk!), it might take 60x-100x longer. For a single value, that not might matter that much, but if you really optimize all of your data structures (like an Array of Structs) and refer to things by their array index, you might very well see large performance improvements. Data-oriented design is trying to write your code in a way that sets up the CPU to be the most peformant it can be, but it definitely comes at some cognitive cost for the developer -- you kinda have to think outside the box some times, and make some assumptions about data you might not otherwise. Andrew Kelley did a recent talk about how he did this with the Zig compiler -- definitely worth a watch if you're new to this kind of thinking. Props to Cherno here for taking on a specific example he hasn't dealt with before and hitting us all with both theory and a call to action

[@ABaumstumpf]

That also means you might WANT to use a 4byte type to store a 0-100 value cause of better alignment and less cache trashing.

[@mikefochtman7164]

Nice discussion about data representation. Board-centric or piece-centric is a good thing to consider. We might also have a similar structure to represent each piece's possible moves. Again the amount of memory isn't tremendous, but the need to access and store might be important. Each piece has a limited number of 'directions' and a limited 'move length' (some pieces limited to single 'step' while others up to eight 'steps'). Like a lot of projects, we often spend more time just thinking about it than actually typing code. And I agree that 'banging out some prototypical code' to get some idea of performance is worthwhile. Once we spent over a month on some stuff, with the full intention of throwing it away, just to learn the issues and bottlenecks. A bit extreme I know, but it was worth it in the end.

[@izzyblackout1090]

Cherno: Theory.. Siri: You're talking to me?

[@irrelevant_noob]

13:53

[@dawiddulian2403]

Delve deeper into this code please! You've been providing a very valuable feedback, and I can't help but assume it was due to the 'best code ever written' claim made in the email 😄

[@skhan1786]

Yes continue this series. Thank you

[@Djellowman]

Pretty good video. I would say that your approach, although I would do it the same way, is not from the perspective of the pieces; it's from the perspective of the board instead of multiple binary piece location maps. The perspective of the pieces would be keeping a list of all pieces, storing their position in the piece objects, and discarding any representation of the board. That approach is ofcourse silly and inefficient here, as the pieces interact with each other based on the positions.

[@reubenrk3406]

Everytime I watch your videos I learn something new

[@gsestream]

well, do also measure when considerations make any sense to ponder on. minimal issues can become monsters for no reason. so each full chessboard evaluation snapshot instance takes 64-bits x 7 types to store. or kinda 56 chars length string to store. when you make the move tree you store that amount of data per node. then you just iterate through the tree. so if the practical implementation does not agree with the theory, then either the theory shuggers or the implementation shuggers. they cant say anything about each other, only if the theory matches the implementation, it verifies that the theory was and is correct, still. also thinking takes energy, and sometimes you are tired. its the knapsack problem, where you optimize effort for a cost, energy. optimal is when you get the most with minimal usable effort.

[@Mahm00dM0hanad]

Thanks a lot for those nuggets of advice, really appreciate that

[@MrAbrazildo]

I never saw the details, but I read some ideas about making chess engine. 12:14, they don't have max depth. Instead, they go all the way through the slower memories, because they already get a good concept about the situation on faster memories, letting the deeper analysis just to tune it better. They spend lots of memory, because it's possible to find something better way deeper/later on the analysis. 12:35, yes. The bits chessboard wastes lots of bits for empty/uninteresting squares. However, this allows it to make several operations in parallel. I once made a chess engine from my ideas, fitting it entirely on L1 cache of 64 KB, but it didn't use this bitwise idea. It resulted a lot slower!

[@irrelevant_noob]

Oh, parallelization was the hidden benefit! ty. (but for the other point, i'm pretty sure there'll always be a max depth, you can't just analyze 200 moves in advance all the time.)

[@MrAbrazildo]

​@@irrelevant_noob Despite there is a clock time limit for the whole game, for which is recommended to self impose an average time limit per moves too, the engine doesn't has to has an unconditional limit. It's not a technical problem, just a practice limit as in any other sport.

[@V000idZer000]

Very well. Time to actually look at the code next time :)

[@RonyMarcolino]

Thank you, very special tips in this video series

[@nestor1208]

this is extremely important, thank you!

[@ericlizama8552]

Do you have any videos on fixed-width types a portability? I’d love to have that knowledge at some point.

[@anon_y_mousse]

I never thought to question that representation of the data before, but now that I've given it some thought, I think it would probably be better if each spot on the board were represented as a uint16_t in an array of 64. That would push the data up to 128 bytes per board, but it would still allow for an instant linear transformation and wouldn't require special instructions like popcnt.

[@user-sl6gn1ss8p]

Why not 1 byte per square then?

[@anon_y_mousse]

@@user-sl6gn1ss8p If you represent the pieces simply as two bits per piece, with one indicating the type and one indicating the color, then you only need 7 bits per square, and that would work too.

[@anon_y_mousse]

@ Apparently half of my posts are either deleted or shadowed, so I'll say it again, but it depends on the actual representation of pieces and whether you represent each piece uniquely, including color information. If you just designate type and color, then you only need 7 bits and uint8_t is perfectly fine. Of course, this also depends on whether you use bit patterns as well, and you could represent every piece uniquely with just 5 bits if you used a sequential ID alone.

[@chillydill4703]

That trailer should be on a t-shirt ASAP!

[@braver210]

I think it would've been better if he created a 8x8 1 byte matrix. Then he would used the first bit for the color(aka odd number is white/not odd is black). The rest of the bits would've been used to actually represent the piece type.

[@google_was_my_idea_first]

You still didn't explaine how you get from an 8x8 grid of bits (1 or 0), only knowing if a piece is there or not, to knowing *which* piece it is?

[@thewelder3538]

The statement of "the more compact we keep our memory, the faster it is to access it", is patently untrue. In fact, in the majority of cases, it's not even close. You VERY often trade memory space for speed of access. In this case, storing the board bitwise, although memory optional is very likely to incur a performance penalty because of the bit manipulation you have to do to extract the data you require. Personally, given the access architecture of the x86 and cache lines, you're MUCH more likely to get better performance storing each square as a uint32_t rather than bitwise. This is due to things like alignment, access time, less requirements for bit manipulation and the size in relation to the cache line. So, although I'm usually a fan of bit packing and bit fields where possible, using them can cause you some really unexpected performance penalties.

[@ABaumstumpf]

For chess-engines on x86 machines there exist a lot of well-documented techniques that needs a specific memory layout. Some of them "waste" a lot of memory to get better cache retention, others use specific bit-layouts to be able to use vector-instructions and do many computations while staying withing L1/2. Chess is a fields that is very different to basically all other games and what might be (perceived) as true for normal games would be completely wrong for a chess engine.

[@mihirpatel3010]

Please write a book.

[@kutanarcanakgul5533]

Good idea :D

[@jigsaw2253]

No

[@mikeweathers5726]

Yes

[@iani_2020]

Yes very good idea! I support it. Cherno what about books of C++? Network in C++? Graphics?

[@AndreiMuntean0]

If he writes a book that’s time he could have spent making videos instead, and the videos are a great joy!

[@kennythegamer1]

Object-Oriented Programming and Domain-Driven Design aren't the same, and neither say to ignore how a processor works; those animal hierarchies are examples for teaching after all. (Yes, copious virtual method calls is bad, but that's not the most efficient way to implement OOP.) Also, data is important as of course data and the algorithms that work with it are necessarily linked, but you'd think that the people who laud Data-Oriented Design would realize it's actually the part that has execution time that they're optimizing even if they just change data layout; the algorithms they use must be like air to them.

[@MrEscuchimi]

You missed the red & white hawaiian shirt

[@ericisconfused]

I feel like the Cherno just watch that 2014 CppCon keynote by Mike Acton (Data-Oriented Design and C++)

[@bidanfullko1]

Seeking connection with human data(results too) and computers logic(space and calculation). General qoute. 🙃

[@NoName-ui5ou]

What's your opinion on the odin language?

[@RaubeR666]

14:00 In theory, theory and practice give the same results. In practice, they don't.

[@ciCCapROSTi]

Oh, I thought you'll go into the actual code to see what data representation would have been better. Naively I think the more compact board based one would be better for two main reasons: you need a lot of them for the tree, so size actually matters, and you very frequently will need to check which moves are valid, and for that you'd have to go through all 12 pages in the original to see, of course you can use bitwise AND but that's still a lot more operations on larger data. But maybe the algorithm uses it more effectively than my naive idea would work.

[@nordern1]

Bit boards are a very common optimization for chess engines. They help for more complex board evaluations and allow better caching and precomputation. The video "Coding Adventure: Making a Better Chess Bot" shows some ways in which they can be used.

[@corporalwill123]

While yes you would need to perform a lot of checks, I think the advantage with the bitwise operations would still win out To generate all future possible moves for the board based representation, you will have to loop through each cell and manually generate the offsets for each piece in every cell, and then again you will have to check if the move is valid at each iteration as well Since compact representation contains every piece, there is absolutely no way to avoid having to check every single cell, to make sure the right move generation is done now, for the bitfield, lets say you first create a board with all currently occupied positions, so it would just be 12 OR operations and store it in B, and you invert it to then represent all spaces so S=~B to generate the new set would only need bitwise operations, for example (assuming bits start from bottom left to bottom right), to generate all white pawn moves (ignoring en passant) lets say with the current state P, all you need to do is (P>>8)&S for non-capturing, and (P>>7 | P>>9)&B for capturing since the initial 12 OR and 12 NOT operations will be spread over every future move calculation, and there are 12 pieces, we can effectively say it amounts to 1 OR and 1 NOT per field, then only counting the white pawn operations, it will amount to 6 + 2 or 8 bitwise operations now let's say generating the white pawn moves with the looping method takes N instructions per pawn, for the initial configuration with 8 pawns, it will take at least 8*N instructions setting 8 bitwise operations = 8 pawns * N instruction means for the first method to win, each pawn would essentially need to have it's moves calculated in 1 instruction, which is obviously not possible, so for 8 pawns, bitwise will always be faster, even going down to 1 pawn, as 3 would have to taken just for doing the for loop, so doing each pawn with 5 doesn't seem reasonable now for the other pieces it's a bit more complicated, since they can move in more than one direction, and pieces like the queen will have to be able to stop if they encounter a piece, but hopefully this has convinced you that the bitfield is the right way to go about it (haven't watched the chess bot video mentioned in the other comment, so I'll probably do that later)

[@salockin9515]

@@corporalwill123 You are absolutely correct. If you're interested, the queen and other slider pieces get their moves generated using a technique called "magic bitboards". Basically, all possible moves for every square are pre-generated when the program starts, and you use a hashing algorithm to convert the current board occupancy to an index to the possible moves for that position.

[@kutanarcanakgul5533]

This episode of Code Review series is the best one ever. Woav we need a playlist called Compatible Programming or How to Think Like a Machine and you can show us how to write CPU or Memory efficient codes.

[@CoolModderJaydonX]

At 1:45, I likely would've made this a 2D array of an enum type, maybe called "ChessPiece", instead of merely a 64-bit integer.

[@debsarkar4893]

I was also thing about that 😀

[@andre_van_duin]

That would be super slow compared to bitboards.

[@sinom]

So making it a 2D array would already make it slow and would potentially mean some of the data is at a completely different points in memory making it even slower. Additionally by default every enum would be a 32 bit integer. So instead of 12 64bit numbers tightly packed together you'd have 64 32 bit numbers potentially spread around everywhere in memory.

[@sidcitris4162]

Not a single line of code was shown in this code review. Still very informative and a good video, just thought it was funny no code was even scrolled through, just the comment at the top of a file

[@DiamondWolfX]

9:43 It's like a bus

[@NintendoJimmy]

I am using data oriented design building games. But OOP in many other cases where performance is not that important.

[@Andeijogando]

system("pause");

[@mr.mirror1213]

fresh comments, Please restart the ray tracing seties

[@quaffie]

do you consider doing onlifäns?

[@tzimmermann]

smfh

[@winchester2581]

Yes, there are a lot of stuff like Hot C++ code

[@atijohn8135]

@@winchester2581 __attribute__((hot)) functions in your area ❗❗❗

[@sheaksadi]

One piece mentioned

[@sdegueldre]

There wasn't a whole lot of code being reviewed in this "code review".

[@TheKastellan]

Coding isn,t just "code". It is the solution, the tooling, etc etc, as well as the "code"

[@Sl33pySt3rdust]

i love c++

[@henokeshetu3232]

this "...best code ever ..." man didn't realize what coding is 😁

[@mobslicer1529]

cherno you should review my windows abstraction code in my game engine it's so evil

[@dj10schannel]

👍 good vid

[@znyd.]

❤

[@wolpumba4099]

*Best C++ Code: Data Representation in a Chess Engine* * *0:00:05** Introduction:* The video discusses the data representation of a chessboard in memory, focusing on how the board is structured for optimal performance in a chess engine. * *0:00:28** Data Layout:* Data layout and memory management are emphasized as crucial aspects of programming, especially in performance-critical applications like a chess engine. * *0:00:58** Bitboards:* The chess engine uses bitboards, where each piece type (e.g., pawn, rook, knight) for each side (white and black) is represented by a 64-bit unsigned integer (12 in total). Each bit corresponds to a square on the board, with a '1' indicating the presence of that piece type on that square and a '0' indicating its absence. * *0:02:34** Piece-Centric View:* The board is represented from the perspective of the pieces rather than the squares, which is efficient for evaluating moves and board states. * *0:05:29** Bitboard Efficiency:* Bitboards are optimized for the specific algorithms used in the chess engine, even though they might not be the most compact way to store the board state. * *0:06:35** Transformation Efficiency:* The choice of data representation is linked to how the data will be accessed and transformed. Compact data can be faster to load and process, but the complexity of operations on the data also plays a crucial role. * *0:08:07** CPU Cache:* Smaller, more compact data structures can be more efficient due to better utilization of the CPU cache, leading to faster access times. * *0:10:28** Testing and Optimization:* The video emphasizes the importance of testing different data representations and algorithms to find the most efficient solution for a given problem. * *0:13:16** Trade-offs:* There's a trade-off between compact data representation and the complexity of operations performed on the data. The optimal choice depends on the specific algorithms and performance requirements. * *0:15:04** Human vs. CPU Perspective:* The video contrasts the human-intuitive way of representing data (e.g., object-oriented programming) with the CPU-centric way, which focuses on efficient data access and manipulation. * *0:16:33** Array of Structures vs. Structure of Arrays:* This concept is used to illustrate the difference between interleaving data elements (less efficient for certain operations) and grouping similar data elements contiguously in memory (more efficient). * *0:18:48** Conclusion:* The main takeaway is to consider the layout of data in memory in relation to how the data will be transformed and used by algorithms. I used gemini-1.5-pro-exp-0827 on rocketrecap dot com to summarize the transcript. Cost (if I didn't use the free tier): $0.05 Input tokens: 33662 Output tokens: 611

[@Al-maghrib-]

so you have just abandoned your engine, and spamming this CODE REVIEW videos ????

[@tilikshinkurt]

why do you not reply to any comments even the ones on top tho 😉

[@--bountyhunter--]

3 minutes ago, 3 likes bro fell off

[@PhilippeSymons]

I stopped listening after I saw the bitboard stuff. I know this is not your code, but this doesn't seem even close to "best code". This data layout seems cumbersome to deal with and seems to force you to iterate over data points much more than is needed. Since a chessboard has 32 pieces, technically only 5 bits are needed to represent every piece on the board. But if you lay it out like that, it's annoying to deal with and you'd have to juggle bit alignments. So I'd just have an array of 64 bytes. Every position on the board is 1 byte. You probably came up with this later in the video at a fairly slow pace, but I couldn't stomach watching any further. It's not your video, the scenario just frustrated me too much to continue watching. Have a nice day!

[@BittermanAndy]

This is an extremely naive and ill-informed take that he (partly) addressed in the video, if you'd kept watching before commenting. Just minimizing the amount of memory you use just isn't that important for the algorithms used in a chess engine. What are you going to do with it then? You're going to need to know where the pieces are, and where they move. Suppose you want to know where all the black pieces are (but not the white pieces), you're going to need to create a new 64-byte array and go through your 64-byte array of the board copying only the bytes representing black pieces - so you end up needing a 64-cycle loop (either with a counter or unrolled), 64 branches (with some logical ORs inside the branches), and up to 16 assignments (when you find the pieces in the board and need to assign them in your result), to get a 64-byte result. If you're using bitfields, you just use bitwise OR operations: allBlackPieces = blackPawns | blackKnights | blackBishops | blackQueens | blackKings. That's only 4 logical ORs and a 64-bit (8-byte) result. It's vastly faster, and for the way chess engines work, it's just flat-out better. Cherno covers this (while admitting he's not an expert on chess engines, but he intuits the idea). You might have learned something, if you could stomach it. "Optimal" memory use depends on what you do with it, not just less == better. That was the entire point of the video.

[@SoDamnMetal]

Lol, the piece count doesn't matter. A board always has 64 squares, and any one of them can have a piece on them at any time, so you must have a 64 bit representation for each piece type to know where they are. The uint64 is defacto standard and it doesn't get any more efficient than that.

[@Iuigi_t]

So when you make a ray tracer, you don't use any acceleration structures because it is "cumbersome"?

[@PhilippeSymons]

​@@BittermanAndy Still haven't watched it, but the operation you mention only seems relevant in a single scenario to me: when it's the cpu player's turn in order to loop trough every cpu's pawn and backtrack every available action and grade these actions. For the players' turn, after all, you may only need to show ui feedback about the available actions of the selected pawn. You wouldn't need to also create a separate list of players' pieces, because you would only need to know if there's a piece at a specific index of the grid when you're considering one of the limited set of moves. None of this requires creating a new bitboard or 64 byte array at all: Iterating through a contiguous 64 byte grid until you found all the cpu's pieces isn't particularly costly. I mean, you'd have to do the same thing bit-by-bit with the 12 bitboards anyway. But even in case it would be the bottleneck, then you could still optimize it by storing 2 additional unsigned 64 integers with bits to represent WHERE the player/cpu's pieces are stored if that would actually be a bottleneck. The 64 byte array then is used to lookup the pawn type. The only reason during gameplay to create new 64 byte arrays or bitboards would be to store/consider the result of a possible cpu action during the backtracking process. But even then it would be a simple memcpy in combination with specific manipulations at the relevant indexes. In any case, using a 64 byte array would simplify the code, debugging (because more readable data) and reduce memory at the same time. And sure, there may be a topic I have missed by not continuing to watch the video. But right now I don't see it.

[@ryan-heath]

​@@PhilippeSymons the number of possible moves to check grows very fast to absurd sizes. To mitigate this problem using a small memory footprint is king. Here a few numbers from chatgpt: Depth Estimated Positions 1 35 2 1,225 3 42,875 4 1.5 million 5 52 million 6 1.8 billion 7 62 billion 8 2.1 trillion 9 75 trillion 10 2.6 quadrillion 11 91 quadrillion 12 3.2 quintillion And depth 12 is not even a strong chess engine ... Last year Sebastian Lague had a few chess engine video's here on YT. I also took part in his Chess bot challenge (ended at pos 64 😎). I learned a whole new world of chess engine programming, using bitboards is more or less the "standard".

[@MuhammadAl-Sharif]

❤