28 ms·

JavaScript in Parallel: Web Workers and SharedArrayBuffer

172 points by avgp 10y ago

franciscop 10y ago
If you don't like to have to load an external file (+ an extra request) you can use my library uwork: https://github.com/franciscop/uwork https://github.com/franciscop/uwork It has some limitations, but for long lived process intensive and async functions is perfect. It has a really clean and easy syntax where you don't need to learn everything about Web Workers and their APIs to be able to use it. If you are already using promises you might not even need anything besides wrapping the function in a callback.
albertTJames 10y ago
If multithread is a possibility for the future of javascript why not make promises and async multithread and keep the same syntax we are using now... What is there to gain with workers ? It seems to me like an unnecessary addition ... but I am interested in the point of view of specialists on the matter. I may be wrong, but promises and async are for me a great formalism upon which one could build a future version of js that is multithreaded.
- sebringj 10y ago
  Ah so you mean call other js processes through async/yield type stuff. I think that is cognitively easier than introducing new concepts like this has with a familiar way to do things. I agree with you. There would have to be some other syntax like "thread" to note it is not in the main thread but acted just like async or something. var somevalue = async doSomething(); var someExpensiveVAlue = thread doExpensiveThing(); var lotsOfExpensiveThings = Thread.all(threads);
  - voxic11 10y ago
    This is how it works in dotnet. var val = await Task.Run(() => doSomeThreadedWork(param)); Indicates to the runtime that the specified delegate may be run on another thread. This doesn't explicitly start a new thread but rather just allows the delegate to execute on one of the thread pool threads that is managed by the runtime. It uses heuristics to decide how many threadpool threads to maintain and whether to actually use one of them to execute your delegate. A similar model would be very useful to have in JavaScript.
    - tracker1 10y ago
      The issue is that in .Net there are locking primatives to access shared values... where as in Node/JS you would need something that only allowed passing of strings, other primatives, and SharedArrayBuffer or similar objects that don't change underneath unexpectedly.
- msoad 10y ago
  Because you can't write and modify object that are shared with other thread while the process is going on without consequences: var str = '{}' await JSON.parseAsync(str); str = '{"foo": 1}' // this line might run before line above
- btilly 10y ago
  Short answer, race conditions. Here is a longer answer. Node currently uses cooperative multi-tasking. Each function call owns the CPU until it gives up the CPU by returning. Therefore all operations are implicitly atomic. Which makes them very easy to reason about. As soon as you move to multithreading, NOTHING is atomic unless you lock it. You can even have problems with something as simple as: globalCounter = globalCounter + 1; (If one thread is suspended between reading on the RHS and writing on the LHS, another thread can fetch fetch/write the value, and then that update gets lost when the first thread continues execution.) There have been many cooperative async programming systems in the past. Every one that has moved to preemptive (which multi-threading is) has uncovered a lot of subtle, hard to spot, and hard to fix bugs because of losing implicit atomic guarantees. So you go back to the safe solution of locking everything. But now locking/unlocking takes away a bunch of performance, limits parallelism, and creates the possibility for things like deadlocks. And now you might as well not bother with multiple CPUs! (See Python's GIL for a well-known example of this result.) The challenge therefore is how to add some pre-emptive multitasking while avoiding creating too many unexpected nasty race conditions.
- tps5 10y ago
  Here's my understanding of this: Aysnc and threads are fundamentally different. Aysnc refers to intelligently pausing/resuming many different operations. This is fantastic for a lot of tasks, especially tasks that require io. A task can be queued up and a callback can be attached to it. Then, while waiting for some condition to be met, your code can keep running. This results in "non-blocking code," which is familiar to all JS programmers. Threads, in this context (web workers), refer to CPU cores. The Async model described above is all handled by a single CPU core. Most web applications don't require more than one core, but some do (or, at the very least, the demand is there). Using web workers, you can access other CPU cores, each of which has its own stack and its own separate Async event model. The problem (from this article) with web workers is that data cannot be shared between CPU cores in JavaScript. Any data you want to pass from your main thread to a web worker must be copied, as in a bitwise copy. This article is about a solution for that, a way to share data between different threads in JavaScript, using a new standard that has been accepted by ECMA. As far as your question, most of the time you don't want or need your promises or Async code to be handled in another thread. It would be insane to offload every single non-blocking line of code to another thread. Threads are much "heavier" than Async. Languages that have good support for threads also have Async. However, wrapping web workers inside promises (or async/await) is absolutely something that makes sense, and something you can do now.
- ic4l 10y ago
  Well for one workers do not share scope, and at the moment sharing memory between the two is quite difficult. Second is race conditions like @btilly explained. Right now workers are mainly used for extreme situations and eventually make it into libraries that others use. I have created a library called Task.js that surfaces this idea into a promise compatible interface where you can just convert a pure function into a worker function. The end result is a promise supported function thats sends the function to a worker with your provided args and resolves when its done (also supports multiple workers and automatic queuing). https://github.com/icodeforlove/task.js https://github.com/icodeforlove/task.js
impostervt 10y ago
What do people actually use Web Workers for? The examples I've seen, including this one, seem contrived. I keep hoping they'll change it to allow background image manipulation, but I haven't seen much real progress in that front.
- deleted 10y ago
  [deleted]
- Klathmon 10y ago
  I've used it for background image manipulation before. Paint the image to a canvas, then grab the imagedata off of it, split it into as many parts as you have threads, then use the "transferrableObjects" property of postMessage to zero-copy transfer the data to each worker to be processed, transferred back, and re-stitched together. It's pretty powerful and suprisingly easy to work with once you understand it. [0] is a snippet from the code, but be gentile... It was a personal project where I was trying out polymer 0.5 and made a lot of questionable design choices... Also, I've heard of the idea of using webworkers as a "first class" platform. That is do all of the core parts of your application in them and only use the "main" thread as a "ui" thread. I haven't gotten a chance to try it out, but it seems like a great idea that could really work well in some SPAs. [0] https://github.com/Klathmon/stitchpics/blob/master/app/elements/cross-stitch/element.js#L95-L118 https://github.com/Klathmon/stitchpics/blob/master/app/eleme...
  - bartread 10y ago
    That's interesting but, AFAIK (and, believe me, I'd be happy to be corrected), what you can't do is create a canvas element (even one not attached to the DOM), and paint directly to it using the standard 2D context and drawing primitives. Like I say, more than happy to be corrected, because that sort of thing would be incredibly helpful. Really, anything that lets you mess with a disconnected DOM in the background and then attach it in the foreground could be useful but (and, again, I'm very happy to be corrected), I don't think you can do this.
    - vanderZwan 10y ago
SureshG 10y ago
A dart example - https://github.com/filiph/prime_finder https://github.com/filiph/prime_finder
- markdog12 10y ago
  I don't think your example uses SharedArrayBuffer? Nice to have Dart example though.
tjfontaine 10y ago
I actually misread the title as "JavaScript in Peril", which depending on you feel about the features ...
ww520 10y ago
What are the statuses of Web Worker support in the mobile browsers? Android? iOS?
- Klathmon 10y ago
  pretty damn good. iOS all the way back to 6 i think? and android since around 4.4 (or chrome all the way back since forever)
- btbuildem 10y ago
  Opera Mini doesn't support it, the rest of them do
- nreece 10y ago
  All browsers (except Opera Mini) support it: http://caniuse.com/#feat=webworkers http://caniuse.com/#feat=webworkers
euroclydon 10y ago
I'd just like some high level guidance on how my browser makes use of threads internally. I feel like I could have further optimized a couple web apps with that knowledge.
- Waterluvian 10y ago
  Excluding web workers, just one thread per tab/window. So there's really no consideration for optimization via. parallelism unless you use web workers. And if I'm wrong, this is the quickest way to get the right info. :)
  - baddox 10y ago
    I'm pretty sure you're wrong. At the bare minimum, setTimeout must use a clock in another thread, since it doesn't block your primary thread code. I'm fairly sure that most of all of the JavaScript APIs that use callbacks are using additional threads, including the ubiquitous XMLHttpRequest.
    - Waterluvian 10y ago
      I'm not sure how the inner plumbing works. But since the queue just pops onto the stack, there's no true parallelism and therefore no optimization opportunity. That being said, I'm not sure you're correct. There is no concern of blocking the main thread, since functions queued up via. `setTimeout()` are not tracked by some non-blocking timer. The queue is only inspected if the stack is empty. So if anything is happening, we just ignore the queue until nothing is happening. `setTimeout()` only guarantees a message will be processed after x milliseconds, not on-time. https://developer.mozilla.org/en/docs/Web/JavaScript/EventLoop https://developer.mozilla.org/en/docs/Web/JavaScript/EventLo...
      - baddox 10y ago
        You can definitely block the main thread. XHR requests can be run synchronously by calling .open() with false as the third argument. And when you do asynchronous XHR requests, the browser can and will run multiple requests in parallel. Of course, the callbacks just get added to the event queue and run one at a time to completion on the main thread. And granted, it's hard to call this an "optimization opportunity," since you should almost never make synchronous XHR requests anyway.
i_s 10y ago
It is really how disappointing the options to share data with workers are in the browser. Combine the limited options options to transfer data quickly, and the limited API available in the worker itself (no version of a DOM, even a gutted one for doing measurements), it is no surprise how few opportunities to use them effectively there are. When it comes to transferring objects, it is so bad people are resorting to JSON.stringifying messages. [0] Seems like it would be easy to just add an Immutable Array and Map to the standard library, and let people use that on workers without these silly limitations. What am I missing? [0] https://nolanlawson.com/2016/02/29/high-performance-web-worker-messages/ https://nolanlawson.com/2016/02/29/high-performance-web-work...
- rl3 10y ago
  I used web workers extensively in a JS project a little over a year ago, and it was a nightmare. Granted what I was attempting was crazy, but it shouldn't have been as painful as it was. Basically the "gotchas" are in the browser implementations. Each browser's web worker implementation is a little different, and those little differences (bugs) have huge implications in terms of what you can and can't do. For example: one browser may relay direct worker-to-worker messages via the main thread, so if your main thread is blocked your workers can't talk to each other, and that largely defeats the entire purpose of direct worker-to-worker communication. Fortunately some of these issues have been fixed since (including that one, if memory serves), but it's slow going. I believe what happened was workers were introduced 5+ years ago, met with little interest initially, and the APIs have rotted for years until recently when interest picked up again, especially since SharedArrayBuffer. My qualm with SharedArrayBuffer is that it kind of sucks to use in pure JS projects, because you have to serialize/deserialize everything to and from the buffer. With the Emscripten toolchain's pthreads support, as far as I'm aware you just compile your code and the heap lives inside SharedArrayBuffer. You don't have to write boilerplate serialization code, so compared to plain JavaScript it's seamless experience in that regard. My advice to anyone using web workers in a pure JavaScript project is to use them as their name implies: offloading long-running calculations. If you try to treat them as true threads, you're going to have a bad time. Especially if your inter-worker messaging volume is high and you have frequent interdependent (blocking) calculations. That said, the work I did was prior to SharedArrayBuffer. For very high-performance projects, it will likely be prudent to use SharedArrayBuffer itself as a messaging medium between workers.
deleted 10y ago
[deleted]
ic4l 10y ago
I kept finding myself needing to toss stuff in a background thread, and ended up making this: https://github.com/icodeforlove/task.js https://github.com/icodeforlove/task.js It makes wrangling multiple workers much easier, and doesn't require you to have external JS files. (also works in node.js) demo: http://s.codepen.io/icodeforlove/debug/ZOjBBB/NjrYzwzWdzLA http://s.codepen.io/icodeforlove/debug/ZOjBBB/NjrYzwzWdzLA
- ralusek 10y ago
  Looks impressive, well thought out interface. That's also an impressive grid of browser compatibility.
z3t4 10y ago
This is a very nice article! There's however a bug in the code, where it will "finish" when the last worker is done: if(msg.data.offset + msg.data.length === buffer.byteLength) While you most likely want to wait for all workers to be done before showing the results. In this code however, the last worker will always finish last because it has more work to do (higher numbers). It's often cheaper to scale horizontally, by spreading the work between physical machines, then to add more cores to a shared memory. So it's not such a big deal to have a single threaded program, and single threaded code is easier to reason about. SharedArrayBuffer will however be nice in JavaScript because it allows optimization is games and such, allowing you to have parallel for loops.
jpalomaki 10y ago
+1 for providing good summary in the beginning. I wish more articles had these.
buttershakes 10y ago
Workers are really bad. Its anecdotal but I've written several projects and more often then not there is a weird browser quirk, a memory leak, or some other nastiness hidden in the worker implementation. I think my next project I'll go with Emscripten pthreads implementation and see if it's better.
quadyeast 10y ago
<= instead of < would make the first few numbers come out correctly: for(var n=2; n <= Math.floor(Math.sqrt(candidate)); n++)

172 points by avgp 10y ago

If you don't like to have to load an external file (+ an extra request) you can use my library uwork: https://github.com/franciscop/uwork https://github.com/franciscop/uwork It has some limitations, but for long lived process intensive and async functions is perfect. It has a really clean and easy syntax where you don't need to learn everything about Web Workers and their APIs to be able to use it. If you are already using promises you might not even need anything besides wrapping the function in a callback.

albertTJames 10y ago

If multithread is a possibility for the future of javascript why not make promises and async multithread and keep the same syntax we are using now... What is there to gain with workers ? It seems to me like an unnecessary addition ... but I am interested in the point of view of specialists on the matter. I may be wrong, but promises and async are for me a great formalism upon which one could build a future version of js that is multithreaded.

sebringj 10y ago
Ah so you mean call other js processes through async/yield type stuff. I think that is cognitively easier than introducing new concepts like this has with a familiar way to do things. I agree with you. There would have to be some other syntax like "thread" to note it is not in the main thread but acted just like async or something. var somevalue = async doSomething(); var someExpensiveVAlue = thread doExpensiveThing(); var lotsOfExpensiveThings = Thread.all(threads);
- voxic11 10y ago
  This is how it works in dotnet. var val = await Task.Run(() => doSomeThreadedWork(param)); Indicates to the runtime that the specified delegate may be run on another thread. This doesn't explicitly start a new thread but rather just allows the delegate to execute on one of the thread pool threads that is managed by the runtime. It uses heuristics to decide how many threadpool threads to maintain and whether to actually use one of them to execute your delegate. A similar model would be very useful to have in JavaScript.
  - tracker1 10y ago
    The issue is that in .Net there are locking primatives to access shared values... where as in Node/JS you would need something that only allowed passing of strings, other primatives, and SharedArrayBuffer or similar objects that don't change underneath unexpectedly.
msoad 10y ago
Because you can't write and modify object that are shared with other thread while the process is going on without consequences: var str = '{}' await JSON.parseAsync(str); str = '{"foo": 1}' // this line might run before line above
btilly 10y ago
Short answer, race conditions. Here is a longer answer. Node currently uses cooperative multi-tasking. Each function call owns the CPU until it gives up the CPU by returning. Therefore all operations are implicitly atomic. Which makes them very easy to reason about. As soon as you move to multithreading, NOTHING is atomic unless you lock it. You can even have problems with something as simple as: globalCounter = globalCounter + 1; (If one thread is suspended between reading on the RHS and writing on the LHS, another thread can fetch fetch/write the value, and then that update gets lost when the first thread continues execution.) There have been many cooperative async programming systems in the past. Every one that has moved to preemptive (which multi-threading is) has uncovered a lot of subtle, hard to spot, and hard to fix bugs because of losing implicit atomic guarantees. So you go back to the safe solution of locking everything. But now locking/unlocking takes away a bunch of performance, limits parallelism, and creates the possibility for things like deadlocks. And now you might as well not bother with multiple CPUs! (See Python's GIL for a well-known example of this result.) The challenge therefore is how to add some pre-emptive multitasking while avoiding creating too many unexpected nasty race conditions.
tps5 10y ago
Here's my understanding of this: Aysnc and threads are fundamentally different. Aysnc refers to intelligently pausing/resuming many different operations. This is fantastic for a lot of tasks, especially tasks that require io. A task can be queued up and a callback can be attached to it. Then, while waiting for some condition to be met, your code can keep running. This results in "non-blocking code," which is familiar to all JS programmers. Threads, in this context (web workers), refer to CPU cores. The Async model described above is all handled by a single CPU core. Most web applications don't require more than one core, but some do (or, at the very least, the demand is there). Using web workers, you can access other CPU cores, each of which has its own stack and its own separate Async event model. The problem (from this article) with web workers is that data cannot be shared between CPU cores in JavaScript. Any data you want to pass from your main thread to a web worker must be copied, as in a bitwise copy. This article is about a solution for that, a way to share data between different threads in JavaScript, using a new standard that has been accepted by ECMA. As far as your question, most of the time you don't want or need your promises or Async code to be handled in another thread. It would be insane to offload every single non-blocking line of code to another thread. Threads are much "heavier" than Async. Languages that have good support for threads also have Async. However, wrapping web workers inside promises (or async/await) is absolutely something that makes sense, and something you can do now.
ic4l 10y ago
Well for one workers do not share scope, and at the moment sharing memory between the two is quite difficult. Second is race conditions like @btilly explained. Right now workers are mainly used for extreme situations and eventually make it into libraries that others use. I have created a library called Task.js that surfaces this idea into a promise compatible interface where you can just convert a pure function into a worker function. The end result is a promise supported function thats sends the function to a worker with your provided args and resolves when its done (also supports multiple workers and automatic queuing). https://github.com/icodeforlove/task.js https://github.com/icodeforlove/task.js

impostervt 10y ago

What do people actually use Web Workers for? The examples I've seen, including this one, seem contrived. I keep hoping they'll change it to allow background image manipulation, but I haven't seen much real progress in that front.

deleted 10y ago
[deleted]
Klathmon 10y ago
I've used it for background image manipulation before. Paint the image to a canvas, then grab the imagedata off of it, split it into as many parts as you have threads, then use the "transferrableObjects" property of postMessage to zero-copy transfer the data to each worker to be processed, transferred back, and re-stitched together. It's pretty powerful and suprisingly easy to work with once you understand it. [0] is a snippet from the code, but be gentile... It was a personal project where I was trying out polymer 0.5 and made a lot of questionable design choices... Also, I've heard of the idea of using webworkers as a "first class" platform. That is do all of the core parts of your application in them and only use the "main" thread as a "ui" thread. I haven't gotten a chance to try it out, but it seems like a great idea that could really work well in some SPAs. [0] https://github.com/Klathmon/stitchpics/blob/master/app/elements/cross-stitch/element.js#L95-L118 https://github.com/Klathmon/stitchpics/blob/master/app/eleme...
- bartread 10y ago
  That's interesting but, AFAIK (and, believe me, I'd be happy to be corrected), what you can't do is create a canvas element (even one not attached to the DOM), and paint directly to it using the standard 2D context and drawing primitives. Like I say, more than happy to be corrected, because that sort of thing would be incredibly helpful. Really, anything that lets you mess with a disconnected DOM in the background and then attach it in the foreground could be useful but (and, again, I'm very happy to be corrected), I don't think you can do this.
  - vanderZwan 10y ago

SureshG 10y ago

A dart example - https://github.com/filiph/prime_finder https://github.com/filiph/prime_finder

markdog12 10y ago
I don't think your example uses SharedArrayBuffer? Nice to have Dart example though.

tjfontaine 10y ago

I actually misread the title as "JavaScript in Peril", which depending on you feel about the features ...

ww520 10y ago

What are the statuses of Web Worker support in the mobile browsers? Android? iOS?

Klathmon 10y ago
pretty damn good. iOS all the way back to 6 i think? and android since around 4.4 (or chrome all the way back since forever)
btbuildem 10y ago
Opera Mini doesn't support it, the rest of them do
nreece 10y ago
All browsers (except Opera Mini) support it: http://caniuse.com/#feat=webworkers http://caniuse.com/#feat=webworkers

euroclydon 10y ago

I'd just like some high level guidance on how my browser makes use of threads internally. I feel like I could have further optimized a couple web apps with that knowledge.

Waterluvian 10y ago
Excluding web workers, just one thread per tab/window. So there's really no consideration for optimization via. parallelism unless you use web workers. And if I'm wrong, this is the quickest way to get the right info. :)
- baddox 10y ago
  I'm pretty sure you're wrong. At the bare minimum, setTimeout must use a clock in another thread, since it doesn't block your primary thread code. I'm fairly sure that most of all of the JavaScript APIs that use callbacks are using additional threads, including the ubiquitous XMLHttpRequest.
  - Waterluvian 10y ago
    I'm not sure how the inner plumbing works. But since the queue just pops onto the stack, there's no true parallelism and therefore no optimization opportunity. That being said, I'm not sure you're correct. There is no concern of blocking the main thread, since functions queued up via. `setTimeout()` are not tracked by some non-blocking timer. The queue is only inspected if the stack is empty. So if anything is happening, we just ignore the queue until nothing is happening. `setTimeout()` only guarantees a message will be processed after x milliseconds, not on-time. https://developer.mozilla.org/en/docs/Web/JavaScript/EventLoop https://developer.mozilla.org/en/docs/Web/JavaScript/EventLo...
    - baddox 10y ago
      You can definitely block the main thread. XHR requests can be run synchronously by calling .open() with false as the third argument. And when you do asynchronous XHR requests, the browser can and will run multiple requests in parallel. Of course, the callbacks just get added to the event queue and run one at a time to completion on the main thread. And granted, it's hard to call this an "optimization opportunity," since you should almost never make synchronous XHR requests anyway.

i_s 10y ago

It is really how disappointing the options to share data with workers are in the browser. Combine the limited options options to transfer data quickly, and the limited API available in the worker itself (no version of a DOM, even a gutted one for doing measurements), it is no surprise how few opportunities to use them effectively there are. When it comes to transferring objects, it is so bad people are resorting to JSON.stringifying messages. [0] Seems like it would be easy to just add an Immutable Array and Map to the standard library, and let people use that on workers without these silly limitations. What am I missing? [0] https://nolanlawson.com/2016/02/29/high-performance-web-worker-messages/ https://nolanlawson.com/2016/02/29/high-performance-web-work...

rl3 10y ago
I used web workers extensively in a JS project a little over a year ago, and it was a nightmare. Granted what I was attempting was crazy, but it shouldn't have been as painful as it was. Basically the "gotchas" are in the browser implementations. Each browser's web worker implementation is a little different, and those little differences (bugs) have huge implications in terms of what you can and can't do. For example: one browser may relay direct worker-to-worker messages via the main thread, so if your main thread is blocked your workers can't talk to each other, and that largely defeats the entire purpose of direct worker-to-worker communication. Fortunately some of these issues have been fixed since (including that one, if memory serves), but it's slow going. I believe what happened was workers were introduced 5+ years ago, met with little interest initially, and the APIs have rotted for years until recently when interest picked up again, especially since SharedArrayBuffer. My qualm with SharedArrayBuffer is that it kind of sucks to use in pure JS projects, because you have to serialize/deserialize everything to and from the buffer. With the Emscripten toolchain's pthreads support, as far as I'm aware you just compile your code and the heap lives inside SharedArrayBuffer. You don't have to write boilerplate serialization code, so compared to plain JavaScript it's seamless experience in that regard. My advice to anyone using web workers in a pure JavaScript project is to use them as their name implies: offloading long-running calculations. If you try to treat them as true threads, you're going to have a bad time. Especially if your inter-worker messaging volume is high and you have frequent interdependent (blocking) calculations. That said, the work I did was prior to SharedArrayBuffer. For very high-performance projects, it will likely be prudent to use SharedArrayBuffer itself as a messaging medium between workers.

deleted 10y ago

[deleted]

ic4l 10y ago

I kept finding myself needing to toss stuff in a background thread, and ended up making this: https://github.com/icodeforlove/task.js https://github.com/icodeforlove/task.js It makes wrangling multiple workers much easier, and doesn't require you to have external JS files. (also works in node.js) demo: http://s.codepen.io/icodeforlove/debug/ZOjBBB/NjrYzwzWdzLA http://s.codepen.io/icodeforlove/debug/ZOjBBB/NjrYzwzWdzLA

ralusek 10y ago
Looks impressive, well thought out interface. That's also an impressive grid of browser compatibility.

z3t4 10y ago

This is a very nice article! There's however a bug in the code, where it will "finish" when the last worker is done: if(msg.data.offset + msg.data.length === buffer.byteLength) While you most likely want to wait for all workers to be done before showing the results. In this code however, the last worker will always finish last because it has more work to do (higher numbers). It's often cheaper to scale horizontally, by spreading the work between physical machines, then to add more cores to a shared memory. So it's not such a big deal to have a single threaded program, and single threaded code is easier to reason about. SharedArrayBuffer will however be nice in JavaScript because it allows optimization is games and such, allowing you to have parallel for loops.

jpalomaki 10y ago

+1 for providing good summary in the beginning. I wish more articles had these.

buttershakes 10y ago

Workers are really bad. Its anecdotal but I've written several projects and more often then not there is a weird browser quirk, a memory leak, or some other nastiness hidden in the worker implementation. I think my next project I'll go with Emscripten pthreads implementation and see if it's better.

quadyeast 10y ago

<= instead of < would make the first few numbers come out correctly: for(var n=2; n <= Math.floor(Math.sqrt(candidate)); n++)