The reason I ask is because many people are saying that Minecraft singlepalyer still uses only one core. I understand that it would be the case for 1.2.5 and before, but that would not make sense for newer versions. Since the client runs an integrated server, wouldn't that mean the client and server run as two threads?
It would not make very much sense for the client and server to run on the same core, since the client-server model separates the components. As far as I can tell, the client and server still exchange packets over an internal connection.
Just because a game is multi-player does not mean that the game has to be multi-threaded, and in the case of Minecraft really the game would not benefit much even if it was multi-threaded. Many users think that if the game was multi-threaded and took advantage of using multiple cores at once that it would run much faster and be a more smooth experience and this simply is a load of crap.
Yes there are areas that it would help such as disc ops, but for the most part we really won't see much of a difference.
Just because a game is multi-player does not mean that the game has to be multi-threaded, and in the case of Minecraft really the game would not benefit much even if it was multi-threaded. Many users think that if the game was multi-threaded and took advantage of using multiple cores at once that it would run much faster and be a more smooth experience and this simply is a load of crap.
Yes there are areas that it would help such as disc ops, but for the most part we really won't see much of a difference.
This is not necessarily true; otherwise, why does 1.3+ run a lot smoother (for me)? Because in earlier versions the game has to process game logic in the same loop that renders frames, and your eyes will perceive any stutter as a reduction in frame rate even if the average FPS is high enough to look smooth:
The server gets to run everything in its own time. If it can't keep up 1 tick per 50ms (this is 20 ticks per second btw, Minecraft Standard Time) then no big issue; it just skips one and carries on as normal. The client just renders what it knows, and will never get slowed down because the server is stuck working something out. That way the client gets higher FPS (or rather, the FPS just doesn't get lower) and the game is more responsive.
If you don't have a multicore processor and it's a pretty old one, then it can't run both at the same time; you'll end up with the old behaviour where slow ticks will slow your FPS. It may still be smoother due to some special magic, but you're not going to see the performance boosts that everyone else gets.
This can best be seen if you teleport to an area which has not generated yet; there is no effect client-side despite the server being basically hung up while generating the chunks, while if they were both on the same thread the entire game would freeze (presuming no measures were taken to allow the client to have some minimum time slot to process user I/O, as a program should so you don't get the "not responding" notice while it works).
Likewise, prior to 1.8 Optifine had a multi-core option that used a second thread for rendering (miscalled "chunk loading", but it actually renders/updates chunks) - which was added to vanilla in 1.8, leading to great performance boosts for some people (I was not one of them, with severe performance degradation, then the computer I had at the time was only dual-core and below the updated system requirements):
The multithreaded chunk loading is crude and it will need a lot of optimizations in order to behave properly. Currently it works best with multi-core systems, quad-core is optimal, dual-core suffers a bit and single-core CPUs are practically doomed with vanilla. Lag spikes are present with all types of CPU.
(again, this actually has nothing to do with "loading" chunks from disk or whatever; I've decompiled Optifine so I can see it really refers to updating a chunk section by re-rendering it, and even Optifine's multi-core rendering caused more lag spikes for me in 1.6.4, while my current computer, with a quad-core CPU, runs better with it). The game also uses (including before 1.8) a dedicated thread for asynchronous disk I/O so the main thread doesn't have to wait for the disk; there are also several other minor threads, although they don't really do much, and too many main threads can hurt since it is relatively expensive for the CPU to switch between them).
There are areas that it will help, but the core logic is a total waste of time in respects to turning it into a multi-threaded application. The thing with multi-threaded applications is that 2 threads can't work with a global variable at the same time. This is why mutex's and similar thread locking code exists, to prevent just such things from occurring. There are a few areas where it will help, rendering is one, disc op's are another, but the core game really won't help much, and if it was turned into multithreaded then it's going to be so chulk full of thread locks that it really won't make much of a difference.
What I'm saying is that multi-threaded applications are very complicated, 1 wrong touch of a normally ok to mess around with variable can bring about a very painful debugging session. Granted I have not done any programming in several years now, so things may have changed somewhat. Hell todays programmer's don't realize how well they got it. Back in my day, if you allocated it, you free'ed it! Todays garbage collection with managed code really makes me scratch my head at times, creating some awfully lazy programmers, that don't clean up after themselves, much like my kids!
I am mostly talking about the client and server. TheMasterCaver answered this for me.
I was just wondering, since the way SSP is done avoids the concurrent access pitfall by communicating in packets like a game over an IP network would. I do agree that multi-threading must be thought out, but now that Minecraft has essentially made client and server two distinct components that communicate internally with packets, they can run concurrently as they don't share variables. I suppose that was done to allow the LAN export, since it just then opens up an IP socket and the server can then accept external connections.
The reason I ask is because many people are saying that Minecraft singlepalyer still uses only one core. I understand that it would be the case for 1.2.5 and before, but that would not make sense for newer versions. Since the client runs an integrated server, wouldn't that mean the client and server run as two threads?
It would not make very much sense for the client and server to run on the same core, since the client-server model separates the components. As far as I can tell, the client and server still exchange packets over an internal connection.
Which MC version are we talking about here?
Any version 1.3 and later, where the client runs an integrated server.
Just because a game is multi-player does not mean that the game has to be multi-threaded, and in the case of Minecraft really the game would not benefit much even if it was multi-threaded. Many users think that if the game was multi-threaded and took advantage of using multiple cores at once that it would run much faster and be a more smooth experience and this simply is a load of crap.
Yes there are areas that it would help such as disc ops, but for the most part we really won't see much of a difference.
This is not necessarily true; otherwise, why does 1.3+ run a lot smoother (for me)? Because in earlier versions the game has to process game logic in the same loop that renders frames, and your eyes will perceive any stutter as a reduction in frame rate even if the average FPS is high enough to look smooth:
This can best be seen if you teleport to an area which has not generated yet; there is no effect client-side despite the server being basically hung up while generating the chunks, while if they were both on the same thread the entire game would freeze (presuming no measures were taken to allow the client to have some minimum time slot to process user I/O, as a program should so you don't get the "not responding" notice while it works).
Likewise, prior to 1.8 Optifine had a multi-core option that used a second thread for rendering (miscalled "chunk loading", but it actually renders/updates chunks) - which was added to vanilla in 1.8, leading to great performance boosts for some people (I was not one of them, with severe performance degradation, then the computer I had at the time was only dual-core and below the updated system requirements):
(again, this actually has nothing to do with "loading" chunks from disk or whatever; I've decompiled Optifine so I can see it really refers to updating a chunk section by re-rendering it, and even Optifine's multi-core rendering caused more lag spikes for me in 1.6.4, while my current computer, with a quad-core CPU, runs better with it). The game also uses (including before 1.8) a dedicated thread for asynchronous disk I/O so the main thread doesn't have to wait for the disk; there are also several other minor threads, although they don't really do much, and too many main threads can hurt since it is relatively expensive for the CPU to switch between them).
TheMasterCaver's First World - possibly the most caved-out world in Minecraft history - includes world download.
TheMasterCaver's World - my own version of Minecraft largely based on my views of how the game should have evolved since 1.6.4.
Why do I still play in 1.6.4?
There are areas that it will help, but the core logic is a total waste of time in respects to turning it into a multi-threaded application. The thing with multi-threaded applications is that 2 threads can't work with a global variable at the same time. This is why mutex's and similar thread locking code exists, to prevent just such things from occurring. There are a few areas where it will help, rendering is one, disc op's are another, but the core game really won't help much, and if it was turned into multithreaded then it's going to be so chulk full of thread locks that it really won't make much of a difference.
What I'm saying is that multi-threaded applications are very complicated, 1 wrong touch of a normally ok to mess around with variable can bring about a very painful debugging session. Granted I have not done any programming in several years now, so things may have changed somewhat. Hell todays programmer's don't realize how well they got it. Back in my day, if you allocated it, you free'ed it! Todays garbage collection with managed code really makes me scratch my head at times, creating some awfully lazy programmers, that don't clean up after themselves, much like my kids!
I am mostly talking about the client and server. TheMasterCaver answered this for me.
I was just wondering, since the way SSP is done avoids the concurrent access pitfall by communicating in packets like a game over an IP network would. I do agree that multi-threading must be thought out, but now that Minecraft has essentially made client and server two distinct components that communicate internally with packets, they can run concurrently as they don't share variables. I suppose that was done to allow the LAN export, since it just then opens up an IP socket and the server can then accept external connections.