dual cpu support?

[FreQi]

I am considering picking up a motherboard and dual Athalon MP 1600+ processors. I am currently running Windows 2000 Pro, and was wondering if I would really see a performance boost with avisynth compared to a single Athalon XP 2100+.

I understand that in order to take advantage of dual cpu's I'd need to use apps that are threaded... not sure if I have the terminology right. Anyway, here's the apps I use for encoding:

AVI_IO (capture with)
Huffyuv 2.1.1 (capture to)
AVISynth 2.0.5 (for trimming, resizing)
decomb.dll 3.91 (for telecine and decimate)
VirtualDub 1.4.10 (for SmartSmoother and Logo filters)
LAME 3.92 (vbr mp3's)
NanDub/DivX 3.11a (to make the final encode)

Anyway, avisynth is what does most of the work here, so that's what I am really concerned about. thanks for your help

[hakko504]

AFAIK VirtualDub/NanDub is SMP aware and should therefor put itself on one CPU while leaving Avisynth on the other. You should see that one CPU is maxing out at 99% load while the other is running at maybe 60-80% of maximum, depending on how much filtering you do.
You should also be able to skip the VD step by getting wilbert's VD importFile for AVIsynth, and add the SmartSmoother/Logo filters to the AVIsynth script. Get it here. (http://www.avisynth.org)

[FreQi]

I've got functions to use vd filters in avisynth, but I actually prefer to use the filters inside vdub or nandub. I have had strange proglems with freezes and that's nothing fun to wake up to, considering it can take 10 hours just go to from source -> avisynth -> filters -> intermediate avi. But when I was making vcd's there was no avoiding it...

I have been making a temporary huffy encode because I use nandub's 2-passes, and it's silly to wait 10 hours two times, then add the divx encoding time. This way I wait one 10 hour spot, then encode to divx which takes about 2 hours. It's pretty awful, which is why I am looking at an upgrade.

I suppose if avisynth would run on one cpu, and vdub on the other, I would end up with one basically doing the decomb and resize while the other smooths and writes to the file. I guess two 1600+ processors would be better than one 2100+ cpu then.

[Leitz]

I just have to warn FreQi:

If I encode using avisynth 2.05 with either VirtualDub for Divx or Helix Producer for RV9 the "overall cpu load" is about 100%. So hakko504 should be right and VitualDub obviously supports SMP.

But whenever I use avisynth with additional filters like temporalsmoother or convolution3d it is only about 60%. Can someone imagine why? Btw: cpu load is rather outbalanced in both cases.

I use an Elitegroup D6VAA (the cheapest smp board on earth) with two PIII-800EB.

[Defiler]

SMP is definitely worth it. I see a huge boost in encoding performance with dual CPUs.
However, you have to be careful about the tasks you create.
Avisynth can crunch along on one CPU, and VirtualDub can encode for you on another. If one of those processes takes much longer than the other, you won't see a 100% performance boost.

If your Avisynth script contains a bunch of:
ConvertToRGB()
Blah()
ConvertToYUY2()
Blah3D()
ConvertToRGB()

, then it's not going to be able to feed the encoder fast enough to keep your second CPU busy.

If, on the other hand, your Avisynth script is merely:

Crop()
SomeFilter()
Resize()

, then you're likely to see a major improvement. Using "Full Processing" in Virtualdub will push you closer to the first case than the second.

That being said, the fastest encoding boxes in the world have multiple CPUs. Welcome to the world of SMP. I'm upgrading mine to dual Athlon XP 2400+ CPUs in two weeks.

[FreQi]

I do use full processing in VirtualDub/NanDub, just because I like using virtualdub filters there. I've used the vdub filters in avisynth, I just usually don't like to. Here's an example script:


LoadPlugin("decomb.dll")
s=AVISource("File_01.avi")+AVISource("File_02.avi")
s.Trim(691,1050).FS2WS()++s.Trim(1051,12725).WS()
Amplify(1.8)

function WS(clip clip)
{ clip.Telecide(guide=1)
Decimate(cycle=5)
Crop(0,60,632,362)
BilinearResize(512,288)
}

function FS2WS(clip clip)
{ clip.Telecide(guide=1)
Decimate(cycle=5)
Crop(0,2,640,478)
BilinearResize(384,288)
AddBorders(64,0,64,0)
}


Then I open that script in *dub and that's where I have been putting the SmartSmoother filter from Donald Graft. Are you saying I would be better off (smp-wise) if I put the filter inside the avs script? Like with this function:


ConvertToRGB
SmrtSmooth(5,25)
ConvertToYUY2

function SmrtSmooth(clip clip, int diameter, int threshold)
{ LoadVirtualdubPlugin("c:\program files\nandub\plugins\Smooth.vdf", "SmartSmootherFilter", 1)
return clip.SmartSmootherFilter(diameter, threshold, 0)
}

[Defiler]

Not necessarily, because you're doing a colorspace conversion either way, and VirtualDub's code is probably pretty good at it. It's just that colorspace conversions in general stall the flow of data, and make it hard to take advantage of multiple CPUs.
I'd definitely try it both ways and see, though.

[MaTTeR]

Vdub with AVS running on a dualie platform is definitely the way to go. I'll never go back to a single CPU system:D Seems odd Mr. Acaila hasn't chimed in on this thread too.

Word of warning, buy the MPs and don't buy the XPs to hack. I took the cheap road(XP hacked) and it seems as though they don't run as effecient as the MP CPUs. Read over at 2cpu.com for more info.

Defiler,

I hear ya about the 2400's, I plan on upgrading my 2 XP 1600s to 2400's in a month or so. Before long we might just be pushing 180FPS. LOL