official Watch_Dogs

[MorganX]

In reference to OCing i5s and i7s, I would challenge you to go look at benchmarks, for example: http://techreport.com/review/23246/inside-the-second-gaming-performance-with-today-cpus

 

Notice how there is very little variation between i5s and i7s of the same generation and specs?

 

Overclocking is it's own topic. :)

 

Looking at those benchmarks the most telling is the multitasking benchmark, lead by the i7s. The others, are close enough. One of the poorest performing (due to bad coding IMO) for me was Arkham City with DX11. Led by the i7.

 

I think with x64 and enough memory, i7s should show their worth. I agree generations are important, that's the whole point of processor improvement.

 

I say if cost is not prohibitive, get the best processor you can afford.

[snaphat (Myles Landwehr) Member]

 

I'll leave this to the programmers, but here are a few interesting tidbits on the notion of x64 and performance:

 

http://www.viva64.com/en/k/0003/

 

 

General notes from MS, server related but probably generally applicable:

• A 64-bit architecture provides more and wider general-purpose registers, which contribute to greater overall application speed. When there are more registers, there is less need to write persistent data to memory and then have to read it back just a few instructions later. Function calls are also faster in a 64-bit environment because as many as four arguments at a time can be passed in registers to a function.

• Poor performance in 32-bit systems is often not the result of a lack of available memory, but the unavailability of large enough blocks of continuous memory. In a typical Windows SharePoint Services 3.0 deployment, Windows, Internet Information Services (IIS), common language runtime (CLR), ASP.NET, SharePoint Products and Technologies, SSPs, and MDACs can all claim a portion of a server?s available virtual memory and can leave a 32-bit address space quite fragmented. When the CLR or SharePoint services request new memory blocks, it can be difficult to find a 64-MB segment in the crowded 32-bit address space. A 64-bit system offers practically unlimited address space for user mode processes.

• Even 32-bit applications can benefit from increased virtual memory address space when they are running in a 64-bit environment. For example, although a 32-bit application is still restricted to 4 GB of virtual memory, it no longer has to share that memory space with the operating system. As a result, it receives an effective increase in available virtual memory.

 

 

1. Sure, as I said, you have more registers to play around with and ABI changes in x86_64. The former, can and does reduce register spilling in general, but it doesn't necessarily result in notable performance gains. Do you have any benchmarks showing that simple recompilation results in great performance benefits (besides a website that just arbitrarily states so without any evidence)? The latter (changes to calling conventions) are unlikely to really increase performance all that much. You have issues if function calls are the significant overhead in your program.

    

2. Wider registers don't contribute to performance if you weren't using 64 bit types in the first place. Chances are that most applications aren't. It's just is not done in typical usage unless specifically needed.

    

3. I'm not really sure where MS is going with this 32 bit memory fragmentation argument. It seems to me, they are being deliberately misleading here by suggesting that processes all share a single virtual address space (VAS). Let me be very clear, each process has its own distinct virtual address space -- it begins completely non-fragmented at the start of a process. The fragmentation to which MS is referring would only occur within a process if the particular process allocated large amounts of memory (2-3GB) in small chunks within its VAS and then proceeded to deallocate some of them, etc. It could potentially become an issue only over-time within the one process -- but make note, it wouldn't affect any other process on the system since they do not share their virtual address space with other processes.

    

4. It is important to make a distinction between virtual memory fragmentation and physical memory fragmentation. The latter is not changed just because you have a larger virtual address space per process. At the end of the day your VAS still maps back to physical memory and your physical memory is of a finite size -- and allocated in the same manner regardless of whether you are using a 32 bit kernel or 64 bit kernel.

    

5. Sure, applications don't have to the share parts of their virtual address space with the OS so they can allocate more memory. That's a given and the one good reason to use a 64-bit OS. I'm not arguing against this. I'm just asking what is the clear-zero-effort performance advantages to moving to an x64 OS? I see your link, but they haven't shown an tangible evidence that what they say is true. I'd welcome benchmarks showing that there is a clear advantage. I would believe a 5% increase simply because of the better register allocation, but a 20% seems rather unlikely and contrived.

[snaphat (Myles Landwehr) Member]

Overclocking is it's own topic. :)

 

Looking at those benchmarks the most telling is the multitasking benchmark, lead by the i7s. The others, are close enough. One of the poorest performing (due to bad coding IMO) for me was Arkham City with DX11. Led by the i7.

 

I think with x64 and enough memory, i7s should show their worth. I agree generations are important, that's the whole point of processor improvement.

 

I say if cost is not prohibitive, get the best processor you can afford.

 

Of course, it was lead by an i7 that costs $1K...

 

So let's be specific here: what you are saying is that the top-of-the-line high-end extreme edition i7 that cost $1000+ is a measly 5 FPS better than the nearest i5 which cost $200+. And ignoring the fact that i7s with similar specs to the i5s have 1-2 FPS difference. And ignoring the fact that ivybridge i5s are seeing better FPS than sandybridge i7s. All shadowed by the fact that these are all running 80-90 FPS...

 

I think that anti-proves your point that i7s have performance gains over i5s in terms of FPS...

[MorganX]

1.  

2. Wider registers don't contribute to performance if you weren't using 64 bit types in the first place. Chances are that most applications aren't. It's just is not done in typical usage unless specifically needed.

    

3.  
4.  
5. Sure, applications don't have to the share parts of their virtual address space with the OS so they can allocate more memory. That's a given and the one good reason to use a 64-bit OS. I'm not arguing against this. I'm just asking what is the clear-zero-effort performance advantages to moving to an x64 OS? I see your link, but they haven't shown an tangible evidence that what they say is true. I'd welcome benchmarks showing that there is a clear advantage. I would believe a 5% increase simply because of the better register allocation, but a 20% seems rather unlikely and contrived.

 

 

All your points sound sound to me. Then again, so do everyone elses. I'll leave the debating of this topic to programmers but do want to comment on two of your points:

 

2. Then based on what you are saying, x64 does provide the opportunity for enhanced program performance buy choosing to utilize the wider registers?

 

5. Programmers are paid enough to exercise plenty of effort to deliver the benefits of the powerful resources available on today's desktops, lol. To not do so would result in what Skin is afraid of, sloppy code that doesn't actually utilize current high end system resources.

 

A multiple core processor is no better than a single core processor if programmers don't make the effort to take advantage.  And for a long time now they haven't really; or is it that the technology base just wasn't there in enough numbers to make it viable to even bother?. It's good to see them moving in that direction.

[Veiva]

If you guys are worried about the system requirements for this game, just wait for the knockoff "Observation Canines" to come out next year. It'll run on Windows XP/Linux with 512mb ram.

 

That's been done, already.

 

No need to wait!

[MorganX]

Of course, it was lead by an i7 that costs $1K...

 

So let's be specific here: what you are saying is that the top-of-the-line high-end extreme edition i7 that cost $1000+ is a measly 5 FPS better than the nearest i5 which cost $200+. And ignoring the fact that i7s with similar specs to the i5s have 1-2 FPS difference. And ignoring the fact that ivybridge i5s are seeing better FPS than sandybridge i7s. All shadowed by the fact that these are all running 80-90 FPS...

 

I think that anti-proves your point that i7s have performance gains over i5s in terms of FPS...

 

I haven't really ignored anything. I've already said previously the extreme's are not worth it. At least not for gaming. I have also said that because games haven't been optimized for x64 or multicore/threads, that there isn't that much of a difference at the high ends. But I do believe as x64 does become the norm and optimized and there is memory headroom, i7s will show their worth.

 

If BF4 x64 and NFS x64 benchmarks show similar results, I will say, for gaming only, you might as well stick with an i5, there's no reason to get an i7. Right now I just don't believe that, in spite of how close the benchmarks are.

[snaphat (Myles Landwehr) Member]

All your points sound sound to me. Then again, so do everyone elses. I'll leave the debating of this topic to programmers but do want to comment on two of your points:

 

2. Then base on what you are saying, x64 does provide the opportunity for enhanced program performance buy choosing to utilize the wider registers?

 

5. Programmers are paid enough to exercise plenty of effort to deliver the benefits of the powerful resources available on today's desktops, lol. To not do so would result in what Skin is afraid of, sloppy code that doesn't actually utilize current high end system resources.

 

A multiple core processor is no better than a single core processor if programmers don't make the effort to take advantage. And for a long time now they haven't really. It's good to see them moving in that direction.

 

2. Yeah, x64 does provide opportunity for enhancement if you are using 64 bit types in a 32 bit program (int64_t for example), then you would  to be doing multiple operations instead of 1 64-bit operation so there is the potential performance benefit from that. But, 95% of programs aren't going to be doing that. You only do such things if you need numbers larger than the range that 32-bit types offer.

 

5. Sure, if you go out of your way specifically, you can definitely see performance benefits. But, I don't believe you'll see them for free in general.

 

And, I agree that multi-core processors are rarely taken advantage of. They aren't even effectively taken advantage of in HPC where it counts. A common myth is that you get free performance with multi-core, but that's simply not the case. It is a large effort to parallelize domain specific problems in most cases.

[PGHammer]

2. Yeah, x64 does provide opportunity for enhancement if you are using 64 bit types in a 32 bit program (int64_t for example), then you would  to be doing multiple operations instead of 1 64-bit operation so there is the potential performance benefit from that. But, 95% of programs aren't going to be doing that. You only do such things if you need numbers larger than the range that 32-bit types offer.

 

5. Sure, if you go out of your way specifically, you can definitely see performance benefits. But, I don't believe you'll see them for free in general.

 

And, I agree that multi-core processors are rarely taken advantage of. They aren't even effectively taken advantage of in HPC where it counts. A common myth is that you get free performance with multi-core, but that's simply not the case. It is a large effort to parallelize domain specific problems in most cases.

All too true.

 

As an exercise for those that are merely curious, I submit no less than the original Supreme Commander OR Supreme Commander: Forged Alliance.  Both are multicore-aware out of the box, and both are, in fact, quite old - the first shipped before Windows Vista.  (And, in case you are wondering, both will run quite happily in Windows 8 or 8.1.)  It was the original Supreme Commander that made the advantages merely of multicore support rather obvious when it came to gaming - however, how many multicore-aware games have followed it?

[Dwarden]

sometimes i wonder (after reading posts of quite many in this thread) if people know that 32bit binary with LAA can address directly 4GB

and there are methods you can address beyond that indirectly , so much for the 64bit buzz ...

imho 64bit addressing over 4GB is ofcourse innevible outcome but it's more important when you go way beyond just 6 or 8GB :)

(aka sorry consoles you can't compete, PC master race wins)

[spaceelf]

sometimes i wonder (after reading posts of quite many in this thread) if people know that 32bit binary with LAA can address directly 4GB

Yes, but it still has to be coded to work with a 32 bit OS.  So that isn't much more than a bandaid on a gaping wound.

[snaphat (Myles Landwehr) Member]

sometimes i wonder (after reading posts of quite many in this thread) if people know that 32bit binary with LAA can address directly 4GB

and there are methods you can address beyond that indirectly , so much for the 64bit buzz ...

imho 64bit addressing over 4GB is ofcourse innevible outcome but it's more important when you go way beyond just 6 or 8GB :)

(aka sorry consoles you can't compete, PC master race wins)

 

I'm not really sure what you are arguing here since LAA only gives your 4GB for 32-bit programs on 64-bit Windows (and only 3GB for 32-bit programs on 32-bit Windows with PAE enabled). Not at all the same thing as being able to address terabytes of data in the case of native 64-bit programs.

 

Also, how exactly would you address more than 4GB if the registers where you can store addresses are all effectively 32-bit width in 32-bit programs?

 

EDIT: http://en.wikipedia.org/wiki/X32_ABI -- forgot about that, I'd like to see a 32-bit OS using that (or 64 bit compatibility layer for 32-bit programs) -- alas, that'll never happen for Windows.

[The_Decryptor Veteran]

You can address more than 4GB of RAM under a 32bit OS if you're smart (especially since Windows and such operate with PAE enabled which gives you a 36bit address space I think)

But really, what's the point? Running as a 64bit app under a 64bit OS gives you the extra RAM without having to do manual mapping. This game is fairly resource intensive, so the CPU required to run it would be 64bit anyway (Since Intel/AMD haven't made 32bit CPUs outside of ultra low end for a long time).

[snaphat (Myles Landwehr) Member]

You can address more than 4GB of RAM under a 32bit OS if you're smart (especially since Windows and such operate with PAE enabled which gives you a 36bit address space I think)

But really, what's the point? Running as a 64bit app under a 64bit OS gives you the extra RAM without having to do manual mapping. This game is fairly resource intensive, so the CPU required to run it would be 64bit anyway (Since Intel/AMD haven't made 32bit CPUs outside of ultra low end for a long time).

 

Looks like you are right about addressing more than 4GB of RAM per process: http://sqlserverfinebuild.codeplex.com/wikipage?title=SQL+Server+AWE+Property (scroll to section Hardware for Extending 32-bit addressing).

 

I honestly had no idea that there were new instructions for this.

 

The interesting part in how this works is that it means that you can't actually use or address anything above the 32-bit address range normally (via normal move instructions) and instead have to copy the data in/out of your 32-bit address range via special instructions. This makes sense considering that the registers would still be 32-bits and thus unable to address anything above that range. The 36-bit extension you mentioned is just to allow processors to address up to 64GB. They could have presumably chose any size and done the same thing with these instruction extensions.

 

I can see why you'd rarely really see programs that did this. I can't imagine the overhead and performance costs are nil to address above 4GB in this case. It is more like a shim of anything. In any case, you learn something new everyday.

[PGHammer]

You can address more than 4GB of RAM under a 32bit OS if you're smart (especially since Windows and such operate with PAE enabled which gives you a 36bit address space I think)

But really, what's the point? Running as a 64bit app under a 64bit OS gives you the extra RAM without having to do manual mapping. This game is fairly resource intensive, so the CPU required to run it would be 64bit anyway (Since Intel/AMD haven't made 32bit CPUs outside of ultra low end for a long time).

And both have made x64 low-end CPUs for quite a long stretch as well - or have we forgotten that Celeron (Intel), Sempron/Turion (AMD) are x64?

 

Users have stalled because they have been ABLE to stall (the "no need to move" argument).

[snaphat (Myles Landwehr) Member]

And both have made x64 low-end CPUs for quite a long stretch as well - or have we forgotten that Celeron (Intel), Sempron/Turion (AMD) are x64?

 

Users have stalled because they have been ABLE to stall (the "no need to move" argument).

 

I don't think users themselves are stalling more than the industry was once maturing in terms of OS and driver compatibility. All of that happened long ago though. They don't ship even computers pre-installed with 32-bit OSes anymore. Game developers just make 32-bit builds of games to ensure maximum compatibility which isn't particularly surprising if you consider that most people don't have more than 4GB of memory anyway. What's the point of forcing additional requirements that would potentially lower sales and gain you nothing?

[PGHammer]

I don't think users themselves are stalling more than the industry was once maturing in terms of OS and driver compatibility. All of that happened long ago though. They don't ship even computers pre-installed with 32-bit OSes anymore. Game developers just make 32-bit builds of games to ensure maximum compatibility which isn't particularly surprising if you consider that most people don't have more than 4GB of memory anyway. What's the point of forcing additional requirements that would potentially lower sales and gain you nothing?

However, running x64 DOES have advantages in sub-4GB RAM situations (primarily stability/robustness) making a mockery of the longtime arguments of x32 apologists that there were no advantages to x64 below 4 GB of RAM.

 

There are advantages in the operating system space, and there are advantages in the application space as well - in both cases, while there is no real alternative if you have more than 4 GB of system RAM, the advantages start below that number - in terms of stability and robustness alone, they start at half that, if not less.  (All of my testing,  both in bare-metal and virtual-machine usage, has borne that out - and it's not unique to Windows; look at Linux, UNIX, or even the BSDs.)

The browser-addon space is a bit of a chicken-and-egg situation, as the application space and the gaming space has also been - the advantages have to be made obvious, and that takes trailblazing.  There are trailblazing applications, and now games - what is needed now are trailblazers in the browser-add-on space.)

[Athernar]

I don't think users themselves are stalling more than the industry was once maturing in terms of OS and driver compatibility. All of that happened long ago though. They don't ship even computers pre-installed with 32-bit OSes anymore. Game developers just make 32-bit builds of games to ensure maximum compatibility which isn't particularly surprising if you consider that most people don't have more than 4GB of memory anyway. What's the point of forcing additional requirements that would potentially lower sales and gain you nothing?

 

Not to mention the previous generation of consoles forcing titles to maintain ~512MB as the absolute minimum target.

[snaphat (Myles Landwehr) Member]

However, running x64 DOES have advantages in sub-4GB RAM situations (primarily stability/robustness) making a mockery of the longtime arguments of x32 apologists that there were no advantages to x64 below 4 GB of RAM.

 

There are advantages in the operating system space, and there are advantages in the application space as well - in both cases, while there is no real alternative if you have more than 4 GB of system RAM, the advantages start below that number - in terms of stability and robustness alone, they start at half that, if not less.  (All of my testing,  both in bare-metal and virtual-machine usage, has borne that out - and it's not unique to Windows; look at Linux, UNIX, or even the BSDs.)

The browser-addon space is a bit of a chicken-and-egg situation, as the application space and the gaming space has also been - the advantages have to be made obvious, and that takes trailblazing.  There are trailblazing applications, and now games - what is needed now are trailblazers in the browser-add-on space.)

 

Can you back your claim of stability/robustness advantages up with some citations and specifics? As far as I know, there is nothing in the x64 portions of the ISA that would yield advantages in these areas. The only effective differences in the modes from a practical standpoint is that you have larger/more registers, can address more memory, and you have some additional x86_64 specific instructions.

 

Unless you are talking about security advantages in terms of ASLR, I don't see any inherent reason why 64-bit OSes would be at a stability advantage. I've honestly never heard of anyone suggesting that x64 OSes are inherently more stable before.

[The_Decryptor Veteran]

When Microsoft transitioned to 64bit they took the opportunity to close down the kernel (PatchGuard) and enforce strict controls on drivers, that's about it for stability.

[snaphat (Myles Landwehr) Member]

When Microsoft transitioned to 64bit they took the opportunity to close down the kernel (PatchGuard) and enforce strict controls on drivers, that's about it for stability.

 

Yup, I entirely agree with this. Driver signing and enforcement of no kernel patching for x64 Windows certainly helps at the software level, but that isn't inherit to x64 as an architecture. It's just a policy by MS. It is also worth noting that enforcement at the x64 level for Windows also largely mitigates the same issues on the 32-bit front because:

• Vendors going through the certification and driver signing procedure for 64-bit builds tend go through them for 32-built builds also even though technically they aren't required to do so. One large reason probably being that uncertified drivers give warnings if you install them and why wouldn't you certify your drivers and product for the OS where you are going to run it?
• It killed the market for kernel patching in general. Why continue to design software that implements security through kernel patches if it is incompatible with any newly purchased computers?

[+Red King Subscriber²]

I am more interested when games will actually start using high amounts of RAM and CPU.

6GB RAM is chump change.

[MorganX]

I am more interested when games will actually start using high amounts of RAM and CPU.

6GB RAM is chump change.

 

Based on many of the comments in this thread, 6GB is apparently not chump change for many Neowinians. :P

[NeoWind]

I wish they will use mantle to supercharge the game performance and after half a year delay must mean something. 

[The_Decryptor Veteran]

Mantle won't "supercharge" it.

[spaceelf]

Mantle won't "supercharge" it.

That depends how much they're pushing.  If you're assuming the same workload in either D3D or Mantle, might not be a big boost, but they could offer higher detail levels or a different shader loadout with Mantle.

 

Personally I highly doubt Watch Dogs will support Mantle...look how long it took Ubisoft to support dx11 at all outside of Assassins Creed, heh.  Might be considerably less complicated than the jump from dx9 to dx11, but we'll see.