View mode: basic / threaded / horizontal-split · Log in · Help
January 09, 2013
Re: manual memory management
On Wednesday, 9 January 2013 at 08:14:35 UTC, Walter Bright wrote:
> On 1/8/2013 11:42 PM, Mehrdad wrote:
>> (True, it wouldn't give you the power of a systems language, 
>> but that's quite
>> obviouly not my point -- the point is that it's a _perfectly 
>> possible_
>> memory-safe language which we made, so I don't understand 
>> Walter's comment about
>> a GC being "required" for a memory-safe language.)
>
>
> The misunderstanding is you are not considering reference 
> counting as a form of GC. It is.

So you would say that C++ code (which uses reference counting) 
uses garbage collection?
January 09, 2013
Re: manual memory management
On Wednesday, 9 January 2013 at 02:49:34 UTC, Rob T wrote:
> On Tuesday, 8 January 2013 at 23:30:34 UTC, David Nadlinger 
> wrote:
>> On Tuesday, 8 January 2013 at 23:12:43 UTC, Rob T wrote:
>>> The only major thing that concerns me is the lack of proper 
>>> shared library support. I hope this omission is resolved soon.
>>
>> What do you need it for? Runtime loading of D shared objects? 
>> Or just linking to them (i.e. binding by ld/dyld at load 
>> time)? I'm trying to collect data on real-world use cases 
>> resp. expectations right now.
>>
>> David
>
> I *really* need runtime loading of plug-in code for a server 
> application. This allows the server code to remain untouched 
> while allowing extensions to be added on by a 3rd party.
>
> Runtime linked shared libs are also nice to have for the simple 
> reason that shared libraries can be updated (to a point) 
> without having to rebuild and relink all applications that make 
> use of the libraries. There are pros and cons to static vs 
> dynamic linking, but definitely both are useful to have.
>
> I'm very surprised that not too many people have been screaming 
> for dynamic linking and runtime loading. It's very hard for me 
> to imagine not having the feature because it's so darn useful 
> and an essential feature if your strategy is to allow 3rd 
> parties to extend an application without hacking at the source 
> code.
>
> If there's another better way, I'd sure like to know about it!
>
> --rt

You can write plugins without dynamic loading, they just are a 
bit more cumbersome to write.

Like I used to do back in the late 90's, by making use of UNIX's 
IPC.

The IPC to use (shared memory, pipes, mailbox, sockets) depends 
on what is required from the plugin. With shared memory being the 
closest to what dynamic loading achieves.

Of course this raises another set of issues like:

- Take care what happens when a plugin dies
- Too many loaded plugins can stress the scheduler
- You might have synchronization issues when using shared memory
- It is a bit more painful to code for

This is the school of thought of the Plan9/Go guys and most 
operating system micro-kernel architectures.

--
Paulo
January 09, 2013
Re: manual memory management
Am 09.01.2013 02:59, schrieb H. S. Teoh:
> On Wed, Jan 09, 2013 at 12:21:05AM +0100, deadalnix wrote:
>> On Tuesday, 8 January 2013 at 16:12:41 UTC, Benjamin Thaut wrote:
>>> My impression so far: No one who is writing a tripple A gaming
>>> title or engine is only remotly interested in using a GC. Game
>>> engine programmers almost do anything to get better performance on
>>> a certain plattform. There are really elaborate taks beeing done
>>> just to get 1% more performance. And because of that, a GC is the
>>> very first thing every serious game engine programmer will kick.
>>> You have to keep in mind that most games run at 30 FPS. That means
>>> you only have 33 ms to do everything. Rendering, simulating
>>> physics, doing the game logic, handling network input, playing
>>> sounds, streaming data, and so on.
>>> Some games even try to get 60 FPS which makes it even harder as
>>> you only have 16 ms to compute everything. Everything is
>>> performance critical if you try to achive that.
>>>
>>
>> That is a real misrepresentation of the reality. Such people avoid
>> the GC, but simply because they avoid all kind of allocation
>> altogether, preferring allocating up-front.
>
> Interesting, that sounds like the heapless programming of the old, old
> days where you map out everything beforehand, and limit yourself to use
> only what is there. Y'know, with fixed-sized arrays, stacks, etc., fixed
> maximum number of objects, etc.. Not a bad approach if you want to
> tightly control everything.
>
> Well, except that you do have preallocation, presumably during runtime
> at startup (and between game levels, perhaps?), so it's not as rigid,
> but during gameplay itself this is pretty much what it amounts to,
> right?
>
>
> T
>

No its not heapless programming. You just try to avoid allocations 
during gameplay. But they are done if needed (or if there is no time to 
do it the "clean" way)

Kind Regards
Benjamin Thaut
January 09, 2013
Re: manual memory management
On Wednesday, 9 January 2013 at 08:28:44 UTC, Mehrdad wrote:
> On Wednesday, 9 January 2013 at 08:14:35 UTC, Walter Bright 
> wrote:
>> On 1/8/2013 11:42 PM, Mehrdad wrote:
>>> (True, it wouldn't give you the power of a systems language, 
>>> but that's quite
>>> obviouly not my point -- the point is that it's a _perfectly 
>>> possible_
>>> memory-safe language which we made, so I don't understand 
>>> Walter's comment about
>>> a GC being "required" for a memory-safe language.)
>>
>>
>> The misunderstanding is you are not considering reference 
>> counting as a form of GC. It is.
>
> So you would say that C++ code (which uses reference counting) 
> uses garbage collection?

Yes.

Reference counting is a poor man's form of garbage collection and 
almost every book about garbage collection starts by introducing 
reference counting, before moving on to mark-and-sweep and all 
the remaining algorithms.

Both fall under the umbrella of automatic memory management.

Oh, a bit off topic but are you aware that C++11 has a GC API?

--
Paulo
January 09, 2013
Re: manual memory management
Am 09.01.2013 00:21, schrieb deadalnix:
>
> That is a real misrepresentation of the reality. Such people avoid the
> GC, but simply because they avoid all kind of allocation altogether,
> preferring allocating up-front.

But in the end they still don't want a GC, correct?

Kind Regards
Benjamin Thaut
January 09, 2013
Re: manual memory management
On Wednesday, 9 January 2013 at 08:51:47 UTC, Paulo Pinto wrote:
> On Wednesday, 9 January 2013 at 08:28:44 UTC, Mehrdad wrote:
>> On Wednesday, 9 January 2013 at 08:14:35 UTC, Walter Bright 
>> wrote:
>>> On 1/8/2013 11:42 PM, Mehrdad wrote:
>>>> (True, it wouldn't give you the power of a systems language, 
>>>> but that's quite
>>>> obviouly not my point -- the point is that it's a _perfectly 
>>>> possible_
>>>> memory-safe language which we made, so I don't understand 
>>>> Walter's comment about
>>>> a GC being "required" for a memory-safe language.)
>>>
>>>
>>> The misunderstanding is you are not considering reference 
>>> counting as a form of GC. It is.
>>
>> So you would say that C++ code (which uses reference counting) 
>> uses garbage collection?
>
> Yes.

You (or Walter I guess) are the first person I've seen who calls 
C++ garbage collected.



> Oh, a bit off topic but are you aware that C++11 has a GC API?

Yes, but I'm not aware of any code which claims to have written a 
GC for it.

> --
> Paulo
January 09, 2013
Re: manual memory management
On Wednesday, 9 January 2013 at 08:54:11 UTC, Mehrdad wrote:
> Yes, but I'm not aware of any code which claims to have written 
> a GC for it.


A precise* GC that is, not a conservative one.
January 09, 2013
Re: manual memory management
On Wednesday, January 09, 2013 00:30:32 David Nadlinger wrote:
> On Tuesday, 8 January 2013 at 23:12:43 UTC, Rob T wrote:
> > The only major thing that concerns me is the lack of proper
> > shared library support. I hope this omission is resolved soon.
> 
> What do you need it for? Runtime loading of D shared objects? Or
> just linking to them (i.e. binding by ld/dyld at load time)? I'm
> trying to collect data on real-world use cases resp. expectations
> right now.

You pretty much need shared libraries for plugins (so, runtime loading of 
shared libraries), whereas all dynamic linking really does is save disk space. 
So, I'd consider the loading of shared libraries at runtime to be a necessity 
for some types of projects whereas for pretty much anything other than 
embedded systems (which will probably want to use C anyway), the saved disk 
space part is fairly useless.

With the stuff I work on at work, I couldn't use D precisely because we require 
plugins (think of trying to do something like gstreamer but without plugins -
it doesn't work very well). Now, much as I love D, I wouldn't try and get the 
stuff that I'm doing at work moved over to D, because it's a large, existing, 
C++ code base which works quite well, and I don't think that switching to D 
would be worth it, but anyone looking to do similar projects in D would be out 
of luck right now.

- Jonathan M Davis
January 09, 2013
Re: manual memory management
On Wednesday, January 09, 2013 09:54:10 Mehrdad wrote:
> You (or Walter I guess) are the first person I've seen who calls
> C++ garbage collected.

I sure wouldn't call that garbage collection - not when there's no garbage 
collector. But Walter has certainly called it that from time to time.

I think that the other term that Paulo just used - automatic memory management 
- is far more accurate.

- Jonathan M Davis
January 09, 2013
Re: manual memory management
On 1/9/2013 1:00 AM, Jonathan M Davis wrote:
> On Wednesday, January 09, 2013 09:54:10 Mehrdad wrote:
>> You (or Walter I guess) are the first person I've seen who calls
>> C++ garbage collected.
> 
> I sure wouldn't call that garbage collection - not when there's no garbage 
> collector. But Walter has certainly called it that from time to time.

There's a collector, it's in the refcount decrement (a little simplified):

if (refcount == 0)
  free(obj);

Granted, it's terribly simple, but it's there.
3 4 5 6 7 8 9 10 11
Top | Discussion index | About this forum | D home