Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Taste of JavaScript's New Parallel Primitives

hacks.mozilla.org

Post reply on HN
Print view View original

71–80 of 107 posts

Re: A Taste of JavaScript's New Parallel Primitives

#71

Post by Sanddancer »

zzzcpan wrote: post #15
pfooti wrote: post #3

You know, I'm not entirely sure how I feel about this. On the one hand: yeah, I get that having really multithreaded stuff is pretty handy, especially for certain computationally-bound tasks. On the other hand, I quite like the single-threadedness of javascript. Promises-based systems (or async/await) give us basically cooperative multitasking anyway to break up long-running (unresponsive) threads without worrying ab…

> I understand exactly when and where my javascript code will be interrupted That's why callbacks, promises, async/await and all that are neither multitasking, nor multithreading. They are all about control, while multithreading is all about parallelism and is essentially a very low-level specialized thing, that nobody should be using, unless absolutely necessary.

I disagree that parallelism is inherently a low-level specialized thing. There are a lot of operations, like handling any sort of media, that are naturally parallel. If I'm parsing through an image file, I know exactly where it begins and ends, and with very few bits that are dependent on other bits, it just makes sense to be able to spread that operation through the many cores that exist in a modern machine.

Re: A Taste of JavaScript's New Parallel Primitives

#72

Post by zzzcpan »

chrisseaton wrote: post #49
zzzcpan wrote: post #15

Earlier quoted context omitted.

> I understand exactly when and where my javascript code will be interrupted That's why callbacks, promises, async/await and all that are neither multitasking, nor multithreading. They are all about control, while multithreading is all about parallelism and is essentially a very low-level specialized thing, that nobody should be using, unless absolutely necessary.

> multithreading is all about parallelism This just isn't true. Why do you think people wrote multi-threaded applications back when almost all machines had just one processor and just one core? Threads give you concurrency as well, even if you don't want or need parallelism.

Of course they do. Anything can give you concurrency. But pretty much anything can make concurrency easier, than threads.

> Why do you think people wrote multi-threaded applications back when almost all machines had just one processor and just one core?

Almost none did. Popular networking servers were either preforking, forking or asynchronous. Desktop GUIs were event driven. Threads weren't even very usable on most systems at that time, i.e. up until a decade and a half ago or so, weren't they?

Re: A Taste of JavaScript's New Parallel Primitives

#73

Post by zzzcpan »

nly wrote: post #70
chrisseaton wrote: post #49

Earlier quoted context omitted.

> multithreading is all about parallelism This just isn't true. Why do you think people wrote multi-threaded applications back when almost all machines had just one processor and just one core? Threads give you concurrency as well, even if you don't want or need parallelism.

Exactly. Threading actually enables a simple asynchronous blocking programming model through locks (at the expense of introducing loads of potential locking hazards).

Blocking presumes synchronicity. Locks are by definition synchronization primitives.

Re: A Taste of JavaScript's New Parallel Primitives

#74

Post by chrisseaton »

zzzcpan wrote: post #72
chrisseaton wrote: post #49

Earlier quoted context omitted.

> multithreading is all about parallelism This just isn't true. Why do you think people wrote multi-threaded applications back when almost all machines had just one processor and just one core? Threads give you concurrency as well, even if you don't want or need parallelism.

Of course they do. Anything can give you concurrency. But pretty much anything can make concurrency easier, than threads. > Why do you think people wrote multi-threaded applications back when almost all machines had just one processor and just one core? Almost none did. Popular networking servers were either preforking, forking or asynchronous. Desktop GUIs were event driven. Threads weren't even very usable on most…

Threads weren't very usable on most systems until around 2001? No, I don't know where you've got that idea from but it's not the case.

Java had threads in 1996. The Windows 32 API had threads from at least Windows 95. Windows NT had them since 1993. I don't know when Linux got threads and couldn't find anything, but I would presume it was the mid 90s at the very latest. In fact I don't think any of these threading APIs will have even changed much since the mid 90s. They weren't new ideas at the time either!

Look at this thread programming manual from 1994 which on page 3 lists five benefits of using threads at the time, only one of which is utilising the relatively rare multiprocessors. http://www4.ncsu.edu/~rhee/clas/csc495j/MultithreadedProgram...

Re: A Taste of JavaScript's New Parallel Primitives

#75

Post by rl3 »

>Consider synchronization: The new Atomics object has two methods, wait and wake, which can be used to send a signal from one worker to another: one worker waits for a signal by calling Atomics.wait, and the other worker sends that signal using Atomics.wake.

Having not yet played with this myself: is anyone familiar with what kind of latency overhead is involved with signaling in the Atomics API? I'm not very familiar with the API yet, so I've no idea how signaling is implemented under the hood.

The MessageChannel API by contrast (i.e. postMessage) can be quite slow, depending. While you can use it within a render loop, it usually pays to be very sparing with it. Typical latency for a virtually empty postMessage call on an already-established channel is usually .05ms to .1ms. Most serialization operations will usually balloon that to well over 1ms (hence the need for shared memory). Plus transferables suck.

>Finally, there is clutter that stems from shared memory being a flat array of integer values; more complicated data structures in shared memory must be managed manually.

This is probably the biggest drawback to the API, at least for plain Javascript. It really favors asm.js or WebAssembly compile targets for seamless operation, whereas plain Javascript can't even share native types without serialization/deserialization operations to and from byte arrays.

Re: A Taste of JavaScript's New Parallel Primitives

#76

Post by kibwen »

kbenson wrote: post #2

> This leads to the following situation where the main program and the worker both reference the same memory, which doesn’t belong to either of them: If only Mozilla had some technology that could deal with ownership of memory... Seriously, if rust doesn't have an ASM.js optimized target yet, it really should.

We Rust folk have definitely got plans in this space. :)

Re: A Taste of JavaScript's New Parallel Primitives

#78

Post by jchrisa »

cpeterso wrote: post #27
CHsurfer wrote: post #11

I keep hoping that JS would evolve to support the actor model, a la Erlang/Elixir, with their process based persistence, concurrency via message passing, etc. It just seems so much simpler and tractable than this proposal.

I've seen projects to compile Erlang to JS, but has anyone experimented with a JS compiler that targets Erlang's BEAM VM like Elixir? JS is an approachable language but Node has problems with scaling and error handling of non-blocking IO. Erlang solves those problems but the language is not approachable and has a smaller ecosystem than JS. I'm imagining something like Node with "micro-workers" so developers could reu…

Please implement!

Re: A Taste of JavaScript's New Parallel Primitives

#79

Post by yoklov »

Klathmon wrote: post #40
yoklov wrote: post #36

Earlier quoted context omitted.

I thought this too, but the fact that you can't send only a chunk of an array buffer is a huge limitation. It basically limits you do using a background thread to do something, instead of dividing the work among many (well, you can, but you loose most of the benefit of transferrable).

Well you can still divide the work among many workers, you just need to incur the cost of copying/splitting the buffer before you start sending them off. In most cases you know how many workers you want at the start of the program, so that cost of splitting/merging only happens once (and you can do that splitting/merging in a worker to avoid hanging the main thread) and then you can pass those chunks around freely.

For workloads like graphics, the cost of splitting/merging happens each time.

Re: A Taste of JavaScript's New Parallel Primitives

#80

Post by ryuuchin »

atoponce wrote: post #60
CiPHPerCoder wrote: post #53

Earlier quoted context omitted.

That's explained in painstaking detail in the Github issue I linked to.

Okay. I read the whole thread (ugh). Arguments for using the kernelspace CSPRNG basically boils down to this: 1. Kernelspace CSPRNGs generally don't change, are well audited, and are generally accepted to be secure. 2. Userspace CSPRNGs don't provide any additional security benefit. 3. OpenSSL is a questionable security product with it's history of vulnerabilities. So, with that said, let's look at each of them. For…

> Microsoft changed their CSPRNG to FIPS 186-2 or NIST SP 800-90A

It's changed once, in Vista SP1. Since then it's only used AES256 in CTR mode as a DRNG as specified in NIST 800-90. So I'm not sure it's fair to say it changed that much. Linux's CSPRNG has also not seen much change other than to make it more resilient in certain conditions (there was some paper on it IIRC) and to add hardware RNG support (e.g. rdrand).

> 3. OpenSSL is a questionable security product with it's history of vulnerabilities.

I don't think this is the (main) argument against its CSPRNG although it may be one of them. My understanding is the main argument against it is that it's overly complicated by design (e.g. entropy estimation, how it's initialized (especially on Windows)). You could also probably argue that it may be showing its age with its use of SHA1 but you could say the same for the Linux kernel as well.

If you want to look at a userspace CSPRNG done right (or what I believe to be one done right) just take a look at BoringSSL's[1]. In the case where there is a hardware RNG it will create a ChaCha20 instance, keyed with the OS's CSPRNG, and use that ChaCha20 instance to filter the rdrand output (as to not use it directly or xor it). If there isn't a HW RNG then it will just use the OS CSPRNG directly.

There's no entropy estimation, no way to seed it, and by design it's simple and fast. You're correct that the system's CSPRNG may not be fast enough, in fact the BoringSSL dev's mentioned this[2] citing TLS CBC mode. This is probably more a problem on Linux than Windows due to the design of the CSPRNG (Linux's is pretty slow).

So with everything being said I would argue that it's always the correct choice to use the system CSPRNG unless it otherwise can't satisfy your needs. In which case just use BoringSSL then.

As a side note if you really need to generate A LOT of random numbers just use rdrand directly. You should be able to saturate all logical threads generating random numbers with rdrand and the DRNG (digital RNG) should still not run out of entropy.

[1] https://boringssl.googlesource.com/boringssl/+/master/crypto...

[2] https://www.imperialviolet.org/2015/10/17/boringssl.html (under the "Random number generation" section)

Post reply on HN