-- [ Picked text/plain from multipart/alternative ] Just a note, I think the 64 bit pictures you're seeing on those sites pertain to the client, not the server.
On 1/22/07, Richard Fennell <[EMAIL PROTECTED]> wrote: > > 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 > -- _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
