Featured Articles

Microsoft officially announces the Xbox One

Microsoft officially announces the Xbox One

As announced earlier, Microsoft has now finally unveiled its next-generation console, the Xbox One. Although it did not shed much light…

More...
AMD poaches more Nvidia talent

AMD poaches more Nvidia talent

AMD has apparently managed to grab yet another high-ranking Nvidian, but this time it was no engineer or developer.

More...
Qualcomm and Samsung overtake AMD

Qualcomm and Samsung overtake AMD

It’s no secret that the mobile boom is taking a toll on makers of PC components and AMD is one of…

More...
Nvidia Geforce GTX 780 detailed

Nvidia Geforce GTX 780 detailed

We managed to confirm the full spec of the upcoming Nvidia Geforce GTX 780 graphics card as well as some performance…

More...
HIS iCooler Turbo HD 7790 reviewed

HIS iCooler Turbo HD 7790 reviewed

Today we’ll take a closer look at a factory overclocked HD 7790, courtesy of HIS. The HIS HD 7790 iCooler Turbo…

More...
Frontpage Slideshow | Copyright © 2006-2010 orks, a business unit of Nuevvo Webware Ltd.
Tuesday, 25 November 2008 15:05

Gigabyte's EP45-UD3P does well - 5 Benchmarks

Written by Eliot Kucharik

Image Image

Review: Stylish in blue and a good all rounder



Benchmarks:

Please note that different bios revisions may give different results. All benches are done with AUTO settings without altering any BIOS option besides CPU VCore, NB VCore and FSB Termination Voltage.


x264:
x264 is a h.264/AVC codec which supports four threads, and it's available for free. We took a PAL episode of "Babylon 5" with a length of 41 minutes, 57 seconds and 8 frames. We tried to "emulate" the most common usage when you encode your movies:

1st: We have a perfect master, so we only de-interlace the content and resize it without any other manipulations; we marked this as "fast."

2nd: You get bad mastering on many DVDs, especially "old" stuff or when the studios are in a hurry for the release. In this case you want to improve the picture quality, which is done by filtering the content. You can choose from lots of filters for any purposes you can think of, but we only used the most common "undot," "FluxSmooth" and "MSharpen." Of course, we also de-interlaced, filters were done before any resizing took place (which is slower). We marked this as "slow."

Image

Image
Note: The DFI P35 mainboard doesn't support half multipliers, so we used 417x8.

As you can see, the P45 chipset is slower compared to the P35, but the differences are very small and you won't notice them.

LameMT:
The same episode we encoded we used for our MP3-testing. We don't recommend using MP3 for encoding, because AC3 can do the job better, but nearly 42 minutes gives us approximately the length of any given album.

A measurement in seconds, as many sites do, is useless, because the differences are too small. So, we used the built-in play/CPU ratio, this means the CPU is encoding x-times faster then the track-length. Fast memory does not play an important role here. For your convenience we also show the single-threaded benchmarks figures, they can be re-produced with any version of L.A.M.E. Only LameMT can do multi-thread and take advantage of multi-core processors.

We used this setting: lamemt --vbr-new -q 2 -V 2 -m j --strictly-enforce-ISO --resample 48

Image

Image
Note: The DFI P35 mainboard doesn't support half multipliers, so we used 417x8.

Same as x264, P45 is slower again, but nothing you should worry about.

(Page 5 of 6)
Last modified on Wednesday, 26 November 2008 17:43
blog comments powered by Disqus

To be able to post comments please log-in with Disqus

 

Facebook activity

Latest Commented Articles

Recent Comments