Dual-core report

[KimB]

Well, I finally got my system working to satisfaction. Overclocked the 2GHz X2 3800+ up to 2.4GHz with no issues (I could probably go higher, but a 20% overclock is perfect for memory and hypertransport clocks).

Had a few problems getting it started (see my other thread), but now that it's running, the performance is just great. (Edit: Erroneous Doom3 performance removed)

Also Cedega seems to work a bit better with dual-core. For example, Fallout 2 had this problem where the fade-in/fade-out that the game does took forever before (during fade-in/out, X was taking up 50% of the processor). Now with dual-core, and the right settings, the game plays great.

Anyway, really exciting stuff. Can't wait to try some fun things like recording TV while playing a 3D game

Anybody got any games they'd like me to bench? Don't have a huge selection, so preferably games that come with demos...

 

[Richard]

Doom3, for instance, jumped up in performance 23% from my old Athlon 64 3000+ overclocked to 2.16GHz (note: 2.4Ghz is only about 11% faster, so Doom3, or nVidia's drivers, or something, is using more than just one core).

IIRC, by default D3 splits off the sound mixing into a separate thread, which seems far too inconsequential for that performance difference.

 

[jvd]

is it a socket 754 athlon 64 ? If so that can explain it

 

[davefb]

any chance of some 'development' benchmarks.. stuff like compiling under visual-studio.. or if you have it , some benchies of intellij .

would love to be able to justify getting dual core on the basis of "compiles my work 2ce as fast"

 

[KimB]

is it a socket 754 athlon 64 ? If so that can explain it

Nope, just upgraded from a socket 939 3000+.

 

[KimB]

any chance of some 'development' benchmarks.. stuff like compiling under visual-studio.. or if you have it , some benchies of intellij .

would love to be able to justify getting dual core on the basis of "compiles my work 2ce as fast"

Well, only problem with this is that I didn't test this previously. I do know that in Linux, at least, only one core was used when I was compiling the kernel.

If you can find a way to manage to split your compilation into two roughly equal-length jobs, of course, and just run them at the same time you'll cut your compilation time in half. But that wouldn't be an easy thing to do.

 

[mczak]

Well, only problem with this is that I didn't test this previously. I do know that in Linux, at least, only one core was used when I was compiling the kernel.

If you can find a way to manage to split your compilation into two roughly equal-length jobs, of course, and just run them at the same time you'll cut your compilation time in half. But that wouldn't be an easy thing to do.

That is very easy for the linux kernel, just do a make -jX (X being the number of threads, fastest results usually X = nr of cpus + 1 or so).

 

[KimB]

That is very easy for the linux kernel, just do a make -jX (X being the number of threads, fastest results usually X = nr of cpus + 1 or so).

Oh, cool, I'll have to remember that

Anyway, used the Windows task manager to check CPU usage under some different apps. Oddly enough, I don't see much of any usage of the CPU when Doom3 is running its demo, so unless the performance increase is entirely due to one CPU being dedicated to Doom3 and not having to switch threads, there's something else that I changed inadvertently.

3DMark05, however, did exhibit some significant usage of the second CPU, but only in the CPU tests. This makes sense to me, because I think the CPU usage tests use software vertex shaders, and since DirectX runs in a separate thread from the game, this would make use of the second CPU.

However, the hardware-accelerated tests made almost zero usage of the CPU, but they didn't fully make use of one CPU either so it's no big loss. Attached is a shot of the task manager after running 3DMark.

 

[KimB]

Update on Doom3:
Turns out I did change something without realizing it: AA was disabled. Now performance hardly changed at all, but the game doesn't seem to be CPU-bound, either (one CPU was only utilized about 85% or so).

UT2004, however, seems to make some use of the second processor. It's not CPU-bound on one processor, but it's making use of the second, to the tune of 15%-20%.

 

[KimB]

any chance of some 'development' benchmarks.. stuff like compiling under visual-studio.. or if you have it , some benchies of intellij .

would love to be able to justify getting dual core on the basis of "compiles my work 2ce as fast"

Alrighty, finally found a reasonably-large piece of source that I could compile with MSVC, the Quake2 source. Unfortunately, CPU usage never passed 50% while the code was compiling, so it doesn't look like MSVC makes use of multiple processors (at least, not by default....).

 

[Pete]

Chal, could you try benchmarking UT2004 and Half-Life 2 (or another game that allows you to disable sound) with and without sound? I'm curious if you'll see the same performance drop enabling audio that TR did. I also see a 10-15% drop enabling Soundstorm-based audio in all my (painfully) CPU-limited CSS demos.

To disable sound in HL2, add "-nosound" to the command line. I'm sure UT2004 has a similar switch.

 

[KimB]

Sorry, don't have HL2, but I can try UT2004 for ya.

 

[Pete]

Thanks, I'd appreciate it. (It happens to tie in with the farcical aquatic poll in the X-Fi thread, too.) I don't expect an improvement, in keeping with the apparent single-threadedness of most games, but who knows?

 

[KimB]

Well, here's what I did:
I recorded a demo in Deck17 with 32 bots on Average, max set at 40 kills.

With sound I got 64.8 fps
Without sound I got 69.5 fps

I'll try it at low res without FSAA/aniso in a sec.

Edit: Turned off BOINC and updated benchmark results

Edit 2: Heh, guess the benchmark was already completely CPU-limited. I was at 1280x960 with 2x AA and 16-degree anisotropic (this is with a GeForce 6600 GT). Here are the results at 640x480, no AA, no aniso:
With sound: 65.8 fps
No sound: 70.0 fps

Anyway, the rather intense benchmark and accelerated speed (demo was recorded at 25fps) really put a lot of stress on the audio, so I expect this is rather an extreme benchmark for sound.

 

[Pete]

Thanks, Chal. I *think* it was Anandtech that showed UT2K3/4 benefitted greatly from discrete, hardware-accelerated sound (something like 60 vs. 80fps), but maybe I'm mistaken.

Edit: It appears I am.

Still hurts to see a 2.4GHz dual A64 is CPU-limited.

 

[Saem]

Compilation tends to be IO bounds quite a bit of the time, compiling with j3 and even j4 on a single core machine makes a fair bit of differences in terms of performance. For dualcore, you might want to think more in the line of j5 or j6, play around with it.

 

[Rys]

Compilation tends to be IO bounds quite a bit of the time, compiling with j3 and even j4 on a single core machine makes a fair bit of differences in terms of performance. For dualcore, you might want to think more in the line of j5 or j6, play around with it.

Just to back this up, Saem is right. You want to use pipes for intermediate communication when compiling, to remove writes to disk as much as poss, and bump up the number of compilation threads to more than 3 or 4.

 

[Saem]

Whoops completely forgot about pipes instead of using files.

 

[KimB]

Oh, cool, didn't realize that the -jX compiler option is a general option. Just tested it out on my own code, and compilation time was nearly halved between single-threaded and -j4. Very nice, thanks

Edit: Compile times seem to reach a minimum at about 3-4 threads with two cores, btw.

 

[KimB]

Hey, guys, found another program that makes great use of multi-core:
XMPEG, using DIVX encoding. I'm typically running about 80% CPU utilization with XMPEG running. Looks like a 2-pass encode of Sin City will take a total of about 1:20 (with high quality iDCT and stuff).