[RANT] Minecraft is NOT single threaded

Discussion in 'Spigot Discussion' started by MrIvanPlays, Sep 11, 2020.

Thread Status:
Not open for further replies.
  1. Optic_Fusion1

    Resource Staff

    I wouldn't be surprised if they were forced to spaghetti due to notch's spaghetti because they don't want to do a full re-write to make their lives easier
     
  2. with the increasing features, a 10 (max 15) developers can't just rewrite the entire thing from scratch.
    or if the previous code is spaghetti, then why the new code is spaghetti too? they aren't forced to (majorly) write spaghetti if the current code is spaghetti. mojang developers are good game designers, but bad engineers.
     
  3. Yes, the server does use some different threads. For example, chunks are saved async (only the IO operation is done on a different thread, actual creation of the data to save is not), and console input has its own thread.

    But otherwise, the game is on one thread. Entity ticking, world ticking, connection ticking, even some networking, is all done on the same thread. Basically all of the vanilla code, and any added code by Bukkit or Spigot is not thread-safe. While there may be some small stuff done on a different thread, it's safe to say the whole server is pretty much ran on one thread.
     
    • Agree Agree x 6
  4. At least they did it with 1.15. Adding less features on favour a little bit refactoring of the code. I would be happy if they do it at least every 3 version of mc. Less features and cleaning up the mess.
     
    #24 ysl3000, Sep 11, 2020
    Last edited: Sep 11, 2020
    • Winner Winner x 2
    • Agree Agree x 1
  5. what did they do? fixing bugs doesn't fix the code, nor the performance. mojang expects that if they fix a bug or 2 the game would have better performance, but its not how it works. the major problem is still there
     
  6. The whole code of the world generator for custom Biomes etc. at least is rewritten to support the features in 1.16. So they do make small steps into the right direction. 1-2 years with no features and a rewrite from scratch has the problem that requirements changing every time a feature is written. E.g. they implemented multithreaded chunk/world generation as a preparation for the new world features.

    At least what I experienced with the company I'm working for is that a refactoring has to included in some feature. Customers normally don't have the money to pay for dedicated refactoring. So if we are touching a component for a feature anyways we can refactor it a little bit.
     
  7. Lol, i love this response so much xD
     
  8. lol (obligatory)

    This post is super silly Ivan.

    People don't say single threaded meaning it only uses a single thread. The phrase means the game has a heavy bias towards a single thread where all the main g

    Wrong. The super bad code is all written by current devs in modern MC versions. I would gladly go back to notch code at this point.

    Notch has very little blame in the performance issues of today.

    Notch's code wasn't even really spaghetti either. Don't know why people say that. I can't recall a single thing of MC of old that would constitute "spaghetti code"

    Mojang trying to rewrite core elements of the game is whats destroying performance. They are continuously adding badly written code and patterns and that is the source. NONE of the recent issues are any fault of notch. The recent issues are because they fully got rid of notch's code and replaced it with something that performs worse.

    Spaghetti has nothing to do with anything here.

    Now I will go take a bath for saying positive things about Notch.
     
    • Winner Winner x 7
    • Agree Agree x 1
  9. EpicGodMC

    EpicGodMC Previously EpicGodMC202

  10. I actually agree on this too. Been thinking for some time now and the performance was gr8 in the older versions. When mojang enforced java 8 with 1.12, things started to get bad cuz they discovered java 8's stream api and the rest you know. Yes before you say streams arent the biggest problem yes I know they're not but you can see versions that dont use it and versions that do (exclude the "new versions have more features" part)

    Im 50/50 on this. You wouldnt know which person says what.
     
  11. The Kids Today™ don't know how to write efficient code. Some of us started writing code for 4 MHz (yes, 4 MHz) processors. Efficiency was important then!
     
    • Funny Funny x 2
  12. Optic_Fusion1

    Resource Staff

    It would be amusing too see people use hacky methods and stuff now and days, anything and everything to optimize the code and save space even a little bit
     
  13. Memories of the Atari 2600 from http://www.ataricompendium.com/archives/interviews/stuart_ross/interview_stuart_ross.html

    In the early days the first few games were contracted out to other programmers, who would basically use up the 4K they had and then stop. My first job was going with Rich Ekerstrom (the Producer) out to Chicago to meet with whoever the programmer was (usually at the worst time, like a Friday night, so they weren’t too happy to see us), and they’d have a little office in their home with an emulator set up. And we’d say, “Gorf needs to do this.”, and they’d say, “It can’t, because we’re out of space.” So I’d have him print out a big green-bar paper (source code) listing and then I’d sit down and take a marker and find bytes we needed. By then Rich would be back with a pizza and it’d be 10:30, so we’d work on optimizing the code, which might take until about 1am. So the programmer would sit back and think, “Ah, this is great. Now I can get paid…”, and then Rich would say, “Ok, well you did that. Now we need to handle this,” and he’d have a list of functions and features that needed to be in the game, and the programmers eyes would just bug out. And the process would start all over again.

    But maybe that can be a blessing...

    As the (ROM) size of games grew, the essence of creativity changed. It became more a process of turning a crank. In the old days we’d struggle to find 5 bytes to put a game feature in; every byte was precious. With the CD, suddenly you had 650 megabytes, and the problem was people felt obligated to fill it up, and so the cost of doing a game wasn’t 1 person over 5-6 months to fill 4K with something carefully crafted - now you had 20 artists rendering pictures because you had room for them, and the development cost went up to like a million dollars.

    (Mentioned on that site is Ed Pryzby. He was my best friend when I was 10 years old.)
     
  14. Optic_Fusion1

    Resource Staff

    That's cool. I believe if people were to go the route of optimize everything & do everything you can to save space you'd have to use Assembly, C, C++, or some other language like that. I don't really think you can get that optimized with something like java sadly qwq
    It would be amusing to see though
     
  15. I did assembly language* for about 15 years. The problem with Assembly is mistakes involving register usage. Things like forgetting to initialize a register so that some completely unrelated function changes and causes your function to crash; Have fun finding that one. Or just wiping out a register by mistake. High-level languages make these problems go away (assuming the compiler doesn't generate bad code, which I've seen more than once).

    The problem with high-level languages is that people are encouraged to use complex features without understanding how they will affect the overall system. More complicated languages (Java, C++, or anything involving constructors!) makes that more likely to be a problem. C is probably better because you know everything that's going on; After all, you're the person who wrote it!

    Of course, nothing will help you if you pay your software engineers $9/hour like Boeing did.

    * TI 9995, Zilog Z8, ATAC-16M, MIPS R3000
     
    #36 Bobcat00, Sep 20, 2020
    Last edited: Sep 20, 2020
  16. Optic_Fusion1

    Resource Staff

    Fair, you still wouldn't be able to get a super small java program though, unlike say super mario bros 1 due to how java works and is in general for example
     
  17. Java is a really bad language to use for anything time-critical.
     
  18. Optic_Fusion1

    Resource Staff

    of course, still useful for a lot of things though (e.g. Minecraft)
    You *could* recreate most if not all older games, the re-creations would just be larger than the original, even with various tricks to make the jar as small as possible
     
Thread Status:
Not open for further replies.