Relative Access to Execution Throughput Comparison Chart - Overclock.net - An Overclocking Community

Forum Jump: 

Relative Access to Execution Throughput Comparison Chart

Reply
 
Thread Tools
post #1 of 41 (permalink) Old 06-02-2014, 05:08 AM - Thread Starter
New to Overclock.net
 
mdocod's Avatar
 
Join Date: Aug 2010
Location: CO, USA
Posts: 4,265
Rep: 621 (Unique: 408)
Hello OCN.

The following "cheat sheet" can be used to quickly approximate the performance difference between popular desktop CPUs depending on the number of threads the workload presents as.

Execution Throughput is synonymous with Instruction Rate, or IPS (Instruction per Second), or Compute Performance in general. Software executes as a series of instructions/computations. The faster those instructions can be executed, the better the software performs. Not all software produces workloads that scale into an unlimited number of cores, as such, comparing CPU performance can be difficult when most benchmarks either test 1 core or all of the cores of a CPU, but nothing in-between. This "chart" is an attempt to bridge that gap and provide a quick-n-dirty reference to compare CPU performance with the primary variable being the number of threads the computing workload presents as.

The relative performance is a rough average derived from my own testing of some CPUs (K10, K15, Ivy/Haswell) and critical analysis of many 3rd party sources (passmark, openbenchmarking, and CPU reviews). Considerations of actual CPU architecture are also taken into account: ( http://www.agner.org/optimize/microarchitecture.pdf ). The chart does not compare a specific workload, rather, is an approximate average of many possible workloads with the key variable being the number of threads the workload presents. The "scores" in the chart are only relevant and relative to other scores within this same chart. In some cases I have indeed made good faith estimates where I had access to little or no relative data to work with. The chart is not derived of raw synthetics, rather, execution performance in actual software workloads like compiling, compressing, decompressing, trans-coding/encoding, physics, rendering, science/math, CAD, image manipulation, gaming etc. YMMV. Passmark and OpenBenchmarking have been heavily influential here to produce baselines upon which to build the chart from.


The chart has been color coded as follows:

The green region is centered over the most relevant region for consideration in gaming and other real-time workloads, most CAD/engineering software (like Sketchup, AutoCAD, Solidworks), popular photo manipulation software (gimp/A-shop).

The light blue, grey and teal region is centered over the most relevant region for consideration in non-real-time workloads with minimal scaling penalties; 3D rendering, trans-coding, video toasting, compiling, compressing, decompressing, encryption, scientific research, distributed computing projects, mathematical research, etc.

The dark blue row, is a theoretical estimate of relative performance in an enterprise class workload encompassing very high numbers of active threads. This can give some indication of how well the CPU and associated platform will tolerate insane-multi-tasking and/or server class workloads (lots of active VMs, or high traffic hosting) and assumes gobs of system memory to accommodate this theoretical workload. This particular row of entries needs to be considered with lots of room for error as this would vary dramatically depending on the specifics of that brutal workload.


The execution throughput of the 3.0 GHZ Pentium G3220 w/1 thread = 10. This is used as the baseline standard to generate the chart. SMT/CMT/Turbo scaling is included where applicable and the chart assumes proper scheduling of the host OS to scale into SMT/CMT properly.

The chart can be viewed in post #3 of this thread below, or by opening this gif image in another tab/window, or by downloading and viewing the attached pdf or spreadsheet.

Created with GIMP

AproximateRelativeExecutionThroughput.pdf 102k .pdf file


AproximateRelativeExecutionThroughput.xlsx 10k .xlsx file


Myths:

1. "New games are optimized for 8 core CPUs."

Software that has been written and compiled to scale into many threads is not "optimized" for many cores, it is simply able to scale into many cores. There is no significant penalty to execution throughput when running several threads on a core. The only significant important characteristic of a CPU's performance is the availability of execution throughput to the workload. Whether that workload is 2 threads or 20 threads running on a 1 core or 10 core CPU, the resulting performance will be based on the availability of execution throughput to that workload. Being able to use more cores, and being "optimized" for more cores, are two very different things. The latter is based in a fallacy.

The advantage to many-core CPUs, comes into play with the number of active threads is far beyond what any one or several pieces of desktop software would ever benefit from spawning. Any attempt to create a workload that is pushing more and more into that "blue" area of the chart, is only counterproductive to the performance of the software. No game will ever be engineered to spawn 200-300+ active threads. It would be an enormous waste of execution overhead. Having strong CPU performance in that "dark blue" part of the chart, is great for workloads that present themselves that way because there is no alternative (enterprise conditions.)


2. "Consoles have 8 cores now, therefor I should build an 8 core gaming compute to be future proof."

The 8 cores in a console would have a combined score of about "22" in the chart above. (on the "8 threaded workload line). Scheduling optimizations for console hardware will be stripped from software when it is ported. The only remaining consideration will be whether or not the CPU in the desktop has enough combined execution throughput for the game engine after scheduling optimizations are removed and overhead from the loss of HSA is factored in. Whether that is provided via 2 cores or 10 cores is going to be largely irrelevant. As you can see, most desktop CPUs provide more execution throughput than the "8core" found in these consoles. The CPU on the consoles is not technically an 8-core CPU, it's a dual-quad CPU implementation, much like an old core2quad where they took two dual cores and strapped them to the same PCB. This creates performance scaling limitations that require scheduling optimizations to work around. A Jaguar module also suffers MP scaling penalties because it shares an L2 cache across all 4 cores of the module. Best performance for a given thread occurs when the thread is allowed to run solo on the module. Due to these scaling limitations of the platform, it is highly unlikely that console games are actually leveraging all 8 cores in a heavily saturated manner as attempting to do so would come with too many penalties and overheads to be worthwhile. It's actually more likely that they are using scheduler optimizations to throw the toughest 1-2 threads on a jaguar module by themselves, and using the other module for the remainder of the less demanding jobs. Actual saturation probably rarely exceeds 80% of available execution throughput.

By my best estimates, if you build a desktop with at least double the single threaded performance (score of "8+" on the 1 thread workload line), and 50% more combined execution performance (score of 33+ on or below the 8 thread workload line) than the console, it will play console ports just fine. Modern i3's and A8/A10 or better CPUs will prove effective for most console ports. The reason for the requirement of at least "double" the single threaded performance is to makeup for scheduler optimization losses and overhead introduced from the removal of the HSA environment.


3. "Games don't use Hyper-threading / Hyperthreading sucks"

Hyper-threading is very misunderstood. Nearly any workload that does not bottleneck a single thread on the instruction decoders or execution resources of a core can benefit from hyper-threading if it scales into multiple threads, games included. The reason we do not observe performance scaling from hyper-threading in many desktop workloads (especially games) is simply because the workload is not simultaneously parallel and demanding enough to scale into the additional available execution throughput. Most observations are made between the i5 and i7, where the i5 is already providing as much execution throughput via parallelism as the software can leverage anyway. Remember, a real-time workload like a game-engine is always technically being "throttled" by a timeline of events that must adhere to real-time. Even though gaming isn't considered by many to be a "true" real-time workload (like running a feedback loop on a precision machine or robot), it still must adhere to all the same principals and a timeline and order of operations and events. This makes "useful scaling" very difficult beyond a certain number of threads.

Observe the difference in performance between the i3 and Pentium in gaming workloads. HT scaling is very effective in gaming workloads when the availability of execution resources is cut in HALF (2 cores instead of 4 cores on the i5/i7). In fact, almost ALL games scale nicely into hyper-threading when the availability of execution resources forces the issue.


4. CMT scaling is better than SMT scaling.

The available execution resources (pipelines) on any one cycle on a haswell core, is basically the same as the available execution resources on any one cycle on a piledriver module. The number of "pipelines" that can have work scheduled on them simultaneously is effectively the same. (the IPC differences stem primarily from cache latency, cache bandwidth, different instruction penalties, average pipeline length, decoder/scheduling performance, instruction/vector size support, and instruction latency)
The entirety of the execution resources in a haswell core are available to a single thread, while only half of those execution resources are available to a single thread on a piledriver module on any given cycle. When ONLY the scaling is observed as thread count increases or decreases, scaling appears better on CMT. This perspective requires a purposeful ignorance of the starting point of execution throughput to have merit. A far more useful way to observe SMT vs CMT scaling, is how much performance is LOST when dropping from 2 to 1 threads on a core or module, as this is actually a far more relevant consideration for the actual performance of real desktop workloads. CMT has a lot more to lose when the thread count is reduced, because the availability of execution resources is also reduced. SMT does not suffer from any loss in available execution resources when the thread count is reduced. From my perspective, SMT scaling is actually better than CMT scaling, because it provides a higher availability of execution throughput to a wider variety of workloads (highly threaded or not). CMT suffers far greater penalties to poorly threaded workloads. In most cases where CMT scaling shows large scaling, and SMT scalin shows minimal scaling, it is because SMT has already achieved decoder or execution resource saturation without the need of another thread to get there. We "observe" scaling from CMT in these conditions because we are effectively "activating" unused resources that SMT was already leveraging before the second thread was thrown into the mix. In cases where workloads do not scale up on SMT, it is because the ideal saturation of execution or decoder or scheduling resources has already occurred. It's not possible for a single thread to saturate the available execution, decoder, or scheduler resources of a pile-driver module, it is effectively "throttled" by the fact that half of its execution resources are forced to lay dormant until another thread is spun up on the module.

Trying to characterize the premise of CMT "scaling" as an upward benefit is not much different than trying to characterize cylinder deactivation as having horse power advantages. It doesn't. The problem is that so many of these concepts are very cerebral and simultaneously disconnected (we can't get our hands on them or visualize them as part of a working mechanical system), so it's very easy to get lost down a rabbit hole of broken relativity and useless perspectives.

The best way to "see" why I prefer the perspective of CMT as a penalty, and not an upward scaling benefit, is to study the execution throughput chart. When comparing an equal number of SMT cores vs CMT modules, the SMT solution offers the highest availability of execution throughput to the widest variety of workloads, highly threaded or not.


5. You're an Intel Fanboy, obviously! Quit bashing AMD you hater!

The conclusions that one might draw from reading this post, and studying the chart, are that I might be here to "prove" that Intel is better than AMD. The chart certainly shows that at this time, Intel is offering a lot of CPUs at competitive prices that offer higher execution performance to the "sweet spot" for most mainstream desktop builders at this time.

Consider the inverse, if I "knew" this "stuff" about CPUs, and chose NOT to share it, then by any standard that makes me an Intel fanboy for sharing it, I would be an AMD fanboy for choosing to sweep it under the rug and keep it to myself. The chart, and my "mythbusters" would be the same whether under a rug or here on the forum.

My concern, is CPU vs CPU, performance, features, cost. There's more to a CPU than the chart in this thread. Don't forget about support for specialized instructions, or platform capabilities like IOMMU. At this time, Intel solutions are better for 80-90% of desktop builds due to the intended use of those builds and the performance characteristics of the Intel solutions available to fit the budget of those 80-90% of builds. This doesn't mean that Intel is "better," It means that Intel CPUs are better for most applications for the money right now. Intel could have run over my dog and I would still have to admit that their CPUs are the better solution for most builds right now.



Enjoy and happy tuning/building!
Eric

A CPU performance comparison chart.

"Kind of a ring thing, comes with a dialer, you hit the symbols, it spins around and lights come on, it kind of flushes sideways" -O'Neill
mdocod is offline  
Sponsored Links
Advertisement
 
post #2 of 41 (permalink) Old 06-02-2014, 07:29 AM
Overclock Failed...
 
billbartuska's Avatar
 
Join Date: Mar 2005
Location: Greater Chicagoland Area
Posts: 13,565
Rep: 1249 (Unique: 969)
Wow. Great work.

Would you post the spreadsheet.?
I like to look at stuff graphically.

https://www.overclock.net/images/smil...lame-small.gif5 GHz Overclock Club https://www.overclock.net/images/smil...lame-small.gifMisinformation is available from a variety of other sources. Misinformation is just like real information but wrong
....and enough power to shoot the speaker cones through the walls.
billbartuska is offline  
post #3 of 41 (permalink) Old 06-02-2014, 09:32 AM - Thread Starter
New to Overclock.net
 
mdocod's Avatar
 
Join Date: Aug 2010
Location: CO, USA
Posts: 4,265
Rep: 621 (Unique: 408)













































































































































































































































































































































































































































































































































































































































































































































































































































































































































































































































































































































































































CPU> G3220 G3258 i3-4150 i5-4440S i5-4590 i5-4670K i5-4690K E3-1271V3 i7-4770K i7-4790K
Workload (threads) 3.0GHZ 4.8GHZ 3.5GHZ 2.8/3.3GHZ 3.3/3.7GHZ 4.4GHZ 4.8GHZ 3.6/4.0GHZ 4.4GHZ 4.8GHZ
256 10 16 19 28 33 44 48 52 63 69
16 16 26 26 36 43 57 63 60 74 80
12 17 27 27 37 43 58 63 60 74 81
8 18 29 28 37 43 58 63 61 74 81
7 19 30 28 37 44 58 63 58 70 77
6 19 30 29 37 44 58 63 55 67 73
5 19 31 29 37 44 58 64 52 63 69
4 20 31 29 37 44 59 65 48 60 65
3 20 32 26 29 35 44 48 38 45 49
2 20 32 23 21 24 30 32 26 30 32
1 10 16 12 11 12 15 16 14 15 16






















CPU> G2020 i3-3220 i5-3470 i5-3570K i7-3770 i7-3770K E5-1650V2 i7-4930K E5-1650 i7-3930K
Workload (threads) 2.9GHZ 3.3GHZ 3.2/3.6GHZ 4.4GHZ 3.4/3.9GHZ 4.4GHZ 3.5/3.9GHZ 4.8GHZ 3.2/3.8GHZ 4.8GHZ
256 9 16 29 39 44 57 75 103 65 98
16 14 22 37 52 51 66 79 109 69 103
12 15 23 38 52 51 67 79 109 69 104
8 16 23 38 52 51 67 69 94 60 90
7 16 24 38 52 49 63 66 91 58 86
6 17 24 38 53 46 60 64 87 57 83
5 17 24 38 53 44 57 55 73 49 69
4 17 25 38 53 41 53 45 58 40 55
3 17 22 30 40 34 40 34 44 31 41
2 17 20 21 26 23 27 24 29 21 28
1 9 10 11 13 12 13 12 15 11 14






















CPU> G640 I3-2100 i5-2400 2500K 4.8G i7-2600 i7-2700K i7-970 970 4.0G i5-750 C2Q 8400
Workload (threads) 2.8GHZ 3.1GHZ 3.1/3.4GHZ 4.8GHZ 3.4/3.8GHZ 4.8GHZ 3.2/3.46GHZ 4.0GHZ 2.66/3.2GHZ 2.66GHZ
256 8 15 27 41 42 59 49 61 17 13
16 13 20 35 54 48 68 54 67 22 19
12 14 21 35 54 49 69 55 67 23 20
8 15 21 35 55 49 69 47 58 23 21
7 15 22 35 55 46 66 45 56 23 21
6 15 22 36 55 44 62 43 54 23 22
5 15 22 36 55 41 59 36 45 23 22
4 16 22 36 55 39 55 30 36 23 22
3 16 20 28 41 30 41 23 27 18 18
2 16 18 19 28 21 28 16 18 13 13
1 8 9 10 14 11 14 8 9 7 7






















CPU> A10-7700K A10-7850K Sempron 3850 Athlon 5350 A4-6300 A6-6400K A8-6500 A10-6800K FX-4300 FX-4350
Workload (threads) 3.4/3.8GHZ 4.4GHZ 1.3GHZ 2.05GHZ 3.7/3.9GHZ 4.8GHZ 3.5/4.1GHZ 4.8GHZ 3.8/4.0GHZ 4.8GHZ
256 22 28 3 4 3 4 15 21 21 26
16 29 38 7 9 8 10 21 29 25 32
12 30 39 8 11 9 11 22 30 25 32
8 30 39 9 13 10 12 23 31 25 32
7 30 39 10 13 10 13 23 32 26 32
6 31 40 10 14 10 13 23 32 26 33
5 31 40 10 14 11 14 23 32 26 33
4 31 40 10 14 11 14 23 32 26 33
3 24 30 8 11 11 14 18 25 20 26
2 17 20 6 8 11 15 15 18 15 18
1 9 10 3 5 7 9 8 9 8 9






















CPU> FX-6300 FX-6350 FX-8320 FX-8320 FX-8350 FX-8350 FX-9590 FX-9590 FX-4100 FX-4170
Workload (threads) 3.5/4.1GHZ 4.8GHZ 3.5/4.0GHZG 4.4GHZ 4.0/4.2GHZ 4.8GHZ 4.7/5.0GHZ 5.2GHZ 3.6/3.8GHZ 4.8GHZ
256 30 42 43 54 49 59 58 64 17 23
16 35 48 47 59 54 65 64 71 21 28
12 35 49 47 59 55 65 64 71 21 28
8 36 49 48 60 55 66 64 71 22 29
7 36 49 42 53 49 58 57 63 22 29
6 36 49 37 47 43 51 50 55 22 29
5 31 42 32 40 37 44 43 48 22 29
4 25 34 27 34 31 36 36 40 22 29
3 20 27 22 25 25 27 27 30 17 23
2 15 18 15 17 16 18 19 20 13 16
1 8 9 8 8 8 9 10 10 6 8






















CPU> FX-6100 FX-6200 FX-8120 FX-8150 P II X4 955 P II X4 970 P II 1055 P II 1090T A II X4 640 A10-3870K
Workload (threads) 3.3/3.9GHZ 4.4GHZ 3.1/4.0GHZ 4.8GZ 3.2GHZ 4.0GHZ 2.8/3.3GHZ 4.0GHZ 3.0GHZ 3.6GHZ
256 26 34 34 53 20 24 29 41 15 19
16 30 39 38 58 26 32 34 48 21 25
12 30 39 38 58 26 32 34 48 22 26
8 30 40 38 58 26 32 34 48 22 27
7 30 40 34 52 26 32 34 49 23 27
6 30 40 31 45 26 32 34 49 23 28
5 26 34 28 39 26 32 28 40 23 28
4 21 28 25 32 26 32 23 32 24 28
3 18 22 19 24 20 24 18 24 18 21
2 13 15 13 16 13 16 13 16 12 14
1 7 7 7 8 7 8 7 8 6 7





A CPU performance comparison chart.

"Kind of a ring thing, comes with a dialer, you hit the symbols, it spins around and lights come on, it kind of flushes sideways" -O'Neill
mdocod is offline  
Sponsored Links
Advertisement
 
post #4 of 41 (permalink) Old 06-02-2014, 12:01 PM
Overclock Failed...
 
billbartuska's Avatar
 
Join Date: Mar 2005
Location: Greater Chicagoland Area
Posts: 13,565
Rep: 1249 (Unique: 969)
No, I have the graphic, but I'm just to lazy to go through One Note > Word > Excel to pull the numbers out of it.
Please post the Excel file as an attachment, if you would.

Thanks.


https://www.overclock.net/images/smil...lame-small.gif5 GHz Overclock Club https://www.overclock.net/images/smil...lame-small.gifMisinformation is available from a variety of other sources. Misinformation is just like real information but wrong
....and enough power to shoot the speaker cones through the walls.
billbartuska is offline  
post #5 of 41 (permalink) Old 06-02-2014, 12:14 PM - Thread Starter
New to Overclock.net
 
mdocod's Avatar
 
Join Date: Aug 2010
Location: CO, USA
Posts: 4,265
Rep: 621 (Unique: 408)
Excel, right wink.gif

See link in fist post for updated spreadsheet.

I understand now what you mean "graphically."

You mean you want to CHART/GRAPH it. I was like, waaaa? How is a PNG not graphical?

I hadn't even thought of that. Good idea.

Well now it's on here as a PNG, an HTML spreadsheet, AND an xlsx. Sweet.

A CPU performance comparison chart.

"Kind of a ring thing, comes with a dialer, you hit the symbols, it spins around and lights come on, it kind of flushes sideways" -O'Neill
mdocod is offline  
post #6 of 41 (permalink) Old 06-02-2014, 12:20 PM
Retired Staff
 
Join Date: Nov 2006
Location: NJ
Posts: 65,144
Rep: 4426 (Unique: 2045)
Quote:
SMT/CMT/Turbo scaling is included where applicable and the chart assumes proper scheduling of the host OS to scale into SMT/CMT properly.

What's the workload you are using? This has major impact on the benefits of SMT/CMT.

To answer most of your questions: (1) a fridge cannot cool a PC (2) 64-bit OS for over 3.4GB (3) If a PCIe card fits, it should work (4) Resolution, not screen size (5) Report, not respond to Spam (6) Single-Rail/Non-Modular PSUs are not always better than Multi-Rail/Modular (7) Sequential does not matter as much as random for OS drives (8) Requirements come before hardware for servers

DuckieHo is offline  
post #7 of 41 (permalink) Old 06-02-2014, 12:36 PM
Overclock Failed...
 
billbartuska's Avatar
 
Join Date: Mar 2005
Location: Greater Chicagoland Area
Posts: 13,565
Rep: 1249 (Unique: 969)
Quote:
Originally Posted by mdocod View Post

Excel, right wink.gif

Well now it's on here as a PNG, an HTML spreadsheet, AND an xlsx. Sweet.

U Da Man!

https://www.overclock.net/images/smil...lame-small.gif5 GHz Overclock Club https://www.overclock.net/images/smil...lame-small.gifMisinformation is available from a variety of other sources. Misinformation is just like real information but wrong
....and enough power to shoot the speaker cones through the walls.
billbartuska is offline  
post #8 of 41 (permalink) Old 06-02-2014, 01:09 PM - Thread Starter
New to Overclock.net
 
mdocod's Avatar
 
Join Date: Aug 2010
Location: CO, USA
Posts: 4,265
Rep: 621 (Unique: 408)
Hi DuckieHo,

The relative performance is determined using a constant assumed ideal scaling for SMT/CMT . The chart is built using +25% and +80% scaling for SMT and CMT respectively when going from 1 thread per core/module to 2 threads per core/module. My intention was to give each technology a decent representation. There will be cases where the constant used to build this chart will be far from accurate if specific workloads are considered.

Regards,
Eric

A CPU performance comparison chart.

"Kind of a ring thing, comes with a dialer, you hit the symbols, it spins around and lights come on, it kind of flushes sideways" -O'Neill
mdocod is offline  
post #9 of 41 (permalink) Old 06-02-2014, 08:56 PM
Retired Staff
 
Join Date: Nov 2006
Location: NJ
Posts: 65,144
Rep: 4426 (Unique: 2045)
Quote:
Originally Posted by mdocod View Post

Hi DuckieHo,

The relative performance is determined using a constant assumed ideal scaling for SMT/CMT . The chart is built using +30% and +80% scaling for SMT and CMT respectively when going from 1 thread per core/module to 2 threads per core/module. My intention was to give each technology a decent representation. There will be cases where the constant used to build this chart will be far from accurate if specific workloads are considered.

Regards,
Eric

So what is the workload? Does it stress FP32, FP64, INT, L1/L2 cache, ect?


You are using an arbitrary scaling factor for SMT and CMT? It would be vastly more useful to provide the raw values and note the potential of scaling.

To answer most of your questions: (1) a fridge cannot cool a PC (2) 64-bit OS for over 3.4GB (3) If a PCIe card fits, it should work (4) Resolution, not screen size (5) Report, not respond to Spam (6) Single-Rail/Non-Modular PSUs are not always better than Multi-Rail/Modular (7) Sequential does not matter as much as random for OS drives (8) Requirements come before hardware for servers

DuckieHo is offline  
post #10 of 41 (permalink) Old 06-03-2014, 02:41 AM
New to Overclock.net
 
Undervolter's Avatar
 
Join Date: Mar 2013
Posts: 4,580
Rep: 520 (Unique: 256)
Quote:
Originally Posted by mdocod View Post

Software that has been written and compiled to scale into many threads is not "optimized" for many cores, it is simply able to scale into many cores. There is no significant penalty to execution throughput when running several threads on a core. The only significant important characteristic of a CPU's performance is the availability of execution throughput to the workload. Whether that workload is 2 threads or 20 threads running on a 1 core or 10 core CPU, the resulting performance will be based on the availability of execution throughput to that workload.

You 're probably right, but i think the nature of software is relevant also and influences the result. I am a bit familiary with x264 for instance. I had done in the past my own experiment with thread number and it's known that it has impact on performance.

Examples:

http://forum.doom9.org/showthread.php?t=146667

http://forum.doom9.org/showthread.php?t=166729

Even 0.5 fps difference, is considerable in a time consuming process like HD video encoding. I am too lazy to repeat it again, but i had seen differences myself in 1090T using this, which is obsolete now, but it is the easiest GUI enabled software to change manually thread number.

http://sourceforge.net/projects/asxgui/

See also here how FX performs better on some multithreaded software than on others:

http://www.anandtech.com/bench/product/287?vs=698

(x264 is widely accepted as one of the real world (non bench) software that can scale as perfectly as possible with cores and has no favourable coding bias in favour of AMD. The dev himself, uses Intel). At some point, i remember clearly, that x264 had maximum thread number 128, but the "auto" setting never uses anything near that.

Observe also how Dragon Age Origins (that on my FX6300 hits 100% load on all 6 cores), shows the FX lagging behind the Intel, while the FX beats the Intel in 7zip and x264. Scaling from scaling is different, according to the nature of software and dev. Seems game developers, don't want to sweat much in order to scale well their games... And Dragon Age is actually an example of laudable effort. Most games simply don't care to do a good job in programming, so they scale poorly. What AMD fans have been complaining about, is exactly the fact that games don't seem coded to scale well (as x264 or 7zip is), with the result, that even in most games AMD performs much worse than Intel.

I think that in general, you are right. However, there are certain limitations inherent to each software that may cause different behaviour.

We are probably say the same thing,but my english isn't of high enough level to follow your wording properly.

Ryzen 2600 - MSI B450 Gaming Plus - 16GB Corsair 3000Mhz C15 - GTX 750Ti
Undervolter is offline  
Reply

Quick Reply
Message:
Options

Register Now

In order to be able to post messages on the Overclock.net - An Overclocking Community forums, you must first register.
Please enter your desired user name, your email address and other required details in the form below.
User Name:
If you do not want to register, fill this field only and the name will be used as user name for your post.
Password
Please enter a password for your user account. Note that passwords are case-sensitive.
Password:
Confirm Password:
Email Address
Please enter a valid email address for yourself.
Email Address:

Log-in



Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools
Show Printable Version Show Printable Version
Email this Page Email this Page


Forum Jump: 

Posting Rules  
You may post new threads
You may post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are Off