Page 2 of 5 FirstFirst 1234 ... LastLast
Results 11 to 20 of 47

Thread: Merging In The GNU D Language Compiler To GCC

  1. #11
    Join Date
    Jul 2011
    Posts
    36

    Default

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

  2. #12
    Join Date
    Oct 2009
    Posts
    174

    Default

    Quote 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

  3. #13
    Join Date
    Oct 2009
    Posts
    174

    Default

    Some links on D and Garbage collection.
    http://stackoverflow.com/questions/4...bage-collector
    http://www.digitalmars.com/d/2.0/memory.html
    http://web.mit.edu/d_v1.020/html/d/f...rence-counting
    http://www.google.com.au/url?sa=t&so...BGFUeI6cdKRp2w
    http://www.digitalmars.com/d/archive...or_145580.html


    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.

  4. #14
    Join Date
    Jul 2011
    Posts
    36

    Default

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

  5. #15
    Join Date
    May 2008
    Posts
    101

    Default

    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.

  6. #16
    Join Date
    Oct 2009
    Posts
    174

    Default

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

  7. #17
    Join Date
    Jan 2011
    Posts
    426

    Default

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

  8. #18
    Join Date
    May 2008
    Posts
    101

    Default

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

  9. #19
    Join Date
    Oct 2009
    Posts
    174

    Default

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

  10. #20
    Join Date
    Sep 2008
    Location
    Vilnius, Lithuania
    Posts
    2,666

    Default

    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.

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •