Multicore

[Solomon555]

I recently decided to upgrade from my old dual core processor, and in doing the research I discovered that very few games actually make use of a multi (dual or quad) core processor. Obviously I like to see STO make use of more than one core. (hint...devs...:D)

On a side note, does anyone know why most games don't seem to support this? I would think most developers would love to add performance, so I imagine the coding is significantly more complicated. Multi-core processors have been out long enough for the industry to have caught up by now.

[DarthDiddler]

ar you saying that the new computer i just got with a quad in it is not going to be used...not happy

[robcoe]

The codeing is VASTLY more complicated. To date the only software i have used that really made use of quad core CPU's are programs like Matlab.

[Azurian]

I think they mentioned something about STO being Dual Core a year ago, but might look into Quad Core capabilities.

[Durakken]

You wouldn't think that people that like star Trek wouldn't know this...

multicore processors, when not being used specifically by a program, is used in other ways...

Let's say you have two programs running that run 8 lines of code each...

With a single core processor it would run them in...lets say 16 seconds (Im not converting to whatever the real amount would be) 1 line of code, 1 second.

With a dual core processor it would run them in 8 seconds.

in a quad core processor it would run them in 8 seconds.

Why is this? You would think the quad core would half it again, but it doesn't why? The answer is that one core has to run every single line in the first one. In the second one one core runs 1 program and the othe runs the other. The Quad does the same...so why doesn't the Quad split it up even more? Well because it would be ineficient... First of all you have to add in more lines of code to split them up so instead of 8 seconds you would increase to say 10 seconds... And secondly, programs are sequential so you can't break up those lines of codes without messing up the program.

There is also another thing they do sometimes but I don't get how it works so can't really describe it, but more or less it is a virtual combination of of the separate cores that increases the power of when it acts as a single core but lowers the overall power of the processor as i understand it.

[rabidchocobo]

Software coding is always way, way behind hardware. Basic code writing hasn't really improved at all for quite some time, but hardware you'll notice improves dramatically all the time. Small improvements occur semi-monthly, and major leaps, like the commercially available multicore processor, occur every few years or so. You can't keep up with the fast pace of PC hardware development.

[Batleh]

I recently decided to upgrade from my old dual core processor, and in doing the research I discovered that very few games actually make use of a multi (dual or quad) core processor. Obviously I like to see STO make use of more than one core. (hint...devs...:D)

On a side note, does anyone know why most games don't seem to support this? I would think most developers would love to add performance, so I imagine the coding is significantly more complicated. Multi-core processors have been out long enough for the industry to have caught up by now.

So first off, I apologize for the wall of text, but do some stuff like this IRL, so I'm going to throw out my 2cents.

So this depends... Basicaly everything your computer does runs as a process or "thread" managed by the OS. Most games (infact, most programs in general) run as a single thread for the game logic, and then pass request for resources off to the OS (they call things like the audio driver, the video driver, the network driver, access the disk etc). Your game might be a single thread running in a single cpu, but other things your computer does will consume your other cores, so even if the game isn't muti-processor aware, as long as the computer is, you'll take advantage of it. Window XP is ok dealing with multi-core systems, Vista is better, Windows 7 is even better.

That being said, if your game is single threaded, if it runs really good with 1 cpu, it won't run twice as fast with 2. It'll run a bit faster because other things use the other CPU, but your game itself won't.

One of the big problems with threading is that for a programmer it can be very expensive to implement. It requires more code overhead (you have to write the code to do the work + all the code to manage the threads), and it can make QA much more involved because there are all sorts of additional potential problems with splitting things out into threads. The short and sweet answer is that for most mortals (myself included) programming threads can be hard/nasty/tricky stuff. If you code has an easily identifiable unit of work that you can spread around, it's not so bad... but if you need to do inter-process communication to pass around info or state or keep things in sequence... if you have to handle process locking to make sure thread 1 doesn't screw up something thread 2 needs... it can get ugly... and debugging it can be outright hell :-)

If I have a program that needs to read a bunch of numbers out of a bunch of files and tell me the total of each of those files, then then total of all of them, doing that in threads actually pretty easy and much faster than doing it as 1 process. You just start up a master job that tracks everything and then a bunch of worker jobs that read the files and add up the numbers. The more cores you have, the more thread, the faster you get your answer because you have a discrete unit of work you can easily spread around to take advantage of free processors.

Why don't games do this? Well, honestly, writing code that splits itself up to run in multiple threads isn't easy for something like a game. You don't always have an easily identifiable unit of work - and because the master process really really has to know what's going on all the time and keep everything in step, the master process can actually slow down the workers and make things less efficient. Plus, some resources (like say, your video card) really don't like being used by more than one process at a time (I'm sure you've watched your video display freak for a second when you alt-tabbed out of a game). Now, some things can work really well in a thread - Loading the next level from disk, downloading artwork from the server, things that don't have to be directly managed by the master thread, but sometimes implementing the overhead of doing this in a thread isn't worth it if you're looking at a deadline.

Consumer desktop support for multithreading is just really now staring to take hold, and most programming languages that games are written in just don't do threading easily (or at all). There are a few initiatives out there to make programming threads easier (probably one of the coolest from a programming standpoint is something from Apple called Grand Central) but for now most programmers have to do all of the thread management themselves, and like I said above.. that's hard.

Now, if you've made it this far, I thank you for putting up with my rambling :-) All is not lost. Now that more and more people have multicore systems, it's becoming more viable to budget the time to get threading working. Major players on the market (Apple, Microsoft, Adobe, etc) are looking at this problem and trying to find ways for us moral programmers to do threading much easier (Apple has announced they're going to open source their Grand Central technology for example), and major programs like Photoshop and Office already have muththreading support or have it planned as a near term release. And once the tools are out there to do it efficiently game devs will start picking them up and seeing what they can do with them as well. So we're not there yet, but it shouldn't be much longer :-)

[Batleh]

There is also another thing they do sometimes but I don't get how it works so can't really describe it, but more or less it is a virtual combination of of the separate cores that increases the power of when it acts as a single core but lowers the overall power of the processor as i understand it.

I assume you're referring to the "Turbo Mode" that the new Intel i7 chips have? Basically Intel's new CPU's have some cool power management smarts. If one core is pegged and the others aren't doing much, it will turn off power to the unused cores and direct that power to the CPU that's busy to run it at a faster speed. So, if you're running lots of things, you 4 cores are chewing happily along at 2.66Ghz, but if you instead are running a single threaded app that's using nothing but 1 core, you'll have 3 cores that are "off" and 1 core running at 2.9Ghz to try and give that single threaded app a bit of a performance boost.

[pxRoberto]

Empire:Total War released a patch post-launch to go from singe thread to multi threading. So if cryptic did things right, but did not have time to make the game mutli threaded, they still can adjust it after launch.

[TechDragon]

You wouldn't think that people that like star Trek wouldn't know this...

multicore processors, when not being used specifically by a program, is used in other ways...

Let's say you have two programs running that run 8 lines of code each...

With a single core processor it would run them in...lets say 16 seconds (Im not converting to whatever the real amount would be) 1 line of code, 1 second.

With a dual core processor it would run them in 8 seconds.

in a quad core processor it would run them in 8 seconds.

Why is this? You would think the quad core would half it again, but it doesn't why? The answer is that one core has to run every single line in the first one. In the second one one core runs 1 program and the othe runs the other. The Quad does the same...so why doesn't the Quad split it up even more? Well because it would be ineficient... First of all you have to add in more lines of code to split them up so instead of 8 seconds you would increase to say 10 seconds... And secondly, programs are sequential so you can't break up those lines of codes without messing up the program.

There is also another thing they do sometimes but I don't get how it works so can't really describe it, but more or less it is a virtual combination of of the separate cores that increases the power of when it acts as a single core but lowers the overall power of the processor as i understand it.

So first off, I apologize for the wall of text, but do some stuff like this IRL, so I'm going to throw out my 2cents.

So this depends... Basicaly everything your computer does runs as a process or "thread" managed by the OS. Most games (infact, most programs in general) run as a single thread for the game logic, and then pass request for resources off to the OS (they call things like the audio driver, the video driver, the network driver, access the disk etc). Your game might be a single thread running in a single cpu, but other things your computer does will consume your other cores, so even if the game isn't muti-processor aware, as long as the computer is, you'll take advantage of it. Window XP is ok dealing with multi-core systems, Vista is better, Windows 7 is even better.

That being said, if your game is single threaded, if it runs really good with 1 cpu, it won't run twice as fast with 2. It'll run a bit faster because other things use the other CPU, but your game itself won't.

One of the big problems with threading is that for a programmer it can be very expensive to implement. It requires more code overhead (you have to write the code to do the work + all the code to manage the threads), and it can make QA much more involved because there are all sorts of additional potential problems with splitting things out into threads. The short and sweet answer is that for most mortals (myself included) programming threads can be hard/nasty/tricky stuff. If you code has an easily identifiable unit of work that you can spread around, it's not so bad... but if you need to do inter-process communication to pass around info or state or keep things in sequence... if you have to handle process locking to make sure thread 1 doesn't screw up something thread 2 needs... it can get ugly... and debugging it can be outright hell :-)

If I have a program that needs to read a bunch of numbers out of a bunch of files and tell me the total of each of those files, then then total of all of them, doing that in threads actually pretty easy and much faster than doing it as 1 process. You just start up a master job that tracks everything and then a bunch of worker jobs that read the files and add up the numbers. The more cores you have, the more thread, the faster you get your answer because you have a discrete unit of work you can easily spread around to take advantage of free processors.

Why don't games do this? Well, honestly, writing code that splits itself up to run in multiple threads isn't easy for something like a game. You don't always have an easily identifiable unit of work - and because the master process really really has to know what's going on all the time and keep everything in step, the master process can actually slow down the workers and make things less efficient. Plus, some resources (like say, your video card) really don't like being used by more than one process at a time (I'm sure you've watched your video display freak for a second when you alt-tabbed out of a game). Now, some things can work really well in a thread - Loading the next level from disk, downloading artwork from the server, things that don't have to be directly managed by the master thread, but sometimes implementing the overhead of doing this in a thread isn't worth it if you're looking at a deadline.

Consumer desktop support for multithreading is just really now staring to take hold, and most programming languages that games are written in just don't do threading easily (or at all). There are a few initiatives out there to make programming threads easier (probably one of the coolest from a programming standpoint is something from Apple called Grand Central) but for now most programmers have to do all of the thread management themselves, and like I said above.. that's hard.

Now, if you've made it this far, I thank you for putting up with my rambling :-) All is not lost. Now that more and more people have multicore systems, it's becoming more viable to budget the time to get threading working. Major players on the market (Apple, Microsoft, Adobe, etc) are looking at this problem and trying to find ways for us moral programmers to do threading much easier (Apple has announced they're going to open source their Grand Central technology for example), and major programs like Photoshop and Office already have muththreading support or have it planned as a near term release. And once the tools are out there to do it efficiently game devs will start picking them up and seeing what they can do with them as well. So we're not there yet, but it shouldn't be much longer :-)

Magic. Gotcha.

[Durakken]

Magic. Gotcha.

Oh come on... that's easy to understand... it's not like we're talking quantum processors.

Let's try using an analogy...

Let's say you work at a McDonalds... You make hamburgers.

You need to make say 100 Hamburgers.

Your boss tells you to make 100 hamburgers so you go and set up your station, the grill only allows 2 patties at a time and you create a system so that as one patty gets done you can take it off the grill, wrap it and throw in the next just as the next patty gets done.

Now obviously you need 100 fries too and your the only one working so obviously this is going to take longer because you are handling 2 tasks and the hamburger or fries aren't as good a quality because your attention is doing 2 things. This means that instead of say an hour of work, you have 2 hours of work...

Now lets throw a second employee in there... What happens? You stay on the grill and you have your system going all smoothly and he works on the fries. You get this work done in an hour because the second person is off doing something that you would have to do if there wasn't another worker.

Let's add 2 more employees? What happens then? Well they have nothing to do so that doesn't lower your time to completion at all

What if we have 100 orders with no fries? Wouldn't it be faster if 2 or more people all worked on the burgers and you'd get it done in 15 minutes? No. Imagine that you only have one grill and one set of ingredients. What ends up happening is that one of you would have to direct the others so that the grill is always having 2 patties on it, the ingredients are always in the same spot, and all the people are working in concert...so what you are doing is creating extra work and chaos which takes time to sort out. If you are doing the grilling and leading the other person then what you have to do is grill the patty, tell the other person what to do, and check their work every single patty...so you are increasing the overall work.


Also... it's unnoticeable in small amount, even though that's when the percentage is bigger, because processors are able to handle a a lot of commands per second...a Ghz is 1,000,000,000 commands per second and most processors are 2.3Ghz so 2,300,000,000 processes. Let's say everyone on Earth did one thing in 1 second. Most processors would be able to record 1/3 of the actions that took place... And we use multicore processors with 2-4 cores now so they can record 2/3 to 100% AND still have time to plan our demise.

It's really amazing...and in 2 years Every action will be able to be recorded by a dual core... and 2 years after that every action will be able to be recorded on 1...It's an amazing thing. Did you know that the sum processing power of the internet is equivalent to 1 human brain...and in the near future (less than 20 years) the sum processing power of the internet will match all of humanity's brain power combined? and 2 years after that, it will be equivalent to double that.

In 20 years time we will be able to do things that we right now, even the smartest of us, will pretty much say is magic. We will have created things that even the Star Trek 31st century would call magic.

Oh and as for as quantum processors...this will blow your mind a bit probably...Let's say you take a single byte (4 bits 0000) in a quantum processor that byte is 1000, 1100, 1110, 1111, 0111, 0011, 0001, 0010, 0100, and every other possible combination at the exact same time and then when you ask it for the answer it gives you the most likely answer which is not always the correct answer and the most likely answer isn't always the same ^.^ Try using that in a math class 2+2=5 sometimes according to quantum processors.

[TwAgIssmuDe]

Well, I have played Galactic Civilizations 2 for awhile, and in the first expansion 'Dark Avatar'. The devs added the abilty for the AI to utilize a second core (if available) on higher tougher settings, it made the already smart AI even more cunning and challenging to play against.

The STO devs could probably add that feature in an expansion pack, I would hate to see my quad core go to waste.

[Solomon555]

Wow, good info here. I decided to go with a quad core at roughly the same speed as my dual core over a dual core with a slightly faster speed because it would help running other applications simultaneously.

I guess I still don't completely understand how Empire can release a patch, but other programs require "vastly" more complicated coding from the start.

Hey, as long as I can get in the game and it runs, I'm happy. :D

[Batleh]

Wow, good info here. I decided to go with a quad core at roughly the same speed as my dual core over a dual core with a slightly faster speed because it would help running other applications simultaneously.

I guess I still don't completely understand how Empire can release a patch, but other programs require "vastly" more complicated coding from the start.

Hey, as long as I can get in the game and it runs, I'm happy. :D

Well, one of the nice things about "finishing" a project is that you have a chance to go back and look at it and see what could be done better - I do it to my own code at work when I get a chance. They probably identified some places where threading might help out but they didn't do it at first because of the complexities involved and they were working under a deadline. Post launch they had a chance to go back and look at their code again, and at that point they already have working code that's been QA'd, they just need to add the threading, so the task becomes easier. Bugs that pop up there are likely due to the threading change, and are easier to track down :-)

[lemlo]

You guys should know that Co offers multi-core support, so I would think that STO would as well.

[andrewprofit]

I recently decided to upgrade from my old dual core processor, and in doing the research I discovered that very few games actually make use of a multi (dual or quad) core processor. Obviously I like to see STO make use of more than one core. (hint...devs...:D)

On a side note, does anyone know why most games don't seem to support this? I would think most developers would love to add performance, so I imagine the coding is significantly more complicated. Multi-core processors have been out long enough for the industry to have caught up by now.

I asked and the reply was something about duo core 32bit. That was a month ago what happens in the future and the quality of the info i dunno. I think it was one of the devs that compiles the clients. I was hoping he would compile a 64bit client.

[Solomon555]

You guys should know that Co offers multi-core support, so I would think that STO would as well.

That's good to know...thanks.