digitalmars.D - DDMD as showcase?
- Xavier Bigand (14/14) Feb 10 2014 Firstly is there some progress on the DDMD project or maybe an other D
- Daniel Murphy (27/41) Feb 10 2014 The old ddmd project is pretty much dead AFAIK
- Adam Wilson (10/51) Feb 10 2014 The GC itself is an orthogonal issue to the compiler. The way I see it, ...
- thedeemon (12/16) Feb 11 2014 If you want a fast GC it needs to be generational, i.e. most of
- Jakob Ovrum (3/19) Feb 11 2014 D code has different allocation patterns from Java and C#. In
- Andrei Alexandrescu (4/24) Feb 11 2014 I agree this is a good hypothesis (without having measured). My
- Adam Wilson (43/68) Feb 11 2014 I'm not so sure about that. That might be true for Java but C# is a stac...
- Paulo Pinto (7/75) Feb 11 2014 Another thing that you didn't mention is that most GC based environments...
- thedeemon (11/13) Feb 11 2014 From Java - most probably. From C# - less so, because C# also has
- Flamaros (3/47) Feb 11 2014 That the idea. In all cases we need some proof of the validity of
- Paulo Pinto (12/56) Feb 11 2014 It has already been proven by Oberon, Modula-3 and Sing# among
- Brad Anderson (3/24) Feb 11 2014 By the way, what is the plan for all the outstanding pull
- Daniel Murphy (6/8) Feb 11 2014 In theory they can be converted automatically by applying, converting an...
Firstly is there some progress on the DDMD project or maybe an other D boostrap? There is a lot of thread and debate around the GC of D, I interrogate me on the capacity of a project like DDMD to prove to every D users that the GC is perfectly usable for system applications. If not it will certainly be improve during the DDMD development to a point can satisfy almost everybody? As I know DMD doesn't release memory, these will have to be fixed in DDMD to match the memory management most application have to apply. I see many interesting points in DDMD : - prove GC based compiler isn't longer to optimize than the C++ version (and capable to reach same performances) - will reveal more language issues or phobos miss. - will be easier to maintain and update
Feb 10 2014
"Xavier Bigand" wrote in message news:ldbpum$1pov$1 digitalmars.com...Firstly is there some progress on the DDMD project or maybe an other D boostrap?The old ddmd project is pretty much dead AFAIK (http://www.dsource.org/projects/ddmd) and was never up to date with the current compiler. For about a year I've been working on automatically converting the compiler source from C++ to D. The conversion has produced a working compiler on win32/linux32/linux64 (other platforms need trivial patches) that compiles druntime/phobos/the test suite without errors. The current effort is around cleaning up the C++ source to produce higher quality D code. The next major step is to actually switch development to the D version. Outstanding patches: https://github.com/D-Programming-Language/dmd/pull/1980 Conversion tool: https://github.com/yebblies/magicport2 You can see some of the recent patches (marked DDMD) here: https://github.com/yebblies?tab=contributions&period=monthlyThere is a lot of thread and debate around the GC of D, I interrogate me on the capacity of a project like DDMD to prove to every D users that the GC is perfectly usable for system applications. If not it will certainly be improve during the DDMD development to a point can satisfy almost everybody?There are no planned GC modifications for the DDMD project. It may result in some compiler devs taking more of an interest in the GC.As I know DMD doesn't release memory, these will have to be fixed in DDMD to match the memory management most application have to apply.Yes, DDMD will use the GC, although it currently has it disabled due to a segfault I haven't tracked down yet.I see many interesting points in DDMD : - prove GC based compiler isn't longer to optimize than the C++ version (and capable to reach same performances) - will reveal more language issues or phobos miss.Maybe, but so far additions to the language have been minimal, and DDMD does not currently use phobos. It is also slower than the C++ version, part of which is due to the GC being slower than the bump-pointer allocator used in the C++ dmd.- will be easier to maintain and updateExactly!
Feb 10 2014
On Mon, 10 Feb 2014 20:19:22 -0800, Daniel Murphy <yebbliesnospam gmail.com> wrote:"Xavier Bigand" wrote in message news:ldbpum$1pov$1 digitalmars.com...The GC itself is an orthogonal issue to the compiler. The way I see it, once the compiler can output precise information about the heap, stack, and registers, you can build any GC you want without the compiler requiring any knowledge of the GC.Firstly is there some progress on the DDMD project or maybe an other D boostrap?The old ddmd project is pretty much dead AFAIK (http://www.dsource.org/projects/ddmd) and was never up to date with the current compiler. For about a year I've been working on automatically converting the compiler source from C++ to D. The conversion has produced a working compiler on win32/linux32/linux64 (other platforms need trivial patches) that compiles druntime/phobos/the test suite without errors. The current effort is around cleaning up the C++ source to produce higher quality D code. The next major step is to actually switch development to the D version. Outstanding patches: https://github.com/D-Programming-Language/dmd/pull/1980 Conversion tool: https://github.com/yebblies/magicport2 You can see some of the recent patches (marked DDMD) here: https://github.com/yebblies?tab=contributions&period=monthlyThere is a lot of thread and debate around the GC of D, I interrogate me on the capacity of a project like DDMD to prove to every D users that the GC is perfectly usable for system applications. If not it will certainly be improve during the DDMD development to a point can satisfy almost everybody?There are no planned GC modifications for the DDMD project. It may result in some compiler devs taking more of an interest in the GC.-- Adam Wilson GitHub/IRC: LightBender Aurora Project CoordinatorAs I know DMD doesn't release memory, these will have to be fixed in DDMD to match the memory management most application have to apply.Yes, DDMD will use the GC, although it currently has it disabled due to a segfault I haven't tracked down yet.I see many interesting points in DDMD : - prove GC based compiler isn't longer to optimize than the C++ version (and capable to reach same performances) - will reveal more language issues or phobos miss.Maybe, but so far additions to the language have been minimal, and DDMD does not currently use phobos. It is also slower than the C++ version, part of which is due to the GC being slower than the bump-pointer allocator used in the C++ dmd.- will be easier to maintain and updateExactly!
Feb 10 2014
On Tuesday, 11 February 2014 at 04:36:28 UTC, Adam Wilson wrote:The GC itself is an orthogonal issue to the compiler. The way I see it, once the compiler can output precise information about the heap, stack, and registers, you can build any GC you want without the compiler requiring any knowledge of the GC.If you want a fast GC it needs to be generational, i.e. most of the times scan just a portion of heap where young objects live (because most objects die young), not scan whole heap each time (as in current D GC). However in a mutable language that young/old generation split usually requires write barriers: compiler must emit code differently: each time a pointer field of a heap object is mutated it must check whether it's a link from old gen to young gen and remember that link (or just mark the page for scanning). So to have a generational GC in a mutable language you need to change the codegen as well. At least this is how most mature GCs work.
Feb 11 2014
On Tuesday, 11 February 2014 at 10:29:58 UTC, thedeemon wrote:On Tuesday, 11 February 2014 at 04:36:28 UTC, Adam Wilson wrote:idiomatic D, young GC-allocated objects are probably much fewer.The GC itself is an orthogonal issue to the compiler. The way I see it, once the compiler can output precise information about the heap, stack, and registers, you can build any GC you want without the compiler requiring any knowledge of the GC.If you want a fast GC it needs to be generational, i.e. most of the times scan just a portion of heap where young objects live (because most objects die young), not scan whole heap each time (as in current D GC). However in a mutable language that young/old generation split usually requires write barriers: compiler must emit code differently: each time a pointer field of a heap object is mutated it must check whether it's a link from old gen to young gen and remember that link (or just mark the page for scanning). So to have a generational GC in a mutable language you need to change the codegen as well. At least this is how most mature GCs work.
Feb 11 2014
On 2/11/14, 6:32 AM, Jakob Ovrum wrote:On Tuesday, 11 February 2014 at 10:29:58 UTC, thedeemon wrote:I agree this is a good hypothesis (without having measured). My AndreiOn Tuesday, 11 February 2014 at 04:36:28 UTC, Adam Wilson wrote:D, young GC-allocated objects are probably much fewer.The GC itself is an orthogonal issue to the compiler. The way I see it, once the compiler can output precise information about the heap, stack, and registers, you can build any GC you want without the compiler requiring any knowledge of the GC.If you want a fast GC it needs to be generational, i.e. most of the times scan just a portion of heap where young objects live (because most objects die young), not scan whole heap each time (as in current D GC). However in a mutable language that young/old generation split usually requires write barriers: compiler must emit code differently: each time a pointer field of a heap object is mutated it must check whether it's a link from old gen to young gen and remember that link (or just mark the page for scanning). So to have a generational GC in a mutable language you need to change the codegen as well. At least this is how most mature GCs work.
Feb 11 2014
On Tue, 11 Feb 2014 08:33:59 -0800, Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:On 2/11/14, 6:32 AM, Jakob Ovrum wrote:often forget about the temporaries we implicitly allocate. Strings, I was thinking about this last night and as I continue reading the GC Handbook, I think I understand more about why MS did what they did with the .NET GC. First of all, they used every algorithm in that book in one way or another. For example, the Large Object Heap is a simple Mark-Sweep because there tend to be relatively few nodes to check and fragmentation is much lower than the ephemeral generations, however, they enabled opt-in compaction in the latest release because the large size of each node meant that fragmentation became a problem quicker in long-running processes. Also the more I dive into it, the more I think that thread-local GC is a bad idea. As I understand it the point is to reduce the overall pause on any one thread by reducing the scope of the heap to collect. However, I would argue that the common case is that a program has a few threads that dominate the majority of running time, with many ephemeral threads are created for quick work (an incoming message over a socket for example). In this case your main threads are still going to have large heaps for the dominate threads and most likely heaps that are never collected on the ephemeral threads. This means that a few threads will still have noticeable pause times, and we've significantly increased compiler complexity to support thread local GC on all threads, and probably hammered thread start up time to do it. I could go on, but my point is that at the end of the day if you want performant collections, you end up using every trick in the book. The mixture may be slightly different, but I would suggest that the mixture is going to be slightly different based on the type of app even using the same language, which is why .NET provides two modes for the collector, Server and Workstation, and Java has four. So saying that D's collector will be different is naturally obvious, but I don't think it will be allocation patterns, with roughly similar use cases, and will most likely end up building in every algorithm available and then tuning it the mixture of those algorithms to meet D's needs. -- Adam Wilson GitHub/IRC: LightBender Aurora Project CoordinatorOn Tuesday, 11 February 2014 at 10:29:58 UTC, thedeemon wrote:I agree this is a good hypothesis (without having measured). My AndreiOn Tuesday, 11 February 2014 at 04:36:28 UTC, Adam Wilson wrote:D, young GC-allocated objects are probably much fewer.The GC itself is an orthogonal issue to the compiler. The way I see it, once the compiler can output precise information about the heap, stack, and registers, you can build any GC you want without the compiler requiring any knowledge of the GC.If you want a fast GC it needs to be generational, i.e. most of the times scan just a portion of heap where young objects live (because most objects die young), not scan whole heap each time (as in current D GC). However in a mutable language that young/old generation split usually requires write barriers: compiler must emit code differently: each time a pointer field of a heap object is mutated it must check whether it's a link from old gen to young gen and remember that link (or just mark the page for scanning). So to have a generational GC in a mutable language you need to change the codegen as well. At least this is how most mature GCs work.
Feb 11 2014
Paulo Pinto <pjmlp progtools.org> Am 11.02.2014 20:58, schrieb Adam Wilson:On Tue, 11 Feb 2014 08:33:59 -0800, Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:Another thing that you didn't mention is that most GC based environments provide tooling for GC tuning, which as far as I am aware, still don't exist for D. Java, .NET and Haskell ones are quite good. -- PauloOn 2/11/14, 6:32 AM, Jakob Ovrum wrote:stack based language with value types. However, I think that, as with I was thinking about this last night and as I continue reading the GC Handbook, I think I understand more about why MS did what they did with the .NET GC. First of all, they used every algorithm in that book in one way or another. For example, the Large Object Heap is a simple Mark-Sweep because there tend to be relatively few nodes to check and fragmentation is much lower than the ephemeral generations, however, they enabled opt-in compaction in the latest release because the large size of each node meant that fragmentation became a problem quicker in long-running processes. Also the more I dive into it, the more I think that thread-local GC is a bad idea. As I understand it the point is to reduce the overall pause on any one thread by reducing the scope of the heap to collect. However, I would argue that the common case is that a program has a few threads that dominate the majority of running time, with many ephemeral threads are created for quick work (an incoming message over a socket for example). In this case your main threads are still going to have large heaps for the dominate threads and most likely heaps that are never collected on the ephemeral threads. This means that a few threads will still have noticeable pause times, and we've significantly increased compiler complexity to support thread local GC on all threads, and probably hammered thread start up time to do it. I could go on, but my point is that at the end of the day if you want performant collections, you end up using every trick in the book. The mixture may be slightly different, but I would suggest that the mixture is going to be slightly different based on the type of app even using the same language, which is why .NET provides two modes for the collector, Server and Workstation, and Java has four. So saying that D's collector will be different is naturally obvious, but I don't think it roughly similar allocation patterns, with roughly similar use cases, and will most likely end up building in every algorithm available and then tuning it the mixture of those algorithms to meet D's needs.On Tuesday, 11 February 2014 at 10:29:58 UTC, thedeemon wrote:I agree this is a good hypothesis (without having measured). My AndreiOn Tuesday, 11 February 2014 at 04:36:28 UTC, Adam Wilson wrote:D, young GC-allocated objects are probably much fewer.The GC itself is an orthogonal issue to the compiler. The way I see it, once the compiler can output precise information about the heap, stack, and registers, you can build any GC you want without the compiler requiring any knowledge of the GC.If you want a fast GC it needs to be generational, i.e. most of the times scan just a portion of heap where young objects live (because most objects die young), not scan whole heap each time (as in current D GC). However in a mutable language that young/old generation split usually requires write barriers: compiler must emit code differently: each time a pointer field of a heap object is mutated it must check whether it's a link from old gen to young gen and remember that link (or just mark the page for scanning). So to have a generational GC in a mutable language you need to change the codegen as well. At least this is how most mature GCs work.
Feb 11 2014
On Tuesday, 11 February 2014 at 14:32:10 UTC, Jakob Ovrum wrote:idiomatic D, young GC-allocated objects are probably much fewer.value types living on stack. In all of them little temporary strings and arrays are often main garbage generators, and most of them die young. Just think how many temporary arrays are allocated and become garbage while you grow a single array variable with "a ~= x;" in a loop. And before you say "Appender" think of associative arrays too. In case of D it's also problematic to decide which allocation pattern is idiomatic for it, since D can be used so differently in different applications.
Feb 11 2014
On Tuesday, 11 February 2014 at 04:19:12 UTC, Daniel Murphy wrote:"Xavier Bigand" wrote in message news:ldbpum$1pov$1 digitalmars.com...That the idea. In all cases we need some proof of the validity of having a GC in a system language.Firstly is there some progress on the DDMD project or maybe an other D boostrap?The old ddmd project is pretty much dead AFAIK (http://www.dsource.org/projects/ddmd) and was never up to date with the current compiler. For about a year I've been working on automatically converting the compiler source from C++ to D. The conversion has produced a working compiler on win32/linux32/linux64 (other platforms need trivial patches) that compiles druntime/phobos/the test suite without errors. The current effort is around cleaning up the C++ source to produce higher quality D code. The next major step is to actually switch development to the D version. Outstanding patches: https://github.com/D-Programming-Language/dmd/pull/1980 Conversion tool: https://github.com/yebblies/magicport2 You can see some of the recent patches (marked DDMD) here: https://github.com/yebblies?tab=contributions&period=monthlyThere is a lot of thread and debate around the GC of D, I interrogate me on the capacity of a project like DDMD to prove to every D users that the GC is perfectly usable for system applications. If not it will certainly be improve during the DDMD development to a point can satisfy almost everybody?There are no planned GC modifications for the DDMD project. It may result in some compiler devs taking more of an interest in the GC.As I know DMD doesn't release memory, these will have to be fixed in DDMD to match the memory management most application have to apply.Yes, DDMD will use the GC, although it currently has it disabled due to a segfault I haven't tracked down yet.I see many interesting points in DDMD : - prove GC based compiler isn't longer to optimize than the C++ version (and capable to reach same performances) - will reveal more language issues or phobos miss.Maybe, but so far additions to the language have been minimal, and DDMD does not currently use phobos. It is also slower than the C++ version, part of which is due to the GC being slower than the bump-pointer allocator used in the C++ dmd.- will be easier to maintain and updateExactly!
Feb 11 2014
On Tuesday, 11 February 2014 at 12:07:35 UTC, Flamaros wrote:On Tuesday, 11 February 2014 at 04:19:12 UTC, Daniel Murphy wrote:others. http://www.inf.ethz.ch/personal/wirth/ProjectOberon/ http://cseweb.ucsd.edu/~savage/papers/Wcsss96m3os.pdf http://research.microsoft.com/en-us/projects/Singularity/ The Oberon one, as even used by ETHZ employees as workstations in mid-90's. That no OS vendor pushed a mainstream OS with them is another matter. -- Paulo"Xavier Bigand" wrote in message news:ldbpum$1pov$1 digitalmars.com...That the idea. In all cases we need some proof of the validity of having a GC in a system language.Firstly is there some progress on the DDMD project or maybe an other D boostrap?The old ddmd project is pretty much dead AFAIK (http://www.dsource.org/projects/ddmd) and was never up to date with the current compiler. For about a year I've been working on automatically converting the compiler source from C++ to D. The conversion has produced a working compiler on win32/linux32/linux64 (other platforms need trivial patches) that compiles druntime/phobos/the test suite without errors. The current effort is around cleaning up the C++ source to produce higher quality D code. The next major step is to actually switch development to the D version. Outstanding patches: https://github.com/D-Programming-Language/dmd/pull/1980 Conversion tool: https://github.com/yebblies/magicport2 You can see some of the recent patches (marked DDMD) here: https://github.com/yebblies?tab=contributions&period=monthlyThere is a lot of thread and debate around the GC of D, I interrogate me on the capacity of a project like DDMD to prove to every D users that the GC is perfectly usable for system applications. If not it will certainly be improve during the DDMD development to a point can satisfy almost everybody?There are no planned GC modifications for the DDMD project. It may result in some compiler devs taking more of an interest in the GC.
Feb 11 2014
On Tuesday, 11 February 2014 at 04:19:12 UTC, Daniel Murphy wrote:"Xavier Bigand" wrote in message news:ldbpum$1pov$1 digitalmars.com...By the way, what is the plan for all the outstanding pull requests that are still in C++?Firstly is there some progress on the DDMD project or maybe an other D boostrap?The old ddmd project is pretty much dead AFAIK (http://www.dsource.org/projects/ddmd) and was never up to date with the current compiler. For about a year I've been working on automatically converting the compiler source from C++ to D. The conversion has produced a working compiler on win32/linux32/linux64 (other platforms need trivial patches) that compiles druntime/phobos/the test suite without errors. The current effort is around cleaning up the C++ source to produce higher quality D code. The next major step is to actually switch development to the D version. Outstanding patches: https://github.com/D-Programming-Language/dmd/pull/1980 Conversion tool: https://github.com/yebblies/magicport2 You can see some of the recent patches (marked DDMD) here: https://github.com/yebblies?tab=contributions&period=monthly
Feb 11 2014
"Brad Anderson" wrote in message news:cbyfliriblkuxnioimwg forum.dlang.org...By the way, what is the plan for all the outstanding pull requests that are still in C++?In theory they can be converted automatically by applying, converting and diffing each commit one by one. Even if that doesn't work out, the codebases will be nearly identical immediately after conversion and converting the commits over manually won't be too difficult.
Feb 11 2014