What do you want next?
Normal single core computers work in such a manner:
10. Instructions sent to CPU to process/calculate
20. CPU passes back results and lets system know it is ready for more processes/calculations
30. GOTO 10.
With this setup, nothing else can be passed to the CPU until it has processed previous results and returned them.
In a multi core (and technically P4 upwards with hyper-threading...) it would work like this, if coded to handle multi-threading:
10. Instruction A sent to CPU Core 1 to process/calculate
11. Instruction B sent to CPU Core 2 to process/calculate
12. Instruction C sent to CPU Core 3 to process/calculate
13. Instruction D sent to CPU Core 4 to process/calculate
20. Next set of instructions queued up
30. First CPU Core to finish passes back results and notifies the system it is ready for next item in the queue. Next Instruction sent to free CPU Core to process/calculate
40. GOTO 30.
As you can see, theoretically, it can process up to 4 times faster if you have a quad core system.
Problem is many fold though in reaching true 4x throughput, mainly being that not too many people actually code for multi core, and some of them that do pseudo code it, defining what parts should got to core 2 and 3 and such instead of letting the sub systems load balance it against first available core.
10. Instructions sent to CPU to process/calculate
20. CPU passes back results and lets system know it is ready for more processes/calculations
30. GOTO 10.
With this setup, nothing else can be passed to the CPU until it has processed previous results and returned them.
In a multi core (and technically P4 upwards with hyper-threading...) it would work like this, if coded to handle multi-threading:
10. Instruction A sent to CPU Core 1 to process/calculate
11. Instruction B sent to CPU Core 2 to process/calculate
12. Instruction C sent to CPU Core 3 to process/calculate
13. Instruction D sent to CPU Core 4 to process/calculate
20. Next set of instructions queued up
30. First CPU Core to finish passes back results and notifies the system it is ready for next item in the queue. Next Instruction sent to free CPU Core to process/calculate
40. GOTO 30.
As you can see, theoretically, it can process up to 4 times faster if you have a quad core system.
Problem is many fold though in reaching true 4x throughput, mainly being that not too many people actually code for multi core, and some of them that do pseudo code it, defining what parts should got to core 2 and 3 and such instead of letting the sub systems load balance it against first available core.
best would be if chris found out he has 4 hidden twin-brothers and they could get started on everything at once (
) <-- theres one without a beard
You should always proofread carefully to make sure you didn't any words out.
Need help? pm me or any other mod.
Good people of the Kenshi forums, I have revised(recast didn't sound nice in me head)my vote and am now one with the multi-threaders.
Let us spread the joys of a multi-core Kenshi to the puny players of other non multi-core supporting games!
We shall forever be mocking them!
My last words: Coneheads was a nice movie.
Edit: Felklaw converted me to the multi-threaders.
Let us spread the joys of a multi-core Kenshi to the puny players of other non multi-core supporting games!
We shall forever be mocking them!
My last words: Coneheads was a nice movie.
Edit: Felklaw converted me to the multi-threaders.
Chris_The_Great wrote:I'm totally adding giant cauldrons now
Baron Karl Friedrich Hieronymus Freiherr von Münchhausen wrote:Do a good deed, none shall remember ye.
Do a bad deed, none will forget ye.
-
Copperhell
- Posts: 11
- Joined: Thu Nov 03, 2011 5:34 pm
The way this game needs many improvements but is epic enough in this state is just awesome. Tinkering with the coding a bit could be good tough; it is very irritating to watch your guy do no damage when he attacks to a bandit's stomach and the bandit is guarding his head or when the bandit is blocking the opposite direction your guy is attacking.
Edit: And maybe adding a "welcome-the-player-into-the-game-guy" for explaining stuff.
Edit: And maybe adding a "welcome-the-player-into-the-game-guy" for explaining stuff.
I went with endurance, because that was probably the first thing that really struck me as unfinished. That said, if you have the time, what I'd really like to see is guards preforming finishing attacks on downed enemies once the battle is over, because it would keep bandits from periodically standing up and having all the guards run back over to finish that one wounded guy.
- OzyTheSage
- Posts: 53
- Joined: Sat Nov 19, 2011 12:36 am
This is kinda hard for me to decide on. On one hand, more features is going to rapidly increase how fun and varied the game is. On the other hand, performance is always a welcome thing. I'm going to vote for multi-threading just so that he can get the big part out of the way before moving on to fun stuff.
Honestly, I think that enabling multithreading is the best step forward.
Getting a good engine and a good base to build upon is probably the best idea. Why would you add features that would later be conflicted with engine upgrades? Its best to build a solid base that CAN handle massive armies before any more features are added.
Getting a good engine and a good base to build upon is probably the best idea. Why would you add features that would later be conflicted with engine upgrades? Its best to build a solid base that CAN handle massive armies before any more features are added.
Planks are best!
- OzyTheSage
- Posts: 53
- Joined: Sat Nov 19, 2011 12:36 am
Think of it this way. You have a machine that can punch one hole into a sheet of paper at a time. That's a single-core processor. If you have the same machine except it can punch 4 holes into the paper at a time, it has 4 cores. Most of the time, with single-threaded programs, the sheet of paper it feeds the machine is only wide enough to have 1 hole punched into it at a time even if it could normally punch 4 in. A multi-threaded program feeds paper in wide enough to be able to have 4 or more holes punched in at a time, thus it does more work in the same amount of time.
Not the best example or the most accurate but...
All you need to know is that things like AI, combat/damage/hit/health/etc. calculations, and pathfinding will work faster with a multi-threaded program, similar to have graphics typically look prettier as you improve your graphics card.
Not the best example or the most accurate but...
All you need to know is that things like AI, combat/damage/hit/health/etc. calculations, and pathfinding will work faster with a multi-threaded program, similar to have graphics typically look prettier as you improve your graphics card.
Hi all !
Changed my vote to multi threading.
If you get it out the way now,I guess we will all be happy,it's a win win situation really.
Temper
Changed my vote to multi threading.
If you get it out the way now,I guess we will all be happy,it's a win win situation really.
Temper
Last edited by Temper on Tue Nov 22, 2011 2:17 pm, edited 1 time in total.
My Kenshi avatar is going to be a very,very naughty little man.
- toaster Assassin
- Posts: 1186
- Joined: Thu Sep 29, 2011 6:27 am
- Location: Sitting at the front desk of the universe and holding the key to unlock your mind.
Ha ha, i'm a band wagon jumper (switched to multi-threading)
Yeah made the switch from more content to multi-threading, because the game is very in-depth and I would not like to see the finished product turn out like the Guild. (Nice game, but full of issues).
/\ Ignore this, it does not exist. (I will deny it if you ask me).Toaster Assassin said: (At this point performance is smooth (great job on early patching) so feature content should be a higher priority)
Yeah made the switch from more content to multi-threading, because the game is very in-depth and I would not like to see the finished product turn out like the Guild. (Nice game, but full of issues).
A voice in your computer's memory that refuses to go away. Now with 15% more (side notes!)
Semper fidelis amplus crustulum!
Kenshi forum rules: (We will assume that you have read this).
Semper fidelis amplus crustulum!
Kenshi forum rules: (We will assume that you have read this).
A few more votes and we'll become the majority (51% means YES on multi-thread support!)*
Spread the joys of Kenshi and laugh, laugh at those playing complex games with single-thread support only.
*My failed political maneuvering does not mean Chris will say yes, any and all agreements/acknowledgments by the great bearded one after my post are simply coincidental.
Spread the joys of Kenshi and laugh, laugh at those playing complex games with single-thread support only.
*My failed political maneuvering does not mean Chris will say yes, any and all agreements/acknowledgments by the great bearded one after my post are simply coincidental.
Chris_The_Great wrote:I'm totally adding giant cauldrons now
Baron Karl Friedrich Hieronymus Freiherr von Münchhausen wrote:Do a good deed, none shall remember ye.
Do a bad deed, none will forget ye.
I'm glad a lot of you decided to hop on over to multithreading, because lets face it:
The game is in early alpha, the version we are playing as of today is pretty much a very stable tech demo of the engine. Compared to how much content and how many features that could be put in this game, we really don't have much of a game to play right now (even though a lot of people on the boards seem more than content with playing it like a game).
What should be important to remember is that this isn't Minecraft, it's not written in Java and the scope and magnitude is much much larger than any other indie game I've seen. I think it's important that we all get used to the fact that development might be be slow. I can't speak for how hard or how effectively Chris is gonna work, but myself I am expecting a finished product at the very earliest 1,5-2 years from now.
What does any of this have to do with multithreading? Multithreading is something that isn't really needed at this stage, it probably isn't gonna directly improve the performance that much, because most people aren't suffering from performance issues at this stage of development. If Chris started adding in content and features on a regular basis, and then started on multithreading half a year from now, he could be stuck with it for several months and everybody would be crying for updates.
In the end we're probably back to logic. It's more logical to start with multithreading earlier rather than later for multiple reasons. It's more logical to start a large construction project with a solid foundation than starting it on a rickety one. It's more logical to harness the full processing power of a modern gaming computer than trying to get by on a quarter of it.
The game is in early alpha, the version we are playing as of today is pretty much a very stable tech demo of the engine. Compared to how much content and how many features that could be put in this game, we really don't have much of a game to play right now (even though a lot of people on the boards seem more than content with playing it like a game).
What should be important to remember is that this isn't Minecraft, it's not written in Java and the scope and magnitude is much much larger than any other indie game I've seen. I think it's important that we all get used to the fact that development might be be slow. I can't speak for how hard or how effectively Chris is gonna work, but myself I am expecting a finished product at the very earliest 1,5-2 years from now.
What does any of this have to do with multithreading? Multithreading is something that isn't really needed at this stage, it probably isn't gonna directly improve the performance that much, because most people aren't suffering from performance issues at this stage of development. If Chris started adding in content and features on a regular basis, and then started on multithreading half a year from now, he could be stuck with it for several months and everybody would be crying for updates.
In the end we're probably back to logic. It's more logical to start with multithreading earlier rather than later for multiple reasons. It's more logical to start a large construction project with a solid foundation than starting it on a rickety one. It's more logical to harness the full processing power of a modern gaming computer than trying to get by on a quarter of it.
thats what i wanted to say too (didnt get myself to say it cause im sick/ill lol)Nithy wrote:Voted for the first option, mainly because the more features the game has, the more interesting it will be for people. That way, more people will check out Kenshi, and more people would buy it, helping out Chris.
at least some little features should be added even though multithread is important too (as i said, chris just needs to find his brothers
You should always proofread carefully to make sure you didn't any words out.
Need help? pm me or any other mod.
Obviously I chose multi threading...
I believe that not only if other functionality comes in and it slows down the systems, we do lose some people (not us die hard zealots!!) who complain about performance.
Also, we don't know how hard it would be for him to recode after the fact to make it MT compatible.
And with the growing AI levels and population, that will benefit the most from a good CPU utilisation.
Much the same way that Flight Simulator X actually gets a great FPS improvement by having a better and faster multi core CPU instead of a beefier GPU.
All the calculations that go on in the background before it is even rendered is what will bog it down, so the better that is handled, the cleaner the end product will run.
And Zalak, multi threading is like taking one strand of cotton, and one strand of silk and....
I believe that not only if other functionality comes in and it slows down the systems, we do lose some people (not us die hard zealots!!) who complain about performance.
Also, we don't know how hard it would be for him to recode after the fact to make it MT compatible.
And with the growing AI levels and population, that will benefit the most from a good CPU utilisation.
Much the same way that Flight Simulator X actually gets a great FPS improvement by having a better and faster multi core CPU instead of a beefier GPU.
All the calculations that go on in the background before it is even rendered is what will bog it down, so the better that is handled, the cleaner the end product will run.
And Zalak, multi threading is like taking one strand of cotton, and one strand of silk and....
-
- Information
-
Who is online
Users browsing this forum: No registered users and 5 guests