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

101–107 of 107 posts

Re: A Taste of JavaScript's New Parallel Primitives

#101

Post by schmichael »

warfangle wrote: post #92
schmichael wrote: post #47

Earlier quoted context omitted.

Pretty meh. I'm sure there are some excellent uses of it that I encounter and enjoy without realizing it, but few of the advanced demos work for me (Chrome on Linux w/Intel gfx) or bring my computer to its knees rendering at very low FPS. It feels like something that was more interested in competing with native than offering a constrained and portable approach.

Quake 3 doesn't work for you? :) http://media.tojicode.com/q3bsp/

A low resolution static subset of a game from 1999 does seem to work in my browser... I'm not super impressed.

Re: A Taste of JavaScript's New Parallel Primitives

#102

Post by Lerc »

AgentME wrote: post #87
Lerc wrote: post #21

Earlier quoted context omitted.

Why is everything-is-async so entrenched in JavaScript? I'd love to have pre-emption and blocking IO in JavaScript but it seems to have been thoroughly excluded by design. What is the reasoning behind this?

Unless you're using webworkers, then javascript runs in the UI thread. If you do blocking IO in the UI thread, then things freeze.

That's the problem in a nutshell, It needn't be that way.

Blocking IO is just one aspect. Anything that is not instantaneous is blocking. Without the ability to preempt something taking a long time you will always be prone to the user interface freezing.

Methods like Array.map() are specifically designed to manage bulk operations immediately, which, without preemption, is at odds with a design where the user interface should perform with the lowest latency.

Re: A Taste of JavaScript's New Parallel Primitives

#103

Post by slavik81 »

brazzledazzle wrote: post #100
slavik81 wrote: post #62

Earlier quoted context omitted.

Forking and threading are different things. Forking creates new processes and duplicates memory. It raises entirely different issues from multi-threading, which does neither. See: http://stackoverflow.com/q/2483041/331041 They discussed forking, but did not discuss multi-threading.

So for OpenSSL's RNG vs. the operating system's CSPRNG is there a difference between forking and multi-threading?

Yes. The problem with an in-process RNG and forking is that the RNG state is duplicated, so both processes get the same sequence of numbers. Multithreading just needs locking to prevent corruption because the state is shared.

Re: A Taste of JavaScript's New Parallel Primitives

#104

Post by brazzledazzle »

slavik81 wrote: post #103
brazzledazzle wrote: post #100

Earlier quoted context omitted.

So for OpenSSL's RNG vs. the operating system's CSPRNG is there a difference between forking and multi-threading?

Yes. The problem with an in-process RNG and forking is that the RNG state is duplicated, so both processes get the same sequence of numbers. Multithreading just needs locking to prevent corruption because the state is shared.

Thanks for taking the time to explain.

Re: A Taste of JavaScript's New Parallel Primitives

#105

Post by atoponce »

ryuuchin wrote: post #80
atoponce wrote: post #60

Earlier quoted context omitted.

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…

> 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].

BoringSSL just uses /dev/urandom directly. It's not a userspace CSPRNG. And as you pointed out, for GNU/Linux systems, it's slow. This is why userspace designs, such as CTR_DRBG, HMAC_DRBG, and Hash_DRBG exist- so you can have a fast userspace CSPRNG with backtracking resistance.

Case in point. On my laptop:

$ pv /dev/null

1.02GB 0:01:20 [13.3MB/s] [ ]

$ openssl enc -aes-128-ctr -pass pass:"sHgEOKTB8bo/52eDszkHow==" -nosalt /dev/null

2.13GiB 0:00:11 [ 198MiB/s] [ ]

And on a server with AES-NI:

$ pv /dev/null

2.19GiB 0:01:06 [ 20MiB/s] [ ]

$ openssl enc -aes-128-ctr -pass pass:"sHgEOKTB8bo/52eDszkHow==" -nosalt /dev/null

31.9GB 0:00:34 [ 953MB/s] [ ]

I've seen other hardware with AES-NI that can go north of 2 GiBps, as I already mentioned. Although not backtracking resistant, those are fast userspace CSPRNGs, that are clean in design.

I've designed userspace CSPRNGs that adhere to the NIST SP 800-90A standards. They're seeded from /dev/urandom on every call, and perform much better than relying on /dev/urandom directly. I won't say they're bug free, but if you read and follow the standard (http://csrc.nist.gov/publications/nistpubs/800-90A/SP800-90A...), it's not too terribly difficult to get correct, and PHP, Perl, Python, Ruby, and other interpreted languages can outperform the kernelspace CSPRNG.

Re: A Taste of JavaScript's New Parallel Primitives

#106

Post by ryuuchin »

atoponce wrote: post #105
ryuuchin wrote: post #80

Earlier quoted context omitted.

> 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…

> 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]. BoringSSL just uses /dev/urandom directly. It's not a userspace CSPRNG. And as you pointed out, for GNU/Linux systems, it's slow. This is why userspace designs, such as CTR_DRBG, HMAC_DRBG, and Hash_DRBG exist- so you can have a fast userspace CSPRNG with backtracking resistance. Case in…

> BoringSSL just uses /dev/urandom directly.

Only if there's no hardware RNG support which I admit can happen (it's not perfect, I freely admit that). I suspect that for Google's use on their servers it's a non-issue (assuming where they use it and need the high(er) speed stuff they'll always have rdrand support). If there is rdrand support then it will only reseed from /dev/urandom after every 1MB (or 1024 calls) of generated random data (per thread).

Re: A Taste of JavaScript's New Parallel Primitives

#107

Post by dimka »

dherman wrote: post #38
schmichael wrote: post #30

> if we want JS applications on the web to continue to be viable alternatives to native applications on each platform This is where I disagree with the direction Mozilla has been going for years. I don't want the web to be a desktop app replacement with HTTP as the delivery mechanism. I'm fine with rich single page web apps, but I don't understand the reason why web apps need complete feature parity with desktop apps…

I don't know if there's a uniform Mozilla position on this, but here's mine! :) The main reason I care about the Web is because it's the world's biggest software platform that isn't owned. If someone can deliver their app to the world without submitting it for review by an app store and without paying a company a %-age of the revenue, and if they can market it through the viral power of URLs, then they have a lot mor…

that presumes that this freedom of self marketing is based on freedom of the internet. there are many countries where internet is restricted and URLs is a part of the restriction filter.
Post reply on HN