SMP-aware & optimized video/audio apps?

[Dr Mordrid]

Just for the record: a lot of multimedia software shows little gain by using HT. This is one reason why the non-HT AthlonXP's & 64's can often run rings around the more expensive Pentium 4 HT's in media production.

Dr. Mordrid

[funsoul]

yep...the 64's are especially promising...just need the full app support

at the time of putting together the new setup, though...the dual xeons (overclocked) seemed to be the best bang for the buck (although no upgrade path)

[LvR]

getting much higher cpu utilization (tmpg, vcd template, best quality) with ht off.

One cannot really directly compare the CPU utilization with HT on and off. You will notice that with HT on, taskmanager reports effectively 2 CPUs doing something - with HT off you will only have one CPU shown.

HT off will invariably show closer to 100% cpu utilization with just about any decent app. The same app that has not been optimized for HT will show around 54% CPU utilization - but on both CPUs - rather like add the 2 together and get to close to 100% (minus the HT admin overhead)

If one had the same app but that was actually highly tuned for HT too, you will find the HT "CPUs" getting closer to 100% - and only once you start seeing that, will an HT aware app show gains when compared to nonHT - thats exactly the reason why Doc 's observation is true - the sw designers often only ensure that with HT present their app don't fall over, but has in fact done very little if anything to tune their routines to take advantage of HT.

[funsoul]

Hi Lawrence
Perhaps what I should have typed was that my re-encoding times are roughly 50% shorter with HT off (see 2 cpu's in task manager) when compared to the results with HT on (4 virtual cpus).

Know any other video and/or audio apps that are optimized for smp?
- Tmpgenc is good,
- premierepro is ok (addition of any video filtering is bad, though),
- virtualdub is pretty decent (only with ht off, though and some filters seem better than others for smp)

[LvR]

Nah - I think your list just about tallies with my experience too.

Have seen some people raving about the Canopus Procoder II - no personal experience though.

[spadnos]

The thing about HT is that it won't help in (at least) two particular cases:

1) When the task is totally compute bound. Remember that HT doesn't add any processing power to the CPU, it only adds another "organizational" set of registers. So, if an algorithm has to do operations on a single in-cache data set that take longer than loading /storing the data, there isn't much of a win because you're waiting for the computations to finish.

2) When a task is totally memory bound. If it takes no CPU power to do the task, and a lot of time to get the data, there's no real win because you're limited by memory transfer rates.

So, it's only in the cases where the amount of processing is roughly "the same" as the amount of memory access that HT really helps. (or when you have tasks that utilize different portions of the CPU, which can then operate simultaneously on independent portions of the silicon.)

- Steve

[LvR]

Sure - but if some apps can use HT better than others to accomplish the exact same task, its simply a question of a lazy programmer - no?

[spadnos]

Originally posted by LvR
Sure - but if some apps can use HT better than others to accomplish the exact same task, its simply a question of a lazy programmer - no?

No.

Or Yes - it depends

In my previous post, I didn't make any distinction between multithreaded programs and single threaded programs. There are two valid comparisons to make for a program: a single CPU with HT and without HT; a single HT CPU and dual non-HT cpus. I was mainly pointing out the difference between a single HT CPU and multiple CPUs - this ignores the added overhead of multithreading (small but measurable), which would need to be accounted for in a single vs. single HT comparison.

Assuming that the program is already multithreaded, there's nothing more for the programmer to do - the OS or CPU should "automatically" execute the threads on separate CPUs or HT siblings. So, in that case there isn't any "Lazy Programmer" syndrome going on.

There can be many solutions to the same problem, and some will translate to multithreading better than others. The programs that aren't multithreaded may be that way due to laziness, or because the authors tried single and multithreading, and found the overhead from multithreading to outweigh any processing gains.

So, they could be lazy, or they may just have a program that they tested and found slower with multiple threads (for whatever reason).

- Steve

[LvR]

Got that. My comment about lazy programmers comes from personal experience where an app was touted as being multi-threaded. Via experimentation I could demonstrate it certainly was - but only to the point of it not even being worth the effort - after putting up a moan and causing a stink together with other users, suddenly the manufacturer were able to implement a few changes that made a world of difference when HT is present.

The fact that they have determined their product to be performing at its best before the moan, did not imply they know what they are doing necessarily.

[Dr Mordrid]

Often the degree of HT support has to be guaged by a feature-by-feature basis. In Premiere many modules gain with HT but others do not. Same with SMP support. This is also true in MSPro and other programs.

Dr. Mordrid