Announcement

Collapse
No announcement yet.

Merging In The GNU D Language Compiler To GCC

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

  • Merging In The GNU D Language Compiler To GCC

    Phoronix: Merging In The GNU D Language Compiler To GCC

    Nearly one year ago I wrote about Digital Mars wanting to merge the GNU D Compiler into GCC. Finally it looks like merging the compiler for the D programming language is nearing a point of reality...

    http://www.phoronix.com/vr.php?view=OTk2NA

  • #2
    Anyway the D constness is kind of broken, and it's a garbage collected language...

    Comment


    • #3
      Originally posted by babali View Post
      Anyway the D constness is kind of broken, and it's a garbage collected language...
      The garbage collector is optional in D. Also, asserting that D's constness were broken seems to require a justification.

      Comment


      • #4
        This is probably a good starting point to understanding the const problem.
        http://stackoverflow.com/questions/4...cal-const-in-d.

        GC in D is optional but some language features and parts of the standard library do rely on GC being available. The former are features not available in C/C++ so I don't see that as a huge issue. The library could be a problem though (I expect long term that a non GC library will appear if it turns out that a lot of people want to use D without garbage collection). From what I have been able to glean GC code should run slightly faster than non GC code (less system memory calls) but use 2-5 times as much memory. It's a *lot* harder to get a memory leak when using a GC so in a real world app that runs a long time you may end up being ahead on memory usage too. The other issue with gc is that the actual gc call can make your application unresponsive for a small amount of time; If your application had to meet a hard deadline (realtime app) this potentually would be a problem. In D you can have GC and non GC code in the same app and you have a degree of control over when the gc actually runs.

        On the whole I like where D is going. It tries to make the easiest way of doing things the most reliable and avoid you making stupid mistakes by design. It also allows you to optimise all the way down to assembly language in the parts of the code where you need performance. I can't think of another language that does both of these things.
        Last edited by kayosiii; 10-05-2011, 12:36 AM.

        Comment


        • #5
          It would also be nice to have gdc merged into gcc proper... It will make it just that much easier to distribute a d based program through launchpad (ppa).

          Comment


          • #6
            I use D as my primary language for development, and while the language itself is everything I could ever hope for, the compilers themselves still need a lot of work. 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.

            But once again, I haven't followed the development of GDC as closely, so maybe they have decent D2 support now, but it definitely won't ever match DMD, unless Digital Mars goes out of business.

            As for D itself having garbage collection - that's the whole point of the language. It might be slower that way, but it saves developers a lot of trouble, since you no longer have to care about obscure things like memory management and can do more work on the conceptual level. It's also easy to learn and more practical that way, while still leaving developers plenty of choices.

            Comment


            • #7
              The proplem with garbage collection is that to understand how your program work, you have to understand how the garbage collection work.
              And you have to write you program depending on how your garbage collector work (i know it possible to change the gc implementation which makes this task harder).
              In C++ you can manage your memory with RAII+refcounting so easily that I see no good reason to have a gc.

              Comment


              • #8
                What about LDC? I've been out of the D scene for a couple of years, but that did look promising.

                Originally posted by babali View Post
                In C++ you can manage your memory with RAII+refcounting so easily that I see no good reason to have a gc.
                One reason: copy-on-write arrays (in particular, strings). I guess you could do this with ref-counting, but I don't know if it's worth the overhead. But I partially agree with babali since memory management in C++ is usually not hard, and D's on-the-stack structs vs. on-the-heap classes are a bit wierd.

                Comment


                • #9
                  Originally posted by Cyborg16 View Post
                  One reason: copy-on-write arrays (in particular, strings). I guess you could do this with ref-counting, but I don't know if it's worth the overhead.
                  It depends on the implementation, but in the gnu stdc++, std::string are COW.

                  Comment


                  • #10
                    Originally posted by babali View Post
                    The proplem with garbage collection is that to understand how your program work, you have to understand how the garbage collection work.
                    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?

                    Originally posted by Cyborg16 View Post
                    What about LDC? I've been out of the D scene for a couple of years, but that did look promising.
                    That's still under development. It can't compile much yet, but it still looks promising.

                    Comment


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


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

                          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

                              Working...
                              X