Interesting tests tbh.
Altough I have a laptop i cannot get the same performace you got on your analysis even tough my hardware performance is similar to yours. (at least thats what I see on the passmark site)
(According to that site a i5-2500k has a 6,411 score and my i72820qm has 6,846
On the same site the hd5850 has 2250 score and mine hd6990m has 2583)
Unfourtunately, Passmark doesn't work as well when comparing different categories of processors (e.g. mobile vs desktop, dual-core v quad-core, etc). There is a good chance you'll see realworld differences even if the Passmark values are similar (as in your case). A quick and dirty adjustment is to compare the scores normalized by thread. For example, the 2500k has 4 threads, so its adjusted score would be (6411/4 1603, while the 2820QM has 8 threads, making its score (6846/8 856. As such, I'd expect your 2820QM to be a little more than half as powerful as his 2500k (on stock). In-game, you'd probably be getting roughly half his fps on average.
So I've figured out why some people are getting an engine error with the DLL switch and why some people are not. Let's clear things up. There's two versions of each DLL. One for 32-bit, and one for 64-bit (if you're running 64-bit Windows). The System32 folder has different bit DLLs in them depending on the OS version. 32-bit Windows correctly has 32-bit DLLs in System32. 64-bit Windows has 64-bit DLLs in System32, and the 32-bit ones for running 32-bit programs are in SysWOW64.
So according to what I've tried, I'm pretty sure this is what is happening: People running 32-bit Windows are getting the "Couldn't initialize render device" error because the DLLs they switch are loaded by the game, and the game rejects it. For people running 64-bit Windows, they are putting 64-bit DLLs into the folder, and the game can't use those so it doesn't even try to load them. That means the game just defaults to loading them from the correct folder in C:\Windows\whatever and correctly starts up. 64-bit users can copy the 32-bit DLL from the SysWOW64 folder and get the same "Couldn't initialize render device" error. The game simply does not load any other DLL than D3DX9_42.dll no matter what you do.
Since the game refuses to load any other DLL I don't understand how this "performance trick" can work. It isn't possible. You can take literally any 64-bit DLL and put it in the game folder and rename it to D3DX9_42.dll and the game will run fine. It simply ignores 64-bit files, and it will only load the 32-bit D3DX9_42.dll. You can't switch these files.
Since the game refuses to load any other DLL I don't understand how this "performance trick" can work. It isn't possible. You can take literally any 64-bit DLL and put it in the game folder and rename it to D3DX9_42.dll and the game will run fine. It simply ignores 64-bit files, and it will only load the 32-bit D3DX9_42.dll. You can't switch these files.
I figured as much but did not know if the 64 bit files were being ignored. I was curious as to what would happen when I removed the dx9.dll and it still loaded up just fine. I even tried the 32 bit ones which did not work. Plus I saw no noticeable difference with the 64 bit .dlls. The problem with those benchmarks is they are from different games that have different circumstances which would mean varying performance levels. Which is why I want a universal benchmark to test these type of things out. I mean some games I do not dip that much but others drag on as more entities are placed.
The D3DX9_43.dll file in c:\windows\system32 is a 64-bit DLL, which explains a few things. If you put this file into your NS2 directory (renamed to D3DX9_42.dll), the OS will attempt to load it, recognize that it's 64-bit, and then attempt to locate a 32-bit D3DX9_42.dll in your system directories This is why you are not seeing the "couldn't initialize render device" error -- it's still using version 42.
On my machine (and probably yours) it will find the D3DX9_42.DLL in c:\windows\system32. This file is actually larger than the one we ship (maybe it has 64-bit and 32-bit included? I'm not sure), so I benchmarked to see if there was any difference. I also relinked NS2 to use D3DX 43.
My benchmark was a client replay, so the exact same client frames were computed in each test, and unfortunately I saw no performance difference between any of the DLLs. This is only one piece of hardware, and a benchmark doesn't necessarily capture all of the different things that could happen during game, but my guess is that people who are seeing performance differences are due to other factors that are varying between games.
The D3DX9_42.dll DLL in system32 that you're talking about is bigger because it's the 64-bit one. The one in SysWoW64 is the 32-bit one and is the exact same size as the one you guys ship. That's the one the game finds when the one in the game directory is missing.
No, SysWoW64 is for 32-bit. Microsoft kept the same name scheme when moving to 64-bit, so system32 remained system32 even though the OS is 64-bit. SysWoW64 is the name they gave for the 32-bit compatibility layer. It's a very confusing name scheme.
I tested this, worked fine, loaded up mineshaft by myself, looked at the waterfall at a certain distance and view, I had the same frame rates before and after the mod, no performance improvements for me
No, SysWoW64 is for 32-bit. Microsoft kept the same name scheme when moving to 64-bit, so system32 remained system32 even though the OS is 64-bit. SysWoW64 is the name they gave for the 32-bit compatibility layer. It's a very confusing name scheme.
I can confirm this. Microsofts 64bit folder organization is a joke.
Unfourtunately, Passmark doesn't work as well when comparing different categories of processors (e.g. mobile vs desktop, dual-core v quad-core, etc). There is a good chance you'll see realworld differences even if the Passmark values are similar (as in your case). A quick and dirty adjustment is to compare the scores normalized by thread. For example, the 2500k has 4 threads, so its adjusted score would be (6411/4 1603, while the 2820QM has 8 threads, making its score (6846/8 856. As such, I'd expect your 2820QM to be a little more than half as powerful as his 2500k (on stock). In-game, you'd probably be getting roughly half his fps on average.
Thank you for the information. I tryed to look for other benchmarks, but its hard to find games benchmarks, comparing both cpus since mobile gpu are diferent then desktop ones.
Anyways. I upgraded my amd drivers to 13.1 and used the dll trick and it seems to run a bit smoother. I manage to play at 1920x1080 with most options on and i manage to get a very good game experience
The D3DX9_42.dll DLL in system32 that you're talking about is bigger because it's the 64-bit one. The one in SysWoW64 is the 32-bit one and is the exact same size as the one you guys ship. That's the one the game finds when the one in the game directory is missing.
I agree that it should be a 64-bit DLL in that location (and the size suggests it), but I inspected the running NS2 process and it does load that particular DLL if the one in the Steam folder is removed. I'm not sure if Windows supports the concept of a universal/fat binary, but maybe there's some trickery like that going on. Either way, it doesn't seem to make any difference for performance.
DC_DarklingJoin Date: 2003-07-10Member: 18068Members, Constellation, Squad Five Blue, Squad Five Silver
Disabling the page file is foolish.
* Windows can not write away a crash dump if it crashes, because it needs a minimum pagefile on its system partition for that.
* Unless you have a great amount of memory, running without page file will max out memory usage.
* When completely out of memory, windows will crash.
* When certain parts run out, windows may not completely crash but behave oddly. (menu's which suddenly do no longer populate for example)
If your pagefile is the reason why you slow down, and in NS2 I doubt this, get a small SSD and put a 2nd pagefile on that partition. (Keeping a small one on the system partition for crash dumps).
Qualify does not need to be impressive if you are only pagefiling, although I do expect a much shorther life expectancy on it then.
dll swapping is as people already noticed a placebo. On a margin of 5 to 10 fps, anything can influence that range making 'real world' tests a moot point. Having a little more cysts on the same map can already lower fps enough to make this test rather useless.
Just like OP I did some empirical testing on this matter. My results imply same kind of increase in fps. I don't believe just building couple of cycst around the map cover such even increase through the both games. I included my specs as attachment if you're interested.
Other thing to notice: My average fps has always stayed around 69-77 with but have never gone close to 90 as now with both rounds with new dx library.
All rounds have been recorded from the start to the end.
edit. Oh yes. Data has been smoothed to be more readable using moving average with 20% span and Robust Loess (quadratic fit) method.
Just like OP I did some empirical testing on this matter. My results imply same kind of increase in fps. I don't believe just building couple of cycst around the map cover such even increase through the both games. I included my specs as attachment if you're interested.
Other thing to notice: My average fps has always stayed around 69-77 with but have never gone close to 90 as now with both rounds with new dx library.
All rounds have been recorded from the start to the end.
edit. Oh yes. Data has been smoothed to be more readable using moving average with 20% span and Robust Loess (quadratic fit) method.
Were those different matches? If they were performance can vary. Could you maybe post the results when recording benchmarks in the same game? You can try using the demo here
Just like OP I did some empirical testing on this matter. My results imply same kind of increase in fps. I don't believe just building couple of cycst around the map cover such even increase through the both games. I included my specs as attachment if you're interested.
Could you do a more consistent comparison? Specifically, record a 20 min demo then benchmark the recording with and without the new dll.
Were those different matches? If they were performance can vary. Could you maybe post the results when recording benchmarks in the same game? You can try using the demo here
The OS uses a pagefile to store programs (etc.) that cannot fit on the RAM and may need to be loaded up quickly. If the OS is efficient and you don't have too many things running in the background, NS2 should be completely stored in the RAM whether or not you have a pagefile. If disabling the pagefile does give any performance increase, then you will see just as much benefit from running less background applications.
Don't disable the page file unless you got 4gb RAM or more, if you got less you risk crashing applications when your RAM runs out.
Despite its warnings that programs may not run correctly, I believe that Windows will actually create a pagefile without informing you if it runs out of space. The problems it is warning you of are the fact that without the pagefile, it will have to completely remove a current program from memory (instead of temporarily moving it to the pagefile) and load the new program from the hard disk. If it has to do this often, then you're going to see huge slowdowns. But again, if you've got many programs running at the same time as you're playing NS2 then you're playing NS2 wrong.
Veil, 20 mins. I5 OC to 3.8, W7x64 with 8gb RAM 8-8-8-24 @1600 vertex3 SSD on 6gb channel. ATI 6850 running max detail@1080p, no AA no occulsion, no texture streaming.
Comments
So according to what I've tried, I'm pretty sure this is what is happening: People running 32-bit Windows are getting the "Couldn't initialize render device" error because the DLLs they switch are loaded by the game, and the game rejects it. For people running 64-bit Windows, they are putting 64-bit DLLs into the folder, and the game can't use those so it doesn't even try to load them. That means the game just defaults to loading them from the correct folder in C:\Windows\whatever and correctly starts up. 64-bit users can copy the 32-bit DLL from the SysWOW64 folder and get the same "Couldn't initialize render device" error. The game simply does not load any other DLL than D3DX9_42.dll no matter what you do.
Since the game refuses to load any other DLL I don't understand how this "performance trick" can work. It isn't possible. You can take literally any 64-bit DLL and put it in the game folder and rename it to D3DX9_42.dll and the game will run fine. It simply ignores 64-bit files, and it will only load the 32-bit D3DX9_42.dll. You can't switch these files.
EDIT: Slight corrections.
I figured as much but did not know if the 64 bit files were being ignored. I was curious as to what would happen when I removed the dx9.dll and it still loaded up just fine. I even tried the 32 bit ones which did not work. Plus I saw no noticeable difference with the 64 bit .dlls. The problem with those benchmarks is they are from different games that have different circumstances which would mean varying performance levels. Which is why I want a universal benchmark to test these type of things out. I mean some games I do not dip that much but others drag on as more entities are placed.
On my machine (and probably yours) it will find the D3DX9_42.DLL in c:\windows\system32. This file is actually larger than the one we ship (maybe it has 64-bit and 32-bit included? I'm not sure), so I benchmarked to see if there was any difference. I also relinked NS2 to use D3DX 43.
My benchmark was a client replay, so the exact same client frames were computed in each test, and unfortunately I saw no performance difference between any of the DLLs. This is only one piece of hardware, and a benchmark doesn't necessarily capture all of the different things that could happen during game, but my guess is that people who are seeing performance differences are due to other factors that are varying between games.
I can confirm this. Microsofts 64bit folder organization is a joke.
Thank you for the information. I tryed to look for other benchmarks, but its hard to find games benchmarks, comparing both cpus since mobile gpu are diferent then desktop ones.
Anyways. I upgraded my amd drivers to 13.1 and used the dll trick and it seems to run a bit smoother. I manage to play at 1920x1080 with most options on and i manage to get a very good game experience
* Windows can not write away a crash dump if it crashes, because it needs a minimum pagefile on its system partition for that.
* Unless you have a great amount of memory, running without page file will max out memory usage.
* When completely out of memory, windows will crash.
* When certain parts run out, windows may not completely crash but behave oddly. (menu's which suddenly do no longer populate for example)
If your pagefile is the reason why you slow down, and in NS2 I doubt this, get a small SSD and put a 2nd pagefile on that partition. (Keeping a small one on the system partition for crash dumps).
Qualify does not need to be impressive if you are only pagefiling, although I do expect a much shorther life expectancy on it then.
dll swapping is as people already noticed a placebo. On a margin of 5 to 10 fps, anything can influence that range making 'real world' tests a moot point. Having a little more cysts on the same map can already lower fps enough to make this test rather useless.
Other thing to notice: My average fps has always stayed around 69-77 with but have never gone close to 90 as now with both rounds with new dx library.
All rounds have been recorded from the start to the end.
edit. Oh yes. Data has been smoothed to be more readable using moving average with 20% span and Robust Loess (quadratic fit) method.
Were those different matches? If they were performance can vary. Could you maybe post the results when recording benchmarks in the same game? You can try using the demo here
http://forums.unknownworlds.com/discussion/127867/benchmark-demo-thread#latest
Try one test normally and the other with the dll using the same game settings. Then post what you get.
Old DLL:
New DLL:
Looks like no change to me.
Despite its warnings that programs may not run correctly, I believe that Windows will actually create a pagefile without informing you if it runs out of space. The problems it is warning you of are the fact that without the pagefile, it will have to completely remove a current program from memory (instead of temporarily moving it to the pagefile) and load the new program from the hard disk. If it has to do this often, then you're going to see huge slowdowns. But again, if you've got many programs running at the same time as you're playing NS2 then you're playing NS2 wrong.
If windows runs out of RAM it blue screens.