Substitute for C++ for AAA video gaming?

[Rbuen4455]

As far as I know, C++ is the lingua franca of AAA gaming. While most AAA games are made through game engines, these game engines are made using C++. No other languages are used primarily because of performance and the need to be in control of memory and hardware access. Even if C++ doesn't disappear from video game production, will there be any other language that will replace C++? Of these languages, which could be a real substitute for high performance game production (or building a game engine)?:
- Java
- C#
- Python
- JavaScript
- C
- Assembly

[Niccolo]

Java doesn't have the performance.

C# has the same problem. It is used for scripting in the Unity engine, where they are expanding on the language with ECS using their own Burst compiler to overcome the issues using C#. Both Java and C# can be used to build native code, but that isn't the only problem for these languages. ECS, in Unity, is aimed at overcoming two independent problems. One is to organize data in a cache friendly fashion (something C++ can more easily do), and the other is to avoid C# (and Java's) use and reliance upon reference counted storage (similar to referenced counted smart pointers in C++). Since the definition of the language requires reference counted containment, generating native code from C# and Java can't overcome a primary performance issue. The Burst compiler, from Unity, is intended to make reliable optimization of both parallel and vectorized code. While promising, and exclusive to Unity, there's no indication this nascent technology has any future beyond Unity.

Python has similar issues.

Javascript doesn't have a chance.

In both cases (and with C# and Java), there is a limit in what can be expressed in those languages which do not translate into fine control of the underlying CPU and/or GPU execution.

C, of course, was originally built to operate as an assembler, and thus works very closely to the CPU's native means of operation. It is not popular among game engine engineers because it lacks the leverage they're accustomed to from C++.

Assembly shares the same issues as C, but with the potential exception of HLA (high level assembly), it is too bound to particular platforms to be of practical value.

More importantly, the GPU is programmed either in C (OpenCL and other emerging open technologies) or C++ (limited implementation for CUDA). It is very unlikely GPU's will ever implement more general languages like C#, Java or Python directly. Where native output is possible, and where it can be generated without the overhead of reference counted containment (as ECS in Unity with the Burst compiler), there could be a way to generate GPU compliant code, but I see no interest or movement in that direction.

There have been prophecies of C++ demise for decades. I'm of the view that if that were going to happen, it would be from something in view at this time. It seems quite unlikely.

[TwilightSpectre]

Many people suggest that Rust will be, at the very least, a strong competitor. As yet it doesn't quite have the ecosystem that C++ does, though, but it's certainly interesting to have a look at, and it's getting there.

[Rbuen4455]

All I know, from both research and experience with these languages, is that languages such as Java and C# are too high level that they can't directly access the hardware unlike C and C++. Java and C# code has to go through multiple layers before being translated into machine code, making them slower while C and C++ just compiles straight to machine code. C and C++ also don't have garbage collection, which is not good for high performance since you need to be in control of memory management in order to prevent FPS lags. However, I heard, at least for C#, that you can use unsafe code such as pointers for low level access and work your way around garbage collection and increase performance. I don't know much about this, but is is possible for C# to have the same performance and low level access that C and C++ have with unsafe coding?

As for JavaScript and Python, from what I've heard, they are more slower than Java and C# (but have easier syntax than Java or C#), therefore, unsuitable for high performance gaming (they can probably used for scripting), though not sure too much on this subject?

As far as I know regarding assembly, back before C and C++ were used for high level gaming, assembly was pretty much the language in use for video games (don't know when it ended) when hardware was too low powered and games were hardware specific (some games were designed for a system like NES while other games were designed for the N64, etc). Is assembly still worth it when it comes to video game development? I'd imagine that assembly is the only real substitute to video game development because aside from CPUs and GPUs having different assembly code, it is much closer to the metal than C and C++ , it's not compiled or interpreted as it goes straight into machine code and would probably offer more performance and control than C or C++, the only problem being that different hardware will have different assembly instruction and given that it's low level, it will be harder to write and will take much longer than a higher level language like C or C++. But I'm not that all experienced with assembly. I should have mentioned earlier that all programming languages, whether compiled or interpreted, don't go straight into machine code, but are translated first into assembly, then to machine code.

More importantly, the GPU is programmed either in C (OpenCL and other emerging open technologies) or C++ (limited implementation for CUDA). It is very unlikely GPU's will ever implement more general languages like C#, Java or Python directly. Where native output is possible, and where it can be generated without the overhead of reference counted containment (as ECS in Unity with the Burst compiler), there could be a way to generate GPU compliant code, but I see no interest or movement in that direction.

I don't know much about how GPUs, but I thought they were coded in assembly first, then you'd use something like C or C++ to access the hardware (where the code is translated into assembly).

[poteto]

I think the OP answered his own question.

No other languages are used primarily because of performance and the need to be in control of memory and hardware access.

[Rbuen4455]

I think the OP answered his own question.

I'm pretty sure somewhere in the near future, C++ will eventually get replaced in the AAA game development, the same way C and Assembly got replaced by C++ in high performance

[Niccolo]

However, I heard, at least for C#, that you can use unsafe code such as pointers for low level access and work your way around garbage collection and increase performance. I don't know much about this, but is is possible for C# to have the same performance and low level access that C and C++ have with unsafe coding?

That's in part what ECS in Unity is about, but "unsafe" C# code doesn't have the same low level access as C++, it is merely somewhat closer.

I'd imagine that assembly is the only real substitute to video game development because aside from CPUs and GPUs having different assembly code, it is much closer to the metal than C and C++ , it's not compiled or interpreted as it goes straight into machine code and would probably offer more performance and control than C or C++,

Working backwards, machine code is merely the numeric and binary formatted version of assembler. There are no tools which write to GPU other than C/C++ or related shader languages. No one writes to an assembler on the GPU except the manufacturers. Usually the GPU's compiler is located on the GPU, though "offline" compilers exist with slightly better optimization (in some cases).

Assembler is not much closer "to the metal" than C or C++. Factually, in the era of the modern optimizing compiler, most of the time (over 99% of the time), the C or C++ compiler generates better performing code than hand written assembler, because the optimizers understand the CPU better than humans do. There are very rare exceptions. C itself (which is entirely accessible from C++), was designed as an assembler independent of the CPU architecture. Linux, Windows, MAC (and by extension iOS and Android) are all written in C.

I should have mentioned earlier that all programming languages, whether compiled or interpreted, don't go straight into machine code, but are translated first into assembly, then to machine code.

The terms of assembler and machine code are largely interchangeable. The primary difference is that assembler is a human readable mnemonic representation, while machine code is the formatted binary version of the same thing. The point is that there is no reduction or alteration of assembler when it becomes machine code. There is a 1 to 1 correspondence for assembler instructions when compared to machine code. You may be thinking of intermediate language code, something part way between a compiled language like C and assembler, usually representative of assembler, but not precisely assembler.

[Ganado]

Rust is a contender. Maybe D. But things don't have widespread adoption.

[Rbuen4455]

but "unsafe" C# code doesn't have the same low level access as C++, it is merely somewhat closer.

I'd imagine that even with unsafe C#, it will still be slower because of the added layers when compiling your C# code.

There are no tools which write to GPU other than C/C++ or related shader languages. No one writes to an assembler on the GPU except the manufacturers. Usually the GPU's compiler is located on the GPU, though "offline" compilers exist with slightly better optimization (in some cases).

Thats what Im saying. You use C/C++ to access the GPU settings, but in the building process of the GPU, the instructions are written in assembly, as the instructions are hardware specific.

Assembler is not much closer "to the metal" than C or C++.

Uh..., assembly language is just one step above machine code. Assembly is still low-level compared to C/C++, which are still high level compared to assembly. The syntax is technically high level and there are some features in C/C++ that abstract away from hardware, and still has to be translated via compiler. Even compilers have to be translated to assembly, then to machine instructions.

Factually, in the era of the modern optimizing compiler, most of the time (over 99% of the time), the C or C++ compiler generates better performing code than hand written assembler, because the optimizers understand the CPU better than humans do.

While true, theoretically, you can still write efficient hand written assembly that beats any modern compiler, depending on how much you know about the CPU and how much time you spend on it.

[Niccolo]

assembly language is just one step above machine code.

With the exception of the high level assemblers, the two are interchangeable. Assembler is machine code in human readable form.

C++ still has C inside it. C was originally written to be an assembler. Most of the statements in C translate into single assembler/machine code instructions.

The "high level" you are thinking of are such topics as the C runtime library functions, C++ classes, etc. but that does not mean C constructs are higher level than assembler. Don't forget, the whole reason C was developed was to write UNIX, where the first version of UNIX was written in assembler which was then translated by hand into C, resulting in nearly the same thing on the original platform.

If a programmer chooses to use higher level techniques, then you'd be correct. If a programmer chooses to write to the lowest level, there's hardly any difference with assembler with the rare exception of those features on a particular CPU that aren't easily accessible. In that fact you are partially correct, but you gave the impression that assembler is "much closer to the metal", and it isn't. C is very close to the metal.

I know this from 4 decades of using it.

"The syntax is technically high level"

Some of the syntax is.

For example:

register int a;

for( a = 0; a < 100; ++a )
{
 //....
}

This forms a loop which when translated into the final machine code is likely the same as that written in hand assembler. "a" will be held in a register (likely would be without the keyword 'register'), and both the test against 100, the increment of 'a' and the conditional jump to the beginning of the loop will all be as efficient as a hand written assembler of the same code.

It is rare that optimizations could be implemented in assembler/machine code which aren't available to the C author and the optimizer.

The "theoretical" notion that one can still write assembler code that beats "any modern compiler" has come to a point to be so rare that it doesn't actually exist. It did back when RAM was $2000 per megabyte (not gigabyte), and optimizers had no room to breathe, but in the modern era you can try as much as you like and still never actually manage to do better than just match what the compiler generates from C. This has been demonstrated so many times in the last 10 years that it simply makes the assertion you believe in a myth at this point. There is one caveat - the author must write knowing how the machine works, just as the assembler programmer must do. In other words, when a programmer learns to view C (and that of C within C++) as an assembler, the results are almost always a match.

In the 80's I could easily match and subsequently exceed the compiler's output in about 30% of the high performance code I wrote. By the late 90's that was down to maybe 5%. At this point if I could match the compiler's voodoo optimizations 0.1% of the time I'd be doing well. Exceeding the compiler's output is rare, and usually related to something like vectorization of floating point calculations on bulk data (and even then, not usually, just occasionally).

Put another way, the only way a modern assembler programmer can hope to succeed at beating the compiler's output is to be able to make assumptions about the CPU and the process being written that the compiler can't make. This boils down to a theoretical point about languages themselves, the amount of information made available to the compiler in a particular expression.

An example of that, outside the scope of assembler, is the std::sort algorithm when compared to the C qsort algorithm. Both implement a form of introsort (quick sort with alternative tails). However, in the C version, the only way to implement a universal comparison function is by using a function pointer. The C library's qsort function calls the comparison function via pointer to function. There is no further optimization available to the compiler because the information about the comparison is blocked (made opaque to the optimizer) through the pointer to that function.

In the C++ version, however, what is passed can be evaluated as a function object. That can resolve to the pointer to a function, as it does in C, but there is an opportunity in the language construct to provide more information that merely a pointer to a function, it can describe the function. This means the optimizer is not "blinded" by an opaque pointer, but by the code itself. The optimizer can then choose to emit the comparison linline, avoiding a function call, making the std::sort faster than C's qsort.

This is an example of that analysis used to create languages, where that information we can encode in our statements is "understood" by the compiler for what it means, not just what it says.

What I'm saying is that the primary potential "block" to a language like C to match or exceed hand written assembler is not the "level" of the language, but of the information available within the language constructs. For C, that was initially design to be a match for the CPU's (generic) feature set.

For high level languages, the "level" of the language does not necessarily mean the result is slower. It can sometimes mean the result is faster, because the information can be used to form an output from what amounts to an "AI" kind of machine which can "out think" a human attempting the same thing in assembler, relative to the behavior of a particular CPU.

This means that, occasionally, what appears to be "far from the metal" due to the multiple-level nature of a language like C++ can actually produce "at the metal" results, and commonly a match to the best assembler a human has sufficient time to write.

Viewed from a different perspective, what I'm saying is that an assembler programmer must assume they have more knowledge and skills for a particular algorithm's implementation than the many PhD's who contributed to the modern C/C++ compiler and the development of the C/C++ language itself.

It isn't likely.

[devilorcdev]

Currently world of game development whether its indie no budget, or small to big companies - is conquered by two specific game engines. After doing my research id say that Unity is 20 times more popular than unreal engine 4. And it is most popular engine, while unreal engine is second.

Both are very good free options, Unreal uses C++, unity uses C#. In fact, I was unreal fan at first because games were more performant than Unity.

As if games massively and mainstreamely will be made in something else than c++, then sure! they are already made in Unity's c++. Java tried. javascript tried. but nothing beats c++ and c# and these 2 giant engines.

However, I wouldnt say c# is better than c++ for games, it is slower for sure (just like javascript and browser games are big no no for 3d mmorpgs lol). But its much easier and less frustrating :) just more well thought from the start, as it was made many years after c++.

However, Unity tries to create their own version of C# - rapid C#. I forgot it's full name, but from tests made by Unreal Engine and C++ veterans (so people focused on speed) it seems its faster than both Ue4 and c++. Google more information about Unity's DOTS. I've recently started Unity (https://begamedev.com) with free tutorials in it, so feel free to have a look.

And we have to understand that popularity is most important factor. For example Node asynchronous calls were something "BIG" back then thats why it took off, however node author made new language "Deno" few years ago, which is much better than Node, however it will never take off and become popular, and right now even after many years its still dead, as it all comes to popularity, marketing, and whats mainstream (majority of people) using.

Right now most popular languages are python, javascript (just no for heavy games), java (actually quite popular, but still not competitor to c++ and c#), c++ and c#.

If something is to overtake c++, then its Unity's DOTS or just unity and default C#.

[Niccolo]

If something is to overtake c++, then its Unity's DOTS or just unity and default C#.

This is not exactly what's going on there.

DOTS is the same thing I was talking about when I mention ECS. DOTS is the "larger umbrella" subject on the point.

It is not a competitor for C++. It is a competitor for Unity's use of C#. The rest of Unity is still written in C++. There is a considerable difference between the features and language provided for scripting vs actual writing of the software. DOTS is about scripting the Unity engine.

DOTS may have yet a full year to be implemented. It is only available in early release example-ware at this point. ECS can be partially implemented (in a hybrid ESC/C# approach), though ECS has been an option for Unity using 3rd party libraries.

In my own work with Unity, I avoid C# almost entirely. I use C++. I needed the full PhysX engine in it's most recent version (ongoing), so I built the engine from source to load as a dynamic library (on most platforms, a static library on iOS). As a result it became rather obvious and natural to continue working in C++ for what Unity considers "scripting", and I use the Unity engine itself for rendering, audio and I/O.

...it all comes to popularity...

I think this is on point, and I'd take it a bit further. The largest body of support libraries I can apply to game development are in C++. While one might measure this as popularity, I submit it can also be measured as the size and depth of infrastructure. There's so much it can be daunting just to find it all, figure out which is best and make informed selections, but no other language offers as many resources.

[Rbuen4455]

Late comment, just saw the posts, but...

If a programmer chooses to use higher level techniques, then you'd be correct. If a programmer chooses to write to the lowest level, there's hardly any difference with assembler with the rare exception of those features on a particular CPU that aren't easily accessible. In that fact you are partially correct, but you gave the impression that assembler is "much closer to the metal", and it isn't. C is very close to the metal.

I am not saying that C is not very close to the metal. I am saying that assembly is closer to machine instructions than C. C/C++ still abstracts away from the machine and still needs to be translated into assembly then into machine code. The general consensus is that C/C++ compared to Java, C# and Python, is more low level since it doesn't have added layers and just compiles to machine code, doesn't run on a virtual machine and doesn't have garbage collection, but compared to assembly, C/C++ is still higher level. Of course you get low level access with C/C++, but overall, it's still high level when compared to assembly and machine code. I guess you can say that C/C++ are mid level languages in that case.

The "theoretical" notion that one can still write assembler code that beats "any modern compiler" has come to a point to be so rare that it doesn't actually exist.

... the only way a modern assembler programmer can hope to succeed at beating the compiler's output is to be able to make assumptions about the CPU and the process being written that the compiler can't make. This boils down to a theoretical point about languages themselves, the amount of information made available to the compiler in a particular expression.

That may be because there's no programmers left who want to code in assembly, only in some areas is assembly ever needed (such as device drivers, new hardware, or just wanting more control over the hardware, etc).While rare nowadays, it's certainly not non-existent. Modern compilers do a great job at translating source code and optimizing, but humans are still better. By spending enough time with your code, you can improve it to absolute perfection, not miss clock cycle, and can get the most performance out of your hardware.
Speed wise, C/C++ is only as fast as the compiler, but of course with compilers that so are advance these days, there's no difference in speed between C/C++ and assembly, but assembly is always going to be faster since it just goes straight into machine code (while C/C++ have to go through syntax/semantic checking, then to assembly translation and finally to machine instructions) and still give you a lot more flexibility, control and direct access over the hardware.

[Rbuen4455]

In response to devilorcdev...
The vast majority of game engines nowadays are written in C++ with higher level languages such as C#, Python being reduced to scripting languages for game logic. Even Unity Engine has it's engine written in C++ while all the game logic and graphics are done through a .NET framework. All heavy performance AAA games these days are all C++ with some scripting language such as C# or Python.

However, looking somewhere in the near future, I can see C++ being replaced by another higher level language for game development. Looking back in history, first to the NES and SEGA games, they were all written in assembly. Then going into the era of N64, PS1 and Original Xbox games, it was a combination of assembly (for hardware optimization, physics, graphics and sound) and C (for scripting). Going later into the PS2, Gamecube and Xbox 2 era, with compilers now advanced and hardware as well becoming more advanced, there was little use of assembly and C was the main language in use with C++ being used as a scripting language (C++ back then was less powerful than it was). Now going into the Xbox 360, PS3, Wii, Wii U era of gaming, where gaming is more complex and compilers are now powerful at optimization, C++ became the dominant language for everything from game engine to game logic to physics effects, etc. Nowadays, all game engines and high performance games are written in C++ with higher level languages being used for game logic. As you can see, low level

I'm just curious as to what the future holds for game programming? Of course however, low level access is still crucial to all video games for performance and using higher languages such as Java, C# and Python for game engine or other low level stuff still poses a problem because these are languages that have garbage collection and run on a virtual machine, making them slow compared to C/C++/Assembly. Will there ever be a time when a single higher level languages will be in use, rather than say, one language for runtime and one language for scripting?

[Rbuen4455]

All of the above, regarding the history of video gaming and the use of assembly compered to C, all comes from what I have researched and compiled BTW.

Also, of course, C++ isn't going anywhere for video gaming as of now, but somewhere in the future, I can see that it is slowly being replaced by more higher level languages, seeing as CPUs are becoming more and more faster that the speed of execution of VM based languages are coming close to that of C/C++.

[talos]

Maybe D. But things don't have widespread adoption.

I'd love for D to be adopted to a bigger audience. I recently discovered it, after spending months learning C, and found it to be a breath of fresh air. Sure, it has its kinks, but it's fun to use.