FYI this attribute landed in WebKit today: http://trac.webkit.org/changeset/169017
On Thu, May 15, 2014 at 1:26 AM, Rik Cabanier <caban...@gmail.com> wrote: > > > > On Wed, May 14, 2014 at 11:39 AM, Ehsan Akhgari > <ehsan.akhg...@gmail.com>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 > > >> 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. I'm unsure how > ANY thread framework in a browser could fix this since there might be other > higher priority tasks in 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. > > >> 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. > > >> 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. > > ... >>> >>> >>> 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 or that are > specifically tailored to work well on a popular system. > > >> 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. > > >> 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. > > >> "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. > > >> ... >>> >>> >>> 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 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 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. > > >> 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. > > ... >>> >>> 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 did a little bit of research. As usual, wikipedia is the easiest to >>> read: 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" > > >> 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. > > 1: > http://www.samsung.com/global/business/semiconductor/minisite/Exynos/data/Heterogeneous_Multi_Processing_Solution_of_Exynos_5_Octa_with_ARM_bigLITTLE_Technology.pdf > > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
