On 2014-05-15, 4:26 AM, Rik Cabanier wrote:
On Wed, May 14, 2014 at 11:39 AM, Ehsan Akhgari <[email protected]
<mailto:[email protected]>> wrote:
On 2014-05-13, 9:01 PM, Rik Cabanier wrote:
...
The problem is that the API doesn't really make it obvious that
you're not supposed to take the value that the getter
returns and
just spawn N workers. IOW, the API encourages the wrong
behavior by
design.
That is simply untrue.
I'm assuming that the goal of this API is to allow authors to spawn
as many workers as possible so that they can exhaust all of the
cores in the interest of finishing their computation faster.
That is one way of using it but not the only one.
For instance, let's say that I'm writing on a cooperative game. I might
want to put all my network logic in a worker and want to make sure that
worker is scheduled. This worker consumes little (if any) cpu, but I
want it to be responsive.
NumCores = 1 -> do everything in the main thread and try to make sure
the network code executes
NumCores = 2 -> spin up a worker for the network code. Everything else
in the main thread
NumCores = 3 -> spin up a worker for the network code + another one for
physics and image decompression. Everything else in the main thread
This is actually a great example of why this API is not needed. ;-)
The right way to build the application is to spawn one worker for the
physics and image decompression computations and perhaps another one for
networking, if that is for some reason expensive enough to be done off
the main thread. Basically I assume the goal here would be to keep the
main thread responsive, in which case no matter how many cores you have
on your system, you should try to do as little work on the main thread
as possible.
And that's exactly what Web applications that offload processing to
background workers do today without this API.
I have provided reasons why any thread which is running at a
higher priority on the system busy doing work is going to make this
number an over approximation, I have given you two examples of
higher priority threads that we're currently shipping in Firefox
(Chrome Workers and the MediaStreamGraph thread)
You're arguing against basic multithreading functionality.
Please let's not reduce each other's arguments to caricatures. ;-)
I'm unsure
how ANY thread framework in a browser could fix this since there might
be other higher priority tasks in the system.
They can't, since the number of available cores at any given point in
time is very hard to determine unless you have at least knowledge about
what the OS scheduler is doing and what other threads are waiting to do
work on the system.
For your example of Chrome Workers and MediaStreamGraph, I assume those
don't run at a constant 100% so a webapp that grabs all cores will still
get more work done.
ChromeWorkers run arbitrary JS (possibly from add-ons) so they can have
arbitrary performance characteristics. The computations we perform on
the MSG thread are also controlled by content in the case of Web Audio,
and I've definitely seen test cases where content keeps the MSG thread
nearly completely busy.
and have provided you with experimental evidence of running Eli's
test cases trying to exhaust as many cores as it can fails to
predict the number of cores in these situations.
Eli's code is an approximation. It doesn't prove anything.
I don't understand your point here.
The API you're pushing here is also an approximation. We're really
arguing in circles now. If you still don't trust my reasoning on why
that is, please at least note that not everyone agrees with you on that.
If you don't find any of this convincing, I'd respectfully ask us
to agree to disagree on this point.
OK.
For the sake of argument, let's say you are right. How are
things worse
than before?
I don't think we should necessarily try to find a solution that is
just not worse than the status quo, I'm more interested in us
implementing a good solution here (and yes, I'm aware that there is
no concrete proposal out there that is better at this point.)
So, worst case, there's no harm.
Best case, we have a more responsive application.
I'd really wish you didn't pretend that this API is the gateway for
people to build "responsive" applications. That's just plain false.
That's fine but we're coming right back to the start: there is
no way
for informed authors to make a decision today.
Yes, absolutely.
The "let's build something complex that solves everything" proposal
won't be done in a long time. Meanwhile apps can make responsive
UI's
and fluid games.
That's I think one fundamental issue we're disagreeing on. I think
that apps can build responsive UIs and fluid games without this
today on the Web.
Sure. You can build apps that don't tax the system
Which is a Good Thing.
> or that are
specifically tailored to work well on a popular system.
Here's a thought experiment. Keeping in mind the fact that this API is
just an approximation for the number of available cores (and I know you
don't agree, but please bear with me) let's say that someone polyfills
this API with (Math.random() * 100 % 8). Would that allow you to tailor
to the user's machine? Not at all. Now, whatever the number of
available cores at a given moment is, I hope we can agree that it
constantly changes on the system depending on what everything else
running on the system is doing, so this API won't let you tailor
anything more to the users' systems than you can do today.
There were 24,000 hits for java which is on the web and a VM but
now you
say that it's not a vote of popularity?
We may have a different terminology here, but to me, "positive
feedback from web developers" should indicate a large amount of
demand from the web developer community for us to solve this problem
at this point, and also a strong positive signal from them on this
specific solution with the flaws that I have described above in
mind. That simply doesn't map to searching for API names on non-Web
technologies on github. :-)
This was not a simple search. Please look over the examples especially
the node.js ones and see how it's being used.
This is what we're trying to achieve with this attribute.
Please cite the use cases that are interesting to you, I don't have the
time or urge to do the research here. :-)
Also, FTR, I strongly disagree that we should implement all popular
Java APIs just because there is a way to run Java code on the web. ;-)
...
Can you restate the actual problem? I reread your message but didn't
find anything that indicates this is a bad idea.
See above where I re-described why this is not a good technical
solution to achieve the goal of the API.
Also, as I've mentioned several times, this API basically ignores
the fact that there are AMP systems shipping *today* and dies not
take the fact that future Web engines may try to use as many cores
as they can at a higher priority (Servo being one example.)
OK. They're free to do so. This is not a problem (see previous messages)
It seems like you're arguing against basic multithreading again
I'll stop responding to claims that I'm arguing against basic
multithreading.
"Others do this" is just not going to convince me here.
What would convince you? The fact that every other framework
provides
this and people use it, is not a strong indication?
It's not possible for me to find exact javascript examples that
use this
feature since it doesn't exist.
I'm obviously not asking you to create evidence of usage of an API
which no engine has shipped yet. You originally cited strong
positive feedback from web developers on this and given the fact
that I have not seen that myself I would like to know more about
where those requests are coming from. At the lack of that, what
would convince me would be good answers to all of the points that
I've brought up several times in this thread (which I have
summarized above.)
Please note that _if_ this were the single most requested features
that actually blocked people from building apps for the Web, I might
have been inclined to go on with a bad solution rather than no
solution at all. And if you provide evidence of that, I'm willing
to reconsider my position.
It's not blocking people from building apps. It's blocking them from
being able to squeeze performance out of their browsers. This is not a
problem for native applications.
I refer you to the Math.random() polyfill analogy above. The API you're
pushing here doesn't even achieve the goal you think it does.
Make it possible for authors to make a semi-informed decision on
how to
divide the work among workers.
That can already be done using the timing attacks at the waste of
some CPU time.
It's imprecise and wasteful. A simple attribute check is all this should
take.
The problem with this API is that it's just as imprecise. But it's not
wasteful. Are you arguing that we should implement it just because it's
only imprecise?
The question is, whether we should do that right now?
In a good number of cases the pool will be smaller than the
number of
cores (ie a game), or it might be bigger (see the webkit bug
that goes
over this).
Which part of the WebKit bug are you mentioning exactly? The only
mention of "games" on the bug is
https://bugs.webkit.org/show___bug.cgi?id=132588#c10
<https://bugs.webkit.org/show_bug.cgi?id=132588#c10> which seems to
argue against your position. (It's not very easy to follow the
discussion in that bug...)
It's in Filip's message how some algorithms run better if you double the
number of threads per core.
Sure, I understand that. I'll also note that the same kind of arguments
on this thread have also happened on the WebKit bug, and it seems like
we disagree on the results.
Also, please note that there are use cases on native
platforms which
don't really exist on the Web. For example, on a
desktop
OS you
might want to write a "system info" application which
actually wants
to list information about the hardware installed
on the system.
I don't think that's all that important.
Well, you seem to imply that the reason why those platforms expose
the number of cores is to support the use case under the discussion,
and I'm challenging that assumption.
Sorry, I don't understand your response.
What I meant to say was that using this API to create a "system info"
application is not that important. The vast majority of users doesn't
care or even know how many cores their system has.
Finally we agree on something! :-)
I did. As expected, it drops off as the load increases. I don't
see what
this proves except that the polyfill is unreliable as it posted.
It's an argument that the information, if exposed from the UA, will
be *just* as unreliable.
You're arguing against basic multithreading again.
...
My point is, I think you should have some evidence
indicating why
this is a good idea. So far I think the only argument has
been the
fact that this is exposed by other platforms.
And used successfully on other platforms.
Note that it is exposed on PNaCl in Chrome as well
So? PNaCl is a Chrome specific technology so it's not any more
relevant to this discussion that Python, Perl, Java, etc. is.
They are all relevant as a counter to your statement of:
"native apps don't typically run in a VM which provides highly
sophisticated functionality for them"
I think Jonas' response on this topic summarized things better than I could.
I did a little bit of research. As usual, wikipedia is the
easiest to
read: http://en.wikipedia.org/wiki/__Big.LITTLE
<http://en.wikipedia.org/wiki/Big.LITTLE> There are many other
papers [1] for more information.
In "In-kernel switcher" mode, the little CPU's are taken offline
when
the big one spool up. So, in this case the number of cores is
half the
physical CPU's.
In "Heterogeneous multi-processing", the big CPU's will help out
when
the system load increases. In this case, the number of cores is
equal to
the number of CPU's.
So which number is the one that the OS exposes to us in each case?
See diagrams on page 4 and 5 of the Samsung paper [1]
Half the cores for "in-kernel" switcher, all the cores for
"Heterogeneous multi-processing"
OK. You still need to explain how you propose to scale this API to this
architecture and also future similar ones.
And is that number constant no matter how many actual hardware cores
are active at any given point in time?
I believe so.
...
What Boris said.
He didn't refute that knowing the number of cores would still help.
I'm trying to do that here. :-)
...
I disagree. Let me try to rephrase the issue with this.
The number
of available cores is not a constant number equal to the
number of
logical cores exposed to us by the OS. This number varies
depending
on everything else which is going on in the system,
including the
things that the UA has control over and the things that it
does not.
I hope the reason for my opposition is clear so far.
No, you failed to show why this does not apply to the web
platform and
JavaScript in particular.
That is not a fair summary of everything I have said here so far.
Please see the first paragraph of my response here where I summarize
why I think this doesn't help the use case that it's trying to
solve. You're of course welcome to disagree, but that doesn't mean
that I've necessarily failed to show my side of the argument.
Your arguments apply equally to PNaCL, Java, native applications
and all
the other examples listed above
Yes they do!
> yet they all provide this functionality
and people are using it to build successful applications.
1. PNaCl/Java/native platforms doing something doesn't make it right.
If other frameworks can use it to make better applications with no bad
side effects, yes, it does make it right.
2. There is a reason why people have built more sophisticated
solutions to solve this problem (GCD/Windows threadpools, etc.) So
let's not just close our eyes on those solutions and pretend that
the number of cores is the only solution out there to address this
use case in native platforms.
I've always said that we can add that later. Threadpools/GCD/TBB serve
specific use cases and are not a solution for everything.
Filip brought up that web workers are not compatible with a GDC-like
solution so that's something that needs to be solved as well.
Yes, these are all interesting points in mind for whoever that decides
to tackle this problem.
To sum up, I have little interest in discussing this indefinitely. So
far I have not seen any strong support for this API from Gecko hackers,
and I believe that the issues I've raised with this API on this thread
are still not sufficiently addressed and have just been dismissed as
non-issues or unimportant problems. I'm still not convinced that we
should implement and ship this API at this time. More discussion on
those issues are welcome, of course.
Cheers,
Ehsan
_______________________________________________
dev-platform mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-platform
