PJS has been removed from Spidermonkey

[Lars Hansen]

Over the course of the last week all PJS support has been removed from
Spidermonkey (bug 117724 and dependents) and all open PJS bugs have been
closed as WONTFIX. Some minor cleaning remains to be done.

Please file bugs should you stumble across code you believe to be PJS-only
or whose complexity is motivated only by PJS, and please close any open PJS
bugs.

--lars

[David Bruant]

Le 14/01/2015 14:40, Lars Hansen a écrit :
> Over the course of the last week all PJS support has been removed from
> Spidermonkey (bug 117724

bug 1117724
https://bugzilla.mozilla.org/show_bug.cgi?id=1117724

David

> and dependents) and all open PJS bugs have been
> closed as WONTFIX. Some minor cleaning remains to be done.
>
> Please file bugs should you stumble across code you believe to be PJS-only
> or whose complexity is motivated only by PJS, and please close any open PJS
> bugs.
>
> --lars

> _______________________________________________
> dev-tech-js-engine mailing list
> dev-tech-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-js-engine

[south...@gmail.com]

I noticed that the referenced bug says:

"By broad agreement we are going to remove PJS from the SpiderMonkey code base. PJS is currently Nightly-only, has very limited future prospects in its current form, gets little attention (both in its implementation and by prospective users), and occasionally gets in the way of other work on the engine."

But when I searched this forum for terms like PJS, RiverTrail, or Parallel Javascript I didn't find any information about the decision to remove PJS other than this message. I don't doubt the reasoning for removing PJS, but I would be interested in knowing what the issues with PJS are. If you can point me to any information/discussion about this decision that would be appreciated.

Thanks,

-Gabriel

[Lars Hansen]

Hi Gabriel,

Most of the discussion has taken place on phone calls, in email, and on the
irc channel (#pjs on irc.mozilla.org). I'm not aware of much having been
posted to blogs or mailing lists.

Let me summarize briefly my view of the matter (I'm only one of several
engineers working on PJS and I came late to it, so this is not necessarily
a consensus view). And this is about PJS as it was implemented in
Spidermonkey, not necessarily the idea in general. I'll use the present
tense even though the code is gone now.

Consider a simple pjs calculation where a is some Array or TypedObject
array:
var b = a.mapPar((x) => x*x)
The kernel function that's the argument to mapPar can be written in a
fairly large subset of Javascript. b is always a fresh array of the same
type as a.

Two significant problems with this API are predictability and performance.

First, it turns out to be hard to describe the subset of Javascript that
can be parallelized reliably, because that subset tends to depend on engine
details. That's not to say it couldn't be done, and it'd be a blocker to
standardization not to do so, but it appears difficult to make that
portable subset large enough to be interesting without very significant
work.

Second, that API has poor performance in many cases. A fresh array is
returned every time, driving up memory management costs, and if the kernel
function is small then the overhead of setting up the parallel computation,
which is unfortunately significant, is only recovered if the array is quite
large. (The overhead includes: warming up and recompiling the kernel code
for parallel computation; setting up and tearing down memory management for
the parallel section; and distributing the work to the workers.) We see
good parallel speedup on large computations that are done repeatedly, but
it is usually a chore to structure the computation to get that speedup.
"Casual" use of PJS with that API will not be useful in many cases;
"nobody" with some random array that they're currently mapping would
benefit from mapping it in parallel.

As a consequence of especially the performance problem - if we couldn't fix
that then the subset description issue would not matter - we started to
investigate alternative APIs, including a parallel pipeline pattern and a
more imperative OpenCL-like pattern, these would perhaps have allowed the
performance to be controlled better by reducing per-iteration overhead and
controlling storage use. Both saw some work but had a ways to go. We also
worked hard at reducing setup overhead, and had some success; more would
have to be done.

In the end, we had used about all the resouces we could afford to use on
PJS, and instead of letting the code languish (and in the process
complicate the engine) we decided to remove it.

--lars

[Lars Hansen]

Hi Gabriel,

Indeed, I can't speak for Intel or for Ecma TC39... That said:

So far as I know, Intel keeps working on RiverTrail/PJS, generating code
for GPUs with some success. Targeting GPUs may be a simpler problem than
full PJS because the subset of Javascript that can be used for the kernel
function is smaller and is more constrained (by the GPU) and perhaps more
easily described. At the same time, there are challenges with different
hardware on different GPUs (in terms of data types and other capabilities),
and with the copy-in/copy-out semantics of GPUs; these problems are perhaps
being overcome by new hardware and may in the long run not matter too much
but now they may limit how the technology can be used for reliably
exploiting GPUs.

I don't know what Intel is doing wrt standardization.

I'm not convinced that PJS quite in the form we had it in Firefox is
viable, but there are so many variables that it's truly hard to say. For
one thing, I think that the applicative style of the API is probably wrong
for the problem domain, at least at current (CPU) core counts - there's too
much overhead, and there will be no parallel speedup except when programs
are (re)written to allow more amortization of overhead. If you have to
rewrite code anyway, is PJS the best API you can have? I think probably
not.

A couple of links with thoughts on how do improve PJS (in very different
ways):

http://smallcultfollowing.com/babysteps/blog/2014/04/24/parallel-pipelines-for-js/
https://github.com/lars-t-hansen/moz-sandbox/tree/master/parInvoke

--lars


On Fri, Jan 16, 2015 at 11:57 PM, Gabriel Southern <south...@gmail.com>
wrote:

> Hi Lars,
>
> Thanks for the detailed response. I only recently learned about PJS when
> I was searching for information about research in parallel programming for
> Javascript. A followup question that I have is what the impact of removing
> PJS from Firefox has on Intel's Rivertrail project and the strawman
> proposal (http://wiki.ecmascript.org/doku.php?id=strawman:data_parallelism).
>
>
> From searching online it seems like many of the presentations I've found
> about Rivertrail (mostly from Intel) portray it in a positive light as
> something moving forward in standardization. I assume you can't speak for
> Intel, but I'm wondering if the removal of PJS form Firefox is just because
> the implementation didn't work well enough for now, and that PJS still has
> potential. Or if PJS is more of a dead-end that is unlikely to progress in
> the future. For just learning about the project seeing it removed from
> Firefox, after what I assume were years of work, does not seem like a
> promising sign.
>
> Thanks again for your response and if this followup questions isn't
> something you can address I understand. I can also try to search the
> standardization mailing lists if it has been discussed there already.
>
> -Gabriel

[south...@gmail.com]

Hi,

I had one other question about PJS. I'd like to know what a good starting point would be to check out, compile, and run SpiderMonkey with PJS.

I would like to be able to run the code from before it was removed. I checked out one of the branches from a few weeks ago (GECKO340_2014112606_RELBRANCH) and ran configure with CXXFLAG=-DENABLE_PARALLEL_JS. But when I tried to run SimPJS-test.js I got an error "SimPJS-test.js:325:20 Error: No such property on self-hosted object: initPos.mapPar(...)"

I don't expect help debugging this particular problem, I'm just wondering if you can give me a pointer for compiling and running something with PJS that I should expect to work.

Thanks,

-Gabriel

On Wednesday, January 14, 2015 at 5:40:26 AM UTC-8, Lars Hansen wrote:

[Lars Hansen]

The first changeset in the series that removed PJS is the one that disabled
PJS in the build. That changeset is labeled b434e8ec434c (on both
mozilla-central and mozilla-inbound) and landed on January 7 under the
username lha...@mozilla.com.

Any changeset before that changeset will have PJS enabled. You shouldn't
need to add any flags when you configure; the flags should be properly set
in js/src/moz.build (search for NIGHTLY). It is possible that if you check
out a branch the NIGHTLY flag will be disabled though - it is only set for
you if config/milestone.txt (in the firefox root directory) has a version
number that ends in 'a1'.

--lars

[south...@gmail.com]

Thanks, I was able to compile with PJS enabled by checking out changeset 4933f14465f2 in mozilla-central. However, when I ran the SimPJS-test.js in parjs-benchmarks I saw it reported that parallel was slower than sequential. Looking at the CPU utilization I did see multiple threads spawned, but only 1 thread had any noticeable activity. I also only saw 1 thread using CPU resources for the ray.js benchmark, and the cat-convolve-mapPar.js benchmark did not run because of a syntax error ("cat-convolve-mapPar.js:19:11 TypeError: ArrayType requires more than 1 argument").

I assume that only having 1 thread running means that the benchmarks were using the sequential fall-back mode, but I was wondering if this behavior is expected based on the state that the code was when it was removed.

Also I was wondering if there are any existing benchmarks where I might expect to see a speedup from using PJS. If not no problem, but I wanted to make sure I have the right baseline for trying to understand the performance of the PJS implementation in SpiderMonkey and that the poor performance isn't caused by some configuration error on my part when compiling or running the code.

Thanks again,

-Gabriel

[Lars Hansen]

Indeed it looks like bitrot set in before we removed PJS. For one thing,
the TypedObject spec has evolved so some TypedObject code has become
invalid since the benchmarks were written. For another thing, as you
observed, there is little parallelism evident.

Instead I checked out the changeset in which SimPJS-test.js was committed,
c8ca0026a72b (from June, I think). Here I see nice parallel behavior in my
performance monitor with both SimPJS-test.js and cat-convolve*.js, and
after an overly lengthy warmup period the ray tracer also gets going on all
cores.

So that might be a better changeset to start with, for experimentation.

--lars