Audio/Video Encoding

MusicMatch Jukebox 7.10

MusicMatch Jukebox 7.10

DivX 6 with AutoGK

Armed with the DivX 6 and the AutoGK front end for Gordian Knot, we took all of the processors to task at encoding a chapter out of Pirates of the Caribbean. We set AutoGK to give us 75% quality of the original DVD rip and did not encode audio; all of the DivX 6 settings were left at default.

DivX 6.0 w/ AutoGK 1.60

Windows Media Encoder 9

To finish up our look at Video Encoding performance, we have two tests both involving Windows Media Encoder 9. The first test is WorldBench 5's WMV9 encoding test.

Microsoft Windows Media Encoder 9.0

Once we crank up the requirements a bit and start doing some HD quality encoding under WMV9, the single core performance drops dramatically:

Microsoft Windows Media Encoder 9.0

Video Creation/Photo Editing Gaming Performance
Comments Locked

109 Comments

View All Comments

  • justly - Tuesday, August 2, 2005 - link

    It would seem I have to put this in even simpler terms for you.

    Processing POWER is not necessarily the same as processing SPEED.
    Using an analogy may be the only way to explain this to you.

    If you are given a task that is simple for you to accomplish, maybe something like moving two bricks 50 feet, having a second person help you will not result in you getting that task done any faster. The only thing that will make this task faster is if you run instead of walk. That difference is speed not power.

    On the other hand if the task is more demanding, this time you need to move a 100 bricks 50 feet, then the second person should be able to cut that time in half if both of you move the same amount of bricks at the same speed.

    I hope that wasn’t too hard for you to understand.

    To go one step further, If in the first scenario (when you had to move just two bricks) if you only move one brick at a time then adding a second person (also capable of moving one brick) will show 100% scaling.

    This demonstrates what I said about a poor performing processor will see a higher scaling when adding a second core, proving my point that higher scaling “shows how “inefficient” a single core is in that test”, not how efficient a duel core is.

    To even attempt to show scaling efficiency in the manor that was done in the article is questionable, and to use a test that was not only less than processor limited on duel core, but less than processor limited on a single core was ignorant (again I am talking processor limited in terms or computational power not speed).

    Since adding a second core does not change memory bandwidth or disk access time I don’t know why you even brought this up, as its irrelevant.
  • masher - Tuesday, August 2, 2005 - link

    > "This demonstrates what I said about a poor performing processor will see a higher scaling when adding a second core..."

    Are you stupid? Your analogy-- muddled and poorly phrased as it is-- proves my point. Not yours. We're discussing a multitasking benchmark. Got any idea what the "multi" in multitasking means? More than one. A single core executes ONE thread at a time. This benchmark has multiple threads running at once.

    To translate this back to your analogy, a single core cannot carry two "bricks" (threads) at the same time. It carries one-- partway or all the way-- then has to "run back" to carry the other one. And so on until the job is done. Sorry for the kindergarten-level analysis, but your posting history demands it.

    Two cores carry two bricks at once...and get the job done faster. If you only had a single brick (a single nonthreaded app) then a second core wouldn't help you. If your second brick only had to move 1 foot rather than 50 (poor app scaling), then a second core would help very little. If your brick-carrying kept being interrupted by a traffic cop (disk or memory bottlenecks) then one core might run as fast as two. But in general-- two cores run multiple threads faster than one.

    Get it now? I rather doubt it...but hope springs eternal to the human breast.

    > "if you only move one brick at a time then adding a second person (also capable of moving one brick) will show 100% scaling."

    Read my explanation above...then take your foot out of your mouth. This statement is the very reason for multicore processors. One core moves one brick at a time. Period.

    > "Since adding a second core does not change memory bandwidth or disk access time I don’t know why you even brought this up, as its irrelevant. "

    Again, you fail to understand the most basic concepts. An "app" that does nothing but copy a large file from A to B is disk-bound. Add two cores or a hundred, and it won't speed up. That's why this is relevant.

    Of course, no app or benchmark is ever 100% disk-bound. But the faster the processor, the more impact a bottleneck will have. An infinitely fast single-core cpu will not run apps in zero time...it'll just spin, waiting for memory or disk. And adding a second core to such a cpu won't yield any gain...BECAUSE of the bottleneck.

    Get it now?

    Of course, our scenario of "Multitask Benchmark 1" and the A64 3800 isn't even close to this scenario. I only mentioned it to discount it, as it was the only quasi-reasonable explanation you could have believed the drivel in your first post. I see otherwise now...you were simply wholly and utterly clueless from the start.

  • justly - Wednesday, August 3, 2005 - link

    Since you seem to believe that we should see an improvement in any multitasking test no matter how simple those tasks are explain this.

    If we know that adding a second core will increase performance (as indicated by 9.1% increase of the duel core PD over a single non-HT P4 for the test in question) then why does the AMD duel core show no increase in performance?

    It can’t be that the AMD duel core is not functioning, because we can tell that it is functioning based on all the other tests.

    Since this IS a multitasking benchmark (as you made sure to point out) maybe you would like a stab at this question also.

    How is it that a duel core PD at 3.0GHz it is still not able to beat (or even match) a single core AMD at 2.0GHz?
    It’s not like this test was designed to cripple an Intel processor (this test runs “files copy in the background while the script runs Microsoft Outlook and Internet Explorer in the foreground”).
  • fitten - Thursday, August 4, 2005 - link

    Please stop using "duel" and use the proper term "dual". Continued use of "duel" when talking about "dual cores" pretty much erodes anything else you will possibly say.
  • masher - Wednesday, August 3, 2005 - link

    > "If we know that adding a second core will increase performance...why does the AMD duel core show no increase in performance? ...It can’t be that the AMD duel core is not functioning..."

    Easy question. Why? Because some resource in contention between the two cores is negating whatever slight gain the second core can offer.

    Your notion that a second core that works in ANY case has to work in ALL cases is terribly misinformed. Consider Intel's HT for instance. Two virtual cores...but given they share so many resources between them, there are many cases where HT not only shows no performance gain, but an actual performance drop.

    It's less common with two physical cores, or even two physical processors...but it can and DOES happen. Intentionally writing code that runs slower on a duallie (even 100X slower) is easy. Writing it accidentally is very possible as well.

    Now here's the part you actually have to use your brain to understand. Take a deep breath and think before reading on. There are implementation differences between AMD and Intel's dual core designs. That means they share different resources, and to differing degrees. Meaning a program that causes some slight contention on Intel may cause more on AMD...or may cause none at all. Whereas different code may contend in totally different areas, and show a totally reverse pattern.

    Starting to make sense to you?


  • masher - Monday, August 1, 2005 - link

    The statement says "comparing AMD to the Intel Dual Cores". Multitask 1 has Intel averaging (9.1+2.3)/2=5.7% better than AMD. Multitask 2 has AMD averaging 14.4 - (13.9+9.1)/2 = 2.3% better than Intel.

    So Anand is calling a 5.7% Intel advantange "slight" but a 2.3% AMD advantage "significant".

    Toss out the Intel Dual Core + HT row -- a fairer comparison in my opinion) and Intel does even better. Add in the non-dualcore Intel row and Intel does better on MT1 and worse on MT2...but not even the most strident AMD fanboy could call that a fair comparision.
  • NullSubroutine - Monday, August 1, 2005 - link

    Not to take sides, but this was just comparision of AMD singc vs AMD dualc % vs Intel singc vs Intel dualc. The performance advantage wasnt direct comparison of AMD's dual core vs Intel's dual core. Disreguard if you understood this, but to simplify the explantion. Say AMD single core has benchmark of 100, Intel single core (/w ht lets say) is 90; then AMD dual core (same cache/mhz) has benchmark of 120 (20% increase) while Intel Dual core was 115 (27.7*% increase). Showing Intel's second core gave 7.7*% more power vs AMD's second core over its first. The purpose of this comparison was to try to find a benchmark (since none seem to be known to the author at this time) to see whose dual core implimentation is more "effiecent". Also possible the author, when describing "significant" or "slight" he did not seem to be averaging their numbers between ht and no ht, but simply sticking with one, at least I would assume this to be the case.
  • Houdani - Monday, August 1, 2005 - link

    OK, you averaged the dual scores (HT and no-HT) to get your numbers. I'm good with that.

    Regardless, it's moot now since Anand subsequently revised his statement to remove the inkling of bias. (He left a typo too -- tried to get rid of "a lot" but forgot to remove the "a")
  • BornStar18 - Monday, August 1, 2005 - link

    The interesting part of his statement is the fact that the AMD Dual Core actually beats the Intel Dual Core in MMCC Winstone. I agree though that a 9.1% improvement is more than slightly better than 0%.
  • GhandiInstinct - Monday, August 1, 2005 - link

    "Ah, ah, ah, you didn't say the magic word."

    AMD and ATi, FTW.

    http://nedry.ytmnd.com/">Source

Log in

Don't have an account? Sign up now