Announcement

Collapse
No announcement yet.

Merging In The GNU D Language Compiler To GCC

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

  • #11
    Originally posted by GreatEmerald View Post
    Again, that's the whole idea. You don't need to care about how your program works, as long as it works. That's the idea behind D - make it simple to understand and use while abstracting things like memory management. For all I care, there could be no memory to begin with. The boost in performance is not worth learning the whole mechanics of RAM. Pointers themselves are obscure enough, and you could very well live without them. So if you are fine with a low-level language, then why comment about D in the first place?
    Yes you have to understand how your garbage collector work. For sure you can do a lot of stuff without even thinking to memory, but when you will need to optimize your stuff, then you'll have to spend time to understand how your garbage collector works and adapt your program to it to improve your performances. Finally you though that you saved time by not managing your memory but in the end you had to do weird optimizations related to how your garbage collector work (and the implementation may change which complicate this task) to get acceptable performances. But you still don't know exactly how your software will behave as you don't master your garbage collector.

    Anyway resources management is not only memory allocation. You can garbage collect your memory but you will still have to do resources management. (openned files, mmap, whatever...). So when you know how to manage your resources properly you can also manage your memory.

    I like high level languages, but I want to know exactly how my program works and I don't like garbage collectors. High level language doesn't imply gc. For exemple C++ is a high level language.

    Comment


    • #12
      Originally posted by GreatEmerald View Post
      GDC, last I heard, was behind DMD by quite a bit, so it is useful mostly if you program in D1, but not D2. For the latter, you want to get DMD. And DMD itself still has issues, like no support for a -fPIC argument. And RDMD, the dependency solver that comes with DMD, is a very awesome concept, but doesn't quite work with libraries of any kind right now, only with executables.
      GDC looks to have made quite a bit of progess lately (it links against the latest D2 frontend 2.055).

      rdmd does work with libraries (I have successfully used it with Derelict) There does seem to be a bug where libraries with a capital L in the name fail. again there have been a lot of bugfixes lately

      Comment


      • #14
        Originally posted by kayosiii View Post
        As far as I see it the main difference between C++ and D in this respect is that D has a standard garbage collector that is enabled by default.
        It implies a lot: a library wrote with manual memory management can run with a garbage collector, but a library wrote without memory management can't run without a garbage collector.

        Comment


        • #15
          GC is the point where I dislike the D language. The rest is awesome.
          Why I don't like GC is simply because I do game development, and in this case, you *have* to create your own memory management to improve performances.

          Comment


          • #16
            Originally posted by Creak View Post
            GC is the point where I dislike the D language. The rest is awesome.
            Why I don't like GC is simply because I do game development, and in this case, you *have* to create your own memory management to improve performances.
            You should look at this page http://www.digitalmars.com/d/2.0/memory.html;
            GC shouldn't largely be a hinderance for game programming as long as you follow the following guidelines.
            Allocate to the stack wherever it is sensible to do so. (use structs instead of classes where you don't need polymorphism) these aren't touched by the gc.
            Preallocate where possible (you want to do this anyway for any kind of realtime application).
            Use malloc and free or one of the other alternate memory schemes where you can't do one of the above and it has a significant impact on performance.
            Turn the GC off until you can allow a gc pass without it getting in the way. eg turn it on between levels, at major save points, when the interface is being used etc.

            Comment


            • #17
              I've written a platformer in D and didn't have to bother at all about the GC. This may be different with a big game with lots of resources in an open world without loading pauses...

              Comment


              • #18
                Originally posted by kayosiii View Post
                You should look at this page http://www.digitalmars.com/d/2.0/memory.html;
                GC shouldn't largely be a hinderance for game programming as long as you follow the following guidelines.
                Allocate to the stack wherever it is sensible to do so. (use structs instead of classes where you don't need polymorphism) these aren't touched by the gc.
                Preallocate where possible (you want to do this anyway for any kind of realtime application).
                Use malloc and free or one of the other alternate memory schemes where you can't do one of the above and it has a significant impact on performance.
                Turn the GC off until you can allow a gc pass without it getting in the way. eg turn it on between levels, at major save points, when the interface is being used etc.
                I know it's not the case for now and it won't be until a while, but imagine D becomes a recognized/used language (as for C++) and we can program on hardware like WiiU, Xbox360 or PS3.
                We just can't wait for next level loading to clean the GC. The memory on these hardware are too small to waste some in the GC.
                That's my opinion, though.

                Comment


                • #19
                  Originally posted by Creak View Post
                  I know it's not the case for now and it won't be until a while, but imagine D becomes a recognized/used language (as for C++) and we can program on hardware like WiiU, Xbox360 or PS3.
                  We just can't wait for next level loading to clean the GC. The memory on these hardware are too small to waste some in the GC.
                  That's my opinion, though.
                  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.

                  Comment


                  • #20
                    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). But for small projects it's very easy to use. Also, the GC is not as bad as many people would think, nor are resources so limited, and where they are, you will be using lower level languages anyway.

                    For example, I'm developing a card game right now, and it's blazing fast so far, and uses quite a low amount of memory. And even then, I know I'm using terribly optimised code where everything is copied instead of being reused, but even despite that, it works flawlessly so far.

                    Comment

                    Working...
                    X