Running Slower on a 64 Bit Processor

I'm working on a new version of a game with an old game engine (I found a comment in the code that said it was a fix for Windows 95!). We have about 20 people working on this project between the developers and the testers. People with dual core Pentium machines have been complaining about some functions being slow for several months. The only dual core I have here is an AMD and while it's slightly slower than single cores, it's not significantly slower.

My main development machine is a 64 bit AMD single core running XP. I also test on an older Athlon 32 bit machine that is 4-5 years old.

I came across a function that runs slow on the 64 bit machine, but runs much faster on my older Athlon. So now I have an example of the problem.

I'm not surprised this game engine has problems. It's a very weird implementation of a Windows program. It looks like it was originally ported to Windows (most likely 3.0 or 3.1 by people who didn't really understand Windows.

Anyway, I'm now stuck at where to go from here. Does anyone have any cheap to free utilities or testing techniques that might help me expose exactly where and what the problem is?

Bill

How about profiling? In Visual Studio 2008 you can use the integrated profiler. Otherwise there are other tools out there, such as DevPartner (they have a community edition with a 1 month free license).
A profiler will indicate the areas in your code that take longest to execute.

Regards

A 64 bit program will be bigger and run slower than its 32 bit counterpart. (in 99.5% of all cases).

This is to be expected. If you think you are going to get more speed by using 64 bit, then you do not understand many of the funcamentals of computer systems.

A single pointer takes TWICE as much memory, and TWICE as many accesses to RAM, and is HALF the speed on a 64 bit sistem. Because the individual instructions are BIGGER you get FEWER in cache.

THE reason for going to 64 bit is because you can easily access more than 4GB of memory (even accesing more than 2GB on a 32 bit machine has issues). If you are NOT using more than 4GB of memory, then you are unlikely to see any benegfit, and WILL see performance issues.

This isn't compiled for 64 bit. It's a 32 bit program no matter what platform it runs on. We've just seen problems running on 64 bit hardware.

Bill

Then it is possibly bacuse of the dual core and may have nothing to do with 64 bit. The timing differences and potentials for cross-thread issues are much greater.

Remember that on a single core, only one thread is executing at a time. Therefore the issues arise when a context switch ovccurs in the middle of an operation. On a multi-code, threads are truely running at the same time, and individual instructions DO overlap.

Given the age of the program, I would start seriously looking at this aspect.

Quote:

---

Originally Posted by TheCPUWizard

Remember that on a single core, only one thread is executing at a time. Therefore the issues arise when a context switch ovccurs in the middle of an operation. On a multi-code, threads are truely running at the same time, and individual instructions DO overlap.

---

That's the point I wanted to mention first...

Second, There are thousands of functions that are obsolete and they must be replaced by new versions of that(especially faster or more advanced). they usually exist for compatibility with 16 bit windows.(specially when they were programming for win95).

So what will happen if you use them on 32 bit platform? in many cases a bit slower(depend on implementation), what about 64bit? again worse.

And finally the third one, you said "game engine", it means an old version of DirectX or OpenGL, for example DX7 and DX8 are extremely old and slow in comparison to current equivalent functions, you think they are the same functions, but they are NOT. At that age they used to use ASM for most of their codes and to simulate many functionalities.

what is the solution? If it is possible then rewrite those pieces of codes for 64-bit CPU or at least exactly 32bit(if they are 16 bit).

Quote:

---

Originally Posted by TheCPUWizard

A 64 bit program will be bigger and run slower than its 32 bit counterpart. (in 99.5% of all cases).

This is to be expected. If you think you are going to get more speed by using 64 bit, then you do not understand many of the funcamentals of computer systems.

A single pointer takes TWICE as much memory, and TWICE as many accesses to RAM, and is HALF the speed on a 64 bit sistem. Because the individual instructions are BIGGER you get FEWER in cache.

THE reason for going to 64 bit is because you can easily access more than 4GB of memory (even accesing more than 2GB on a 32 bit machine has issues). If you are NOT using more than 4GB of memory, then you are unlikely to see any benegfit, and WILL see performance issues.

---

Well...I don't want to get too much into it since it is kind of off-topic however, the above is a little bit misleading in my eyes. It is a common misconception that 64-bit does not generate any performance improvements unless the system has more than 4 GByte of RAM. A common example is the Windows operating system which actually maps system dlls and OS components into a process address space and thus reducing the total address space (worst case can be 2 GByte available on a 4Gbyte system). Since 64-bit systems do not have the limitation, one can actually reclaim the missing memory.

Some applications can actually benefit from larger registers (encryption software is one example) and thus execute faster by some magnitude.

Now, certainly there is still the disadvantage you mentioned....the same data take up more space in memory on a 64-bit system. However, there are techniques available to minimize the impact. So the statement of being twice as slow as on 32-bit is a bit too simplified.

The game engine is designed around DX 7. I did finally track down at least one function that is causing problems. Deep down in the call tree it is using a couple of LPDIRECTDRAWSURFACE7 types.

I've never worked with Direct X before, all my other projects have been in the corporate world, I cut my teeth doing embedded programming, which did teach me to be efficient. Processing power and memory are usually restricted. In any case, I'm just getting into the DirectX documentation. It doesn't look as bad as the Microsoft MAPI documentation, but it not that much better...

We do want to compile this for 32 bit processors because there is nothing in the game to have any reason to cut down on our potential market like that. One of our testers is using Windows 98, though how he shoe horned it into the 512MB memory space is beyond me.

If I can figure out how to convert to DX 9 and it would speed things up, that would be fine. It's not unreasonable to require DX 9 and it's compatible back to Win 98, though I think we're going to set the requirements to Win 2000 and later.

Bill

Quote:

---

Originally Posted by Andreas Masur

So the statement of being twice as slow as on 32-bit is a bit too simplified.

---

I did not mean to imply that the program taken as a whole would be twice as slow; I was explicitly talking about one (common) operation (the dreferencing of a pointer, whe the pointer value is currently in memory (not in a register).

There are some operations that ARE faster, a very few that are identical, and many that are slower (with a worst case of 2x). When compined into a typical program the overall effect is statistically (by a large majority) a slower program.

Again, this statement is based on taking source code (C++) from a 32 bit application and simply re-compiling it. Redesigning it to take advantage of 64 bit (eg much larger emory buffers rather than partial caches) can yield a significant improvement.

Tracking deeper into the code that I know has had problems, there is a loop with a call to

Code:

---

ddrval = whatSurf->Blt(&tgt,pdds,&src,flag,dfx);

---

It's in a while loop that will keep running until the function returns S_OK. The time out is 10000 iterations of the loop. I'm beginning to suspect that the problem may be here.

Further testing needed...

Bill

Optimization of 64-bit programs
http://www.viva64.com/art-1-2-1756520624.html
Abstract. Some means of 64-bit Windows applications performance increase are considered in the article.

AMD64 (EM64T) architecture.
http://www.viva64.com/art-1-2-1496710594.html
Abstract. The article briefly describes AMD64 architecture by AMD Company and its implementation EM64T by Intel Company. The architecture's peculiarities, advantages and disadvantages are described.

Development of Resource-intensive Applications in Visual C++
http://www.viva64.com/art-1-2-2014169752.html
Abstract. The article will familiarize developers of application software with tasks set before them with the mass introduction of 64-bit multi-core processors symbolizing revolutionary increase of computing power available for an average user. It will also touch upon the problems of effective use of hardware resources for solving everyday applied tasks within the limits of Windows x64 operating system.

We made some progress on what was causing the problem. We had a somewhat lengthy report generated for debugging purposes. When the generation of that was shut off, the game ran much quicker on 64 bit processors. The generation of this report didn't have much of an impact on 32 bit processors.

I have no idea why heavy disk I/O would impact some machines so significantly and older machines would actually run faster under the same load. You'd think the chip set would have been tested under these conditions. Unless there is some interaction going on like DirectX and heavy disk I/O is screwing things up on the slow machines.

Bill

Hmm, that *is* curious. My XP64 machine at work and another bought at the same time always seems to be very slow on the disk access side----both on Windows and Linux, it seems, so it's probably not a driver issue. Not sure what it might be.