I hear "C++" and yet what I see looks like 99% plain C, including the absurd habit of spamming "struct" in front of every function argument. No constexpr in sight, "inline" as if any compiler cared for the last 3 decades (outside of definitions in header files to resolve multiple definitions). Just rename the file to .c, replace "cin" and officially make it the C benchmark. At least that way one could add a comparison to see how much "actual" (read: "modern", read "not outdated for 15 years") C++ would hurt performance.

Go packages are awful. They can’t have circular dependencies because the go team are lazy/bad compiler writers.

Skill issues

18:45 Stack is limited in Debug mode cuz Rust prefers to assume the stack is small so you are less likely to get surprised in prod. 20:45 You just cant have circular dependencies. Splitting it into separate crates or sequestering out your build.rs dependencies into their own file makes it cleaner.

Rust is language you don't use if you want things to work quickly if you don't know Rust, which you don't.

a good one…you just convinced me to subscribe with your content quality . thanks 🎉🎉

1:38 you probably misunderstood how packages work. You import a literal folder,when you change the folder name,it doesn't work. You should change the name of the package within the file and try again and see what happens. I know this for a fact since for one of my projects I import the package based on folder name, but the package declaration has a different name then the folder it's in. Iirc, package names are not important,it only matters that .odin files within the same directory have the same package declaration 3:05 you can look up functions on the odin website, you just navigate to packages and there you can type whatever in the search bar. Very useful since chatgpt nor googling will help you with odin :')

This is awesome!

Man that's actually a good and simple explanation. keep it up!

8:46 the actual fast way to do it is with intrinsics that map to instructions specifically tzcnt on x86. Other important instructions for bitboards are pext and lzcnt and lead to large speedups.

Omg i love the idea of int specify your own bit. I don't like how there is inconsistency in syntax when declaring an array/slice.

zig has fmt so don't have to worry about where the bracket go :D

yeap Odin quite cool, easy to use and create some and also blazingly fast - 10 \ 10

I have been toying around with the C# code and the original is horrible. I added a new linter that had sensible rules and performed several refactors using built-in VSCode code actions such as merge if statement. === No Refactors 2525 LOC === Layer 0 2300 LOC - Turned on the linter === Layer 1 1680 LOC - Removed Extra white space - Put braces inline rather than with white space - Put singlular statements on a single line instead of spaced if under 110 characters - Fixed OutOfBounds function to be a one liner - Removed unnecessary using === Layer 2 1480 LOC - Removed redundant if..else paths - Simplified conditionals - Denested conditionals - Removed unnecessary parentheses === Layer 3 (in progress) (39% the LOC of the original) < 1000 LOC - Began extracting functions and eliminating DRY violations ===== Summary The core logic would’ve been much clearer and simpler if the functions were modular and less tightly coupled. In the best case, we could get this down to under 500 LOC, but it’s so tangled that I won’t know for a few more days. ======= Performance Side-Note I converted the bitboard_array_global and castle_rights_global to readonly and saw a noticeable performance boost from 5500 ms to 4900 ms on my Laptop. Which is 1.12x faster.

16:00 Where I last worked , it was very important to use the size_t in our C code, and generally _t variants. I'm still learning low level programming, but I think it was to do with it being embedded software having to run on many different platforms. I also couldn't use bool because we had a few platforms (or compilers for those platforms I guess) that didn't support this type.

Next time try to centralize the camera on top of the code! i means intelligently

A few refactoring tricks that are imperative language agnostic will help you. 1. Early return. --- old if (cond) { logic } else { logic return } --- new if (!cond) return .. logic 2. And instead of nested if. --- old if (cond) { if (cond2) { logic } } --- new if (cond && cond2) { logic } 3. Extraction of pure code. --- old const main = () => { pure calculation side effect pure calculation side effect } --- new // you can unit test calc1 and 2 instead of performing an integration test only on main const calc1 = (...params) => { logic } const calc2 = (...params) => { logic } const main = () => { r1 = calc1(...) side effect(r1) r2 = calc2(...) side effect(r2) } 4. Converting functions that call outside of themselves to ones that are self contained. (Only do this if possible and if it makes sense to, in rare cases in mutable languages you actually must write it in the poor style of external mutation, if you must do that, isolate it as much as you can to mitigate uncontrolled side-effects) --- old let i = 0 const f = i => { i++ } f(i) // i is mutated from f, making f non-deterministic and hard to debug --- new const f = i => i + 1 f(i) // i + 1 is returned but i itself is never mutated out from under you 5. Eliminating global variables and instead using block scoped variables. 6. Reducing mutable variables through higher order functions if applicable, such as using map, filter, and reduce. This simply reduces bug surface area, however, not all imperative languages have performant support for this. ==== General refactoring approach 1. Apply above transformations and more with the goal of concise code that is modular and easy to reason about. Clean code is easier to manipulate that ugly and overly mutable code. 2. Create Integration tests for functionality and unit tests for any pure functions you were able to extract. I recommend using property based testing approaches so you don't have to enumerate a billion example tests. 3. With the tests in place, you start slowly refactoring out with the goal of breaking up everything into self-contained functions. Functions should have 1 responsibility. Meaning that a function should do as few things as possible. The reason for this is so that you can make your system Composable rather than fragile. 4. With your composable building blocks tested, you can then build up more easily. ==== Overall, you should see a massive reduction in the lines of code and your code will be far better if you follow my advice. === Update I have seen very often people using switch statements which is super annoying and bloated. It is equivalent but more terse to use an object instead (atleast in JS, make sure your language you do this in supports hash maps). --- old switch (thing) { case ..: .. case .. : .. .... } --- new (JS syntax) const cases = { 'case1' : () => logic, 'case2' : value or whatever, ... } cases[thing] Alternatively: { 'case1' : () => logic, 'case2' : value or whatever, ... }[thing] // Note: usually you want the cases in your object literal to have a value and not be a function so that you can assign the result to a variable then do further logic // like so: const value = { 'case1' : value, 'case2' : value, ... }[thing] logic on that value ...

Perfect timing for this video! I was just getting started with Odin and was running up against this kind of issue. Great explanation about how variables end up on the stack vs heap, and how to handle some basic cases.

The BIG BIB elephant in the room!

Thank you very much. Very nice course!

And there it is C++ gorgeous language. Still king!

i love how rust segment is 3x times larger than others

Why not use zig build system, "zig init" command helps

keep up the great work!

Still no Fortran? You missed the most important language for high performance computations

You should try using C

13:20 About Nim literals - you can actually use 'u64' only on first value of array and compiler will infer that type for other literals.

Lovely odin lang videos. The sound quality of video is too low though, maybe a microphone issue?

Which of these languages would you consider enjoyable/unenjoyable? I write C++, and I don't hate it like some people do, but I do want to try some other languages just for fun like Odin, Zig, and Rust. Im heavily leaning towards Odin, and heavily leaning against Rust at this point.

For Rust what profile release optimizations did you use? Because i found an increase in performance by, of course using Release with Opt Level 3, but also using "thin" for the LTO (removed typo)

Great video.

I would highly highly recommend you take a look at one of theprimeagen's recent videos with Casey Muratori where they talk about such comparisons between languages

I'll update the speeds here if people make improvements: C: 339ms C#: 683.2ms C++: 331.2ms D: 383.8ms (compiled with ldc2 instead) was 787.4ms (with dmd) Go: 627.4ms Java: 1988ms (used longs and alternate algorithm for rook and bishop moves) Nim: 429ms (with flags: nim c -d danger -d:lto --passC:"-march=native") was 645ms in release Odin: 398ms - added no bounds check to perft function Python: 124536ms or 124 seconds just using ints and no numpy Python with pypy: 51139ms Rust: 463.03ms (made everything global) Swift: 585ms (with unsafeTemporaryAllocation) was 37,430ms Zig: 335.8ms Code: github.com/hcsalmon1/Chess-Engine-Test

I have tested your D lang algorithm on my 14 years old Asus X52F laptop with 3 different compilers. Operating system: Linux Mint 22.1 beta, processor i3 M370, 8 GB DDR3 RAM Compilers: gdc 13.3, dmd 2.109.1, ldc2 1.36 (LLVM 17.0.6) Compile, exe file size, and run times in milliseconds 1. ldc2 -O3 -release -of=main main.d 2.4 MB 1843 ms 2. gdc -O3 -frelease -o main main.d 2.4 MB 1868 ms 3. dmd -O -inline -release -of=main main.d 3.9 MB 2696 ms

No Free Pascal, Fortran or bash?

was C++ faster than C because in C++ bools are 1 byte and u used 4 byte ints in the C code?

I already said you do not need BigIntegers for Java, you can just use longs. I sent you a PR.

Maybe you can try Kotlin on the JVM, it does have ulong types. And if you paste Java code into IntelliJ it can try to convert it to kotlin automatically. I haven’t had great results with that latter feature on larger code size though, it then produces horrible style but that can be cleaned up afterwards

In c++ you didn't use bits for the least significant one digit's position. It's probably more optimized than your code.

If you were up for it, I’d be curious to see a C vs C++ vs comparison too. Great video though, thanks!

Regarding C# array[x][y] exists and does roughly what you expect it to, but there is a difference how access is processed between var[x, y] and var[x][y]

I made an updated version to this video. Here's the Github with the updated code: github.com/hcsalmon1/Chess-Engine-Test

You hate too much things, don’t you?

I don't have a idea why, but C++ was faster than C. 1) Maybe it's because the compiler developer didn't write "if original_languge == C++ then emit sleep (1000) everywhere". I would like to know why you expect something else? 2) Measure variance. The difference for C, C++, and Zig should have a insignificant p value.

For nim, because arrays only have a single type, you only need to mark the type of the first value in it and it will propegate that type to the rest of the values if possible. I'm sorry that nobody mentioned that. Also I hope you compiled nim in release mode and not the default debug mode. I don't remember how significant the difference is though.

Is the code available on like a GitHub repo? I want to take a look at the Rust one specifically.

would be nice if you show us the compiler flags as well

I believe the zig compiler doubles as a c compiler too - have you considered compiling your c code using the zig compiler to see if you get different results for the c program? Not sure if zig can also compile c++ though.

Why is Python even there lol is like comparing race cars with a drawing of a car.. I guess if you use Python with pypy it would make sense but those are compiled language vs an interpreted one

Regarding D: first, you're using the wrong compiler. To generate fast code use LDC, it's LLVM based and should be close to C++ in performance. Especially in your task where there are basically no allocations, so GC is not a problem at all. Second, vscode supports D pretty fine, just install the extension named "D Programming Language (code-d)".