POV-Ray : Newsgroups : povray.off-topic : A tale of two cities Server Time
26 Sep 2024 23:36:13 EDT (-0400)
  A tale of two cities (Message 71 to 80 of 105)  
<<< Previous 10 Messages Goto Latest 10 Messages Next 10 Messages >>>
From: nemesis
Subject: Re: A tale of two cities
Date: 14 Mar 2012 15:47:08
Message: <4f60f5bc$1@news.povray.org>
Invisible escreveu:
> Backwards compatibility is pretty evil, eh? ;-)

haskell still to get its own historic warts... :)

-- 
a game sig: http://tinyurl.com/d3rxz9


Post a reply to this message

From: Orchid Win7 v1
Subject: Re: A tale of two cities
Date: 14 Mar 2012 18:29:57
Message: <4f611be5@news.povray.org>
On 14/03/2012 17:49, clipka wrote:
> Am 14.03.2012 18:09, schrieb Warp:
>> clipka<ano### [at] anonymousorg> wrote:
>>> If a GC implementation doesn't track free blocks, how is it ever going
>>> to re-allocate them to anything?
>>
>> A naive implementation of that would be:
>> [...]
>
>
> Well, I wasn't actually considering approaches that would be
> prohibitively inefficient :-P

That's actually how Haskell's GC works. :-P

(Or rather, it is if you select 1-space. The default is 2-space. In 
other words, it allocates twice as much RAM as it actually needs. When 
one half fills, it copies everything to the other half. More RAM, but 
less processor time...)


Post a reply to this message

From: Orchid Win7 v1
Subject: Re: A tale of two cities
Date: 14 Mar 2012 18:35:01
Message: <4f611d15$1@news.povray.org>
On 14/03/2012 16:51, Warp wrote:
> Invisible<voi### [at] devnull>  wrote:
>> The GC engine needs to know quite a bit about the objects it's scanning
>> - how big they are, where their pointer fields are, etc.
>
>    Exactly how does the GC engine know how large a block of allocated
> memory is? Where is this information stored?

Usually the object's class tells you that. You already have a vtable or 
similar structure. (At least, you do in languages where /everything/ is 
dynamically bound by default.)

>    Also, if objects are transparently movable in memory without breaking
> the references pointing to them, that means that in addition to the
> reference the actual raw memory address of the object has to also be
> stored somewhere. Where is this information stored?

Depends on the implementation.

Smalltalk does it by adding a layer of indirection. The address of every 
object in the system is held in a giant "object table". All objects are 
referred to be object IDs, which are merely indices into this table. To 
move an object, merely update its object table entry. (You can also 
store auxiliary information here - e.g., if you wanted to /lock/ the 
object while it's being moved.)

How Haskell does it is to copy each object from its old location to its 
new location, and then overwrite the old copy with a "hey, this is where 
I moved this object to" reference. The GC engine then uses that to 
update any references in other objects as it finds them.

>    You can't avoid bookkeeping when you are allocating blocks of variable
> size.

Sure. At a minimum, you need to know the size of those blocks. 
Realistically, you also need to know what they contain, or you can't 
follow pointers. You probably need to know a little other stuff too.

Most of this information is per-class rather than per-object, however.


Post a reply to this message

From: Orchid Win7 v1
Subject: Re: A tale of two cities
Date: 14 Mar 2012 18:36:06
Message: <4f611d56$1@news.povray.org>
On 14/03/2012 19:47, nemesis wrote:
> Invisible escreveu:
>> Backwards compatibility is pretty evil, eh? ;-)
>
> haskell still to get its own historic warts... :)

Sadly, yes.

Although it /does/ have fewer than most languages. Then again, there's 
less of it to start with, so I guess it would do.


Post a reply to this message

From: Orchid Win7 v1
Subject: Re: A tale of two cities
Date: 14 Mar 2012 18:36:43
Message: <4f611d7b$1@news.povray.org>
On 14/03/2012 18:58, nemesis wrote:

> it's everywhere, Andrew. Kinda like electricity: you just notice it when
> it goes down (and a huge call stack fills your browser).

Do you want to know... what... it... is?

The Matrix is everywhere. It is all around us. Even here, in this very 
room. You can... feel it. When you walk across the street. When you go 
to church. When you pay your taxes.

(Wait, what were we talking about?)


Post a reply to this message

From: Darren New
Subject: Re: A tale of two cities
Date: 14 Mar 2012 23:37:53
Message: <4f616411$1@news.povray.org>
On 3/14/2012 2:26, Invisible wrote:
> pointlessly over-engineered,

The difference between enterprise software and other software is that 
enterprise software is capable of being managed centrally. You can configure 
it and maintain it and check its health while it's running, centrally, 
without being there.

Do you get paged when your web server goes down? Can you configure how much 
traffic has to dip before you get woken up at night? Can you get a list of 
the people who are allowed to see a particular page? Can you track down 
which ISP is at fault when the traffic to your site dips 20%? When serving 
pages is slow, can you tell which part of the system is causing it? A bad 
disk sector? A flakey network card?

-- 
Darren New, San Diego CA, USA (PST)
   People tell me I am the counter-example.


Post a reply to this message

From: Darren New
Subject: Re: A tale of two cities
Date: 14 Mar 2012 23:40:46
Message: <4f6164be$1@news.povray.org>
On 3/14/2012 8:03, Invisible wrote:
> Heh, really? Most languages I work with can allocate new objects in O(1)
> time and using O(1) memory for bookkeeping. I'm not used to dynamic
> allocation being anything to worry about.

Yeah, it's the *de*allocation that takes a while.

-- 
Darren New, San Diego CA, USA (PST)
   People tell me I am the counter-example.


Post a reply to this message

From: Darren New
Subject: Re: A tale of two cities
Date: 14 Mar 2012 23:42:54
Message: <4f61653e$1@news.povray.org>
On 3/14/2012 9:24, clipka wrote:
> So far, so good. But how does the GC know how long each chunk of
> garbage-to-collect is?

It's using basically the same kind of information that's already in each 
object to point to a vtable. If the first word of each object points to a 
vtable, you stick the information once in the vtable about how big it is and 
where the pointers are.

-- 
Darren New, San Diego CA, USA (PST)
   People tell me I am the counter-example.


Post a reply to this message

From: Darren New
Subject: Re: A tale of two cities
Date: 14 Mar 2012 23:47:26
Message: <4f61664e$1@news.povray.org>
On 3/14/2012 15:34, Orchid Win7 v1 wrote:
>  merely update its object table entry.

This is also important for the "becomes" operator.

In Smalltalk, if you have an array X of size 10 that you now want to be size 
20, you can do something essentialy like this:

y := a new array of size 20.
copy first ten elements of x into y.
x becomes y

That last statement swaps the variables x and y, so that all former 
references to x now point to y and vice versa. It's how smalltalk does the 
equivalent of std::vector without actually having a header object and a 
content object.

I've nver seen any other language do that.

> Most of this information is per-class rather than per-object, however.

And I suspect if your language is sufficiently strongly typed, you could 
figure out the classes of non-variant data without having to add information 
to the instances.

-- 
Darren New, San Diego CA, USA (PST)
   People tell me I am the counter-example.


Post a reply to this message

From: Darren New
Subject: Re: A tale of two cities
Date: 14 Mar 2012 23:50:29
Message: <4f616705@news.povray.org>
On 3/14/2012 2:55, Invisible wrote:
> to know whether the libraries eventually settled down and they stopped doing
> crap like this, or... ?

Both those are deprecated now."

> to make it easy for people to write code for your platform and only your
> platform. >:-D

I didn't say they had a generous reason for doing it. But it's exactly that 
reason for why 90% of OSS is either targetting programmers or sucks. Usually 
both. That which doesn't is paid for by a large company trying to displace 
proprietary software.

-- 
Darren New, San Diego CA, USA (PST)
   People tell me I am the counter-example.


Post a reply to this message

<<< Previous 10 Messages Goto Latest 10 Messages Next 10 Messages >>>

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.