32-bit vs 64-bit

Well, that depends on how one looks at "efficient". It may not operate exactly the same... but the efficiency of code can be just as good. And that's the point. SL is still using the Havok 1 engine and we're up to what... Havok 4 now? How outdated is that? Is Havok even the best engine for SL to use at this point?

I remember a while back LL announced they weren't planning on upgrading to Havok 2 (which is already out of date) because SL was working well enough that such an update was not required. I'm sorry, but SL is no where near working well enough.

Old business addage: people make excuses. Winners don't. The point that's being made here (and in about 3 other threads I'm aware of at this time) is that as good as SL is... it could be way better if a team was assigned to the sole, permanent task of tweaking the core engine. That means both server-side and client-side software. Because if as some have claimed (although wrongly, I believe) that "lag" is due to client-side "problems"... those problems are caused by the SL software-- not my duo-core, 1 gig RAM, X800-XL 256meg DDR3 PCIx computer running on a 4.5mbps cablenet connection.

While we're talking tech... a brief note. I hear people discuss FPS and ping and other measurements, and all that is fine and good. I speak techanese. But I've found over the years that simple common sense can bypass pretty much all of that. Example: When I'm using SL, does it slow to a crawl, freeze me in place, take 3 minutes to do a simple inventory search, take 10 minutes to load textures? When the answer to all of those questions is yes, yes, yes, yes, yes... that's not client-side problems. FPS doesn't matter at that point. What matters is grid-wide user experience of the system. FPS is nothing but a measurement of a symptom. I've often seen times when the Time Dilation and Sim FPS readings were just fine, but I and others were crawling. That goes to deep-core, software-oriented problems. Even a non-tech person can figure that one out.

Now that deep-core may be server oriented (hardware), server-oriented (software) or client-side software (ie, Secondlife.exe)... but the problem obviously exists. The only question left after that: what is LL going to do about it. Make excuses and leave it as it is-- or go in with the magnifying glass and bazooka?

Only the latter attitude will hunt down and kill the Lag Monster. But we digress; question is 32 bit vs 64 bit. At this point, 64 bit duo-core is great for running multiple applications at once, but as far as SL goes, a good, fast 32 bit solo system with a heavy-duty graphics card will do just as well.

Running AMD Dual Core. I get no noticable performance change between using 1 core or both.

Havok completely irrelevant, since physics is handled on the server.

It doesn't matter how efficient the code is, if the SL engine has to do more work. I just checked out Unreal, and the busiest scene had less than a dozen 3d objects in view, because most of the objects in view had been replaced by precomputed mattes - projectiles were all particles, any object far enough to be "fogged" was a simplified version... a base in the distance was little more than a textured cylinder.

In SL, you can easily have 30,000 objects inside your draw distance, and the client has to track all of them, and upload all non-culled objects to the video card even if they're barely visible.

In Unreal, you have a limited set of camera views, and you don't get to change them without changing your state, so it never has to recompute a culling tree without warning. In SL your camera can be anywhere.

In Unreal, there's a limited set of object types. All mantas look the same. In SL every object is unique.

The SL client is imply doing more than the Unreal client, and the only way to NOT make it do more is to massively reduce people's options.

I don't think anyone's said that all lag is client side. Obviously a lot of it is server side. But the server simply isn't involved in the rendering of things like particles.

EVERYTHING is a "software problem".

The texture problem and other downloading problems are due to Linden Labs naive implementation of a kind of pseudo-TCP on top of UDP. That's definitely a problem LL needs to fix (I think they should use TCP for downloading large assets, personally). But that's got nothing to do with the performance of your computer, 32-bit versus 64-bit, or whether other games are "more efficient".

Dual core runs SL better than single, simply because it lets things other than SL (like, say, processes that are part of the OS) run at full speed on SL's behalf. My Athlon 64 X2 runs SL *significantly* faster and more responsively now that I have both cores working. Whether SL itself runs threads on both cores or not, you're still better off with two cores.

LOL. Havok is completely irrelevant? LOL

If you checked out Unreal and all you saw was 16 objects... you've never been in an Unreal Invasion tourney with dozens of monsters coming at you and dozens of fighters fighting them. I think there's a bit of oversimplification there. I understand that Unreal works differently than SL... but that's kind of the issue, isn't it?

Regarding SL rendering "30,000" items... nah. First of all, items farther than 20m are automatically culled by SL depending on size of the object. If a user has his vision set at 128m (or the standard 96m) then anything beyond that range is automatically culled. As far as objects and prims, man, systems have been doing simple vertex graphics (which is basically the equivalent of what SL graphics appear to be) for more than two decades.

Sometimes I think techs are so busy studing the bark they can't see that the forest is on fire. I know from personal experience, that quite often techs get so knee-deep in code, they can't see a simple solution to a problem. They forget to look outside the box.



Sure it does! The server is involved in absolutely everything that happens in SL. It might not render the actual particles themselves, but it for sure has to tell the client where and how to render them. (I think we had this same debate elsewhere, didn't we Argent? And we discussed the very same things there. And we're doing so yet again?). It is pretty obvious the server has a lot to do with the generation of particles. Otherwise, how is the client supposed to know when, how, and where a particle moves or changes (especially those attached to avatars). I've heard this claim of "client handles all particles" before and it just doesn't wash. Unless SL is a peer-to-peer system... the server HAS to be significantly involved.



Which is exactly the point. It's not the user or the user's equipment... ie, the ball is in LL's court.

Whether they were using Havok 2, 3, or 4, the client would still be faced with rendering hundreds of times as many objects with a fraction of the optimizations available.
I wasn't counting characters in the 16 objects... the job of rendering characters is harder in SL, too, but that's just muddying the waters here.
Yes, but not in the way you mean. Unreal works differently than SL because Unreal can work differently from SL. If you were to restrict SL the way Unreal is restricted, so it could have the same kind of rendering speed as Unreal, you'd lose:

* In-game building.
* In-game scripting.
* Custom textures. When you entered an estate, you'd be restricted to using the textures assigned by the estate owner.
* Attachments.
* And more...

You wouldn't end up with Second Life. You'd end up with "There".
I'm accounting for all of that: I explicitly mentioned it, in fact, when I pointed out that even culled objects have to be tracked by the client because the client has no idea of where you OR your camera are going to move next. And at a 4 sim corner of an object-dense area (Like, say, Gibson... where two sims worth of objects are crammed into two quarter-sims) you can easily have 30,000 objects in draw distance.

My draw distance is normally 256. That can put 60,000 * 4 / PI... 40,000 objects... in draw distance even without special cases like that.
Yeh, I know. I started hacking on graphics in 1981.
Yep, and you completely missed the point there too. Let me try that again.

If the server is lagged, then it won't update the particle emitter and target. The client will leave the emitter and target following the last path the server gave it. The particle system will continue to run, based on the last particle system downloaded from the sim. No matter how lagged the sim is, the particle system will continue to emit particles. The sim can even go offline, and the particle system will continue to run until the client finally realises it's gone and grays the screen out. Lag on the sim doesn't have any effect on particle systems, and particle systems don't have any effect on the sim.

There is an effect from sim *activity*, since the particle system is competing computationally with everything else the client is doing. But that effect is *least* when the sim is lagged (and thus not sending updates) and *greatest* when the sim is healthy.

Particles aren't attached to avatars. Prims are attached to avatars, particles are emitted by prims. But... the server doesn't know where any of the prims attached to an avatar *are*. As far as the server is concerned, *all* objects on an avatar are located in the center of the avatar's bounding box.

This isn't a "claim" by some random forum pundits, this is what Linden Labs programming documentation describes. The *only* thing the server knows, and tells the client, is the position and velocity of the avatar. Everything beyond that is handled by the client.
Yep, and there's lots of things that they need to fix. There's other things they *can't* fix, and this is one of them. I really hope LL doesn't listen to you and dumb down Second Life until it's as barren and pointless as "There" just so you can get a higher frame rate.

Argent, we've had the conversation about particle generation and server side/client side before. You already know I disagree with the claim that the server has very little to do with particle generation. This thread is about 32 / 64 bit processors, yes? To settle this continuing-across-multiple-thread issue, I've contacted LL. I'll let you know what they say, one way or the other.



I'm not recommending they "dumb down" the system... nor did I even intimate such. Just the opposite-- I'm recommending they make it smarter. Fix the code. Correct the glitches. You keep arguing how the system is so great. In some ways, SL is unique. That doesn't mean it's efficient coding. Argue for it all you care... the problems are there, they're obvious... and they're fixable.

There is absolutely no reason an inventory search should lag an avatar to a standstill for 3 minutes. There is no reason an entire sim should lag to syrup for 30 seconds to a minute, then run just fine. There is no reason textures should take 10-30 minutes to load. Those are problems of code... and they need to be fixed. That is all that I or anyone has said. Technoese does not alter that reality.

Anytime someone tells me something that "can't" be fixed... I'll go out and find the person who will fix it anyway. I've worked with programmers and techs for years. I've seen people who were capable but limited in scope, people who knew nothing technically but were geniuses at trouble-shooting, and people who knew no limits period. I've watched as certified techs gave up on a problem only to have someone else solve it (I once solved a serious Novell problem when the certified techs gave up).

Some people don't know the meaning of the word "can't" and they don't make excuses. Those are the ones who succeed. Some folks get stuck on the blueprints... while others fix the pipes.

This is a thread on 32 vs 64 bit systems... not on the technical operations of SL particle generation. We've heard the server vs client arguments before. I believe the question of the thread is 32 vs 64 bit processors.

It think there have been a couple of good answers so far: a high-clock-speed 32 processor might run SL itself faster. But duo-core can divide behind-the-scenes processes better, taking such processor stress off of the operation of SL. Myself, if I were going to buy a computer, I'd go for 64 bit simply because that's the direction the industry is moving. Why buy yesterday's technology?

Of course... already we're seeing some killer deals on 32 bit closeouts... and a good Pentium or Athlon will run SL just fine.

Also, there appears to be a BUG in SL with AMD Athlon 64 X2 4800+ Processors (proably effects others, but that is what I have) and you HAVE TO disable one of the processor cores on the SecondLife.exe process else anything that uses timing is jerky and your SL experience is very very degraded. I didn't know about this bug and because of it I didn't play SL for the longest time because it ran horrid on a very new pc with good videocard.

64-bit is NOT faster tahn 32-bit!!

TBH Emerald, you just saved SL for me... i was running SL with the duel core capability before, and after u mentionned disabling one of the CPU's it now runs sweet as a dream

My specs are:
AMD Athlon 64 X2 Dual Core 4200+
Sapphire PURE RD580 CrossFire (Socket 939) PCI-Express Motherboard
HIS ATI Radeon X1900 ICEQ3 SILENT Heatpipe (Crossfire Edition) 512MB GDDR3 (PCI-Express)
Corsair 2GB DDR XMS3200C2PT TwinX (2x1GB)
Seagate Barracuda 7200.10 250GB ST3250620AS SATA-II 16MB Cache

and a few other bits and bobs, and now SL runs like a dream

cheers again Emerald!

I agree... I usually have all those apps open at the same time as well as 3 different email programs and yahoo to name some of non graphical intense ones.

I currently run a AMD Athlon 64 3300+ and am planning my next build, since the latest SL updates and Photoshop CS2 have been installed on it.

What I wonder is, would I free up CPU usage on the Dual Core, if I went with dual Nvidia Sli 512meg video cards?

Also, Is there a way in photoshop to force it to run on the second core, leaving SL to run on the first?

I have been looking at building a AMD Dual Core and having SLi Dual Nvidia Video Cards. If I do so, I would love to know the best way to optimise that machine to run SL and Photoshop CS2 (as well as other graphic intense programs).

Yes, and the last time you just quit answering when I asked you for support of your position, and pointed out that particles work *best* when the sim's lagged so bad you're disconnected. You're doing it again.
Some are fixable. Some aren't. The low rendering speed isn't fixable without doing the same kinds of optimizations that ordinary video games perform, and that's not possible without changing the world in fundamental ways.
I agree. I haven't disagreed with any of those points. I have pointed out many of them myself, and suggested fixes.
Some things can't be fixed without making compromises elsewhere. Second Life's frame rate can be improved, but not without severly restricting what residents can do.

Here's a real-world example: Internet Explorer security can't be fixed without changing the API for the Microsoft HTML control in a way that Microsoft is unwilling to do. I first brought *that* one up nearly ten years ago, and people who think "anything can be fixed" have been saying "no, Microsoft will fix it" for that long. Microsoft just released patches for Vista to cover up another symptom of the same design flaw they baked into the core of IE in 1997... the first time I'm aware of a security patch being released for an OS while it was still in beta.

It's not that these things are impossible, it's that making them happen requires breaking other things. You have to decide what you're going to break. Where are you going to compromise.
I've been working on 64-bit systems since 1994. 64-bits is irellevant to Second Life. 64-bits is almost completely irrelevant to almost everything that the typical user does. It's a red herring. AMD pulled a neat trick to fix a design flaw in the x86 architecture and used 64 bits as a marketing hook to get people to accept the compromise of recompiling all their programs to make it work.

I went with AMD64 because it happens to be the fastest CPU I could afford, and it looked like the socket would be supported for a while. There's no point in reasoning beyond that, particularly there's no point in worrying about 64- or 32- bit when you're running a 32-bit program on an OS that doesn't even support a full 64-bit model (Win64 is L32LLP64, not LP64).

Why buy yesterday's technology? Because yesterday's technology has won in the market. There's no alternative to Intel's ABI, a design that goes back to 1979.

There's a patch available from ms for win xp to fix the affinity problem on athlon processors, you have to ring them to get it though so either get that or turn off one of the cpu's when running SL and it runs much nicer. The patch has been available for at least 6 months btw.

SL runs fine on xp 64 pro with current nvidia drivers and all the latest updates from MS although unless you have another reason to run 64 bit xp it's probably not worth the trouble.