Matt you are, in the truest sense of the word, a genius. To those with intelligence similar to yours, I'm confident that was a excellent explanation. To those of us who struggle to balance their check book, you lost me after the third paragraph!
Believe it or not, mathematicians have no problem with square root of negative 1 (nor do electrical engineers). An analogy to grasp can come from the world of project management. In a given example, there is the concept of critical path -- those things that define a project duration.
Consider that the render task is really a project.. You can juggle things around , improved performance on varioius sub-tasks, and maybe improve duration. Then agian, maybe not. If you significantly reduce the time of task "A", then perhaps something else becomes the limiting facto - a new critical pathr.
So here we have V5/V6, HT/Non-HT, Dual processors, Dual channel, processors, MoBo chipset, disk drive, NZQ, Cache on cache, ..... and you get the message -- you rmilage will vary!!
well, reading this makes me see 2 things - one, it's been a while since I took algebra :)
2 - HT isn't all it's cracked up to be - that's for sure.
Anyway, I understand the whole thing, and it's what I've always "understood" so to speak. No complaints here - the times are improved in V6 for me sometimes just a small amount, but it doesn't seem to affect me too badly negatively.
LoL, Now c'mon buster does he really have to explain that again?
Just look at c and you will = d but don't take away from l m n o p average. Whats not to understand.
Nice break down Matt. I understood most of it, but the first part when you went from EQ0 to EQ1. If I substitute "1" in for C0 and then invert the bottom divisors and multiple I get:
T=(W+WR)/P and not T=W/(P+R).
I wanted to make sure these equations where not equal and you just did some further variable extrapulations so I set W=2, R=3 and P=4, and they're definately not equal. So I'm just a little confused on how you got EQ0 reduced to EQ1 as an equivalent.
Oh and BTW, the other equations sure do look like some C code to me.
What follows is, because it is a simplification, not entirely correct, but I'll attempt to draw a picture of what is happening for people who are trying to get a handle on this.
In Vegas, there are a few contributing factors to a render. For this example, let's take a DV render to MPEG 2 with a few effects:
The Vegas 5 engine views this as:
*Read and Decode some DV, then do some filtering and processing, then hand that output to the MPEG compressor.
*While this is happening, MPEG compression work would be done separately, on another thread.
The Vegas 6 engine views this as:
*Read and Decode some DV, then hand that to the engine for filtering and processing.
*While this is happening, do some filtering and processing, then hand that output to the MPEG compressor. This can be done on multiple threads.
*While all of that is happening, do the MPEG compression on another thread.
The costs involved in managing threads and switching between them are not negligable, and the gains from using logical processors in HT may not be enough to overcome the costs incurred through threading. In light of the dual-core offerings from AMD and Intel, optimizing for multiple physical processors shows great promise.
As was stated in the initial writeup, one project can not serve as an example one way or another. We have several projects and benchmarking examples showing performance gains with HT processors, and Vegas 6 shows markedly improved performance on true multi-processor machines over Vegas 5.
The important thing to understand here is that the reading and decompression is threaded before the engine gets to composite, filter, temporally resample, and otherwise play with your video
There are times when the engine will have to wait on frames to be read and decoded, but this threading allows for the engine's requests to be satisfied immediately in many cases.
If you view "hand that" in my earlier post as someone standing between two workers and managing the work done by one and the requirements of the next, you have a picture of what is going on.
This is all well and good, if not understandable. I would like to get this down into simpler terms. As someone else asked quite a while back.... why can't there be background rendering as Pinnacles (Avid) Liquid Edition.... then would we need all this 'math'?
To me, it is amazing to apply effects, transitions, etc and watch Liquid Edition quickly render it out, or continue editing for a few seconds as LE does it's thing.
Thanks,
Barry
"rednroll, square root of -1, is an imaginary number ."
Yes, Calculus at work here. In Calc you deal with "complex numbers" . A complex number is composed of two parts, the first part is the "real part" and the second part is the "imaginary part". It's usually shown in math form of (REAL + IMAGINARY), or {a + ib} where the imaginary part is designate with the letter "i" infront of it. So the square root or -1 is actually in the imaginary part of the complex number so it would be SQRT(-1)= {0+i(1)} or simplified "i".
I always wanted to be an engineer, so I could wear the hat and drive the train. My boss keeps telling me, I have to work up to it before I reak those benefits. I'm holding in there.
Rednroll, nice explanation. Complex number theory is just a starting building block in the math world of an electrical engineer. Laplace, fourier, series, boundary...etc... mathematics is "air" engineers live by in the begining. Most Programmers usually do not apply enought math to their work in sound or video design, leading to some bad designs and mysterious problems.