On Tue, Aug 24, 2010 at 2:47 PM, Neil Toronto wrote:
>
> In my defense, I was talking about framerate, not total or average cost of
> memory management.
That is very different situation.
> Games are really almost real-time apps.
I'd say that they *are* real-time apps. You really want to be
pr
On Wed, 2010-08-25 at 08:33 -0600, Jay McCarthy wrote:
> On Tue, Aug 24, 2010 at 3:47 PM, Neil Toronto wrote:
> > Matthias Felleisen wrote:
> >>
> >> Catching up with some mail.
> >> Neil wrote:
> >>>
> >>> Avoiding allocation reduces GC collects, which reduces stutters and
> >>> hitches.
> >>
>
On Tue, Aug 24, 2010 at 3:47 PM, Neil Toronto wrote:
> Matthias Felleisen wrote:
>>
>> Catching up with some mail.
>> Neil wrote:
>>>
>>> Avoiding allocation reduces GC collects, which reduces stutters and
>>> hitches.
>>
>> My (possibly old) understanding of GC and mutation tell me that this
>> i
Matthias Felleisen wrote:
Catching up with some mail.
Neil wrote:
Avoiding allocation reduces GC collects, which reduces stutters and hitches.
My (possibly old) understanding of GC and mutation tell me that this
is one of those prejudices that programmers should get rid of. Every
mutation g
On Aug 24, 2010, at 7:13 PM, Matthew Flatt wrote:
> When the GC is well-tuned, it's difficult to slow a program down by
> using mutation --- especially relative to all the other ways you can
> slow a program down.
This is good enough for me to correct my old belief about mutation and GCing.
At Tue, 24 Aug 2010 16:03:00 -0700, Joe Marshall wrote:
> On Tue, Aug 24, 2010 at 3:43 PM, Matthew Flatt wrote:
> > At Tue, 24 Aug 2010 09:53:21 -0700, Joe Marshall wrote:
> >> I'm surprised that racket3m uses page protection. Taking a hardware trap
> >> can often be thousands of times slower tha
Here's a program that tries to expose various costs.
On my machine, the output is:
'cons-of-cXr+barrier-set!
cpu time: 13137 real time: 13206 gc time: 552
'cons-of-cXr+free-set!
cpu time: 12832 real time: 12995 gc time: 541
'cons-of-cXr
cpu time: 10023 real time: 10103 gc time: 526
'cons-o
On Tue, Aug 24, 2010 at 3:43 PM, Matthew Flatt wrote:
> At Tue, 24 Aug 2010 09:53:21 -0700, Joe Marshall wrote:
>> I'm surprised that racket3m uses page protection. Taking a hardware trap
>> can often be thousands of times slower than taking an inline conditional
>> branch.
>
> The hardware trap
At Tue, 24 Aug 2010 09:53:21 -0700, Joe Marshall wrote:
> I'm surprised that racket3m uses page protection. Taking a hardware trap
> can often be thousands of times slower than taking an inline conditional
> branch.
The hardware trap happens once per GC-managed page between minor
collections, whi
So at this point, we don't really know what the relative costs are. -- Matthias
_
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/dev
On 08/24/2010 11:38 AM, Jay McCarthy wrote:
On Tue, Aug 24, 2010 at 10:53 AM, Joe Marshall wrote:
I'm surprised that racket3m uses page protection. Taking a hardware trap
can often be thousands of times slower than taking an inline conditional
branch.
My understanding is that 3m doe
On Tue, Aug 24, 2010 at 10:53 AM, Joe Marshall wrote:
> I'm surprised that racket3m uses page protection. Taking a hardware trap
> can often be thousands of times slower than taking an inline conditional
> branch.
My understanding is that 3m does this because it is doing exact
garbage-collection
On Tue, Aug 24, 2010 at 7:05 AM, Matthias Felleisen
wrote:
>
> Catching up with some mail.
>
> Neil wrote:
>
>> Avoiding allocation reduces GC collects, which reduces stutters and hitches.
>
> My (possibly old) understanding of GC and mutation tell me that this is one
> of those prejudices that pr
On Tue, Aug 24, 2010 at 11:43 AM, Kevin Tew wrote:
> After a garbage collection all non-nursery memory is write-protected.
> The first write to a page (16kB) , after a garbage collection, incurs the
> cost of unprotecting the page so it is writable and recording that the page
> has been written on
On Aug 24, 2010, at 10:46 AM, Matthias Felleisen wrote:
> (I don't quite understand why there's no extra cost for the second access,
> but I'll think about it and figure it out.)
If I understand things correctly, the short answer is "fancy hardware." The
page is marked as read-only in the MMU,
That's the mechanism, but I think Matthias's question is about the
impact on performance. Assuming so, the answer is that it doesn't seem
to matter much relative to everything else. Even programs that use
mutation heavily don't manage to mutate many of the old-generation
pages between major collect
(I don't quite understand why there's no extra cost for the second access, but
I'll think about it and figure it out.)
How do these costs compare then? Are we really at a point where mutation is
superior to short-term allocation as far as the GC is concerned? Do you have
measurements or is th
After a garbage collection all non-nursery memory is write-protected.
The first write to a page (16kB) , after a garbage collection, incurs
the cost of unprotecting the page so it is writable and recording that
the page has been written on.
All subsequent mutations to objects in a unprotected pa
And what if they don't live in the nursery?
On Aug 24, 2010, at 10:51 AM, Kevin Tew wrote:
> Write barriers in racket3m are implemented using memory protection primitives
> provided by the OS.
> Between collections we only incur a write barrier cost the first time a page
> (16k in racket) is
Write barriers in racket3m are implemented using memory protection
primitives provided by the OS.
Between collections we only incur a write barrier cost the first time a
page (16k in racket) is written to.
After the first access per page, additional mutations on that page have
no extra cost, unt
Yes, I was taught the same thing in 1984. That's not the issue.
On Aug 24, 2010, at 10:17 AM, Robby Findler wrote:
> My experience is that allocation is the primary thing to look for to
> improve performance.
>
> Robby
>
> On Tuesday, August 24, 2010, Matthias Felleisen wrote:
>>
>> Catch
My experience is that allocation is the primary thing to look for to
improve performance.
Robby
On Tuesday, August 24, 2010, Matthias Felleisen wrote:
>
> Catching up with some mail.
>
> Neil wrote:
>
>> Avoiding allocation reduces GC collects, which reduces stutters and hitches.
>
> My (possibl
Catching up with some mail.
Neil wrote:
> Avoiding allocation reduces GC collects, which reduces stutters and hitches.
My (possibly old) understanding of GC and mutation tell me that this is one of
those prejudices that programmers should get rid of. Every mutation goes across
an access bar
23 matches
Mail list logo
