We have detected that cookies are not enabled on your browser. Please enable cookies to ensure the proper experience.
Page 3 of 3 FirstFirst 1 2 3
Results 51 to 62 of 62
  1. #51
    Join Date
    Jul 2016
    Location
    UK
    Posts
    2,282
    Quote Originally Posted by Snowlock View Post
    I guess that's a 'no'.



    Exactly. This is the reason some people claim that an older computer will run LOTRO better than a newer one, right? It's going to increase the cap on memory resources the client can draw on. So will the new cap help performance then?

    We got 64 bit servers in 2015 (16?) It didn't help. But the type of "lag" that people generally called "server lag" is because it happens to everyone in the same place at the same time. But it's actually (the last time I spoke to a dev about it) the CLIENT maxing its resources for everyone in the same way at the same time due to some very inefficient in game mechanics). When it's confined to area.
    [waves], hello?? I have recorded 32bit programs using more than 2-3GB, I have had LOTRO.exe running with 3.8GB in use around M.T. (crashed @ ~3.85GB) for starters.

  2. #52
    I believe Snowlock is talking about players and not known locations that cause less than the optimal experience.


    It becomes more evident over time many players swap ILI's also Li's to gain the advantages of different features allocated to them while incombat.

    I recently learned some found a way to utilize Plugins to further this advantage. If its true I don't know. In any case I question if actions directed through the client at an exceptionally fast speed can be processed by the game servers without causing lag.

    If this does indeed increase the lag we already endure will any new upgrades in regards to 64bit enhancement reduce these kinds lag?
    Università degli Studi di Roma "La Sapienza" Sapienza University of Rome

    Graduate PhD con lode Scienze della Politica

  3. #53
    Join Date
    Mar 2007
    Location
    Missouri
    Posts
    368
    Quote Originally Posted by Yarbro View Post
    [waves], hello?? I have recorded 32bit programs using more than 2-3GB, I have had LOTRO.exe running with 3.8GB in use around M.T. (crashed @ ~3.85GB) for starters.
    That's called making the .exe LAW ( Large Address Aware ). It's a simple thing as it only requires the programs executable to be modified, which TurSSG likely did at some point. It enables a 32bit program to access up to 4gb of ram, however it becomes unstable the closer to 4gb the program gets.

  4. #54
    Join Date
    Feb 2007
    Location
    USA
    Posts
    6,333
    Quote Originally Posted by Korandon View Post
    That's called making the .exe LAW ( Large Address Aware ). It's a simple thing as it only requires the programs executable to be modified, which TurSSG likely did at some point. It enables a 32bit program to access up to 4gb of ram, however it becomes unstable the closer to 4gb the program gets.
    Yep, happened in June 2007.

  5. #55
    Join Date
    May 2007
    Posts
    5,283
    Quote Originally Posted by Yarbro View Post
    [waves], hello?? I have recorded 32bit programs using more than 2-3GB, I have had LOTRO.exe running with 3.8GB in use around M.T. (crashed @ ~3.85GB) for starters.
    ? Not sure your point to me here. I believe you, its just that that wasn't my statement regarding 32 bit and memory usage. You'd have to ask the guy who discussed it. I don't know the numbers or the levels.

    All I've heard since the discussion changed from "server lag" to "client lag" and this has been around for a long time, prior to the data center moves, (probably since the 2014 PC which had a good cross section of PVP'ers who, though couldn't agree the sky is blue in the daytime, did all take to heart the issue of "the lag" and engaged a number of then-Turbine employees about it) was that the issues were with the client, as in the LOTRO program, both in inefficiencies of the code and in some sloppy mechanics. A big one being account shared items.

  6. #56
    Join Date
    Sep 2016
    Posts
    1,775
    Quote Originally Posted by OghranNasty View Post
    I wished SSG would just close threads that end in personal battles. Nobody wants to read this.
    Quote Originally Posted by LabadalofDorlomin View Post
    @Cordovan

    Please don't lock this thread when you arrive in work this morning. Just deal with the 2 who hijacked it for petty arguments.
    It actually started off really interesting until over inflated egos got in the way.

    I for one am still interested in this subject and would like it to get back on track.

    Hopefully.....Thanks
    Ok, I have now pruned more than 50 posts from the thread and banned two of the folks who were most prevalent in dragging this (and other threads) off topic with personal fighting. Unless you would like to join them, I would recommend not making it personal. I will keep the thread open per the suggestions above.
    Community Manager, Lord of the Rings Online
    Follow LOTRO on: Twitter - Facebook - Google+ - Pinterest - Twitch - YouTube
    Find Cordovan on: Twitter Instagram
    Support: help.standingstonegames.com
    coolcool

  7. #57
    Quote Originally Posted by scorrp10 View Post
    Apple is not "working" on 64 bit OS. OSX has been fully 64bit since 2011 10.7 "Lion".

    The problem is that hardware manufacturers may stop providing 32 bit support, meaning operating systems will need to emulate the environment for 32 bit apps. Any such apps that presently rely on direct hardware acccess (mainly graphics) are going to see a major performance degrade.
    This is not entirely true. Apple is deprecating the ability for 32-bit applications to run on Mac OS. Right now it's in an optional thing that just throws a warning, but it's going to be problem sooner rather than later. Apple hasn't set an exact date for it, but with the pace they've been settings, I'd expect it to happen within the next two versions.

  8. #58
    Join Date
    Jul 2016
    Location
    UK
    Posts
    2,282
    Quote Originally Posted by Snowlock View Post
    ? Not sure your point to me here. I believe you, its just that that wasn't my statement regarding 32 bit and memory usage. You'd have to ask the guy who discussed it. I don't know the numbers or the levels.

    All I've heard since the discussion changed from "server lag" to "client lag" and this has been around for a long time, prior to the data center moves, (probably since the 2014 PC which had a good cross section of PVP'ers who, though couldn't agree the sky is blue in the daytime, did all take to heart the issue of "the lag" and engaged a number of then-Turbine employees about it) was that the issues were with the client, as in the LOTRO program, both in inefficiencies of the code and in some sloppy mechanics. A big one being account shared items.
    Sorry, I was in a hurry and quoted the wrong person. My 5 y/o decided today was the day to take up the quests she abandoned in Garth Agawen 2 months ago; so I was monitoring my stable horse's arrival and posting to the forum at the same time.

    Microgit have crippled their own software many times over the years, but someone usually comes along and "fixes" it; like the 32GB limit on formatting Flash memory as FAT32, when the actual limit is 2TB; the WinXP formatter was perfectly happy to do it, and so was Win7 at launch, then suddenly they decided to stop it; not sure what they allow in Win8-10, but I have FAT32 formatted 128GB cards with no issues using 3rd party software.

    dx10 on WinXP was another. WMP 11 on XP one more.

    I understand there are even artificial limits on how much RAM various flavours of 64bit Windows can "see"

  9. #59
    Rewriting for 64bit does more than give access to extra memory. The Microsoft x64 (64bit) calling conventions allow for 4 integer and 4 floating point numbers to be passed by register (much faster), versus the x86 (32bit) stdcall conventions that push numbers onto the stack (slower).
    Squirrel!

  10. #60
    Well this is getting rather juicy now on the technical fronts.

    From what I glean from this thread, pre and post pruning (thnx Cordovan), is that most informed posters don't really know or are at odds with what a 64 bit games engine/client? will do for us if anything.

    So, it;s a lottery. I'm betting that SSG don't fully know what benefits it will bring us - fairly sure they know what benefits it has to them, which is possibly why they are reluctant to weigh in to the conversation.

    Where is this new engineer who was employed to do this and got waylaid with other back end duties? Lets here from you please. Even if it is only to introduce yourself to the baying crowd.... we don't bite.... much
    ----A casual stroll through the lunatic asylum shows that faith does not prove anything----

  11. #61
    Architectural benefits of AMD64 (64bit) vs. intel386 (32bit)

    larger address space
    a richer register set

    Typically a 30% speed improvement for compute-intensive code like video processing on (64bit) compared to (32bit).
    This is most likely due to the fact that we have 16 x 64 bit general purpose registers and 16 x SSE registers instead of 8 x 32 bit general purpose registers and 8 x SSE registers.
    64-bit compilers use the SSE registers while 32-bit compilers use the standard ALU.
    This makes 64-bit code faster due to the narrower FP width (64 vs 80) plus additional instructions.


    Architectural downside of x64 mode

    all pointers (and thus many instructions too) take up 2x the memory, cutting the effective processor cache size in half in the worst case.

    Estimate the increase in the overall memory usage for a 64bit application compared to a 32bit one to be around 15-30 %.

    -

    The game will benefit from the larger amount of Ram that will be allowed to address

    in systems with 8 to >=16GB of Ram.
    If you have a pc with 4GB ram it wont make any difference.

    The crashes due to memory leak or slow garbage collection ( zone transition), will be far less, again if you have above 8GB of Ram.
    Dont forget you have the Operating System in the background and other programs like your browser etc that use system memory too.

  12. #62
    Join Date
    Jul 2016
    Location
    UK
    Posts
    2,282
    Quote Originally Posted by Chompee View Post
    Rewriting for 64bit does more than give access to extra memory. The Microsoft x64 (64bit) calling conventions allow for 4 integer and 4 floating point numbers to be passed by register (much faster), versus the x86 (32bit) stdcall conventions that push numbers onto the stack (slower).
    In real life, x64 hasnt been much of a speed boost over x86; this based on my experiences with XP32 v XP64 and Win7 32 v Win7 64; the improvements were perhaps 10-15% at best.

    As I said before, any new client needs to address the lack of gfx card use; just fixing this and ignoring the whole 32 v 64 bit would improve the game immensely; as would fixing the lack of multi core support. The fact is, the client will have to address ALL of these if there is to be any real improvement; and that is basically a complete top to bottom rewrite of the code. A job that would take a TEAM of programmers several YEARS and a lot of MONEY to get right.

    The only way to pay for that would be to launch it as a whole new subscription only game and I am not sure they could get the Tolkein estate to go for that.

    I suspect they have been tinkering with the code to try and allow multi core use; how my AMD cpu implements the game has changed over the last year; more cores are being used, as many as four*; but the total cycle time still doesnt exceed 1.5 cores worth.

    * But only if I set affinity to four cores or less; give it six cores and it reverts to using two.

 

 
Page 3 of 3 FirstFirst 1 2 3

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

This form's session has expired. You need to reload the page.

Reload