Unfortunately, most threads must run at 50ms because that is how Minecraft is built to work (time has to be updated every 50ms, and there's no use in dedicating one thread to updating a long for the sake of not having two other threads run at the same tick). I would much prefer something like 10/20ms, because my machine is quite incredible and is comfortable with pretty much anything

I'm asking you guys to tell me what you think of this thread pattern for a game like Minecraft...will it encounter a problem, will it perform slowly, etc.

Thanks

Find me on GitHub: connergdavisMy current project is called Obsidian Framework and is a private Minecraft server application used to play Multiplayer.

how does it make sense to multi thread the player updating but single thread your IO (reading/writing of packets, adding to queue, that part)

unless I misinterpreted

I haven't had time to think about file I/O ops yet...now that I think about it, I don't think it would be that easy to execute a lot of I/O operations on one thread.

Looking at how I've mixed my pattern up a bit (I run using Netty networking framework now, so its threads are accounted for) I'm now looking at something like this (not including Netty) :

Entity updating ~ Number of threads equals number returned from Runtime#availableProcessors()File I/O ~ Number of threads equals number returned from Runtime#availableProcessors() OR I might do that number / 2, depends on which works betterWorld updating ~ One thread per running world, this works fine because Minecraft servers often have multiple worlds running, and the amount of tasks executed here is small

On my beta MC server, I will be running one world for a while until I feel it necessary to test more than one, which means I'll be running 9 non-networking threads on my 2-core hyperthreading processor @ 2.93 GHz. If it can run a CraftBukkit server with 25 people just fine (~20% CPU) it can run mine

ALSO

Not relevant to my current situation, but..

You said it would be bad for networking packet I/O, but I've seen (and talked to the people who've made) gaming servers that run Networking I/O operations on one thread each. As long as that thread is dedicated to a specific operation, and you do all you can to make it do as little as possible while still doing its job, you can easily get it done.

Find me on GitHub: connergdavisMy current project is called Obsidian Framework and is a private Minecraft server application used to play Multiplayer.

It's even worse, if you're doing multi-threaded (heavy) file I/O on a HDD (mechanical seeks) you'll ruin your performance, you can easily lose factor 25x or so, when one file is near the center and the other is near the edge of a disk.

Hi, appreciate more people! Σ ♥ = ¾Learn how to award medals... and work your way up the social rankings!

It's even worse, if you're doing multi-threaded (heavy) file I/O on a HDD (mechanical seeks) you'll ruin your performance, you can easily lose factor 25x or so, when one file is near the center and the other is near the edge of a disk.

That doesn't sound right. If you multi-thread your file requests, you could improve performance many times on both mechanical HDs and SSDs. Sure, if you're just reading large files, reading 32 of them at the same time is gonna reduce performance on mechanical drive, but reading 32 4kb files at the same time may increase performance a lot due to how a mechanical hard drive reads files in the order they are encountered when seeking, not in the order they were requested. It all depends on the file size of the files you're reading. If you have many small files, multiple threads are going to have better performance.

Even if you are reading larger files, using 2 or more threads might be a good idea, as that might remove the HD - CPU sync that happens when reading:CPU requests file -> CPU idles -> HD seeks and finds file -> HD sends file data to CPU -> HD idles -> CPU starts processing file...It's the same reason you queue up OpenGL commands and not wait for a command to complete, right? I might be off on this last part...

Some HDDs will improve in performance as the number of outstanding IO's (i.e. queue depth) increases. This is usually the result of more advanced controller logic on the drive performing command queuing and reordering commonly called either Tagged Command Queuing (TCQ) or Native Command Queuing (NCQ). Most commodity SATA drives either cannot do this, or their implementation is so poor that no performance benefit can be seen.[citation needed] Enterprise class SATA drives, such as the Western Digital Raptor and Seagate Barracuda NL will improve by nearly 100% with deep queues.[5] High-end SCSI drives more commonly found in servers, generally show much greater improvement, with the Seagate Savvio exceeding 400 IOPS—more than doubling its performance.[citation needed]

I don't really know what to make of it. Definitely need a benchmark. Sadly Tom's Hardware has only been doing SSD benchmarks for the last year. -.-

how does it make sense to multi thread the player updating but single thread your IO (reading/writing of packets, adding to queue, that part)

unless I misinterpreted

The disk can only do one thing at a time, multithrading IO doesn't make sense. At least as far as I know.

"reading/writing of packets, adding to queue, that part"

once again, it doesn't make sense to multithread game logic and single thread the packets reading/writing and adding to queue

should be the other way around

@Conner_

keep the file handler single threaded

and I'm not sure what you mean by "You said it would be bad for networking packet I/O"

do you mean I said it's bad to single thread it?

it is not as good to have single threaded as multithreaded, but you might not necessarily need to multithread since I don't think minecraft gets a lot of players per server anyways () i was mostly just pointing out that you had the concepts reversed. game logic should be single threaded, something like reading/writing from a network and adding to different queues can run in parallel

Only things being written to or read from are Minecraft save files (small data region files and one ~2mb level save) and player saves. Player saves can't go above like 8kb, depends on the amount of items they have in their inventory.

Find me on GitHub: connergdavisMy current project is called Obsidian Framework and is a private Minecraft server application used to play Multiplayer.

Now that I think about it, you will always have performance gain from multithreading your file i/o but the question is, is it necessary (probably not lol, unless you're constantly saving/loading files, like a huge webserver might do)

Now that I think about it, you will always have performance gain from multithreading your file i/o

...

reading from hdd is synchronous so that won't happen, requests to it are queued

It doesn't matter how you 'reason' your way out, it's simply much faster to write large amounts of contiguous bytes, one file at a time.

A HDD doesn't work like your average I/O queue, where the throughput is constant. The more time the (mechanical) head is moving (due to seeking), the more throughput you lose.

If you write a big file, the head hardly moves.If you write two a big files, the head moves back and forth on each write (lets assume every 4K).

Every seek takes about 5-10ms, which limits your seeks to 100-200 per second (IOPS).100 * 4K = 400K / sec200 * 4K = 800K / secThis is worst-case scenario, mind you, but the more files you concurrently read/write, the more likely it becomes that you reach that dreadful performance.

This is also why copying a directory-structure with lots of tiny files has such horrible performance: every dozen reads are followed by a seek and the writes are also all over the place...

Hi, appreciate more people! Σ ♥ = ¾Learn how to award medals... and work your way up the social rankings!

Now that I think about it, you will always have performance gain from multithreading your file i/o

...

reading from hdd is synchronous so that won't happen, requests to it are queued

It doesn't matter how you 'reason' your way out, it's simply much faster to write large amounts of contiguous bytes, one file at a time.

A HDD doesn't work like your average I/O queue, where the throughput is constant. The more time the (mechanical) head is moving (due to seeking), the more throughput you lose.

If you write a big file, the head hardly moves.If you write two a big files, the head moves back and forth on each write (lets assume every 4K).

Every seek takes about 5-10ms, which limits your seeks to 100-200 per second (IOPS).100 * 4K = 400K / sec200 * 4K = 800K / secThis is worst-case scenario, mind you, but the more files you concurrently read/write, the more likely it becomes that you reach that dreadful performance.

This is also why copying a directory-structure with lots of tiny files has such horrible performance: every dozen reads are followed by a seek and the writes are also all over the place...

I think you're thinking too much into it If the benchmark says that dedicating more than one thread to file I/O operations executes an operation faster than on a single thread, it's fair to assume that you should probably dedicated more than one

Find me on GitHub: connergdavisMy current project is called Obsidian Framework and is a private Minecraft server application used to play Multiplayer.

I think he's under the misconception that you can concurrently read things from a hdd (that would potentially be obscenely inefficient, because of the reasons he stated) in which case his theory would be correct.

I think he's under the misconception that you can concurrently read things from a hdd (that would potentially be obscenely inefficient, because of the reasons he stated) in which case his theory would be correct.

I could see multi-threaded seeking being about the same speed as single-threaded, but I could never see it being faster.

Do you know what the difference is between requesting to write files from two threads is as opposed to requesting to write a file from one thread?

(the actual process that is happening after you send a request to write a file)

actually there is no difference, which is why you guys are wrong.

if anything the difference is, with multi threading you add 2 requests to the queue one after the other (potentially) and the first request is fulfilled then the second request is filled.

in single threading, you add one request to the queue, it is fulfilled, then you add the next request to the queue and it is fulfilled.

if externals application are hogging the hdd, then there should really be no speed difference (if they are, multithreaded will be faster, depending on what other applications are doing)

so in an ideal environment where only your application is using the hdd, in terms of file writing speed, there is no ~noticeable difference

the actual speed comes from other things not directly related to writing files (for example, things like creating FileOutputStream objects can be done concurrently)

this is the truth, this was supported by my benchmarks

i don't see why you keep holding on to the idea that when you multithread file writing, the disk is writing each file at the same time and therefore seeking a lot... that's not true. you only seek once per file

No, it's a question of physics and velocity. Hard drives are not flash memory, they have a spinning disk which revs up and if you seek in the opposite direction it must stop and spin the other way. Physics.

Hihi, HDDs have a constant speed. If you seek back, you simply have to wait for slightly less than a single revolution.

If you all think the operating system translates your InputStream reads directly into disk seeks, you need to brush up on the evolution of operating systems from the DOS days. Modern operating systems have buffer caches and IO schedulers that go all the way down to understanding disk geometry.

The main problem with using threads willy nilly is the amount of memory they take up, since they each have to haul a stack along with them. All the other claims being thrown around are meaningless unless they can be backed up with actual data. Benchmarks aren't perfect, but I'll take them over anecdote any day.

Besides, if you want performance, you really should be using nio, and that's an async design that doesn't lend itself to thread-per-stream anyway.

No, it's a question of physics and velocity. Hard drives are not flash memory, they have a spinning disk which revs up and if you seek in the opposite direction it must stop and spin the other way. Physics.

Hihi, HDDs have a constant speed. If you seek back, you simply have to wait for slightly less than a single revolution.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org