Hi, yes, I understood your problem of taking the cpu time to check, but I simplified my post by just saying that if you could figure out a message...

Sounds like where the use of a 2nd core would come in handy.

Reminds me of an article in (if I remember correctly) the Oct. issue of MSDN Magazine - the one that covered threading and parallel processing.

The author posited that in the past CPU cycles are considered >precious< and therefore a sin to WASTE.

Now with multiple cores, it's okay to do speculative processing (trying to GUESS the user's next operation) and if it's correct - use the results otherwise simply TOSS the results and start guessing at something else...

In other words, we can now afford to throw away processing since some of the cores will be sitting unused anyway...

-Will

Hi Will, yeah there is something to be said for that idea of doing speculative processing.

One other issue though is with larger models it is not just CPU time that can be a problem but also memory consumption. Things that may need to carve off a big chunk of memory in addition to occupying a core can tend to be more intrusive. If the chunk of speculative work occupies enough memory it can push other things out to disk and start the whole virtual memory system swapping, that creates a big negative impact on the "standard task" that is happening at the same time...

I have actually been working on some stuff recently for multi-core, just yesterday I finished up a piece of work to make the tessellator thread safe. That was a pretty big step, but I still need to do some more work to separate things out into more individual work items though.

- Michael

Yes, it was a really good article.

He was giving examples of doing database searches based on locality, prefilling listboxes etc., with choices that seemed appropriate depending on what the user had done previously.

He also gave a photoshop example of filters where instead of filling a dialog with previews of how the filter with varied options will look to just go ahead and perform the various filter operations on the full image instead - if the user chooses one of the presets, the work is done already, if not, toss it, rinse and repeat...

It was a lightbulb moment for me reading it cause I'm an old school programmer starting out with 8080s, 6809's 6811's, etc., every cycle was like gold - those old habits die hard!

This concept of throw away processing was enlightening.


I had the performance dialog open one evening and I was watching MOI crunch though a fillet (which I gave up on cause it took too long) - I saw that it wasn't CPU intensive at all so I can appreciate that your actual processing may not improve all that much using a technique like this - the GUI maybe, but that would be (if ever) after MOI has advanced to supporting way more functionality than it does now (perhaps parts libraries, large lists of things etc.)

-Will

Hi Will,

re: (Crunching through a fillet not CPU intensive)...

Hmm, normally filleting eats CPU to a really high degree... But the crunching will happen in moi_commandprocessor.exe, not MoI.exe .

- Michael

I was just looking at the 4 core graphs - the 1st if I remember correctly was only about 40 - 60%, never pinned, the others were at the bottom.

-Will