Ashes of The Singularity DX11 vs DX12 - R9 Nano

[Fjodor2001]

Why it is not fair? Consumers and oems don't have much of a choice except to make this unfair comparison if they want to buy processors today. People also made the same comparison in the past, that's why AMD decided to discontinue the development of the Bulldozer family.

Read my subsequent posts. I've already explained it.

 

[Raftina]

It well known that Linux is just a more compact, more efficient OS than Windows. The 64 bit version of Linux generally only needs 5-7 GB of hard drive space for the entire OS versus about 20+ GB for a Windows 64 bit install.

Putting aside the loose correlation between code efficiency and disk usage and how much a distro's package selection affects install footprint, your install footprint comparison does not compare the same things.

Windows 64 bit has about 10 GB of files on a fresh install. The other 10+ GB comes from the fact that Windows creates a page file and a hibernation file under the system partition. The size of the page file scales with RAM, because it exists to hold information paged from RAM to the storage when it becomes desirable to move information out of RAM. The size of the hibernation file also scales with RAM, because it stores information from RAM when the system powers down but needs to start from where it left off. They are separate files, because Windows uses kernel state stored in the hibernation file to reduce boot time. In a 8 GB RAM system, these files push C:\ over 20 GB.

Linux does something very similar, except it uses a swap partition that's separate from the root partition, and the swap partition is used for both swapping and hibernation, so there's no persistence of hibernation information if a large amount of swap occurs. By default, the easy to use Linux distros reserves a swap partition that's the same size as the RAM installed. In a 8 GB RAM system, the swap partition will take 8 GB.

You can disable the page file, hibernation file, and swap space. The real space consumption comparison is about 6 GB for a GNOME or KDE install vs a 10 GB Windows install.

It is more compact you are right there,it is more compact because it lacks everything,no API for graphics no net framework no visual c no nothing that can improve performance,if you only need straight up x86 code then sure I guess it might be a bit faster if it runs less background stuff.

Surely you jest. OpenGL, glibc, GNU itself. One reason Linux has such a small install footprint compared to Windows is because Linux packages share libraries much more than Windows programs, and distro maintainers deliberately compile packages so that they share the same versions of dependencies.

 

[DrMrLordX]

You're comment is correct, but it was not the subject my post brought up, nor the point of it. Instead, this was my point:

But you said it was unfair for people to compare Piledriver CPUs to Skylake or Haswell. It isn't unfair. AMD stayed frozen in time, while Intel did not (not that Intel has been making great leaps in performance either, but still).

Continually comparing Bulldozer or Piledriver CPUs to Sandy Bridge on newer and newer generations of software only holds so much interest. Eventually, we are going to want to see how it handles on today's hardware.

I.e. maybe the FX CPUs such as FX8350 did not get a fair chance, since the SW available at that time did not make use of its full multi-core potential.

AMD knew what was the software environment of the day just as well as Intel. If anything was "unfair" it was the FMA4/FMA3 switcheroo that Intel pulled (arguably, AMD should have been able to account for that). As far as the AVX/AVX2 split instruction thing goes, if AMD had the willingness and ability to produce their own free compiler alternative to ICC that performed just as well as ICC (if not better), then I'm sure we'd see a lot better support for split AVX and/or xOP in executables compiled in that environment. Fact is, AMD can't even provide that software, much less convince anyone to use it when compiling their code.

Now AMD has not released any 4 Module / 8 Thread follow-up to those CPUs for 3 years. So if we compare it to the latest Intel CPUs, then obviously it will not keep up.

But they have released 2m/4t CPUs, and those don't keep up with Intel's 4c/4t CPUs. Sometimes they don't even keep up with Intel's 2c/4t CPUs.

But that does not say much about how competitive it could have been at the time of release, if different SW had been available back then. To figure that out, the FX8350 will have to be compared to the Intel CPUs available back then, but with the latest SW.

Sorry to have to say it this way, but most people don't care about hardware from 2011/2012 anymore, unless they're holding on to 2500k or 2600k CPUs and bragging about how they're "still relevant" or what have you.

Finally, the good that has come out of this is that when AMD Zen is released, Bulldozer has at least already paved the way for better multi-core support in SW. So SW should be able to make better use of the 8 cores in Zen already from the start.

I don't really agree with that statement. If we're still talking games like AotS which is presumably FP-heavy without many SSE/SIMD optimizations, we have a situation where BD/PD act more like a quad than an octocore CPU performance-wise. Chips like the 3770k and 5820k have done more to put pressure on PC publishers/developers to start supporting more than 4 threads in software.

AotS is compiled with ICC afaik. Of course it will run like a dog on AMD cpus. I expect DX12 games with CPU Agnostic compilers to work nicely in every CPU out there that is not more than 5 years old.

ICC generally does a better job than the ever-ubiquitous MSVC when it comes to compiling and autovectorizing, even for AMD CPUs. There have been circumstances where ICC deliberately uses older/slower ISAs for CPUs that don't register as "genuine Intel", and much has been done to expose that problem. But if you have code that is (for example) aimed at SSE2 or SSE3 at best, then ICC is going to produce executables that outperform those compiled by GCC by a hair and MSVC by quite a bit, even on AMD CPUs.

Today, the problem comes from how ICC handles stuff like . . . AVX/AVX2 (it forces the AMD CPUs that support such instructions to split them in hardware) or xOP (ICC doesn't support xOP at all).

AMD should have invested more in compiler development years ago before they launched the first Bulldozer CPUs. Then they should have continued with compiler development and launched a full suite of software to support HSA prior to the release of Kaveri. They did neither, and they're still reaping the whirlwind.

Pointless arguing is pointless.
It is all about opmitization.

To see how all CPUs should stack just look at some synthetic CPU benchmarks like Cinebench:

Cinebench is far from perfectly optimized. At best, it shows us fp performance when a). using dated ISA extensions and b). the code is loose enough that not everything stays in l2. Cinebench R11.5 particularly puts the knife to AMD, though I can't tell if that's an ICC problem or what. R10 is (in my opinion) the most "fair" since it uses maybe SSE2. It shows you legacy code performance, which is often the most relevant software anyway.

Perfectly optimized games should have CPU hierarchy the same as CB MultiThread benchmark.

No, perfectly - and by that I mean ABSOLUTELY perfectly - optimized games should have CPU hierarchy similar to something like y-cruncher. But how many games support AVX2 or xOP? Probably none.

 

[frozentundra123456]

Everything is sequential by nature. I mean everything. Even CB is sequential by nature, but it was optimized to run in parallel on multiple threads.

Also, there are games that are above the equilibrium point where i3=fx8350.


Haha. Gtx750, such a fail of a card, barely faster than r7 250 - AKA a cut down 7750 which is already a cut down 7770 which was released when my grandfather was dating my grandmother. Try harder

Better check your benchmarks again. GTX 750 is faster than r7 250x. benchmark

 

[DrMrLordX]

That you tube video shows a 7870k almost as fast as the 4670k, which simply does not make sense(it would mean the 7870k is as fast as the 8350). If it is true, then it certainly means that the FX needs more than simply "moar cores" to be competitive, even under DX12.

When does the video show the 7870k being as fast as a 4670k? The video features an overclock 4690k. It's also interesting to note, that while the framerate averages and minimums for the 7870k and the 4690k are similar, the max frames for the 4690k are twice that of the 7870k.

As far as a 7870k being as fast as an 8350 . . . maybe it is in that particular benchmark? That's one of the reasons why Shintai's link is so problematic, since it uses difference settings; a different GPU; and a different selection of CPUs. A head-to-head between an 8350 and a 7870k would have been more informative.

 

[Erenhardt]

Better check your benchmarks again. GTX 750 is faster than r7 250x. benchmark

Accroding to Dark Zero's benchmark it is not:
http://forums.anandtech.com/showpost.php?p=37804384&postcount=69

750 is not even 30% faster than r7 250
r7 250X is 40% faster than r7 250,
Simple math, 250X is faster than 750.

If you have anything against that go argue with dark zero.

 

[XavierMace]

Unless I'm missing something, that benchmark has literally ONE test including those two cards. Neither are even the subject matter of that review. Not really sure how that could be considered conclusive evidence of your stance.

 

[MiddleOfTheRoad]

It is more compact you are right there,it is more compact because it lacks everything,no API for graphics no net framework no visual c no nothing that can improve performance,if you only need straight up x86 code then sure I guess it might be a bit faster if it runs less background stuff.

As for the linux benches...does anybody even know what these programs are for and what they do?

It also doesn't have all the viruses, shovelware and malware that loads up the windows registry to make it crawl. If all that crapware actually improved performance -- then your point might actually matter.... since it doesn't it's moot.

 

[TheELF]

Yes I am sure everybody working on sites that do benchmarks make it a point to load up on crapware before running benches.