Valtteri Kiviniemi wrote:
Hi
My experience is that, if you run 64bit OS and 32bit binary, the
operating system will emulate the program, and it decreases performance
and consumes more CPU. I have AMD64 debian installations, and if I run
hlds_amd binary (the 32bit one) the server FPS is only ~200-300 and it
consumes ~3-5% CPU at IDLE, and with 10 players about 20%...
With the outdated hlds_amd64 binary the FPS is constantly 500 and the
server consumes about ~5-8% CPU with 10 players. I suggest that if you
want to run the updated 32bit binary, you're better have pure 32bit OS.
The outdated hlds_amd64 binary is IMO better and the hitreg is perfect.
I don't care how outdated it is, becauce the fact is that it performs
much better than the 32bit installation, and consumes less CPU.
I'll update to the 32bit installation only when the 64bit binary wont
work anymore.
REMEMBER: don't fix it if it ain't broken..
The idle CPU usage is not really a good benchmark. This is more a
display of how much overhead the kernel interrupt has. For example you
could very well have a 1000hz 32 bit kernel and a 250hz 64bit kernel.
The 250hz kernel will use much less cpu usage at idle as it is doing 4
times less interrupt requests. (possibly 500hz kernel as you have
suggested a 500fps max on your game server).
This could also be effected by VAC2 as you are running VAC1 or insecure
on the 64bit version.
While like you i am very dis-heartened by valves lack of 64bit support
(after purchasing 60+ 64bit AMD CPU's do to the performance increase)
however i think you MAY be comparing apples with oranges. Also remember
that Vac2 (Which i believe runs in a seperate thread) may be using some
of those interrupts (effecting your fps and cpu usage).
To get your tests more accurate both kernels should be compiled with as
similar config as possible, hardware should be exactly the same and both
game servers should run without VAC. (-insecure in the command line).
It may also be something to do with the c++ libraries and the
gettimeofday() procedure taking less time (More efficient in the kernel)
to run on 64bit. This is used a lot in HLDS/SRCDS and is the reason your
server will crash should you do an NTP update or change the time on the box.
What is more worrying to me is that it seems valves programming toolset
is fast becoming more restrictive to us to which point they could end up
dropping Linux all together. It seems at first their compiler is unable
to compile Linux with 64bit and now the Linux binaries are fast becoming
vastly inefficient in comparison to their windows counterparts.
This could be due to the work load involved in recoding and maintaining
parts of the program specifically for Linux (which may not be
financially possible). Keeping both binaries running different branches
could mean different bugs and 3 times as much work. Whatever the reason
VAC2 and SRCDS are by far more efficient on windows and if the current
trend continues we will see a death of the Linux version within a year
or two.
Possibly the funniest part of this saga is the AMD64 logo on the
http://half-life2.com/ website and the
http://amd64downloads.filecloud.com/hl2.asp site.
I am not trying to flame valve. They consistently support their products
for years after release and are always helping the community. I love to
play their games and have the utmost respect for their software and
staff. What I am trying to highlight is that its been a downhill run for
the Linux distro for at least the last 3 years and i cannot see it
changing. Did Valve change compilers in late 2004 early 2005? Was it
related to the Source release? Most importantly, Are there any plans to
stop this getting any worse?
(Most of the information in this email is based upon my experimentation,
experience and the assumptions formed from these. I am probably wrong in
several places :) )
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlds_linux
