12 Programming Languages Tested! - Chess move generator test with updated results

[@CodingWithTom-tn7nl]

I'll update the speeds here if people make improvements: C: global - 353.4ms C#: 768.4ms C++: 337.2ms D: 438ms (compiled with ldc2 instead) was 787.4ms (with dmd) Go: 685.8ms Java: NA Nim: 533.6ms (with flags: nim c -d danger -d:lto --passC:"-march=native") was 645ms in release Odin: 505.8ms Python: 1,383,536ms or 22-23 minutes Rust: 536.4ms Swift: 37,430ms (On Windows 11) Zig: 348ms

[@dawid0115]

22:41 well you don't have to, you can specify the type and use the dot notation like that: const multi_arr: [2][2]u8 = .{ .{1, 2}, .{3, 4} };

[@CodingWithTom-tn7nl]

Thanks, I had never seen that syntax before. It's a lot easier.

[@dawid0115]

@CodingWithTom-tn7nl you had, like in std.debug.print("something", .{})

[@andreialdea6072]

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

[@TheMachina42]

To be fair this is a much better benchmark, as the algorithm isn't just a for loop within a for loop.

[@dolorsitametblue]

@@TheMachina42 they're still useless unless you go in detail and explain why one version is slower/faster. Until then you're comparing implementation bugs/quirks that experienced (in that language) developer would not write.

[@TheMachina42]

@@dolorsitametblue That's true, I think it's a reasonable benchmark about how simple it is to write code that runs to X level of performance, obviously not perfect, but it gives a good appreciation of what kind of performance you can expect.

[@thedeemon]

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)".

[@CodingWithTom-tn7nl]

I downloaded ldc2 and ran the test again: .\ldc2.exe main.d -release 438 ms

[@samjiman]

For D, I'm not sure about the PATH problem. For me, I put "C:\Dev\D\dmd2\windows\bin64" in my PATH environment variable and it works fine, having grouped various compilers under "C:\Dev" on my machine. As for speed, it could be something to with garbage collection or lack of optimizations. You could also try using another compiler such as LDC2, which is LLVM based and might optimize the code better than the reference compiler. I usually use LDC2 for my projects as it supports ARM64 (at least on Linux) as well as x86_64. It's worth mentioning that "import stdio.stdio" is not the same as the C standard lib. In D, the C standard lib functions are provided by "core.stdc.stdlib". An example function being int exit(int).

[@dolorsitametblue]

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.

[@phusicus_404]

Test with C3 pls it's so fucking great! C++ compiler can indeed do some things which require manual optimization in C

[@meryplays8952]

Double that for C3.

[@Lena-yt3yl]

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]

[@asdfasdf-is3xf]

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.

[@CodingWithTom-tn7nl]

I wish I had known that, thanks. I always tried to use release mode in all test.

[@meryplays8952]

@CodingWithTom-tn7nl Can you please-please-please update the timings for Nim based on the above observations?

[@CodingWithTom-tn7nl]

@ It was already in release mode. I just tested regular debug mode vs release now: Nim debug: 13 seconds Nim release: 0.722 seconds I had things running on my computer so it was a bit slower that in the video. There is a big difference between debug and release. Removing u64 from the constants wouldn't affect speed at all. It's the same code, just less annoying to write.

[@asdfasdf-is3xf]

@CodingWithTom-tn7nl release mode is the recommended way to compile nim code, but there's another mode called danger that removes things like extra bounds checks. You can also use (iirc) "-d:lto" to enable link time optimization, and --passC:"-march=native" to let the compiler make system optimized assembly. I'm not sure whether other languages do any of these things by default

[@CodingWithTom-tn7nl]

@@asdfasdf-is3xf flags: nim c -d:danger -d:lto --passC:"-march=native" speed: 533ms I've updated the pinned comment with the new speed.

[@Evansgr123]

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.

[@destiny_02]

yes it can, but the c and c++ compiling functionality is actually handled by clang compiler. main benefit to using zig c++ over clang is it has better cross compilation support and can produces smaller binaries (since all headers are compiled from source with your custom flags, rather than just linking precompiled library)

[@CodingWithTom-tn7nl]

I'll try it and see the difference. Edit: zig cc -O3 main.c Constants.c 351ms It was the same speed.

[@LTibor2012]

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

[@gronki1]

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

[@CodingWithTom-tn7nl]

Maybe I can try Fortran at some point. I just have no experience in the language and got burned out trying out too many new languages.

[@nupaulmiller6412]

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)

[@CodingWithTom-tn7nl]

Cargo.toml: [package] name = "main" version = "0.1.0" edition = "2021" [profile.dev] opt-level = 1 [profile.release] opt-level = 3 lto = "thin" Command: cargo build --release time: 534ms

[@nonae9419]

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.

[@destiny_02]

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

[@CodingWithTom-tn7nl]

CPP: Release mode 64 bit, in visual studio C: GCC -O3 C#: Release mode 64 bit, in visual studio D: --release Go: no flags nim: nim c -d:release main.nim Odin: -opt:2 -no-bounds-check Python: no flags Rust: cargo build --release in cargo.toml: [profile.release] opt-level = 3 Swift: -release (I think) Zig: -O -releaseFast

[@destiny_02]

@CodingWithTom-tn7nl using different compilers for C and C++, that explains the performance difference. try using -O3 -march=native -static -flto -s for even more performance. also would be interesting to see CLANG vs GCC vs MSVC(visual studio). often clang produces faster executables.

[@thedeemon]

@CodingWithTom-tn7nl For D it should be "ldc2 -O --release main.d" For Swift it should be "swiftc -O main.swift"

[@Nellak2011]

Hey if you are adding more languages, try out F#. I am wondering if it is comparable to C# or if it is faster

[@phusicus_404]

@@Nellak2011 I guess not faster

[@CodingWithTom-tn7nl]

I have almost no experience with functional languages, so that would be a lot more work than copying the code and fixing the errors. I've tried coding in Haskell before and still barely understood most of it.

[@Nellak2011]

@CodingWithTom-tn7nl F# is not like Haskell. It is functional first, but has full interop with C#. If you need to do C# stuff for OOP or performance, it lets you but discourages bad patterns strongly by its design. Imo it is a great language.

[@sjorgen9122]

F# and C# both compile to the same Intermediate Language (IL) that then is JIT compiled into machine code, so there wouldn't be any performance difference for the same IL. But, at the level of the programmer you could be better or worse at one or the other at writing optimized code to give to the compiler and would maybe see a performance difference that way

[@MrWorshipMe]

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

[@realGeobor]

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.

[@TheMachina42]

Odin is the simplest, Zig is imo the most enjoyable one (but there is a 2 week period needed to stop thinking like C/C++, and adapt). Rust is the more C++ like imo but I don't really enjoy it, It's cool for string processing tho, Rust is almost like C++ but with sane defaults if that make sense.

[@skilletpan5674]

No Free Pascal, Fortran or bash?

[@meryplays8952]

Double the first two.

[@danny-jo1rb]

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

[@desertfish74]

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

[@CinergyTech]

Would like to see comparison of other languages next round such as Mojo, Carbon, Pony, Ring, Gleam, Julia, V Lang, Elixir, Lua, Dart and Kotlin. Can make simple loop code or binary search algorithm for the comparison.

[@CodingWithTom-tn7nl]

I'll take a break from comparisons for a while. It was a bit stressful getting these to work. I've already started confusing aspects of languages. But I'll definitely make more comparisons in the future though.

[@zoltankurti]

Great video.

[@iCrimzon]

Go is the best again as usual, gotta put the Nim logo on top of the Go logo if you include it next round. (I'm not sponsored by big Go)

[@songxu7837]

I am the first😁