Monkey's Audio - not faster on P4?

[beatle]

I bought a P4 in hopes that it performed better at encoding media, specifically Monkey's Audio. I rip with Audiograbber and then encode the resulting wavs with Monkey's Audio command line. Call me crazy, but I think it was actually faster with my Barton. Fluke? Fact? CPU usage is pegged @ 50% so I'm assuming that it doesn't take advantage of HT.

 

[alexruiz]

Why don't you test it several times measure the time in both systems with a quite large file, then average the times? that should give a good indication if this applies or not.... Remember that the applications MUST be optimized for SSE2/HT in order to run faster in the P4.

 

[Jeff7181]

Originally posted by: alexruiz
Why don't you test it several times measure the time in both systems with a quite large file, then average the times? that should give a good indication if this applies or not.... Remember that the applications MUST be optimized for SSE2/HT in order to run faster in the P4.

Not entirely true. The Pentium 4's longer pipeline makes it more efficient at encoding media. When the P4 is fed large chunks of data to process it can keep it's pipeline full... AMD can do the same thing, but since it's pipeline is smaller, it can't process as much data. But... if the P4 is fed small chunks of data, the pipeline doesn't stay full, making it less efficient... AMD processors like smaller chunks of data because the pipeline is smaller and it can remain full and continue processing at high efficiency.

(that's my understanding of it, I know other things come into play such as branch prediction, instruction sets, etc, etc... but the length of the pipelines is what makes the two CPU's so different, as AMD could use SSEII just like the P4, and they have in the Athlon-64)

 

[beatle]

I wish I could just swap mb/cpu combos, but it's not that easy. I could try encoding on my 1700+ box, but I don't think that would be a fair comparison. It would be interesting if the 1700+ @ stock speeds beat the P4, but I don't see that happening.

 

[Accord99]

The application may only be single-threaded so it won't take direct advantage of HT. However, you can try running two instances of the encoder at the same time, split the WAVs in half so that each encoder has about the same amount of data to process. In this way, I can get a 27% gain in LAME MP3 encoding.

 

[beatle]

Split the wavs in half? Audiograbber will automatically call the command line encoder of MA and append the appropriate arguments for the type of encoding I want to do. Is there a simple way to do this? Otherwise it seems splitting them would take longer than the encoding time I save by having it encode automatically.

 

[oldfart]

How about with another encoder? I use CDex which is based on the LAME encoder. CDex is cool since it can encode MP3 directly from a CD instead of a two step, two program CD->wave and wave->MP3 operation. I'm converting a couple hundred CD's to MP3 and it helps! I have two optical drives and do two CD's at a time. Just thought I'd throw that out. Dont know if it applies at all.

 

[Accord99]

Originally posted by: beatle
Split the wavs in half? Audiograbber will automatically call the command line encoder of MA and append the appropriate arguments for the type of encoding I want to do. Is there a simple way to do this? Otherwise it seems splitting them would take longer than the encoding time I save by having it encode automatically.

Can you rip everything to WAV first, then use two instances of the GUI to each compress half of the files. Or if you have 2 optical drives, using oldfart's technique should gain an advantage from HT. Anyways, how slow is slow? I did a couple of tests and a relatively conservative P4c 3GHz only takes 43sec to compress a 404MB WAV file. Using two instance, HT increases performance by about 14.5%.

 

[beatle]

I got 43.1 seconds on a 404MB wav using the -c2000 (normal) argument. I usually compress extra high though (to save space - 3 megs on that encode), and that takes 116.7 seconds. Maybe I need to scrap the extra high argument for the sake of speed. It still makes me wonder exactly what speed my Barton would have clocked. Anyone care to measure?

 

[Jeff7181]

Originally posted by: beatle
I got 43.1 seconds on a 404MB wav using the -c2000 (normal) argument. I usually compress extra high though (to save space - 3 megs on that encode), and that takes 116.7 seconds. Maybe I need to scrap the extra high argument for the sake of speed. It still makes me wonder exactly what speed my Barton would have clocked. Anyone care to measure?

I might do it if I get bored sometime, tell me exactly how/what you're doing and I'll try to replicate it.

 

[alexruiz]

Originally posted by: Jeff7181

Originally posted by: alexruiz
Why don't you test it several times measure the time in both systems with a quite large file, then average the times? that should give a good indication if this applies or not.... Remember that the applications MUST be optimized for SSE2/HT in order to run faster in the P4.

Not entirely true. The Pentium 4's longer pipeline makes it more efficient at encoding media. When the P4 is fed large chunks of data to process it can keep it's pipeline full... AMD can do the same thing, but since it's pipeline is smaller, it can't process as much data. But... if the P4 is fed small chunks of data, the pipeline doesn't stay full, making it less efficient... AMD processors like smaller chunks of data because the pipeline is smaller and it can remain full and continue processing at high efficiency.

(that's my understanding of it, I know other things come into play such as branch prediction, instruction sets, etc, etc... but the length of the pipelines is what makes the two CPU's so different, as AMD could use SSEII just like the P4, and they have in the Athlon-64)

Partially true my friend..... CACHE helps inmensely, as shown in the anandtech review of the budget CPU... The statement I bolded is wrong..... despite the shorter pipeline, the Athlon can process as much data as the P4 per second.... it is because it has a higher IPC.

Take any application that is data intensive, in fact, make a video encoding using a version of an aplication / codec that are not optimized..... (ulead video studio 4 for example) then, do the same with a version optimized for SSE2 or HT.... the results will be very different, and in both cases the data processed was roughly the same....

Your post are usually very accurate Jeff, but even the top shooters can miss a duck once in a while

 

[beatle]

To get a 404MB wav, I ripped Norah Jones' cd and merged all tracks together except 2 and 10. Try Audacity for this. I then compressed it using normal and extra high settings with MAC.exe. If you like, PM me and we can set up a transfer (for testing purposes only!) Or you can rip a different cd and merge the tracks that yield ~404MB. I have a feeling Accord99 didn't get his wav this way.

Normal:
mac.exe <source.wav> <destination.ape> -c2000

Extra high:
mac.exe <source.wav> <destination.ape> -c4000

Make sure you download and run the install package from Monkey's Audio's site. This is a great codec!