View Full Version : Better multicore CPU usage in the future?
Valhakar
06-16-2009, 09:33 AM
<p>I just recently returned, so if this is a dead horse, sorry.</p><p>I see that the EQ client already has multicore support, but it is a hybrid since the code was originally written for a single core CPU. The byproduct is one core staying at 90-100% and a second core finally taking off 5-20% depending on load. This is a cascading model.</p><p>Vista and W7 both now have the ability to assign cores to a single processor thread. You can force it in the OS, but it is buggy at best and can lead to other issues. A Sony client written in a wrapper could be the solution however. The EQ client stays as a single core process while the wrapper uses mutiple processors and threads to load balance usage.</p><p>Thoughts?</p><p>-D</p>
Aneova
06-16-2009, 11:14 AM
<p>currently they are moving more process's to be handled by the GPU rather then the CPU, this update it's shadows.</p>
Mulethree
06-16-2009, 05:11 PM
<p>Last fall they moved some animation processing to a seperate thread - thats most of the 5-20% you see on your second core. You don't need vista or w7 for an application to assign threads to processors - they can do that fine with NT and XP too.</p><p>The problem is that 90% of the work is done in one thread - and only one processor can work on one thread. There are probably seperate threads to handle network comms, chat, voice chat, maybe the 2d UI overlay etc. but the work on those threads is a small percentage of the total. Those are pretty simple to coordinate - stick some data in a queue and let the other thread to do it's thing. </p><p>Each bit of work you move to a seperate thread means adding coordination for each piece of data thats shared between threads - locks on each shared data structure, code to make private copies of data, or to check locks, lock data, unlock data, wait for a lock to be freed etc. Not just in the re-located code, but everywhere those data structures are used. It can be quite a bit of processing overhead, and then there is the complication of making it skip all that overhead in cases (e.g. single core) where a seperate thread doesn't buy you anything. </p><p>So they look for routines that are a sizeable portion of the processor load, but which have small data-sharing requirements, and make sense to happen asynchronously. There can't be many that are sizeable, and how many of those have manageable data-sharing? - even fewer. Make sense async? even fewer </p>
Bromir
06-18-2009, 04:20 AM
<p><cite>Valhakar wrote:</cite></p><blockquote><p>I just recently returned, so if this is a dead horse, sorry.</p><p>I see that the EQ client already has multicore support, but it is a hybrid since the code was originally written for a single core CPU. The byproduct is one core staying at 90-100% and a second core finally taking off 5-20% depending on load. This is a cascading model.</p><p>Vista and W7 both now have the ability to assign cores to a single processor thread. You can force it in the OS, but it is buggy at best and can lead to other issues. A Sony client written in a wrapper could be the solution however. The EQ client stays as a single core process while the wrapper uses mutiple processors and threads to load balance usage.</p><p>Thoughts?</p><p>-D</p></blockquote><p>XP supports that too you know <img src="/smilies/3b63d1616c5dfcf29f8a7a031aaa7cad.gif" border="0" alt="SMILEY" /></p><p>But on the MC system. The threads off feedback and dialog was pretty long so please excuse me for not trying to find and link the stuff that was said directly. It was however said that the MC work was a work in progress and that stuff would be added along the road as time and opportunity would be available to the dev handling it.. If I dont remember wrong I beluieve it was only one programmer that was doing it but he was doing a great job with it.</p><p>My guess is that he might have been doing some of the GPU work <img src="/smilies/3b63d1616c5dfcf29f8a7a031aaa7cad.gif" border="0" alt="SMILEY" /> CPU work will come along.</p><p>On the core/process thing. Xp with multi cores handles it too . And the eq2 client could be moved to any core way before MC thread support was added . ie. having eq2 running on lets say core 4 on a quad is possible indeed. I know for a fact that works on xp pro at least but I havent tried it on home and to be honest im not sure if home supports the MC stucture as well or in the same way as xp pro does. You can do exactly the same thin in vista even with MC support enabled in the client. More the core process to another cpuid and it will run there as base ..</p><p>Try it <img src="/smilies/3b63d1616c5dfcf29f8a7a031aaa7cad.gif" border="0" alt="SMILEY" /></p><p>Yours.</p>
Lethe5683
06-18-2009, 12:26 PM
<p><cite>Mulethree wrote:</cite></p><blockquote><p>Last fall they moved some animation processing to a seperate thread - thats most of the 5-20% you see on your second core. You don't need vista or w7 for an application to assign threads to processors - they can do that fine with NT and XP too.</p><p>The problem is that 90% of the work is done in one thread - and only one processor can work on one thread. There are probably seperate threads to handle network comms, chat, voice chat, maybe the 2d UI overlay etc. but the work on those threads is a small percentage of the total. Those are pretty simple to coordinate - stick some data in a queue and let the other thread to do it's thing. </p><p>Each bit of work you move to a seperate thread means adding coordination for each piece of data thats shared between threads - locks on each shared data structure, code to make private copies of data, or to check locks, lock data, unlock data, wait for a lock to be freed etc. Not just in the re-located code, but everywhere those data structures are used. It can be quite a bit of processing overhead, and then there is the complication of making it skip all that overhead in cases (e.g. single core) where a seperate thread doesn't buy you anything. </p><p>So they look for routines that are a sizeable portion of the processor load, but which have small data-sharing requirements, and make sense to happen asynchronously. There can't be many that are sizeable, and how many of those have manageable data-sharing? - even fewer. Make sense async? even fewer </p></blockquote><p><span style="color: #00ccff;">I'm pretty sure the UI wpuld be moveable to a seperate core, and simply turning off the UI improves my frame rate by as much as 10fps.</span></p>
bluefish
07-10-2009, 07:47 PM
<p><cite>Bromir@Runnyeye wrote:</cite></p><blockquote><p><cite>Valhakar wrote:</cite></p><blockquote><p>I just recently returned, so if this is a dead horse, sorry.</p><p>I see that the EQ client already has multicore support, but it is a hybrid since the code was originally written for a single core CPU. The byproduct is one core staying at 90-100% and a second core finally taking off 5-20% depending on load. This is a cascading model.</p><p>Vista and W7 both now have the ability to assign cores to a single processor thread. You can force it in the OS, but it is buggy at best and can lead to other issues. A Sony client written in a wrapper could be the solution however. The EQ client stays as a single core process while the wrapper uses mutiple processors and threads to load balance usage.</p><p>Thoughts?</p><p>-D</p></blockquote><p>XP supports that too you know <img src="/eq2/images/smilies/3b63d1616c5dfcf29f8a7a031aaa7cad.gif" border="0" /></p><p>But on the MC system. The threads off feedback and dialog was pretty long so please excuse me for not trying to find and link the stuff that was said directly. It was however said that the MC work was a work in progress and that stuff would be added along the road as time and opportunity would be available to the dev handling it.. If I dont remember wrong I beluieve it was only one programmer that was doing it but he was doing a great job with it.</p><p>My guess is that he might have been doing some of the GPU work <img src="/eq2/images/smilies/3b63d1616c5dfcf29f8a7a031aaa7cad.gif" border="0" /> CPU work will come along.</p><p>On the core/process thing. Xp with multi cores handles it too . And the eq2 client could be moved to any core way before MC thread support was added . ie. having eq2 running on lets say core 4 on a quad is possible indeed. I know for a fact that works on xp pro at least but I havent tried it on home and to be honest im not sure if home supports the MC stucture as well or in the same way as xp pro does. You can do exactly the same thin in vista even with MC support enabled in the client. More the core process to another cpuid and it will run there as base ..</p><p>Try it <img src="/eq2/images/smilies/3b63d1616c5dfcf29f8a7a031aaa7cad.gif" border="0" /></p><p>Yours.</p></blockquote><p> XP?? [Removed for Content] is that? Experience points? does not compute</p><p>sorry just poking fun .. I haven't used xp in over three yearsso I have no clue whats it capable of anymore</p>
Waruri
07-19-2009, 06:27 PM
<p>Well crap had I know this I would not have upgraded from my E8500 to the Q9550</p><p>My E8500 was easily stable at 4.0ghz, my Q9550 is Locking up occasionally with it at 3.96ghz,</p><p>Processor load when running EQ2, Google Chrome with 5 sites open, Ventrilo, and ACT</p><p>Core 0 - 19%</p><p>Core 1 - 5%</p><p>Core 2 - 5%</p><p>Core 3 - 90% <-- EQ2</p>
guillero
07-20-2009, 03:48 AM
<p><cite>Waruri wrote:</cite></p><blockquote><p>Well crap had I know this I would not have upgraded from my E8500 to the Q9550</p><p>My E8500 was easily stable at 4.0ghz, my Q9550 is Locking up occasionally with it at 3.96ghz,</p><p>Processor load when running EQ2, Google Chrome with 5 sites open, Ventrilo, and ACT</p><p>Core 0 - 19%</p><p>Core 1 - 5%</p><p>Core 2 - 5%</p><p>Core 3 - 90% <-- EQ2</p></blockquote><p>Did you enable Multi-Core CPU support in the Performance options ingame?</p><p>As eventho I have only a Dual Core, I see a very different CPU's usage as you are when I enable Multi-Core CPU support ingame.</p><p>Jer</p>
vBulletin® v3.7.5, Copyright ©2000-2025, Jelsoft Enterprises Ltd.