I used C++ in the past. I liked .h files. I use C# now but I don't see a reason to go back.
Maybe anyone going back to C++ can answer the question why use C++ instead of C# ?
Why C++ instead of C#?
Moderators: hgm, Rebel, chrisw
-
- Posts: 179
- Joined: Tue Jun 15, 2021 8:11 pm
- Full name: Emanuel Torres
Re: Why C++ instead of C#?
Performance is the biggest reason for me. If you're not too concerned about performance, C# is fine.
[Moderation warning] This signature violated the rule against commercial exhortations.
-
- Posts: 389
- Joined: Tue Oct 08, 2019 11:39 pm
- Full name: Tomasz Sobczyk
Re: Why C++ instead of C#?
No garbage collector and easier to optimize on the lowest level, more control over the resulting code.
dangi12012 wrote:No one wants to touch anything you have posted. That proves you now have negative reputations since everyone knows already you are a forum troll.
Maybe you copied your stockfish commits from someone else too?
I will look into that.
-
- Posts: 7216
- Joined: Mon May 27, 2013 10:31 am
-
- Posts: 179
- Joined: Tue Jun 15, 2021 8:11 pm
- Full name: Emanuel Torres
Re: Why C++ instead of C#?
You shouldn't be allocating in the first place.
[Moderation warning] This signature violated the rule against commercial exhortations.
-
- Posts: 7216
- Joined: Mon May 27, 2013 10:31 am
Re: Why C++ instead of C#?
Yes bad programming habit. Unless efficiency is not a problem in that part of the chess engine.
O wait. Maybe it can still trigger a garbage collect later on.
-
- Posts: 881
- Joined: Sun Dec 27, 2020 2:40 am
- Location: Bremen, Germany
- Full name: Thomas Jahn
Re: Why C++ instead of C#?
A disadvantage of C# is that the compiled program needs the .Net Runtime to run. Either your users have to install it or you have to create really bloated executables (20MB for a simple chess engine) where you include all dependencies in a the (now self-extracting) executable.
-
- Posts: 883
- Joined: Sat Mar 13, 2021 1:47 am
- Full name: Amanj Sherwany
Re: Why C++ instead of C#?
It all depends on your goal, if you want to create the best engine ever, and you don't care about the effort, go for ASM, if you also want to keep your sanity but still create a very competitive engine, go for a language that you have almost total control (C, C++, Rust maybe?)
If you want to learn a language, use that language, there is no one size fits all
If you want to learn a language, use that language, there is no one size fits all
-
- Posts: 7216
- Joined: Mon May 27, 2013 10:31 am
Re: Why C++ instead of C#?
From msdn:
"Allocating memory from the managed heap is faster than unmanaged memory allocation. Because the runtime allocates memory for an object by adding a value to a pointer, it's almost as fast as allocating memory from the stack. In addition, because new objects that are allocated consecutively are stored contiguously in the managed heap, an application can access the objects quickly."
https://docs.microsoft.com/en-us/dotnet ... ndamentals
"Allocating memory from the managed heap is faster than unmanaged memory allocation. Because the runtime allocates memory for an object by adding a value to a pointer, it's almost as fast as allocating memory from the stack. In addition, because new objects that are allocated consecutively are stored contiguously in the managed heap, an application can access the objects quickly."
https://docs.microsoft.com/en-us/dotnet ... ndamentals
-
- Posts: 881
- Joined: Sun Dec 27, 2020 2:40 am
- Location: Bremen, Germany
- Full name: Thomas Jahn
Re: Why C++ instead of C#?
That might be unintuitive to some having made bad experiences with managed languages in the past but it matches with my experience. At least when using the .Net Runtime. C# in Unity is a different matter entirely.Henk wrote: ↑Wed Sep 01, 2021 3:43 pm From msdn:
"Allocating memory from the managed heap is faster than unmanaged memory allocation. Because the runtime allocates memory for an object by adding a value to a pointer, it's almost as fast as allocating memory from the stack. In addition, because new objects that are allocated consecutively are stored contiguously in the managed heap, an application can access the objects quickly."
https://docs.microsoft.com/en-us/dotnet ... ndamentals
An example to illustrate the smartness of the runtime and the garbage collector: For each node I explore in the search I create a new Position instance with the new operator. With 1M NPS you'd expect a lot of work for the garbage collector because it has to allocate and free memory for a million objects. But if you use a memory profiler you realize that the runtime is reusing the instances. If you're searching to depth 12 you just need 12 at the same time.
Another example: For lists of reference types it can be faster to use a new List<T> than to reuse an existing one by clearing it. Clearing actually visits every element in the lists and sets the pointer to null. But just letting the list go out of scope achieves the same thing much cheaper. The runtime can clean up the instance and all the references it contains directly.