What's the situation regarding the 64bit executable?

[Dano]

I know Oleg stated that there would be both 32 and 64bit executables available at launch and obviously we only got the 32bit one but did Luthier or anybody else ever mention the 64bit one in regards to it's eventual release or not?

[louisv]

I know Oleg stated that there would be both 32 and 64bit executables available at launch and obviously we only got the 32bit one but did Luthier or anybody else ever mention the 64bit one in regards to it's eventual release or not?

Look around in the folders, you will find a bunch of filenames with '64' in them, others with '86'. It could be that the 64 bit version is just switched off...I guess once they consider the code clean enough bugwise (and memorywise) then they will enable it, probably as a future beta. My guess.

[ATAG_Snapper]

Look around in the folders, you will find a bunch of filenames with '64' in them, others with '86'. It could be that the 64 bit version is just switched off...I guess once they consider the code clean enough bugwise (and memorywise) then they will enable it, probably as a future beta. My guess.

Hmmmm, if I was a competitor, I'd be squirming.........:-D

[Rattlehead]

Pardon my ignorance, but what would a 64-bit exe bring to the table?

[addman]

Pardon my ignorance, but what would a 64-bit exe bring to the table?

Because 64 bits are more than 32 bits therefore it has to be better. Seriously though, I couldn't care less about that right now, just make the 32-bit version work properly please.

[louisv]

Pardon my ignorance, but what would a 64-bit exe bring to the table?

Larger memory space. More memory.

2 to the power of 32 is 4GB. Windows and stuff take close to 2 GB, so 2 left for applications. If you have more than 4 and you use a 32 bit OS, you never use anything above 4. Now if you have, say, 8 GB, that is 6 GB for applications if you use a 64bit OS.

That does not accelerate applications as such, but depending on how the app manages the memory, it could. For instance by pre-loading a bunch of stuff in memory that would have been on disk. More important is the fact that your app can be much bigger and powerful.

[kilosierra]

IF a application is 64 bit, it CAN run faster than the 32 bit equivalent, as it can pump more data with one cycle. That doesn`t mean though, that a 64 bit app is automatically twice as fast than a 32 bit app because the bus is twice the size.

Apps which through around huge masses of data, like databases, encoding, CAD, but also games CAN be faster with 64 bit.

[CaptainDoggles]

64-bit executable will likely bring only minimal performance gains.

I'd rather see a host of other bugs fixed, new sound, better graphics, etc. before they waste time on a 64 bit executable.

[ATAG_Doc]

64 bit users are elitist

[ATAG_Snapper]

64-bit executable will likely bring only minimal performance gains.

I'd rather see a host of other bugs fixed, new sound, better graphics, etc. before they waste time on a 64 bit executable.

That may well be the case.

I was knocked out by the difference in rendering times between Adobe Premiere Pro CS4 (32-bit) and the more recent CS5 64-bit). However, Adobe worked very closely with Nvidia to fully exploit Nvidia's CUDA structure calling it their Mercury rendering engine to reduce to mere seconds the video processing which formerly took minutes -- or even hours. Playback of even huge multitrack video & audio files were now smooth as silk, and not choppy as before in the earlier 32-bit CS4 version. Stability and fewer-to-no crashes have been a major benefit, too.

But, I agree as you imply: 64-bit programming isn't necessarily the magic answer. Adobe threw their massive software programming resources into the CS5 project, and have refined it even more very recently with a 5.5 update. It may be unrealistic to expect a smaller dev operation like 1C to fully capitalize on 64-bit potential in any meaningful way (frame-rates, stutters, stability) than what they could more readily achieve with their current 32-bit coding optimization. And I, for one, don't wanna wait another 7 years to find out! :)

[speculum jockey]

I'd like DirectX 11 up and running before they even start to worry about the 64bit exe. From what I have heard and read, DX11 is a much more efficient version that DX10 is and this will usually result in better performance with the same or even more eye-candy enabled. (confirm/deny)

[CaptainDoggles]

Confirm. DX11 supports tessellation shaders, which make graphical transformations a snap.

[NedLynch]

confirm

My own experience, after supporting DX11 with a patch in Shogun2 the game looked better and framerates went up. The general consensus seems to be you can just do more with each pixel more efficiently.

[Buchon]

I'd like DirectX 11 up and running before they even start to worry about the 64bit exe. From what I have heard and read, DX11 is a much more efficient version that DX10 is and this will usually result in better performance with the same or even more eye-candy enabled. (confirm/deny)

DX11 contain AA processing optimizations, witch mean better performance with AA enabled and use better HDR precision witch mean better HDR lighting.

Also can do high quality shadows processing without performance loss (no aliased shadows)

[TUSA/TX-Gunslinger]

Maybe that's why AA is wierd in current DX10 release :)

That would certainly make every competitor squirm and explain the length of development time.

Heheh.... this could be very interesting come monday, except I'm going overseas for a week.

S!

Gunny

[Tree_UK]

DX11 contain AA processing optimizations, witch mean better performance with AA enabled and use better HDR precision witch mean better HDR lighting.

Also can do high quality shadows processing without performance loss (no aliased shadows)

This is correct, although some here during development thought that DX11 would be a hindrance to performance, it won't it will improve FPS and the graphic detail, If a game is coded correctly in DX10 then applying DX11 shouldn't be a whole big deal, (so I've been told).

[Skoshi Tiger]

Back to the original topic, when DCS A10 was released there was a major issue with Track IR not being recognised in the 64bit version, so until Natural Point got around to fixing their software I was forced (Seriously , who could go back to not having a trackIR?) to use the 32bit version of the game.

Since the Track IR software was fixed and I was able to use the 64bit version I haven't really noticed any boost in performance on my system.

64 bit is good to have, but the software has to take advantage of the extra memory space.

Cheers!

[louisv]

That's just it, because a lot of people still run in 32bit (even if the hardware has been 64bit since the later models of Pentium IVs), the devs have to keep the two versions very similar and will not really take advantage of the wider data path until a large majority have made the move.

Then programmers will be able to make bigger programs.

Remember the days of 16bit ? The 286, 386 ?

Programs were quite a bit smaller then, with an address space of 2 to the 16th power being 64K on the 8088, the first PCs. The 286 and 386 had a bigger space of 1MB, or 20bit of address space.

So to recap,

16bit: 64KB of memory
32bit: 4GB
64bit: 18.4 X 10^9 GB or about 18.4 Giga GB or 18.4 Exabytes

18.4EB is a big number, I wonder when we will go 128 !

[ZaltysZ]

Remember the days of 16bit ? The 286, 386 ?

Programs were quite a bit smaller then, with an address space of 2 to the 16th power being 64K on the 8088, the first PCs. The 286 and 386 had a bigger space of 1MB, or 20bit of address space.


8088 had 16-bit registers, so only 16-bit long addresses were possible, what gave those 64KB. However, there were also possible to use segmented memory access, which combined segment selector and offset to allow access more memory than 64KB. Hardware had means to use 20-bit address space (1MB), which could be accessible by software via segmented access. Usually 640KB were available to user, and upper region were used by BIOS.

268 and 386 added 24-bit and 32-bit protected modes respectively, whose extended available address spaces to 16MB and 4GB.

[Igo kyu]

Originally Posted by louisv
Remember the days of 16bit ? The 286, 386 ?

Programs were quite a bit smaller then, with an address space of 2 to the 16th power being 64K on the 8088, the first PCs. The 286 and 386 had a bigger space of 1MB, or 20bit of address space.
8088 had 16-bit registers, so only 16-bit long addresses were possible, what gave those 64KB. However, there were also possible to use segmented memory access, which combined segment selector and offset to allow access more memory than 64KB. Hardware had means to use 20-bit address space (1MB), which could be accessible by software via segmented access. Usually 640KB were available to user, and upper region were used by BIOS.

268 and 386 added 24-bit and 32-bit protected modes respectively, whose extended available address spaces to 16MB and 4GB.
That's almost right, but probably due to language differences, it doesn't read quite correctly to me.

Segmented memory addressing was standard on the early IBM compatible PCs.

The Intel 8086 (16 bit) started segmented addressing which gave it one megabyte of address space, then Intel made the 8088 (which was in some ways an 8 bit chip though it used 16 bit registers, as the 8086 and the earlier "8 bit" chips had). Because the 8088 was sort of 8 bit, though it had a one megabyte address space like the 8086, it used cheaper 8 bit support chips, and IBM chose the 8088 for their PC, presumably because the support chips (which wouldn't necessarily come from Intel in the case of either CPU) for the 16 bit 8086 were more expensive.

Segmented memory addressing was such a mess, it gave Intel a legitimate six month lead over the Motorola 68000, but that mess kept running for five or ten years due to "IBM compatibility".

[louisv]

268 and 386 added 24-bit and 32-bit protected modes respectively, whose extended available address spaces to 16MB and 4GB.

I was writing from memory...but I stand corrected.

[Antoninus]

That's just it, because a lot of people still run in 32bit (even if the hardware has been 64bit since the later models of Pentium IVs), the devs have to keep the two versions very similar and will not really take advantage of the wider data path until a large majority have made the move.

According to the latest Steam hardware survey already 60+ % of users have an 64 Bit OS. Among the users with PCs that can satisfactorily run CloD the percentage is probably much higher. All new PCs have at least 4 GB RAM or mostly much more. If any software wants to fully utilize these amounts memory it has to be 64 bit.

CloD development started 7 years ago and thats perhaps the biggest reason why something that should become the foundation of a new series of flightsims for the next decade is still a 32 bit application. I doubt they would loose many sales without a 32 bit exe. Casual gamers with outdated hardware probably don't look for a hardcore sim, but something like WoP.


Since the Track IR software was fixed and I was able to use the 64bit version I haven't really noticed any boost in performance on my system.

64 bit is good to have, but the software has to take advantage of the extra memory space.


If you only have 4 GB RAM installed there is no extra memory that 64 bit DCS A10 can use.

[ATAG_Doc]

64 bit is the de facto standard now for personal computing.

[Madfish]

It doesn't really matter if it's standard or not.

Until CloD uses more than 4gb ram we wouldn't really benefit. It only makes sense or is required if the application is actually USING more than 4gb of ram for itself. The OS and other applications don't matter.

I'm running on 16gb here and usually I have a crazy number of applications etc. running. Combined they use the memory but each application only a small chunk. So the applications themselves can be anything - just the OS has to be a x64 version and you don't have to worry about memory issues anymore, if you got a decent amount of ram that is.

[Stefem]

According to the latest Steam hardware survey already 60+ % of users have an 64 Bit OS. Among the users with PCs that can satisfactorily run CloD the percentage is probably much higher. All new PCs have at least 4 GB RAM or mostly much more. If any software wants to fully utilize these amounts memory it has to be 64 bit.

CloD development started 7 years ago and thats perhaps the biggest reason why something that should become the foundation of a new series of flightsims for the next decade is still a 32 bit application. I doubt they would loose many sales without a 32 bit exe. Casual gamers with outdated hardware probably don't look for a hardcore sim, but something like WoP.



If you only have 4 GB RAM installed there is no extra memory that 64 bit DCS A10 can use.

Guys, it has only to be recompiled to 64bit, almost no more work for devs.

And forget magical performance improvement ;)

[ATAG_Snapper]

It doesn't really matter if it's standard or not.

Until CloD uses more than 4gb ram we wouldn't really benefit. It only makes sense or is required if the application is actually USING more than 4gb of ram for itself. The OS and other applications don't matter.

I'm running on 16gb here and usually I have a crazy number of applications etc. running. Combined they use the memory but each application only a small chunk. So the applications themselves can be anything - just the OS has to be a x64 version and you don't have to worry about memory issues anymore, if you got a decent amount of ram that is.

When playing CoD I frequently have Task Manager running on a second screen (as well as the EVGA gpu monitor utility) and it usually shows at least 4.5 Gigs of memory in use - frequently more! There are all kinds of applications running in the background, plus for the sim itself I'm running TrackIR5, Ventrilo, Voice Commander, etc.

If I were running Win 7 32-bit and only had 4 Gigs of RAM on my machine (as many in this forum have), would this not be a memory bottleneck? Could this be a reason for performance and stability problems reported for CoD? Perhaps CoD itself uses less than 4 Gigs of RAM, but add in the other applications combined with the 4 Gig limitation of Win 7 (or Vista) 32-bit and you encounter a drastic memory shortage?

[Blackdog_kt]

What you say does happen Snapper, but it's a case of overall RAM management, ie a matter of having enough RAM and a 64-bit OS to use it.

If the sim doesn't use more than 3 GB for example (the entire game folder is about 4 gigs), having a 64-bit executable for the sim won't matter much. What matters is having more than that and an OS that can "see" it so you can give CoD the assumed 3GB it needs and have enough left to run whatever else you need to run in the background ;-)

[Igo kyu]

Guys, it has only to be recompiled to 64bit, almost no more work for devs.
This is very probably mistaken.

If the devs used the sizes of variables in any of a thousand ways that they could, then changing from 32 bit to 64 bit could cause problems. It doesn't have to, if the devs were scrupulous about not using the sizes of the variables it all might just work, but if they used any of the possible optimisations that depend on the sizes of variables, then it will probably be a very long job to make a 64 bit version of the game.

Obviously, I don't know how the devs made the game, but if there were almost any optimisations at all, then simply recompiling it for 64 bit would probably break the code. You'd get error reports from the compiler about what broke where, but sorting that out is typically tricky, because what seems to be broken there is often connected to something that doesn't seem broken here, and that's connected to something else somewhere else, and so on and so on. Eventually you sort out all the connections, but that might be months later. Feeding random code to the compiler and chasing the errors it gives you is probably not the most efficient way of working.

[ATAG_Snapper]

Thanks for the clarification, BD. From my layman's perspective, in terms of memory "more" won't necessarily help, but it won't hurt either.

[hc_wolf]

Try some testing fun. Go to your conf.ini and change the render.

dx10_0
dx11_0
dx10_x64_... or something. I forget. but look in the files you can change dx to a number of dx 10 and 11 settings.

I used to get strange artifacts. But that was a couple of patches back. I have not tried since. Someone give a go today and see how it goes :D

I will look when I get home and post the variations.

[Tree_UK]

I remember very well that Oleg stated in an interview that CLOD would benefit form large amounts of ram, so I was somewhat surprised to find that it only had a 32bit exe.

[Stefem]

This is very probably mistaken.

If the devs used the sizes of variables in any of a thousand ways that they could, then changing from 32 bit to 64 bit could cause problems. It doesn't have to, if the devs were scrupulous about not using the sizes of the variables it all might just work, but if they used any of the possible optimisations that depend on the sizes of variables, then it will probably be a very long job to make a 64 bit version of the game.

Obviously, I don't know how the devs made the game, but if there were almost any optimisations at all, then simply recompiling it for 64 bit would probably break the code. You'd get error reports from the compiler about what broke where, but sorting that out is typically tricky, because what seems to be broken there is often connected to something that doesn't seem broken here, and that's connected to something else somewhere else, and so on and so on. Eventually you sort out all the connections, but that might be months later. Feeding random code to the compiler and chasing the errors it gives you is probably not the most efficient way of working.

This is generally true, probably the most common problem in porting from 32bit to 64bit is that the size of long and pointer change in the 64bit data-type model, but since CoD (accordingly to devs) was designed to be compiled for both 32bit and 64bit target platform I believe that, excluding QA wich is a very important part, it wouldn't require much more work than recompile the game.