I use these guys all the time:
http://github.com/untyped/unlib/blob/master/for.ss
No guarantees that I'm not duplicating other peoples' efforts.
Cheers,
-- Dave
On 22 Aug 2010, at 07:26, Noel Welsh wrote:
> Hi Will,
>
> My "numerics" package on Github has for/vector with some slight
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
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
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
I've just pushed a change to drracket so that it now will compile
files in the collection paths, but not in the main collection path
where the distribution is (as that is the one where thigns should be
compiled already and also the one where you might not have write
access). It also still avoids co
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
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
Would it make sense to detect when you CAN write into the main collects to make
this feature more useful for working on the core?
Sent from my iPhone
On Aug 24, 2010, at 8:46 AM, Robby Findler wrote:
> I've just pushed a change to drracket so that it now will compile
> files in the collection
On Aug 24, Jay McCarthy wrote:
> Would it make sense to detect when you CAN write into the main
> collects to make this feature more useful for working on the core?
That was basically the suggestion I made: that DrRacket will try to
write a temp file to a directory to determine if it's writeable,
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
(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
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
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,
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
Hashes seem to have been added to ASL in a haphazard way. For some
reason the MUTABLE hash operations are present, but not the IMmutable
ones. Also, the docs don't seem to reflect their existence.
Anyone? (Jay, did you push this?)
_
For list-rel
The ffi's "memset" operation takes an optional "type" argument, but it's not
clear what happens if the type isn't _byte. Here are the docs:
(memset cptr byte count [type]) → void?
cptr : cpointer?
byte : byte?
count : exact-nonnegative-integer?
type : ctype? = _byte
(memset cptr offset b
Dave,
Thanks a bunch for pointing out the untyped code! I have a few questions
below, mostly trying to understand the behavior of the macros and reconcile it
with their names.
I'm not sure that I understand for/foldl and friends. I think of the functions
foldl (and foldr) as taking *one* acc
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
What documentation are you looking at?
http://docs.racket-lang.org/htdp-langs/advanced-prim-ops.html#(part._(lib._htdp-advanced..ss._lang)._.Hash_.Tables)
As far as the immutable functions, when I sent you the list of the
functions I intended to add, those were not on it. They were
intentionally
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 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
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
Oh yeah, that's what I figured (and why there was such a long delay
before my change), but I thought I'd reply here since that's where
this came up most recently.
Robby
On Tue, Aug 24, 2010 at 9:56 AM, Laurent wrote:
>
>
> On Tue, Aug 24, 2010 at 16:46, Robby Findler
> wrote:
>>
>> I've just pu
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
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
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
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
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.
Is there a way to say "give me all the require sub-forms" instead of
having to enumerate them explicitly:
(provide require only-in except-in prefix-in rename-in combine-in
only-meta-in for-syntax for-template for-label for-meta)
thereby missing some in future extensions of the base language?
There is not now but we could make a module that only exported them so you
could provide all-from-out it and thus centralize the list of subforms. That's
the cleanest idea I have. (You don't want to hear my really bad ideas)
Jay
Sent from my iPhone
On Aug 24, 2010, at 8:46 PM, Shriram Krishnam
This seems like it would be a good way to handle all the constructs
that have sub-forms-as-standalone-macros (require, provide, big-bang,
match?, etc). Maybe there are other good ways, too, but the current
setup is a nuisance AND highly non-modular.
Shriram
On Tue, Aug 24, 2010 at 11:11 PM, Jay
On Aug 24, Jay McCarthy wrote:
> There is not now but we could make a module that only exported them
> so you could provide all-from-out it and thus centralize the list of
> subforms. That's the cleanest idea I have.
This assumes you want only the core ones, and not things that are
defined in othe
32 matches
Mail list logo
