| Pages: [1] :: one page |
| Author |
Thread Statistics | Show CCP posts - 0 post(s) |
Dar Wento
Gallente
Fallen Angel's
Xelas Alliance
   |
Posted - 2007.01.05 12:07:00 -
[1]
Edited by: Dar Wento on 05/01/2007 12:16:24
When will EVE adapt to the world of multi-threading and utilize all the power harnessed in todays cpus, please?
It's been around long enough for CCP to have done this by now, in my opinion. I see quite a few threads about serious dual core-issues in the "Known issues & workarounds"-forum.
Regards,
/Dar.
|
TheFirstInquisitor
|
Posted - 2007.01.05 12:28:00 -
[2]
I remember seing a Dev making a long topic reply to this, which can be summarised by saying
Eve uses CPU for everything
Eve client is fairly impressed you have something more than Direct X 7
Graphics cards do zilch
Also that it would require a rewrite as Dual Processors/Multi thread had about as much relevance when Eve was made that Quantom processors have now.
Note to all, What I say may be infact of a more humorous tone than comes accross. |
Indra Sebuchiore
Sebiestor tribe
|
Posted - 2007.01.05 12:29:00 -
[3]
Latest dev blog hints: yes.
__________________________________________
"In girum imus nocte, et consumimur igni."
|
Abye
Caldari
UNITED STARS ORGANISATION
|
Posted - 2007.01.05 13:20:00 -
[4]
You can't just tack on good multithreading to any grown application.
A rewrite of the application takes a big bunch of time.
|
Iyanah
Minmatar
Mining Munitions and Mayhem
|
Posted - 2007.01.05 13:24:00 -
[5]
 Originally by: Abye
You can't just tack on good multithreading to any grown application.
A rewrite of the application takes a big bunch of time.
indeed. multi-threading is a completely new way of structuring the way the program logic is handled by the system. as such you pretty much have to re-write the engine. it's not a small task, and alot of established MMO games that pre-date multi-threading are not using it.
it'll probably get there, but such a massive change will take time. lots of time.
==========================================
Iy |
babyblue
|
Posted - 2007.01.05 13:34:00 -
[6]
All games implement a form of multi-threading/scheduling by breaking down intensive tasks and doing them over "many frames" (AI for example). You will get probably ZERO benefit from multithreading on a single core processor - unless you are streaming in media from some I/O device on one thread while doing something else on the other - and most games will do this for things like music in any case. You also have to factor in state change (context switch) between threads which obviously has some overhead.
|
Andrue
Amarr
|
Posted - 2007.01.05 17:25:00 -
[7]
Originally by: Abye
You can't just tack on good multithreading to any grown application.
A rewrite of the application takes a big bunch of time.
You can sometimes if the existing code is object oriented and adheres to strict black box principals. OTOH that won't usually yield the best gains so a rewrite (or significant refactor) is best.
--
(Battle hardened industrialist)
[Brackley, UK]
Linux is only free if your time is worthless |
Andrue
Amarr
|
Posted - 2007.01.05 17:27:00 -
[8]
Edited by: Andrue on 05/01/2007 17:30:26
Edited by: Andrue on 05/01/2007 17:29:43
Edited by: Andrue on 05/01/2007 17:28:22
Originally by: babyblue
All games implement a form of multi-threading/scheduling by breaking down intensive tasks and doing them over "many frames" (AI for example). You will get probably ZERO benefit from multithreading on a single core processor - unless you are streaming in media from some I/O device on one thread while doing something else on the other - and most games will do this for things like music in any case. You also have to factor in state change (context switch) between threads which obviously has some overhead.
Multi-threading rarely helps on a single core CPU unless-as you say-another thread is blocking on I/O. About the only time it does is when the OS scheduler is a bit too aggressive. In those cases by spawning multiple threads you can grab a proportionally greater %ge of the CPU.
If 99% of the threads the CPU is running re yours you might (not always, lol) get 99% of the CPU. With only one thread you might get 70%. I think this is more of an issue with cooperative threading though. Most modern OSes pretty much let a single thread run for as long as nothing else wants the CPU (effectively) so spamming the system with threads is counterproductive.
As you say the effort of switching even thread contexts can be relatively high.
--
(Battle hardened industrialist)
[Brackley, UK]
Linux is only free if your time is worthless |
SlingBlader
|
Posted - 2007.01.05 18:32:00 -
[9]
It's pretty obvious that EVE could benifit from multithreading even on single core processors. Whenever you jump into a system with a huge gate-camp the game client freezes up for a bit while it loads all the data. There are many other points in which EVE will hang on IO like that. It would be much more graceful if EVE use threading to draw objects as they become available in memory intead of waiting for everything to load. Most of the time you just see a bunch of colored squares anyway... no reason to make me wait for the itty bitty ship that is going to be drawn behind it.
That said... turning a large, complex, single-threaded program into a multi-threaded one is a huge undertaking. Even if your system is already well encapsilated you will have to identify all the shared resources and synchronize them. After that comes the fun multi-threaded debugging phase where you get to find all the shared resources that you missed, race conditions, etc.
I suspect however that CCP is simply going to bite this off at the same time they write the DX10 client. No reason to go back and multi-thread the existing client.
|
Ikkajo
Minmatar
Sirius Cybernetics Corpotation
|
Posted - 2007.01.06 00:01:00 -
[10]
/puts on professional hat - I write realtime 3D rendering engines for a living
If the code is well structured it's actually fairly trivial to gain quite a few multithreaded benefits in the rendering pipeline for both graphics and audio. However, the really big caveat is that they have well designed code that separates the rendering (scenegraph) from the game logic. The basic logic then gets applied at the scene graph level, while the other thread(s) take the previous frame of data and proceed to render that to the video and audio hardware. That said, I've dealt with a lot of "game programmer" code before and that is very rarely the case that they have well engineered code that would allow this to happen.
IOW, I agree with the other posters here: almost a certainty they would have to completely recode the client from scratch to make use of it properly.
|
babyblue
|
Posted - 2007.01.06 00:09:00 -
[11]
Edited by: babyblue on 06/01/2007 00:08:54
Originally by: Ikkajo
/puts on professional hat - I write realtime 3D rendering engines for a living
If the code is well structured it's actually fairly trivial to gain quite a few multithreaded benefits in the rendering pipeline for both graphics and audio. However, the really big caveat is that they have well designed code that separates the rendering (scenegraph) from the game logic. The basic logic then gets applied at the scene graph level, while the other thread(s) take the previous frame of data and proceed to render that to the video and audio hardware. That said, I've dealt with a lot of "game programmer" code before and that is very rarely the case that they have well engineered code that would allow this to happen.
IOW, I agree with the other posters here: almost a certainty they would have to completely recode the client from scratch to make use of it properly.
And also consider most of the game logic is actually on the server, which is of course, multi-threading. You could possibly buy some time by streaming in stuff on a thread during warp so the eventual state change at the end is easier, but this is more an issue of cooperation between client and server than a case of multithreading purely on the client.
|
| |
|
| Pages: [1] :: one page |
| First page | Previous page | Next page | Last page |