Has anyone played SL with a 64-bit CPU?

Hiyah all! I was wondering... if anyone plays SL with a 64 bit CPU, and how does that 64-bit'ness effect SL's performance. Im thinking of buying a computer, but cant decide wether to go with a 64 bit athlon, or a 3ghz Hyperthreading P4.

Anyone have one?

==Chris

It will probably not affect SL significantly. My understanding is that the 64 bitness of a cpu will affect the performance of software that is coded to take advantage of it.
Dude, you have way too much money you know. My PC is 3 yrs old and runs SL just fine. You'll pry this baby from my cold dead hands
Heh, lately I've been mostly playing Master of Magic, a 10 year old game, and coding Darwin's login system for maythria. Not awfully resource intensive

Dude. I thought you were in college. Wow.

Heh, saving money is probobly one of the best ideas I've carryed out in a long time

Yeah... but how friggin much man? That's like 4,000 dollars, right?

The SL sim servers may benefit from 64bit CPUs if the servers were compiled to take advantage of it.

I can't imagine the client benefiting from memory mapping above 4GB though.

Well, I doubt the servers would even benefit from 64bit computing because most lines can't handle that much data, so it would never really get enough data to proccess. I mean, it would do it with greater ease, but so would a proccessor that's simply faster.

Mmm, you have Intel on the brain.

Remember, 32 195mhz processors are faster than even a dual 3.06ghz

Oh heheh yep. My bad.

Of course, to be totaly obnoxious:

It would be soooooo hard to synchronize 32 proccessor's to work in sequence OMG WTF LOL!!!111!11!

Not when you have a one-threaded processor gobbler like SL

The 64-bitness of the new hammer-core AMDs isn't going to help SL at all. Nor, at this point, will hyperthreading help in any discernable way.

We're unlikely to create a version of SL compiled for x86-64 anytime soon - the only benefits of this would be access to the larger register file (which might marginally improve performance) and access to larger memory sizes. I should hope we won't be using up more than 4GB any time soon.

In contrast, with HT chips becoming more common, we *might*, eventually, multi-thread SL in such a way that it gains a performance boost from HT and SMP systems... but doing this isn't a high priority since optimizing for the latest and greatest CPUs while ignoring older, slower stuff isn't a great strategic move.

What's relatively unknown at this point is how SL's performance on the new Athlon-64/Opteron compares to the P4 - AMD's new chips have a number of architectural innovations which make them fast regardless of the 64-bit stuff, especially for an application like this one. SL is hard to benchmark; framerates fluctuate based on myriad factors so I wouldn't put alot of faith in people's "I get 30fps on my 3Ghz P4!" assertions. And, we don't have enough experience with the AMD chips here at LL to make any real recomendation.

So, I realize this isn't very helpful, but it will hopefully clear up some questions about these technologies.

I've worked out a couple of "benchmarks" for SecondLife: in the vehicle sims, the framerates when standing in the middle of the green track starting gate looking south, and standing on the southmost tire stack in the rezzing area looking north. Since framerate (and physics performance, but I can't control that) while racing is where it matters most for me, that's where I do testing.

On the subject of multithreading in SecondLife, I noticed that the SL executable has five threads running. One of them is obviously the main render thread, but what do the other four do if hyperthreading won't give a significant boost?

Known locations are a good starting point, but you also need to factor in:

- draw distance
- enabled graphical effects and other settings
- number of avatars visible
- number of objects/textures/particles visible
- number of sounds playing/preloading
- number of known objects (did you teleport or fly a long distance recently? Are there still sims on your minimap that are outside your draw distance?)
- bandwidth settings

Internally, we can control all of this using static test sims, but it's not so easy in the production environment.

One of the other threads is an I/O thread - it spends most of its time asleep, either waiting for requests or blocked on the filesystem. The others are controlled by Windows/various drivers, and also don't do much CPU work on their own.

I believe my P4 3ghz is hyperthreaded, I could be wrong but I'm pretty sure it is.

I get 39fps... if I stand in an empty field and a bunch of other variables as Ian said, lol.

SL runs pretty fast though, the only "lag" issues I've had are the typical ones everyone gets.

Ask me a question that would better see if it makes SL run faster/better with hyperthreading, cuse I really can't think of any examples. I mean it loads fast and new areas pretty much load quickly, but that could all have to be more cuse of my ADSL rather than my P4.

Everyone else pretty much covered the rest I was thinking, the only real advantage you'd get with hyperthreading and/or 64 bit is from future top of the line programs/games that will take advantage of them, I've heard Half Life 2 has some hyperthreading something. I'm not aware of any 64 bit programs out right now though.

It might be a good future investment, but if you think about it once hyperthreading and 64 bits get popular they make make improvements and the such, so it might be better to go with whatevers cheaper now and wait untill they really start putting the things to use.

Ask over in the Mac Alpha forum... pretty sure some people there are running on G5's, which are 64-bit, if I remember correctly.

And yes, I remember correctly .

Just fyi...coordinating CPUs is largely a matter of software, and the tools exist. For example, the MS Datacenter operating system--which almost nobody knows even exists--can coordinate processors to the extent that you can actually hot swap them and the software will redistribute the load on the fly...as in unplug a rack and rip it out, and the system will remain whole. That particular OS is created largely for the big Unisys multiproc boxes and is intended as an answer to the IBM mainframe and Solaris multiproc solutions...but there it is. Furthermore, you can cluster and load balance these solutions.

SL would gain no significant benefit at all from a 64 bit architecture at this point in time, unless it was completely rewritten, and even then the difference would be marginal, and user base slim to none, I suspect. Remember every piece of the subsystem, including graphics drivers and so forth, would need to be rewritten or you would have to use a compatability mode, similar to running a 16 bit program on Windows today...and that is not recommended at all.

Actually, 64-bit processors almost always support 32-bit code without using a compatibility mode.

If you have a P4 running at 3GHz I can pretty much guarantee it's a C-revision, meaning that it's hyperthreaded. If you want to see for yourself, hit ctrl+alt+del, go to the performance tab, and see whether CPU Usage History has one graph or two.

One graph = non-hyperthreaded, two graphs = hyperthreaded.

Having hyperthreading results in statistically insignificant gains as far as SL is concerned. When an app which is mostly single-threading is pegging the CPU, you will see about 50% usage on both graphs. When multiple threads (from one or more apps) are pegging the CPU, you see more like 60-90% use on both graphs.

One benefit of hyperthreading is that SL plays nicer with other apps. You can have SL running and start other apps (even heavy apps that like CPU) without too much interference. You will see the load spike up above 50%, and it feels pretty much like SL isn't even running. Of course this is dependent on the divergence of resources demanded by whatever is running on each "thread pipe" (for want of a better term) - hyperthreading works by letting one thread use CPU resources not currently required by another.

As for 64-bit CPUs, these are mainly useful if you want to access more than 4 gigabytes of RAM without having to use overhead-laden bank-switching methods. The larger registers are also a factor, but they only matter for integer mathematics. Great if you are writing something on the Descent engine, which uses fixed-point multiplication. However, this is not 1995. Everyone has FPUs these days. All the hard stuff (i.e. the floating-point math) is handled in the FPU, which does not use the integer registers (which are what have been taken up to 64 bits.)

What advantage those chips MIGHT have is in the area of onboard memory controllers. I don't know how much that matters against a P4 like mine, with the front-side bus running at 880MHz.

For what it's worth:

Multiple threads and hyperthreading are not the same thing, or even that closely related. Intel's HT "splits" the CPU into two virtual CPUs, allowing the processor to literally perform two operations simultaneously.

Multithreading is software based and allows a single process ("program" to have two or more running streams of operation. This allows you to do things like keep busy while accessing the disk, run event-driven programs and OSs, and share namespaces.

If your 3GHz P4 with HT is running SL really well, it has more to do with the 3GHz than it does with the HT. Also, your P4 also has faster memory, disk, FSB than someone's 1.2Ghz Celeron. It all adds up. I **think** 64-bit processors might be able to increase the throughput of SIMD, certainly HT will.

Finally, I remember some old advice about buying computers: better to spend every cent (euro?) you have budgeted for it. Paying the premium price for the cutting edge technology today is probably cheaper in the long run than having to replace today's budget computer with next year's budget computer. But as I said, this is old advice - PCs are commodities these days.

Hmm, I could be wrong on this Ian, but I think either Andrew or Doug said a while back that SL's audio is actually handled in a separate thread already? If this is the case, it should already have a marginal benefit from HT. Though when I say marginal, I mean barely measurable

If SL and other games are your bottleneck application, put the money into a high end video card with lots of fast RAM on it. It will take a significant load off the CPU and look prettier in the end.

The audio playback is in a separate thread, so HT/SMP will help a tiny bit there. However, the playback is more efficient than the audio decode which is unfortunately handled on the primary thread. We will address many of the sound issues in an upcoming version.




SL looks significantly better as you slide up the video card scale, but the application itself is more CPU bound than GPU bound. If you already have AGP and vertex shader support, a faster CPU and more main memory will get higher framerate than a spiffy new graphics card.

I'm running an Opteron 240 right now (just upgraded ). Single processor but hopefully another when I've got some more money to spend. I run SL just fine - Windows is 32 bit .

I also run Gento 64 bit, but due to Wine not being compilable in 64 bit and I haven't figured out 32 bit emulation (hint if anyone can help me with this please do!) I won't be able to try 64 bit SL yet.

I've kinda been considering getting the Windows XP 64 bit beta, but I don't really want to bother with it as it's buggy and I'd have to find 64 bit Windows drivers for all my hardware, which would be a royal pain.

From my experience with Gentoo 64 bit, any program that uses 32 bit assembly won't compile in 64 bit so if a Linux version of SL ever does come out there's little chance there would be a 64 bit version. Of course there's the emulation libraries I mentioned above that would let a 64 bit environment run a 32 bit program, but it just runs in 32 bit mode then and doesn't gain any 64 bit enhancements.