Jump to content
Sign in to follow this  
Talisman

64-bit client?

Recommended Posts

SSG seems to be pinning all their hopes on a new 64-bit client for LOTRO. Cordovan, at least, thinks it'll solve a lot of the performance/lag issues.

Will it really help, or just introduce all new headaches and performance issues?

Share this post


Link to post
Share on other sites
15 hours ago, Talisman said:

SSG seems to be pinning all their hopes on a new 64-bit client for LOTRO. Cordovan, at least, thinks it'll solve a lot of the performance/lag issues.

Will it really help, or just introduce all new headaches and performance issues?

I suspect one of the biggest issues they are facing is the 32 bit RAM limit - which is around 4GB.

Yes, it will give them room to play in above 4GB, and will not need to have a compatibility layer to work (as 32bit programs in Windows use several shims and thunking layers to work on the base 64 bit OS - kinda similar to how native Linux apps work on Windows) - which should help with some of the issues.

That said, this isn't a silver bullet.  I would expect some issues to be resolved, maybe a few more mitigated (present but bearable), and probably even a few more popping up.

Share this post


Link to post
Share on other sites

It will probably solve issues, but it will also create new issues/bugs.

If there won't be performance degradation when they launch it and continue to put effort in it, it will probably turn out to be a good decision because it will improve the game on the medium/long term.

Share this post


Link to post
Share on other sites

It will likely resolve mask some issues, it will likely not resolve near as much as they hope.  At best it will mask some underlying issues better, it however won't solve them.   The problem with the engine wasn't 32-64b or even optimization in general really.  The simple fact is people who didn't design or were otherwise subject matter experts on the engine kept trying to cram things into it for years it was never designed to handle.   For much of what they tried to do over the years (if they were bound and determined to go down certain design paths);  they should have bitten the bullet and re-designed an engine capable of handling it.  Or worked inside the limits of the engine they had, not the one they wished they had.   My bet this wont have much more effect than a typical placebo from a user stand point.  Even when the engine was still relatively contemporary it had db issues, lag issues,  comm isues that made it perform more poorly than it should have that were largely un-related to Hware, ISP,  or scheduling.  Hell I would bet $ there is still MyLotro DB polling going on.     Moving those to 32b vs 64b only means those issues happen at a faster pace(their hope is fast enough to mask from user).  It does nothing to resolve those issues.  The problem is the engine(and what they are trying to do with it, versed what it was actually designed to do) not the bit/mem width

Share this post


Link to post
Share on other sites

Um... execution speed has little to do with bitness.

The most likely issue players would see are bugs arising from expecting 32 bit values and getting 64 bit values instead.  That and also having the client consumes a crapton of RAM.

It's going to be interesting to see what Minas Tirith does on a 64 bit client.

Share this post


Link to post
Share on other sites
On 25.5.2017 at 1:44 AM, Almagnus1 said:

That and also having the client consumes a crapton of RAM.

The client is doing that NOW, and fails in trying to continue doing so at the 32bit limit.

Also, it's like, 2017, if you hit bugs because of incorrect assumptions wrt. the size of ints or pointers, you have been doing something very wrong in the course of the last, like, 15 years. Types like size_t and (u)int[xy]_t have been a thing since C99.

Of course, if you have been exclusively targetting Windows and used stuff like PULONGLONG and other horrors (of course, in sometime last millenium MS invented upper-case macros for just about any useless type) and all that nonsense, you might well end up in some trouble.

Then, again, since we're talking Turbine legacy code here that likely stems from sometime around then, yeah.

SNy

PS. I meant to ask earlier, but since I now replied, anyway, care to elaborate on the source of these rumours?

Share this post


Link to post
Share on other sites
1 minute ago, SNy said:

The client is doing that NOW, and fails in trying to continue doing so at the 32bit limit.

Also, it's like, 2017, if you hit bugs because of incorrect assumptions wrt. the size of ints or pointers, you have been doing something very wrong in the course of the last, like, 15 years. Types like size_t and int[xy]_t have been a thing since C99.

Of course, if you have been exclusively targetting Windows and used stuff like PULONGLONG and other horrors (of course, in sometime last millenium MS invented upper-case macros for just about any useless type) and all that nonsense, you might well end up in some trouble.

Then, again, since we're talking Turbine legacy code here that likely stems from sometime around then, yeah.

SNy

It really comes down to when the code base was written, as there could very well be parts of the code base that are old enough where pointer size becomes an issue.

It's an issue where SSG may just need to suck it up and go get help in order to fix it, but that's something I would NEVER broadcast to anyone.

Share this post


Link to post
Share on other sites
15 hours ago, SNy said:

PS. I meant to ask earlier, but since I now replied, anyway, care to elaborate on the source of these rumours?

People on the OF are saying it's from Cordovan's LOTRO Twitch stream.  I don't watch those so I haven't heard it myself, but that's what the source seems to be.

Share this post


Link to post
Share on other sites
4 hours ago, warspeech said:

People on the OF are saying it's from Cordovan's LOTRO Twitch stream.  I don't watch those so I haven't heard it myself, but that's what the source seems to be.

They are.  It's been mentioned, people are treating it like it's the next coming of the Valar, and it's going to solve all of LotRO's problems because they don't understand what this really means.

If anything, a 64 bit client is going to mask some of LotRO's issues at the expense of higher memory consumption, and cause some of the entitled sitting on XP and the 32 bit versions of Vista, 7, 8, 8.1, and 10 to lash out in anger because they don't understand why Turbine has to enforce a memory limit on their clients and point figures at us entitled using our 64 bit OSs being racist against them.

Share this post


Link to post
Share on other sites
1 hour ago, Almagnus1 said:

They are.  It's been mentioned, people are treating it like it's the next coming of the Valar, and it's going to solve all of LotRO's problems because they don't understand what this really means.

If anything, a 64 bit client is going to mask some of LotRO's issues at the expense of higher memory consumption, and cause some of the entitled sitting on XP and the 32 bit versions of Vista, 7, 8, 8.1, and 10 to lash out in anger because they don't understand why Turbine has to enforce a memory limit on their clients and point figures at us entitled using our 64 bit OSs being racist against them.

I'm going to miss those claims like "I run lotro in ultra settings with my Windows ME machine that has an Intel Celeron and 1GB of ram"  People confuse loading with playable.

Share this post


Link to post
Share on other sites
29 minutes ago, Amenhir said:

I'm going to miss those claims like "I run lotro in ultra settings with my Windows ME machine that has an Intel Celeron and 1GB of ram"  People confuse loading with playable.

And people also confuse "supported operating systems" with "whitelisted operating systems" >.>

Share this post


Link to post
Share on other sites
On 9.6.2017 at 3:02 PM, warspeech said:

People on the OF are saying it's from Cordovan's LOTRO Twitch stream.  I don't watch those so I haven't heard it myself, but that's what the source seems to be.

Thanks.

So not even some written piece at some 3rd party (a)social media site, but a mumbled piece in a live stream that the only other participant understood as an announcement? Nothing to see there, move along.

SNy

Share this post


Link to post
Share on other sites
6 hours ago, SNy said:

Thanks.

So not even some written piece at some 3rd party (a)social media site, but a mumbled piece in a live stream that the only other participant understood as an announcement? Nothing to see there, move along.

SNy

I went back to the anniversary videos - Cordovan asked the engineer, Zyrca, about it. She explained the "challenges" involved in the upgrade. Cordovan did come back and say that the 64-bit client is something they are investigating, but they have not committed to it.

At about 8 minutes in.

Share this post


Link to post
Share on other sites

OK, that was helpful and I can say that I can actually relate to most of the comments, especially wrt. the ones from the female developer.

About the process to switch from Awesomium to CEF (Chromium Embedded), I need to do something similar, with the help of (hopefully) others, but from XULRunner (mozilla, basically) to CEF. Though I don't quite get why she finds it worth mentioning that it can now display web content. That doesn't appear to be the hard part, after looking into it a bit. The hard part would be interaction, scripting and connecting back- and front-end. Maybe I misunderstood.

Anyway, wrt. to the 64bit-ness. She talks a lot about stuff that has, basically, nothing to do with the bitness issue, per se. What she says about them using an ancient version of MSVC (is it so ancient that it doesn't have a 64bit target? Is that conceivable?) and especially all the libraries they use... would be an issue for them either way. If I understand that correctly, they have not been updating their build system and dependencies in a long time, which would of course help explaining the issues at large to a great extent. Then again, while I haven't touched the client for ages, I don't remember them supplying a whole lot of external DLLs with the client, and short of static linking, those dependencies might actually lie more in the tooling for content creation and updates as well as stuff on the server than in code for the client. Then again, she spoke about client bitness, and don't I remember that they had been talking about server bitness when they announced their big move to the new datacenters?

SNy

Share this post


Link to post
Share on other sites

The key thing we don't know is what the SSG build system looks like.

If it's based around using an archaic version of MSVS, then there's going to be odd issues with bitness.

Share this post


Link to post
Share on other sites

For x86 64 bit code would be a bit faster generally, however doubling the RAM requirements for pointers by 2x can be a serious problem. For example, code that make use of linked lists, not to talk of double-linked lists which are the default kind of lists in C++1x.  If you cons up a list of 32-bit integers then 32 bit code would use 32+2x32 = 96 bits per cell, 64 bit code would use 32+2x64 bits = 160 bits, which is a solid 1.66x.

If you have problems fitting into the virtual address space available under 32 bit code (2, 3 or 4 GB depending on OS) you often end up introducing random hacks to deal with it.  Those can slow down code. However, in the transitions I observed this effect was generally overrated. People remember lots of terrible hacks, which they might have been, but the actual resulting technical slowdown was a lot less dramatic than selective memory indicated.

Of course dropping 32 bit versions does change the demographics of the computers that run the code. You kick out a lot of older computers and you force a lot of other people to do a fresh install of the OS. That has a serious impact on average execution speed. Your compiled code also has the benefit of always expecting a new generation of CPUs, which means your compiler can drop a bunch of outdated sequences, and new instructions are available (especially SIMD).

Share this post


Link to post
Share on other sites

I would be interested to see from Turbine the actual demographic numbers about who's using what OS version... assuming their client is pulling that information.

I have a nasty feeling that enough of their players are still on XP... and it would probably piss off enough of the RP crowd to make transitioning away from XP suicide.

Share this post


Link to post
Share on other sites
On 5.7.2017 at 6:11 PM, Darmokk said:

For x86 64 bit code would be a bit faster generally, however doubling the RAM requirements for pointers by 2x can be a serious problem. For example, code that make use of linked lists, not to talk of double-linked lists which are the default kind of lists in C++1x.  If you cons up a list of 32-bit integers then 32 bit code would use 32+2x32 = 96 bits per cell, 64 bit code would use 32+2x64 bits = 160 bits, which is a solid 1.66x.

1.66 times RAM usage of course sounds quite serious, but it is hardly the case that the whole 32bit address space is filled with pointer-heavy data structures.

I don't know the internals, of course, but I would venture a guess that memory-mapped regions for faster access to data files etc. do have a much higher impact on the memory usage. Therefore, increasing the available address space could greatly increase the MTBCTD of the client without too much of an actual impact on physical memory. Not to mention that the age of 2GB physical memory has been over for a while.

SNy

Share this post


Link to post
Share on other sites

Cordovan just clarified on the forums. You can find his quote easily on the general forums thread on this.  

 

He said, they are "intending" to make a 64-bit client. But he said they are still looking in to it and it may not be possible. So he can promise we will get one.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this  

×