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

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #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
      Miserable, with C++ code will make C# faster than C++. Yeah, can be faster if you wrote the C++ part

      Comment


      • #4
        Originally posted by atomsymbol

        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


        • #5
          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; 07 April 2019, 11:27 AM.

          Comment


          • #6
            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


            • #7
              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


              • #8
                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; 07 April 2019, 01:33 PM.

                Comment


                • #9
                  Originally posted by atomsymbol
                  If the garbage collector supports finalizers and guarantees to invoke them, then garbage collection is strictly safer than C++/Rust RAII.
                  If that were true, there would be no need for "with/try with resources/using/etc." patterns. No GC languages guarantee anything. In fact, GC that never runs is a valid GC, so you have to rely on those clutches (a poor man's RAII) when working with resources that needs to have defined lifetime.

                  Comment


                  • #10
                    Originally posted by kpedersen View Post

                    C++ is *not* manual memory management.
                    RAII ...
                    Garbage collection itself is actually a little old fashioned.
                    We're talking about technology, not fashion. Each memory management algorithm / convention has its pros and cons. It's not really about fashion and even if nobody uses some technology, it doesn't tell anything about its technical merits. You're also confusing RAII, which is a C++ term, with automatic memory management in general. Not all automatic resource management schemes are tied to stack like in C++. You could have affine/linear type systems, total functional programming, region inference, etc. Besides garbage collection is doing just fine. It's the best mechanism in quite many applications. There are also a wide variate of collectors. Familiar with Shenandoah in Java 12?

                    Comment

                    Working...
                    X