I'm on an hp mini. It runs on an Atom processor. I ran ants.clj and it was
frozen for a little while. Then after maybe 30 seconds it looked normal --
a tick every second or half second or so. I'm running a lot of applications
though. On Ubuntu here too.
On Sun, Jul 5, 2009 at 11:17 PM, B Smith-Mannschott
<bsmith.o...@gmail.com>wrote:
>
> On Tue, Jun 30, 2009 at 18:01, Rich Hickey<richhic...@gmail.com> wrote:
> >
> > On Tue, Jun 30, 2009 at 7:50 AM, Krukow<karl.kru...@gmail.com> wrote:
> >>
> >> On Jun 29, 7:51 pm, B Smith-Mannschott <bsmith.o...@gmail.com> wrote:
> >> [snip...]
> >>> much on my netbook. The problem seems to be that with only a single
> >>> (hyperthreaded) core the render agent is almost constantly interrupted
> >>> by some pesky ant while attempting to snapshot the world, forcing the
> >>> render agent to automatically retry. And so, the ants run merrily
> >>> around the world, only I can't see it.
> >>
> >> If my understanding of the STM is correct (and it may very well not
> >> be) the render function should not retry. The render function reads
> >> all the refs that define ant positions, but does not modify any ref.
> >> So I suspect that the missing renders are caused by a thread
> >> starvation rather than retries.
> >>
> >> But I'd like to hear if Rich agrees ;-)
> >>
> >
> > MVCC history in Clojure's STM is dynamic, created by need. There is no
> > read tracking, and more important for this case, no transaction
> > tracking. So, if a read transaction is unable to satisfy its snapshot
> > view from history, it will flag the offending ref with a fault and
> > retry. When a writer sees a ref with a read fault it will grow history
> > for that ref. In this way only as much history is created as is needed
> > to satisfy the dynamic contention patterns, and
> > tracking/synchronization is minimized.
> >
> > The problem for scanning readers like render is that the ref that
> > caused the fault this pass is unlikely to be the ref that causes the
> > fault next time, and it will take a while to accumulate even one step
> > of history for each scanned ref using the fault system.
> >
> > This has caused me to implement (in git master) some long-planned
> > controls on ref history. You can now supply :min-history and
> > :max-history args to ref. The defaults are 0 and 10 respectively. By
> > setting min-history to some positive value, history will be
> > accumulated even in the absence of faults, providing a window, if you
> > will, for scanning readers like render.
> >
> > You can see this history acquisition by periodically running:
> >
> > (map ref-history-count (world 20))
> >
> > while the ants demo is going.
> >
> > So, now you can preemptively maintain history in the ants demo by
> > modifying the world init with some min-history (the value 2 below is
> > your 'knob' for accommodating the duration of the render sweep)
> >
> > (def world ... (ref (struct cell 0 0) :min-history 2) ...)
> >
> > Please let me know how that works for you, and, everyone else, please
> > let me know if max-history default of 10 causes you any trouble
> > ("Transaction failed after reaching retry limit").
>
> Sorry it took me so long to try this out...
>
> I've tried this with a build of
> a1397390d8b3b63f2039359520629d87b152d717 (July 4), I tried
> :min-history values of 2 and 9, which didn't help, meaning the window
> stayed blank because the rendering agent does not run to completion. I
> was able to get something to display by dialing :min-history up to
> 100. It draws less than one frame per second, but it does draw.
> (Perhaps it's too much to expect for a single core to juggle some 50
> threads.)
>
> I'm going to play around with it some more and see what I find.
>
> // Ben
>
> >
>
--
John
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~----------~----~----~----~------~----~------~--~---
