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 Smit
On Tue, Jun 30, 2009 at 18:01, Rich Hickey wrote:
>
> On Tue, Jun 30, 2009 at 7:50 AM, Krukow wrote:
>>
>> On Jun 29, 7:51 pm, B Smith-Mannschott wrote:
>> [snip...]
>>> much on my netbook. The problem seems to be that with only a single
>>> (hyperthreaded) core the render agent is almost constan
On Jul 1, 3:09 pm, Rich Hickey wrote:
[snip]
> lock architecture that is woven throughout. In fact, I think the
> possibility for knobs is a key strength of an STM. Furthermore, such
> knobs can be dynamic, allowing for applications that analyze their own
> runtime situation and adapt, in this
On Jul 1, 8:43 am, Daniel Lyons wrote:
> While that may be true for the time being I think that Rich's original
> response still holds water: that usually, correctness is more
> important than performance and correctness is the real win with STM.
[snip...]
Agreed - happy Clojure user her
On Wed, Jul 1, 2009 at 1:50 AM, Krukow wrote:
>
>
> On Jun 30, 6:01 pm, Rich Hickey wrote:
>> 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 s
On Jun 30, 2009, at 11:50 PM, Krukow wrote:
> I like the pragmatics of :min-history, and I believe it would be
> sufficient for many scenarios. However, I suspect we are now moving
> closer to the situation that Cliff Click was predicting [1] where as a
> programmer you need more precise knowledg
On Jun 30, 6:01 pm, Rich Hickey wrote:
> 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 offendin
On Tue, Jun 30, 2009 at 7:50 AM, Krukow wrote:
>
> On Jun 29, 7:51 pm, B Smith-Mannschott 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 sn
On Tue, Jun 30, 2009 at 10:10, Daniel B Lucraft wrote:
>
> I didn't think it was possible for the render agent to be interrupted
> like that. Isn't the point of the MVCC system that the render agent
> will see a consistent view of the world as it was when the render
> started? And that the ants ca
I think I remember running the ants.clj demo on my netbook and it running
normally. I'll check again this evening.
On Tue, Jun 30, 2009 at 12:40 PM, Daniel B Lucraft
wrote:
>
> I didn't think it was possible for the render agent to be interrupted
> like that. Isn't the point of the MVCC system
I didn't think it was possible for the render agent to be interrupted
like that. Isn't the point of the MVCC system that the render agent
will see a consistent view of the world as it was when the render
started? And that the ants can continue modifying the world during the
render's processing but
On Jun 29, 7:51 pm, B Smith-Mannschott 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 automati
After watching most of Rich's Clojure presentations over the weekend,
I found myself playing with ants.clj again on my netbook. The ant
simulation runs brilliantly on my quad-core machine at work. Not so
much on my netbook. The problem seems to be that with only a single
(hyperthreaded) core the r
13 matches
Mail list logo
