AMD Chip Rapes Intel C2Duo discussion

[Defenestration]

It does also appear to apply to desktops. See the following for more info:

http://forum.notebookreview.com/showthread.php?t=60416

http://www.laptopvideo2go.com/forum/...howtopic=10272

[ikonia]

I'm not using windows, so those patches don't apply to me.

While the hard disk file systems are not identical they are all running on pretty much %0 fragmentation and all on WD Raptors.

Directhex the xvid codec does support threads, and I'm using the threads=2 option (I've also tried to flood both cores with thread=4. I'm just finishing this lastest session of ripping and then I'll actually set some time aside to do some test rips and play with some options.

Clunk - if you offer some advice on the AMD box, I'll be happy to run your benchmarks at stock and over clocked

[Defenestration]

Are you running kernel 2.6.22 or later with the new SLUB allocator enabled ?

[CrazyMonkey]

The C2D is bought to overclock You could wack it up and rape the AMD?

However at stock i am not suprised.

EDIT: Have you tried encoding larger pieces of video on both machines, perhaps the tides may change with a longer length of video.

[ikonia]

Are you running kernel 2.6.22 or later with the new SLUB allocator enabled ?

tried it with and without and tried it a slightly earlier version too, makes no different to the outcome.

[ikonia]

The C2D is bought to overclock You could wack it up and rape the AMD?

However at stock i am not suprised.

EDIT: Have you tried encoding larger pieces of video on both machines, perhaps the tides may change with a longer length of video.

I'm quite surprised at this to be honest.

as the mass market won't overclock so this technology must be ssen as "better" at stock value for it to shift the volume it has and earn the reputation it has.

[GSte]

I'm quite surprised at this to be honest.

as the mass market won't overclock so this technology must be ssen as "better" at stock value for it to shift the volume it has and earn the reputation it has.

It is better at stock value.... you have found what must be one of the only situations in which it isn't

[Dorza]

This is probably a pointless post since if your a LFS user you will probably know this and I maybe showing a lack of understanding/knowledge on the issue at hand, but I'll say it anyway....Is the system optimized for the Core 2 architecture or as close to it as possible, as with gentoo you tell the gcc compiler to optimize the programs you are compiling for use with CPU architecture, so you can get the most out of the CPU.

Currently the gcc compiler doesn't have core 2 support iirc so the previous most suitable architecture should be used instead.

[Biscuit]

The fact these questions can even be raised makes me smile and cuddle my opty 175 in its last few months of loyal service

[ikonia]

This is probably a pointless post since if your a LFS user you will probably know this and I maybe showing a lack of understanding/knowledge on the issue at hand, but I'll say it anyway....Is the system optimized for the Core 2 architecture or as close to it as possible, as with gentoo you tell the gcc compiler to optimize the programs you are compiling for use with CPU architecture, so you can get the most out of the CPU.

Currently the gcc compiler doesn't have core 2 support iirc so the previous most suitable architecture should be used instead.

A very fair post, but 1.) compiler optimisation won't make that much of a difference to whats been shown, and 2.) all of these have generic x86_64 arch none are platform optimised.

[directhex]

A very fair post, but 1.) compiler optimisation won't make that much of a difference to whats been shown, and 2.) all of these have generic x86_64 arch none are platform optimised.

is work definitely spanning cores correctly? try checking with htop (you can enable a PROCESSOR column which shows which core a given thread is using). we've had problems with our altix where jobs haven't used all available cores unless explicitly forced with a tool like dplace

[ikonia]

thats the problem hex, the AMD appears to be splitting the work very effectivly, however the intels don't.

I'm running other tests at the moment to find out if its just this task or if other tasks are not being managed correctly.

[directhex]

this may seem obvious, but you're not using any kind of cpu frequency scaling are you?

[directhex]

okay, looks like a fault in xvid - try doing "mencoder -ovc lavc -oac lavc -lavcopts acodec=mp3:threads=2 -o foo.avi someinput.avi" - cpu load spreads MUCH more evenly with that codec

CPU load with lavc: ~124% (at about 60% of both cores)

CPU load with xvid: ~100% (at about 100% of 1 core)

a mplayer/mencoder svn checkout might behave better, but you know what a pain ./configuring that project is

[directhex]

x264 threads like a dream - ~181%

shame you want mpeg4 part 2, not mpeg4 part 10

[badass]

A very fair post, but 1.) compiler optimisation won't make that much of a difference to whats been shown, and 2.) all of these have generic x86_64 arch none are platform optimised.

Just noticed that.
One hardware site or other compared the befefits of going x86-64 on K8 and Core2 based systems. The AMD system, whilst overall slower both 32 bit and 64 bit, gained a lot more going x86-64 than the Core2 based system.
It did a very good job of closing a lot of the gap going 64 bit.