Announcement

Collapse
No announcement yet.

Merging In The GNU D Language Compiler To GCC

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

  • #21
    Originally posted by kayosiii View Post
    In this case you almost certainly want to avoid the standard libraries anyways.
    http://www.rossbencina.com/code/real...ts-for-nothing (this article explains why).
    You will want to turn the GC off. Preallocate where possible and use a very simple memory management scheme that avoids memory fragmentation (Which I understand results in quite a bit of performance degredation on these platforms).

    I may well be wrong about this so if you know better than me please feel free to correct.
    To be sure of what we're talking about, when you say standard libraries, what's the scope? only std::vector, std::hash_map, etc...? or there is more?

    Comment


    • #22
      Yeah, when writing code for consoles, you should probably allocate everything at level loading time, do not allocate or free anything ingame, then free everything when the level is done. At least that's what I was doing on the DS (quite slow memory management + fragmentation problems). Or use your own memory management code to avoid fragmentation ingame if you're going the streaming route.

      Comment


      • #23
        Originally posted by Creak View Post
        To be sure of what we're talking about, when you say standard libraries, what's the scope? only std::vector, std::hash_map, etc...? or there is more?
        There is a full explanation in the linked article - the article is specifically about realtime audio but the principles remain for realtime graphics. Generally you want to avoid any code that isn't known to be real-time friendly, eg anything that dynamically allocates memory is out. In a multithreaded application this restriction only applies to the threads that must run realtime but you still should be careful .
        http://stackoverflow.com/questions/4...bage-collector this page will help explain which parts of the D standard library to avoid when GC is turned off.

        Comment


        • #24
          From what I've seen, D is currently the only thing in the world that has the potential to replace C++. It has a fair shot too, imbued as it is with the will of the people who know C++ (and its myriad flaws) best.
          Originally posted by GreatEmerald View Post
          Exactly - for huge projects, you probably won't use D to begin with due to the limited amount of external library support (you could create bindings yourself, but for complex libraries, such as ncurses, it will likely not work anyway).


          Originally posted by Other People
          <Long-winded yammering>
          There's a reason so many games made in the past decade use scripting extensively, including the biggest-budget AAA titles imaginable. I mean, feel free to complain at Tim Sweeney about the garbage collected nature of UnrealScript, but don't be surprised if he laughs in your face from his ergonomic throne made of money.

          Honestly, complaining about the GC is just asking to be called a lazy or bad developer. Didn't your mentors ever teach you about premature optimisation? Trade-offs and good design? Code that exists can be optimised. Code that doesn't is just an idea, and totally worthless.

          Comment


          • #25
            Originally posted by Wyatt View Post
            From what I've seen, D is currently the only thing in the world that has the potential to replace C++.
            Replace? I seriously doubt it given the VAST amount of C++ code that is being relied on and the VAST amount of C++ code that is being written every day, that said I think that with proper exposure D can certainly become a popular viable alternative to C++, same goes for Go and (to a lesser extent due to 'in-practice' Apple platform lock-in) ObjC. And inclusion into GCC is a step in the right direction imo.

            Originally posted by Wyatt View Post
            There's a reason so many games made in the past decade use scripting extensively, including the biggest-budget AAA titles imaginable.
            Apples and oranges, the heavy lifting is not done with scripting. What is being discussed here is the allocation/deallocation of tons of in-game data, which can cause severe performance problems when the GC kicks in at it's own behest. There are techniques to limit this of course, like not deallocating data (optimally reusing it instead) during gameplay, allocating everything up front etc. However these solutions generally increase the overall memory usage and, ironically, forces the programmer to work around the GC rather than being helped by it.

            This all depends on the performance required of course, you can write platform/shooter-style games in interpreted python and lua which will run perfectly fine on anything resembling modern hardware, of course the game logic in such games are very simple and again the heavy lifting is done by native code graphics/sound libraries and hardware acceleration. There's a reason the top AAA titles aren't written in garbage-collected languages, being that they need to squeeze every bit of performance out of the hardware in order to stay competitive.

            That said, if we look past very performance-dependant software there's obviously a ton of applications where garbage collection will have little to no impact on performance and simply make the programmer's life easier.

            Comment


            • #26
              Originally posted by Wyatt View Post
              Honestly, complaining about the GC is just asking to be called a lazy or bad developer.
              Come on... It seems like you're only seeing your vision of programming.
              There are different notion of optimizations. I can tell, as I work as a developer in the game industry, that at least one memory manager is mandatory. And these memory managers aren't made by lazy or bad developers, far from that! They often are developers with huge knowledges of the different hardwares specifications.

              If you start coding a new engine and that you know you'll need to make your own memory manager, you'll disable the GC, not because you're bad or lazy, but because keeping the GC knowing you'll disable it later to improve performances is like shotting yourself in the foot! You'll damn yourself when you'll have to convert the GC-enabled code to the GC-disabled code.

              From what I've read here, D seems to be a good language for simple games or, maybe a good scripting language, but when we talk about AAA game engines, the GC feature seems to be the main flaw.
              But you can still begin your main function with GC.disable() and rewrite all the standard functions that assume the GC is enabled...

              Comment


              • #27
                Originally posted by XorEaxEax View Post
                That said, if we look past very performance-dependant software there's obviously a ton of applications where garbage collection will have little to no impact on performance and simply make the programmer's life easier.
                I totally agree. I think the guys that wrote the language D didn't aim the game industry.

                Comment


                • #28
                  Originally posted by XorEaxEax View Post
                  Apples and oranges, the heavy lifting is not done with scripting. What is being discussed here is the allocation/deallocation of tons of in-game data, which can cause severe performance problems when the GC kicks in at it's own behest. There are techniques to limit this of course, like not deallocating data (optimally reusing it instead) during gameplay, allocating everything up front etc. However these solutions generally increase the overall memory usage and, ironically, forces the programmer to work around the GC rather than being helped by it.
                  I think you are largely missing the point here. D is not Java where you have to use the GC for everything; you can skip the GC for the heavy lifting. Furthermore since D is a relatively clean language, it compiles really fast and tools like rdmd exist to make D behave like a scripting language you may be able to forgo grafting on a high level language for the game logic (in which case you would have been using GC anyways). is that really so hard to understand?

                  Having said that there are a few features that D should include to make high performance game programming easier.
                  Last edited by kayosiii; 06 October 2011, 05:15 AM.

                  Comment


                  • #29
                    Originally posted by kayosiii View Post
                    I think you are largely missing the point here. D is not Java where you have to use the GC for everything; you can skip the GC for the heavy lifting. Furthermore since D is a relatively clean language, it compiles really fast and tools like rdmd exist to make D behave like a scripting language you may be able to forgo grafting on a high level language for the game logic (in which case you would have been using GC anyways). is that really so hard to understand?
                    As read in a site given by yourself:
                    That said, while D is designed to be usable with the GC disabled in a few critical pieces of code (the kind of critical pieces where real time constraints exist and you probably shouldn't be using any form of malloc not explicitly designed for real time computing anyhow), it was largely designed with the assumption that GC would be present.
                    -- http://stackoverflow.com/questions/4...bage-collector
                    Here I understand that beginning a project with the intention of disabling the GC is a bad idea..
                    So who should I believe, you or the site you gave?

                    Comment


                    • #30
                      Both pieces of information are correct.

                      The article said you want to be careful turning the GC off completely and that the reccomended approach is to turn the GC off for all critical pieces of code (where you would if you are writing realtime safe code disable all dynamic memory management).

                      I said you can use GC allocated objects, stack allocated objects and manually managed objects in the same codebase and use the non GC objects to do your heavy lifting. Conceptually this isn't that different from using a C++ with a high level scripting language that is garbage collected except that you can realistically to do it all in the one language and you get to have your game logic compiled instead of interpreted.

                      Comment

                      Working...
                      X