Yes, we support hyperthreading in that our apps are multithreaded.

What are your expectations, and why?

Why do you bring up "plugins" specifically?

Peter

>What are your expectations, and why?
>Why do you bring up "plugins" specifically?
My expectations is that the software performs as best as it can. I'm also assuming that hyper-threading may help achieve this goal.

I mention plug-ins because it would seem to me that plug-ins may best be run in threads. The current software I'm using (nTrack) really bogs down when I add plug-ins and it does not utilize hyper-threading (as far as I know). So, I'm actually considering upgrading to some package that will better utilize the CPU.

In the Mac, they seem to be going with dual processors, like we used to do in in the Wintel world. It seems to me that we've done down this "hyper-threading" road rather than dual processors.

Mike

Is it just the application that utilises hyperthreading, or multiple threads (dual proc) or can the plugins divide themselves between processors as well as the host?

Sure, a plug could create its own thread, but this SHOULD be left to the host as the host controls the thread context that the plugin runs in.

Since audio processing is a serial concept - sample 1, then 2, then 3 - the notion of a parallel processing plugin doesn't make a lot of sense. A secondary thread can be used to "cook" parameter changes, but in the end, the i/o to/from a plugin is serial.

That is:

Sample X from all tracks/source must appear on the output at exactly the same time.

So, while the host could multithread each plugin, in the end something will have to wait for the work/processing to complete before it can be output. So, running one or more plugins in parallel with each other is possible, but only in the case where they have completely independent inputs or sources of their samples. If any FX is dependent on the output of another plugin, then the ability to stream them in parallel is diminished, if not lost.

Examples:

If you have

Track 1 routed to FX 1 routed to Master Bus
Track 2 routed to FX2 routed to Master Bus

Now there is a potential for FX1 to run on one thread, while FX2 runs on another thread. You can achieve some parallelism in your processing.


If you have

Track 1 routed to FX 1 routed to FX2 routed to Master Bus
Track 2 routed to FX2 routed to master.

You can't run FX 1 in parallel with FX2 because FX2 needs the output of FX1 before it can do any work. If you run FX 1 immediately after you start FX 2, then you must buffer both FX1s input and output while FX2 is busy processing the previous input. Buffering increases latency.

Multiply these scenarios by 20-30 tracks with 15 FX or so and you see that there can be any number of possible parallel and/or serial streams of data being moved around.

The point in all of this is that samples are serial. If all the paths are completely independant, then some parallelism in processing can be achieved, however as soon as you change a route, you may loose this.

This is about the weakest link in the chain. If there are many sources Feeding a particular destination, then that common destination will dictate the type of parallelism you can achieve.

One other aspect to consider is that the more threading and parallelism you attempt, the more buffering is required to maintain the throughput. The more buffering, the more latency.

So, while it is possible to 'spread' things out accross multiple CPUs - whether real or virtual as in hyperthreading - the benfits become matters of trade offs as buffering is introduced.

Peter

"performs as best as it can"

A reasonable expectation, though subjective. There are always trade offs. Someone might consider that running a 2 ms or less is 'peforming as best as it can" while others demand that having 100 tracks is 'peforming as best as it can".

Plugins can only be run in parallel under certain conditions. Hyperthreading makes this a no go as plugin processing will most likely involve using Floating point, and the current Hyperthreading technologies - the last time I looked - can't share the FPU.

Basically this means that any benifits of multiple threading where two or more threads are doing floating point math will result in a force sharing of the FPU - i.e. same behavior as a single processor.

Peter

This is what ron kuper from cakewalk had to say about sonar 3.1.1 on the issue of multiprocessing.

http://www.digitalprosound.com/2004/03_mar/features/sonar_multiproc.htm

I don't own a dual processor system [yet] but was wondering how Vegas 5 handled audio processing compared to sonar 3.1.1. I own both [soon V5]so its not a big deal to me but to others I guess...

Ed.

btw...I know you can't talk about V5 yet, just passing info around. I just hope this area of V5 is comparable in performance. I still like mixing in Vegas better.

Dual processors CAN make quite a difference in plug-in count among things when used with an app that properly supports it. Unfortunately, Vegas 4 is worthless in this area as it barely touches the second CPU. Let's hope Sony has their act together with V5 and dual processor support.

this is very interesting. Thinking about my setup with regards to mixing, I think a lot of parallelism could be achieved.

The question then becomes, is it more worthwhile to upgrade my machine to a dual Operton - or to a faster single processor machine.

I guess we'll have to wait and see with Vegas 5!

Peter - thanks especially for the info about Hperthreading not sharing the FPU - I didn't know this!

Jason

>Basically this means that any benifits of multiple threading where two or
> more threads are doing floating point math will result in a force sharing of
>the FPU - i.e. same behavior as a single processor.
Right - then the FPU would become the bottleneck.

I guess we're left with multiple CPUs then?

When I saw "as best as possible", I mean the ability to add tracks & plug-ins and have the drain on the CPU be linear.

Thanks for your replies.

Mike

In my understanding, hyper-threading is more than just creating threads, which we've seen in this discussion don't really help in a serialized environment.

But the hyper-threading model is one of dual CPU's which should help in the digital audio domain. I want a program that can utilize this technology and allow me to create more 96/24 tracks with more plug-ins.

Mike

AFAIK, Vegas divides takes between 2 processors as follows:
Processor 1 handles all the video FX rendering.
Processor 2 handles DV decoding + encoding, and all the audio.

For video, most of the time you are going to see processor 2 being idle. For audio, it should be the opposite. An idle processor doesn't do much so you gotta figure that dual Opterons won't help much. However for video dual processors might be useful if you render farm your computer to itself. I have no idea if that works well.

I wouldn't count any chickens yet.....

Sony has yet to claim that V5 will actually use multiple processors in a way that will increase plug-in count. Vegas 4 was a BIG disappointment for me in this area and one of the main reasons I no longer use it for audio work.

I have a feeling that V5 will offer more new nifty video features than badly needed audio stuff. I hope I am wrong.

fishtank: come on, man.

PCH just clearly stated why there is no major advantages to dual processors, but if there are, Vegas already supports threads which is roughly the same thing. That article from Sonar said more or less the exact same thing, even though its package tried to indicate otherwise.

I understand this issue is very important to you, and I'm not saying nobody should listen to you - but I do think you've overestimated the benefits of dual processors due to the fact that you didn't understand either what PCH or the Sonar article actually said: Audio is a serial process, and does not benefit in any major fashion from parallel computing. The only thing you can do is throw "everything else" at the second CPU.

>PCH just clearly stated why there is no major advantages to dual
> processors, but if there are, Vegas already supports threads which is
> roughly the same thing. That article from Sonar said more or less the exact
> same thing, even though its package tried to indicate otherwise.
No - PCH did not say that about dual processors, he said that about hyper-threading. In a dual processor environment, we would expect to see real gains. I wished the Sonar tests had included a dual processor example - perhaps they did and didn't like the results?

Mike