Announcement

Collapse
No announcement yet.

Unity Is Growing Their LLVM Compiler Team As They Try To Make C# Faster Than C++

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Unity Is Growing Their LLVM Compiler Team As They Try To Make C# Faster Than C++

    Phoronix: Unity Is Growing Their LLVM Compiler Team As They Try To Make C# Faster Than C++

    With game engines becoming increasingly advanced, Unity Technologies is looking to expand their compiler team with more LLVM expertise...

    http://www.phoronix.com/scan.php?pag...-Compiler-Team

  • #2
    In the end, when it comets to low-level interpretation of code, all languages compiled to native code use almost the same instructions,.. Only difference is in memory management mechanism.. Manually written memory management might also have worse performance (and memory leaks related bugs) than garbage collection.. So, languages as Java and C# are great for projects, where there's not enough resources to do fine tuning and heavy testing...

    Comment


    • #3
      Originally posted by kravemir View Post
      Manually written memory management might also have worse performance (and memory leaks related bugs) than garbage collection.
      I agree. (On the other hand, garbage collection prevents the programmer from manual memory management optimizations. Assuming the programmer thoroughly analyses the code, programmer's understanding of how memory is used by the program is better than garbage collector's understanding.)

      Comment


      • #4
        Miserable, with C++ code will make C# faster than C++. Yeah, can be faster if you wrote the C++ part

        Comment


        • #5
          Originally posted by atomsymbol View Post

          I agree. (On the other hand, garbage collection prevents the programmer from manual memory management optimizations. Assuming the programmer thoroughly analyses the code, programmer's understanding of how memory is used by the program is better than garbage collector's understanding.)
          Quite many runtime environments support having both GCed and non-GCed memory at the same time. Even Java.

          Comment


          • #6
            Originally posted by caligula View Post

            Quite many runtime environments support having both GCed and non-GCed memory at the same time. Even Java.
            Yep. Even C++. UE4 for example is C++ and garbage collected. Not the typical Boehm's GC but a home grown one.

            That said, C++ is *not* manual memory management. RAII in many ways is faster and safer than garbage collection.

            Garbage collection itself is actually a little old fashioned. The main reason why it was deprecated in Apple's Objective-C and newer languages like Rust decided to opt for RAII.

            In my opinion, a hybrid approach is nice. RAII for speed and GC to detect circular reference counts. Best of both worlds. However you will still need a decent developer to take full advantage rather than a typical Unity user.
            Last edited by kpedersen; 04-07-2019, 11:27 AM.

            Comment


            • #7
              Very interesting. I wonder if the Godot team would take an interest in this and could they benefit from similar, if not same, optimizations in their engine?

              Comment


              • #8
                Originally posted by kravemir View Post
                In the end, when it comets to low-level interpretation of code, all languages compiled to native code use almost the same instructions,.. Only difference is in memory management mechanism.. Manually written memory management might also have worse performance (and memory leaks related bugs) than garbage collection.. So, languages as Java and C# are great for projects, where there's not enough resources to do fine tuning and heavy testing...
                Um, no... There is -no- garbage collector that can manage memory... GC is -not- memory management. There is -no- possible way for any GC mechanism to perform decent let alone well. And it far, far worse in memory constrained scenarios. I'm pretty sure Google has already proved to billions of people worldwide how terrible garbage collection is with android.

                Comment


                • #9
                  Garbage collection is problematic for games and other real time applications. Usually when the garbage collector runs, it must stop some or all threads in order to perform it's job. In Unity this is very evident: we get "gc spikes". The game visibly stutters when the garbage collector kicks in.

                  If the application is not a real time application such as a web server or command line utility, then garbage collection is perfectly fine.
                  Last edited by paulpach; 04-07-2019, 01:33 PM.

                  Comment


                  • #10
                    Originally posted by kpedersen View Post
                    That said, C++ is *not* manual memory management. RAII in many ways is faster and safer than garbage collection.

                    Garbage collection itself is actually a little old fashioned. The main reason why it was deprecated in Apple's Objective-C and newer languages like Rust decided to opt for RAII.
                    If the garbage collector supports finalizers and guarantees to invoke them, then garbage collection is strictly safer than C++/Rust RAII. In the typical case garbage collection has greater latency than C++/Rust RAII and the order of finalization is random - but after a series of full garbage collections the number of invoked finalizers is guaranteed to be >= (greater or equal to) the number of invoked C++/Rust RAII destructors when handling failures. Without extensive thinking|testing C++/Rust RAII might omit to destroy unreachable cyclic object graphs allocated on the heap which are hard to reason about.

                    With both approaches the programmer might be forced to deal with complex mutex interactions when handling failures.

                    Neither of the approaches provides help if (because of a bug in the program) the programmer forgets to explicitly set certain variables to nil/null/nullptr or forgets to explicitly call certain destructors in order to free resources. That is: both approaches require the programmer to sometimes free resources manually.

                    Originally posted by kpedersen View Post
                    In my opinion, a hybrid approach is nice. RAII for speed and GC to detect circular reference counts.
                    I agree with this.

                    ----

                    And now something completely different: Email alerts sent by Semantic Scholar have a long way to go before they are semantically accurate.

                    Comment

                    Working...
                    X