Multithreading with Web Workers

Discussion in 'Javascript/Plugin Support' started by Fhntop, Jan 2, 2018.

  1. Poryg

    Poryg Pixie of the Emvee kingdom, Ham of a Hamster Veteran

    Messages:
    3,348
    Likes Received:
    8,115
    Location:
    Czech Republic
    First Language:
    Czech
    Primarily Uses:
    RMMV
    But they are supported by MV and handled by javascript, in fact it's a javascript running outside of the main thread (or some people like to say on the background).
     
    #21
    elpeleq42 likes this.
  2. Fhntop

    Fhntop Villager Member

    Messages:
    28
    Likes Received:
    22
    First Language:
    Spanish
    Primarily Uses:
    RMMV
    I've only used JS with web browsers so I keep misusing the term, thanks for clarifying xD
     
    #22
  3. Joy Diamond

    Joy Diamond Talkative Veteran

    Messages:
    135
    Likes Received:
    172
    First Language:
    English
    Primarily Uses:
    RMMV
    Web workers are not implemented until nw.js 0.18.4
    • RPG Maker MV 1.5.1 uses nw.js 0.12
    • RPG Maker MV 1.6.0 beta uses nw.js 0.25
    So you would have to wait until RPG Maker MV 1.6.0 to even consider web workers.

    The much much bigger issue is the following reality:
    • Only about 5% of good programmers can create threaded programs with a reasonable low enough amount of bugs to be still useful.
    Multi-threading is not natural to the human mind, the metaphors get all confused in the mind & bugs creep in & multiply.

    And that is just the beginning of the problems ...

    I strongly suggest not even considering doing multi-threading programming until 90%+ of your code is unit tested ...:

    • This is a reasonably good metric on whether you are a ready for the confusion of multi-threaded programs, because you will need tons of good unit testing to create a multi-threaded program has a reasonably low enough amount of bugs to be useful.
     
    #23
    LTN Games and Fhntop like this.
  4. BigEd781

    BigEd781 undefined method 'stupid_title' found for nil:NilC Veteran

    Messages:
    940
    Likes Received:
    303
    Location:
    Austin, TX
    First Language:
    Dothraki
    Primarily Uses:
    N/A
    Being a software engineer for going on 13 years now that "statistic" is extremely hyperbolic, but yes, it makes things more difficult. I wouldn't suggest not trying it though. What's the worst that happens here? The programmer learns a bit more than they knew before.

    It's not rocket science, but you need to be careful about minimizing shared state, synchronizing access to shared state where required, and generally structuring your code to avoid race conditions (easier said than done, yes, requires experience.) It's not trivial, but the complexity depends on the problem you're trying to solve, and everyone starts somewhere.

    As an aside, good luck unit testing race conditions. By definition they can be hard to catch and you would need to be very careful in how you write your tests (along with some luck) to be even moderately comfortable that you've exercised the code in a way which would bring them out. Typically experience and careful code reviews are how you catch race conditions prior to release.
     
    Last edited: Jan 4, 2018
    #24
    Fhntop likes this.
  5. Fhntop

    Fhntop Villager Member

    Messages:
    28
    Likes Received:
    22
    First Language:
    Spanish
    Primarily Uses:
    RMMV
    Thank you very much for your detailed response!
    I saw just recently the beta for 1.6.0 but I guess now I have to try it xD

    I'm not worried about the bugs. I have some experience with the topic using other languages and after much reading I'm almost sure (because of how Web Workers communicate) that there won't be many issues the way I'm thinking of using them.

    Anyway, just like @BigEd781 says, the worst that can happen is that I learn something new :D
     
    #25
    Joy Diamond likes this.
  6. Joy Diamond

    Joy Diamond Talkative Veteran

    Messages:
    135
    Likes Received:
    172
    First Language:
    English
    Primarily Uses:
    RMMV
    If you want to write multi-threaded programs for yourself, then sure, go ahead & have tons of fun. It is very educational.

    I didn't write my sentence carefully enough, sorry. By "useful" I meant useful to other people when you release your code to them.
    • In other words, create multi-threaded programs that you can give to other people & is useful, with a reasonably low enough bugs to not drive them crazy at a critical time (when the bugs suddenly show up).
    It can be done, but yes, very very hard to unit test race conditions:
    • If you can write proper multi threaded programing; then you also know how to write proper unit tests that catch (most) of them -- and it is not luck, it requires a lot of skill.
    • And yes, experience & careful code reviews are also required
    • (And many other things -- above I just summarized it as quickly as possible on the most important part, unit testing)
    As I wrote above:

    As evidence of how hard multi-threaded programming is, how the metaphors get confused in the mind & bugs creep in & multiply, I point you to the geniuses at Intel who design CPU's for multi-threading ... (just a random report I picked up that was reported yesterday to do with multi-threading issues):

    So in today's monumental mess up:
    • Intel CPU's all leak kernel information to User processes (they do speculative look ahead & you can read an address in a user process & see if it cached or not; i.e.: did you guess a kernel memory will return yes or no)
    • Cost to fix: 17% to 23% slowdown on ALL Windows & Linux systems that use Intel CPU's made in the last 10 years!
    • The bug is in the super-fast L1 cache, which does not have protection to make sure a ring-3 user process can access ring-0 [cached] kernel memory.
    Article: https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/

    Explanation of the problem: https://cyber.wtf/2017/07/28/negative-result-reading-kernel-memory-from-user-mode/

    To understand the scale of the problem & the importance of this fix (even if it does cause the 17% to 23% slowdown worldwide in computers):
    • It is well known in the security world, that: *Any timing attack*, can in general, be converted to code that can break a password in a minute or less....
    • Although the above statement would appear to be speculative, experience has shown, in reality: it is true.
    • Thus not fixing this problem, means, passwords, all over the world will be broken ...
    P.S.: AMD of course has to take advantage of this, their zinger:

    "AMD processors are not subject to the types of attacks that the kernel page table isolation feature protects against. The AMD microarchitecture does not allow memory references, including speculative references, that access higher privileged data when running in a lesser privileged mode when that access would result in a page fault."​

    And I do not mean geniuses sarcastically. I mean it sincerely, they are geniuses who design the CPU's in our modern day computers:
    • And with all their testing, even over 10+ years, they let a super serious bug like that creep into their CPU architecture.
    Multi-threading is really hard because it goes counter to how our minds work, it confuses the metaphors in our mind that we use when programming. And when we are confused, then we create bugs without realizing it.
     
    #26
  7. BigEd781

    BigEd781 undefined method 'stupid_title' found for nil:NilC Veteran

    Messages:
    940
    Likes Received:
    303
    Location:
    Austin, TX
    First Language:
    Dothraki
    Primarily Uses:
    N/A
    I don't necessarily disagree with anything that you're saying, but I think it's too general and dogmatic. You're likely to scare beginners off from even trying. What you're doing matters. If you're spinning up N threads to e.g. make some web requests and return some data the likelihood of having a slew of bugs is low. If you're designing a massively complex general purpose CPU which _implements_ a threading pipeline... yeah, you're bound to have more issues. An assessment of complexity and associated risk is required here.

    Also, we're talking about RPG Maker scripts here, not CPU's driving millions of computers. Worst case someone releases a buggy script, wastes the time of a handful of people, and then the script dies.

    Re unit testing: you can't unit test everything. Not even close. In a past life I helped to design a digital tissue scanner used by pathologists. This thing was massively complicated, depending on dozens of hardware modules and integration with remote services. You simply can't unit test something like that in a way which mimics real life use.

    Unit testing is all well and good, but only integration testing and beating the crap out of the code in a real environment bring the hard stuff to light.
     
    #27
  8. Fornoreason1000

    Fornoreason1000 Black Sheep Veteran

    Messages:
    199
    Likes Received:
    91
    Location:
    Anor Londo
    First Language:
    English
    Primarily Uses:
    RMMV
    as stated, its hard to make use of the Web Workers in MV.
    MV's main problem I've noticed with performance is the creation of hundreds to thousands of objects in one frame(a 40x40 map will take around 100ms to create after loading, a 60Fps frame is only 16.6ms) which it uses PIXI.js to do.

    the best you can do use them to load sprites and Audio in the workers and run some processing on them, but since the workers do not share data with the main thread and cannot access PIXI.js, globals (such as $gamePlayer, $gameMap), DOM and anything else defined in the main thread. This makes Worker nearly useless for the purposes of Graphics and Audio.

    this is to avoid the thread concurrency issues we already talked about. you need to transfer the data across (to the Worker AND back to the Main thread), which I've been told is pretty slow anyway. it also "Copies" the data, so the instance in the worker is a complete separate object.
     
    #28

Share This Page