Smalltalk › Squeak › Croquet › Croquet - Dev

MessageTally Status

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

4 messages Options

Derek Arndt

MessageTally Status

Hey guys,

I'm back again investigating rendering and general performance of
croquet (especially on low end machines where the UMNs Spanish
Language Project it's unplayable), when I ran into this e-mail:
https://lists.duke.edu/sympa/arc/croquet-dev/2007-10/msg00071.html

What's the status of MessageTally, is it still deemed unreliable?

Cheers,
Derek

Joshua Gargus-2

Re: MessageTally Status

Hi Derek,

I just asked Andreas about it. The question is a bit complicated, and doesn't have a single answer. There are two major issues:

1) the time consumed by long-running primitives is incorrectly assigned to the next message send.

2) if you have a large number of processes that wake up with a timer interrupt, perform a sub-millisecond action, and then sleep (for instance, on a heavily loaded Croquet router) then the results will be statistically biased, because the same interrupt that wakes up the profiler also wakes up the sleeping process.

An example of 1) can be seen in:

http://lists.squeakfoundation.org/pipermail/vm-dev/2007-June/001410.html

What is your target hardware? What are your scenes like (#vertices/#objects)?

Josh

On Apr 4, 2008, at 11:44 AM, Derek Arndt wrote:

Hey guys,

I'm back again investigating rendering and general performance of croquet (especially on low end machines where the UMNs Spanish Language Project it's unplayable), when I ran into this e-mail: https://lists.duke.edu/sympa/arc/croquet-dev/2007-10/msg00071.html

What's the status of MessageTally, is it still deemed unreliable?

Cheers,
Derek

Derek Arndt

Re: MessageTally Status

Hey Josh,

Currently I'm looking at the performance of a couple of different scenes. The first is rendering nothing but a skybox (the idea being maybe if this has an unusually low framerate then adding other mesh data to the scene could quickly drop us into unplayable territory, I still haven't cracked this)

And the second scene is a part of the UMN Spanish Language Project where there's some background geometry (say 6500 primitives with about 20k vertices) with a single animated character (I'll have to look up more proper numbers, but I'll guess less then 1k triangles with 18ish bones running the animation on the GPU).

The CPU performance and MessageTally aside, I would assume you'd have some insight into framerates possible (So for example there's a line of code where Croquet gives itself a break to let other OS processes get some CPU time, which is fine for many applications, but I don't see why the higherPerformance setting of sort wouldn't imply realtime framerates would be a priority)

Derek

On Apr 4, 2008, at 3:40 PM, Joshua Gargus wrote:

Hi Derek,

I just asked Andreas about it. The question is a bit complicated, and doesn't have a single answer. There are two major issues:

1) the time consumed by long-running primitives is incorrectly assigned to the next message send.
2) if you have a large number of processes that wake up with a timer interrupt, perform a sub-millisecond action, and then sleep (for instance, on a heavily loaded Croquet router) then the results will be statistically biased, because the same interrupt that wakes up the profiler also wakes up the sleeping process.

An example of 1) can be seen in:

http://lists.squeakfoundation.org/pipermail/vm-dev/2007-June/001410.html

What is your target hardware? What are your scenes like (#vertices/#objects)?

Josh

On Apr 4, 2008, at 11:44 AM, Derek Arndt wrote:
Hey guys,

I'm back again investigating rendering and general performance of croquet (especially on low end machines where the UMNs Spanish Language Project it's unplayable), when I ran into this e-mail: https://lists.duke.edu/sympa/arc/croquet-dev/2007-10/msg00071.html

What's the status of MessageTally, is it still deemed unreliable?

Cheers,
Derek

Joshua Gargus-2

Re: MessageTally Status

On Apr 4, 2008, at 2:20 PM, Derek Arndt wrote:

Hey Josh,

Currently I'm looking at the performance of a couple of different scenes. The first is rendering nothing but a skybox (the idea being maybe if this has an unusually low framerate then adding other mesh data to the scene could quickly drop us into unplayable territory, I still haven't cracked this)

And the second scene is a part of the UMN Spanish Language Project where there's some background geometry (say 6500 primitives with about 20k vertices) with a single animated character (I'll have to look up more proper numbers, but I'll guess less then 1k triangles with 18ish bones running the animation on the GPU).

When you say "primitives", you roughly mean "triangles", right? How may TFrames are these primitives split between?

The CPU performance and MessageTally aside, I would assume you'd have some insight into framerates possible (So for example there's a line of code where Croquet gives itself a break to let other OS processes get some CPU time, which is fine for many applications, but I don't see why the higherPerformance setting of sort wouldn't imply realtime framerates would be a priority)

I think that particular thing is to help deal with the totally borked thread priorities on Windows... if you're trying to run things (eg: DirectShow filters) in other threads, they'll get totally starved by the foreground application, so you have to explicitly give them some time. Ugh.

Josh

Derek

On Apr 4, 2008, at 3:40 PM, Joshua Gargus wrote:
Hi Derek,

I just asked Andreas about it. The question is a bit complicated, and doesn't have a single answer. There are two major issues:

1) the time consumed by long-running primitives is incorrectly assigned to the next message send.
2) if you have a large number of processes that wake up with a timer interrupt, perform a sub-millisecond action, and then sleep (for instance, on a heavily loaded Croquet router) then the results will be statistically biased, because the same interrupt that wakes up the profiler also wakes up the sleeping process.

An example of 1) can be seen in:

http://lists.squeakfoundation.org/pipermail/vm-dev/2007-June/001410.html

What is your target hardware? What are your scenes like (#vertices/#objects)?

Josh

On Apr 4, 2008, at 11:44 AM, Derek Arndt wrote:
Hey guys,

I'm back again investigating rendering and general performance of croquet (especially on low end machines where the UMNs Spanish Language Project it's unplayable), when I ran into this e-mail: https://lists.duke.edu/sympa/arc/croquet-dev/2007-10/msg00071.html

What's the status of MessageTally, is it still deemed unreliable?

Cheers,
Derek