blackweb wrote: »

Ranique wrote: »

I just going to refer to my initial post and ask you to read it. Just saying that I'm wrong, without putting anything against it, is wrong. You clearly don't have any clue what you are talking bout. You have proven that when you started to claim that 32 bits programs out of memory switched to disk cache. that one is hilarious ridicilious.making a 64 bits client is a total waste of resources, please stop your witch hunt and stop making a fool of yourself! It is not going to happen and if it will I'll stop paying any money to ZOS cause of the way they waste it!

Ok so what you are saying is that when an x86 app runs out of memory, it doesn't page to virtual memory or disk and that I have no idea what I am talking about?

http://blogs.msdn.com/b/ericlippert/archive/2009/06/08/out-of-memory-does-not-refer-to-physical-memory.aspx

Eric Lippert makes some very good points:

The amount of data storage reserved for a process is only limited by the amount of space that the operating system can get on the disk. (*)

This is the key point: the data storage that we call “process memory” is in my opinion best visualized as a massive file on disk.

There is a thorough discussion on virtual memory or memory mapping that begins with.

So, suppose the 32 bit process requires huge amounts of storage, and it asks for storage many times. Perhaps it requires a total of 5 GB of storage. The operating system finds enough disk space for 5GB in files and tells the process that sure, the storage is available. How does the process then write to that storage? The process only has 32 bit pointers, but uniquely identifying every byte in 5GB worth of storage would require at least 33 bits.

This describes the scenario that ESO is running under.

The process can deal with this situation by attempting to identify portions of the virtual address space that no longer need to be mapped, “unmap” them, and then map them to some other pages in the storage file. If the 32 bit process is designed to handle massive multi-GB data storages, obviously that’s what its got to do. Typically such programs are doing video processing or some such thing, and can safely and easily re-map big chunks of the address space to some other part of the “memory file”.

Does more memory lead to better performance? As Mr. Lippert states, it does

I haven’t yet mentioned RAM. RAM can be seen as merely a performance optimization. Accessing data in RAM, where the information is stored in electric fields that propagate at close to the speed of light is much faster than accessing data on disk, where information is stored in enormous, heavy ferrous metal molecules that move at close to the speed of my Miata. (**)

Does 64-bit or x64 windows make a difference? It sure does according to Mr. Lippert.

And of course, many of these problems effectively go away on 64 bit Windows, where the address space is billions of times larger and therefore much harder to fragment. (The problem of thrashing of course still occurs if physical memory is smaller than total working set, no matter how big the address space gets.)

Note that Mr Lippert specifically addresses the problem of thrashing above.

Ranique,

You should think carefully before telling a Microsoft developer (which I am) or anyone for that matter that they do not know what they are talking about. I made my points in simple terms that non-technical readers could understand. We can go much deeper technically if you like but at this point, you will be arguing with Eric Lippert who as his bio describes is

Eric Lippert is a principal developer on the C# compiler team.

Feel free to respond to his blog post if you disagree with him. I would ask for an apology for your condescending, nasty and just plain wrong post that I quoted above but I don't think one will be forthcoming given your snide tone. Maybe it is you who should stop "making a fool of yourself"?

I think that it is safe to say that ZoS is working on an x64 ESO client for windows especially considering that Windows 10 which will be released in 19 days on July 29 will be 64-bit only.

http://techera.co.in/tag/windows-10-64-bit-only/

I hope this gives the Zos devs a sense of urgency about releasing a x64 client.

WEB

You wont get any appologies. You are simply wrong.

I'm not argueing with a fool like you and your links are NOT supporting your claims.
If a 32 bits system runs out of the full 4GB of memory (ESO only uses like 2!) it does use the pagefile, but that is not relevant for the discussion and the main point you are ignoring. Memory is no longer an issue cause it is the CPU itself that is the wekeast link now. You claim you know so much bout pc's, but you clealry don't know the most basic rules of the weakest link. You should really read up Von Neumann. As you clearly have no clue bout those things, any claims you are making bout your experience are very likely made up.

You should appologise to me. In you false arguments you have admitted that you gave a wrong presentation of the memory issue. You admitted to be wrong and only insist on defending your wrong and false claim cause you are a total nitwit.

64bits eso.exe has no influence on performance so kaning it so is a total waste of time.
That is the simple conclusion.

I remember having to modify the Skyrim executable to make it allocate more than 2GB of memory because it would crash every 15 minutes otherwise. It took players running 1080p an hour to run out of memory space but players like me running 1600p were experiencing it constantly.

The fixed this issue in the first major patch.

I don't think ESO has this particular problem because I almost never crash and I'm still running at 1600p. The textures for 2560X1600 in this game are smaller than the ones uses in Skyrim I think.

I think the crashes are for different reasons.

Ezareth wrote: »

I remember having to modify the Skyrim executable to make it allocate more than 2GB of memory because it would crash every 15 minutes otherwise. It took players running 1080p an hour to run out of memory space but players like me running 1600p were experiencing it constantly.

The fixed this issue in the first major patch.

I don't think ESO has this particular problem because I almost never crash and I'm still running at 1600p. The textures for 2560X1600 in this game are smaller than the ones uses in Skyrim I think.

I think the crashes are for different reasons.

ESO is already large address aware, so ESO can already use up to 4 GB on a properly equipped 64-bit Windows box.

blackweb wrote: »

lordrichter wrote: »

Ezareth wrote: »

I remember having to modify the Skyrim executable to make it allocate more than 2GB of memory because it would crash every 15 minutes otherwise. It took players running 1080p an hour to run out of memory space but players like me running 1600p were experiencing it constantly.

The fixed this issue in the first major patch.

I don't think ESO has this particular problem because I almost never crash and I'm still running at 1600p. The textures for 2560X1600 in this game are smaller than the ones uses in Skyrim I think.

I think the crashes are for different reasons.

ESO is already large address aware, so ESO can already use up to 4 GB on a properly equipped 64-bit Windows box.

ESO uses about 1.5 GB of memory by default.

I see we've come full circle. So I'll just quote myself:

KhajitFurTrader wrote: »

The 32-bit ESO executable is complied using the IMAGE_FILE_LARGE_ADDRESS_AWARE flag, so on a 64-bit OS it is possible for it to use a user-mode virtual address space of up to 4 GB. But it doesn't. Why?

On a 64-bit OS, the 64-bit client of WoW rarely uses more than 2.5 GB of memory, while running on a machine w/ 32 GB of physical RAM and usually more than 17 GB of it free, i.e. not even including the disk cache. Why is that?

One reason could be that it's simply bad programming style to allocate memory for assets that aren't needed yet. malloc() what you need in time, free() that what's become obsolete for a while. This is good sense. On a 64-bit address space, the pressure to free obsolete assets might be a bit lower, but there really isn't a good excuse for any process to be a memory hog (except when you're a RDBMS - then go for it). And between the OS caching disk I/O, and the engine pre-loading anticipated assets, there really isn't that much of a of a performance penalty.

People often ask for a 64-bit client, but sometimes for all the wrong reasons. An architecture change doesn't make any program automagically faster, unless it's able to be optimized for it. It's often overlooked that optimization mainly happens in the instruction set department specific to the x64 architecture, i.e. being able to do the same task in less CPU cycles, or do more work within the same time. Being able to address more memory surely can be helpful, but not all kinds of tasks can profit from this in the same way. It may help with some bottlenecks in different circumstances, but it's not a panacea.

That being said, word on the street is that the PS4 client already is 64-bit. Given the fact that all clients on all platforms share the same code base, it's only a matter of time and testing before we might see an announcement for a beta phase.

There's an aspect missing from this discussion: MONEY! Plain and simple, it costs more to develop an x64 application. Saying that x64 or x32 is faster is almost a mute point, because it all boils down to the time invested in programming for optimization in each architecture. Inherently the 32 bit architecture is easier to program and is more forgiving (unless you run out of memory space). That being said, there are many instances where the x32 versions of apps are indeed a bit faster that their x64 counterparts. Again, its not due to architecture, but rather optimizations, of which x64 requires significantly more time invested to maximize it's potential.

In x32 most data is transmitted by memory, in x64 this is highly ineffective, so this task is done using registers if possible. x64 architecture has more registers than it's x32 equivalent and because all computations are performed inside registers, theoretically, is much faster. However, if you are running in 32-bit mode, even if it is a 64-bit processor, it can still use only the x32 set of registers.* So , if an x64 developer had the expertise and the time to invest, they could indeed optimize the x64 executable to maximize register usage and theoretically gain a performance edge over it's x32 counterpart, while at the same time increasing available memory, which is a win-win scenario.

Unfortunately in the real world overhead of the business may outweigh overhead in the application. So even if a developer team is perfectly capable of making some awesome x64 optimizations, they may never get the chance since most of the time the bean counters have already determined when and how they will invest their time in order to keep investors happy. It's a constant battle in the gaming development world between developers wanting to build the perfect game, and investors just wanting it to be good enough to meet their monetary quotas.

Do I wish the ESO Devs were given the amount of time and resources necessary to create an awesome x64 version? Yes, definitely! Will it happen? Who knows.

*REF

Yeah it doesn't cost more money at all...

It is literally the same coding, but with some small changes to use the 64bit registers and memory allocation, and of course compiled as a 64bit Binary.

vwaskarb16_ESO wrote: »

Yeah it doesn't cost more money at all...

It is literally the same coding, but with some small changes to use the 64bit registers and memory allocation, and of course compiled as a 64bit Binary.

This is a fairly accurate description of what would be involved in porting ESO PC to x64. I think the biggest task would not be recoding for x64 but re-testing ESO. That will take some time.

[Moderator Note: Edited per our rules on Advertising]

SirAndy wrote: »

blackweb wrote: »

ESO would not have to be refactored but it would have to be recompiled, then retested.

I do this stuff for a living.
I have yet to see a complex 32bit application (game or otherwise) that could simply be recompiled in 64bit without any changes to the actual code.
That has never happened, not once, in many, many, many years of doing this line of work 12 hours a day.

Games in particular (and yes, i have worked several years as a programmer in the gaming industry) use a lot of 32bit optimized code, function calls and external libraries that were compiled for 32bit.
Many data types need to be changed, data structures need to be adjusted, realigned and/or compacted. Function return values, timers, 3d models, GPU interactions all have to be reworked.
Memory buffers need special attention as well, not just from a technical point but also from a logistical point. Your 32bit memory pipeline will have to be reworked to efficiently use the additional 64bit address space.

Matter of fact (as stated in my earlier post), i'm reworking a large enterprise application from 32bit to 64bit as we speak. The original memory management used about 2GB of data buffers in RAM while constantly pipelining huge amounts of data through that 2GB buffer. The new version uses over 70GB (!) of memory on a 128GB machine.
The whole memory pipeline had to be refactored to do that, and no, that wasn't easy.

Suggesting that a simple recompiling would be enough (or even just work) shows me how little you actually know about the subject ...

Give it a rest. I could say the same thing about you. I would just recompile it first, then see what breaks. I doubt it would even compile as x64 but its a good starting point. Then make necessary code changes from there. Get it to run. Test it. Make some more changes etc. But I am not a game developer.

lordrichter wrote: »

vwaskarb16_ESO wrote: »

Yeah it doesn't cost more money at all...

It is literally the same coding, but with some small changes to use the 64bit registers and memory allocation, and of course compiled as a 64bit Binary.

If the program was designed with the limitation of a 32-bit application in mind, knowing that the application can get from 3.5

I think you missed out the part where I said one of the changes would be Memory Allocation. So it wouldn't matter how the old 32bit coding was designed, it would be redone with 64bit Mnemonics in mind.

vwaskarb16_ESO wrote: »

lordrichter wrote: »

vwaskarb16_ESO wrote: »

Yeah it doesn't cost more money at all...

It is literally the same coding, but with some small changes to use the 64bit registers and memory allocation, and of course compiled as a 64bit Binary.

If the program was designed with the limitation of a 32-bit application in mind, knowing that the application can get from 3.5

I think you missed out the part where I said one of the changes would be Memory Allocation. So it wouldn't matter how the old 32bit coding was designed, it would be redone with 64bit Mnemonics in mind.

A program that does not use all available memory as a 32-bit application must be modified if it is going to use the additional memory offered by 64-bit architecture. A simple recompile and an offer of additional memory from the operating system are not enough. As @SirAndy has already said, memory allocation is not even the primary concern, however, it is enough for me to determine that 64-bit is not the panacea that people think it is.

lordrichter wrote: »

vwaskarb16_ESO wrote: »

lordrichter wrote: »

vwaskarb16_ESO wrote: »

Yeah it doesn't cost more money at all...

It is literally the same coding, but with some small changes to use the 64bit registers and memory allocation, and of course compiled as a 64bit Binary.

If the program was designed with the limitation of a 32-bit application in mind, knowing that the application can get from 3.5

I think you missed out the part where I said one of the changes would be Memory Allocation. So it wouldn't matter how the old 32bit coding was designed, it would be redone with 64bit Mnemonics in mind.

A program that does not use all available memory as a 32-bit application must be modified if it is going to use the additional memory offered by 64-bit architecture. A simple recompile and an offer of additional memory from the operating system are not enough. As @SirAndy has already said, memory allocation is not even the primary concern, however, it is enough for me to determine that 64-bit is not the panacea that people think it is.

Stop talking down to people as if you have some sort of inside information on Windows software development or game development. I have to wonder if some of you so-called experts have ever build a working windows software application. A few questions for you wanna-be experts in terms that even you can understand:

Would you extensively refactor code that will not build or compile?

Would you extensively refactor an existing code base without testing those changes as you make them?

Is it possible to test changes to an existing code base if you cant even get it to compile or build?

If you answered yes to those three questions, you are a bad software developer who should not be allowed anywhere near any working software to make modifications to it. Again, the approach I would take would be:

1. Apply minimal x64 changes to the existing eso code base.
2. Get it to compile or build.
3. Test the result.
4. Make more changes.
5. Test the result.
6. And so on.

I WOULD NOT MAKE WHOLESALE CHANGES TO AN EXISTING CODEBASE WITHOUT TESTING THOSE CHANGES AS I MADE THEM. It is very difficult if not impossible to test software that will not build or compile. If you do want to refactor existing software, starting with a stable baseline that will compile or build is always a good approach.

Edit: for those of you who learned to code from a "For Dummies.." book, the iterative approach I suggest is called "Agile".

x64? Meh...

x64 and DirectX 12? Now you're talking!

oldskool2485 wrote: »

x64? Meh...

x64 and DirectX 12? Now you're talking!

I could not agree more. I am running Win10. I think that dx12 would give ESO a nice boost in performance and scaling.