October 24, 2012
On Wednesday, 24 October 2012 at 12:21:03 UTC, Paulo Pinto wrote:
>
> Having dealt with systems programming in languages with GC (Native Oberon, Modula-3), I wonder how much an optional GC would really matter, if D's GC had better performance.
>
> --
> Paulo

Well, performnce is only part of the GC equation. There's determinism, knowing when the GC is invoked and ability to control it, and increased complexity introduced by a GC, which tends to increase considerably when improving the GCs performance and ability to manage it manually. All this means there's a lot more potential for things going wrong, and this cycle of fixing the fix may never end.

The cost of clinging onto a GC may be too high to be worth relying on as heavily as is being done, and effectivly forcing a GC on programmers is the wrong approach because not everyone has the same requirements that require its use. When I say "forcing", look at what had to be done to fix the performance of the game in question, what was done to get rid of the GC was a super-human effort and that is simply not a practical solution by any stretch of the imagination.

A GC is both good and bad, not good for everyone and not bad for everyone, with shades of gray in between, so it has to be made fully optional, with good manual control, and easily so.

--rt

October 24, 2012
On Wednesday, 24 October 2012 at 18:26:48 UTC, Rob T wrote:
> On Wednesday, 24 October 2012 at 12:21:03 UTC, Paulo Pinto wrote:
>>
>> Having dealt with systems programming in languages with GC (Native Oberon, Modula-3), I wonder how much an optional GC would really matter, if D's GC had better performance.
>>
>> --
>> Paulo
>
> Well, performnce is only part of the GC equation. There's determinism, knowing when the GC is invoked and ability to control it, and increased complexity introduced by a GC, which tends to increase considerably when improving the GCs performance and ability to manage it manually. All this means there's a lot more potential for things going wrong, and this cycle of fixing the fix may never end.
>
> The cost of clinging onto a GC may be too high to be worth relying on as heavily as is being done, and effectivly forcing a GC on programmers is the wrong approach because not everyone has the same requirements that require its use. When I say "forcing", look at what had to be done to fix the performance of the game in question, what was done to get rid of the GC was a super-human effort and that is simply not a practical solution by any stretch of the imagination.
>
> A GC is both good and bad, not good for everyone and not bad for everyone, with shades of gray in between, so it has to be made fully optional, with good manual control, and easily so.
>
> --rt

I do understand that.

But on the other hand there are operating systems fully developed in such languages, like Blue Bottle,

http://www.ocp.inf.ethz.ch/wiki/Documentation/WindowManager

Or the real time system developed at ETHZ to control robot helicopters,

http://static.usenix.org/events/vee05/full_papers/p35-kirsch.pdf

I surely treble at the thought of a full GC collection in plane software. On the other hand I am old enough to remember the complaints that C was too slow and one needed to write everything in Assembly to have full control of the application code.

Followed by C++ was too slow and one should use C structs with embedded pointers to have full control over the memory layout of the object table, instead of strange compiler generated VMT tables.

So I always take the assertions that manual memory management is a must with a grain of salt.

--
Paulo




October 24, 2012
On Wednesday, 24 October 2012 at 21:02:34 UTC, Paulo Pinto wrote:
> So I always take the assertions that manual memory management is a must with a grain of salt.
>
> --
> Paulo

Probably no one in here is thinking that we should not have a GC.

I'm sure that many applications will benefit from a GC, but I'm also certain that not all applicatins require a GC, and it's a mistake to assume everyone will be happy to have one as was illustrated in the OP.

In my case, I'm not too concerned about performance, or pauses in the execution, but I do require dynamic loadable libraries, and I do want to link D code to existing C/C++ code, but in order to do these things, I cannot use the GC because I'm told that it will not work under these situations.

It may be theoretically possible to build a near perfect GC that will work well for even RT applications, and will work for dynamic loadable libraies, etc, but while waiting for one to materialize in D, what are we supposed to do when the current GC is unsuitable?

--rt

October 25, 2012
On Wednesday, 24 October 2012 at 23:05:29 UTC, Rob T wrote:
> In my case, I'm not too concerned about performance, or pauses in the execution, but I do require dynamic loadable libraries, and I do want to link D code to existing C/C++ code, but in order to do these things, I cannot use the GC because I'm told that it will not work under these situations.

You can very much link to C and C++ code, or have C and C++ code link to your D code, while still using the GC, you just have to be careful when you send GC memory to external code.

You can even share the same GC between dynamic libraries and the host application  (if both are D and use GC, of course) using the GC proxy system.

October 25, 2012
On Wednesday, 24 October 2012 at 23:05:29 UTC, Rob T wrote:
> In my case, I'm not too concerned about performance, or pauses in the execution, but I do require dynamic loadable libraries, and I do want to link D code to existing C/C++ code, but in order to do these things, I cannot use the GC because I'm told that it will not work under these situations.

You can very much link to C and C++ code, or have C and C++ code link to your D code, while still using the GC, you just have to be careful when you send GC memory to external code.

You can even share the same GC between dynamic libraries and the host application  (if both are D and use GC, of course) using the GC proxy system.

October 25, 2012
On Thursday, 25 October 2012 at 02:15:41 UTC, Jakob Ovrum wrote:
> On Wednesday, 24 October 2012 at 23:05:29 UTC, Rob T wrote:
>> In my case, I'm not too concerned about performance, or pauses in the execution, but I do require dynamic loadable libraries, and I do want to link D code to existing C/C++ code, but in order to do these things, I cannot use the GC because I'm told that it will not work under these situations.
>
> You can very much link to C and C++ code, or have C and C++ code link to your D code, while still using the GC, you just have to be careful when you send GC memory to external code.
>
> You can even share the same GC between dynamic libraries and the host application  (if both are D and use GC, of course) using the GC proxy system.

I am speaking without knowing if such thing already exists.

Maybe someone that knows the best way to do so, could write an article about best practices of using C and C++ code together in D applications.

So that we could point them to it, in similar vein to the wonderful article about templates.

--
Paulo
October 25, 2012
On Thursday, 25 October 2012 at 02:15:41 UTC, Jakob Ovrum wrote:
>
> You can very much link to C and C++ code, or have C and C++ code link to your D code, while still using the GC, you just have to be careful when you send GC memory to external code.
>
> You can even share the same GC between dynamic libraries and the host application  (if both are D and use GC, of course) using the GC proxy system.

My understanding of dynamic linking and the runtime is based on this thread

http://www.digitalmars.com/d/archives/digitalmars/D/dynamic_library_building_and_loading_176983.html

The runtime is not compiled to be sharable, so you cannot link it to shared libs by defult. However, hacking the gdc build system allowed me to compile the runtime into a sharable state, and all seemed well.

However, based on the input from that thread, my understanding was that the GC would be unreliable at best.

I suppose I could do some tests on it, but tests can only confirm so much. I'd also have to decipher the runtime source code to see what the heck it is doing or not.

--rt
October 25, 2012
On Thursday, 25 October 2012 at 08:34:15 UTC, Rob T wrote:
> My understanding of dynamic linking and the runtime is based on this thread
>
> http://www.digitalmars.com/d/archives/digitalmars/D/dynamic_library_building_and_loading_176983.html
>
> The runtime is not compiled to be sharable, so you cannot link it to shared libs by defult. However, hacking the gdc build system allowed me to compile the runtime into a sharable state, and all seemed well.
>
> However, based on the input from that thread, my understanding was that the GC would be unreliable at best.
>
> I suppose I could do some tests on it, but tests can only confirm so much. I'd also have to decipher the runtime source code to see what the heck it is doing or not.
>
> --rt

You are right that compiling the runtime itself (druntime and Phobos) as a shared library is not yet fully realized, but that doesn't stop you from compiling your own libraries and applications as shared libraries even if they statically link to the runtime (which is the current default behaviour).

October 25, 2012
On Thursday, 25 October 2012 at 08:50:19 UTC, Jakob Ovrum wrote:
> You are right that compiling the runtime itself (druntime and Phobos) as a shared library is not yet fully realized, but that doesn't stop you from compiling your own libraries and applications as shared libraries even if they statically link to the runtime (which is the current default behaviour).

Yes I can build my own D shared libs, both as static PIC (.a) and dynamically loadable (.so). however I cannot statically link my shared libs to druntime + phobos as-is. The only way I can do that, is to also compile druntime + phobos into PIC, which can be done as a static PIC lib.

So what you are saying is that I can statically link PIC compiled druntime to my own shared lib, but I cannot build druntime as a dynamically loadable shared lib? I can see why thatmay work, if each shared lib has it's own private compy of the GC. Correct?

I recall that druntime may have some ASM code that will not work when compiled to PIC. I think gdc removed the offending ASM code, but it may still be present in the dmd version, but I don't know for sure.

Another question is if I can link a dynamic loadable D lib to C/C++ code or not? Yes I can do it, and it seems to work, but I was told that the GC will not necessarily work. Am I misunderstanding this part?

--rt
October 25, 2012
On Thursday, 25 October 2012 at 02:15:41 UTC, Jakob Ovrum wrote:
> You can even share the same GC between dynamic libraries and the host application  (if both are D and use GC, of course) using the GC proxy system.

What is the GC proxy system, and how do I make use of it?

--rt