On Sun, May 18, 2014 at 4:51 PM, Xidorn Quan <quanxunz...@gmail.com> wrote:
> IMO, though we may have a better model in the future, it is at least not > harmful to have such attribute with some limitation. The WebKit guys think > it is not a fingerprinting when limiting the max value to 8. I think it > might be meaningful to also limit the number to power of 2 (very few people > has 3 or 6 cores so they will be fingerprinting as well). > There are CPU's from Intel [1], AMD [2], Samsung [3] and possible others that have 6 cores. I'm unsure why we would treat them differently since they're not high-value systems. And I think it makes sense to announce that, UA does not guarantee this > value a constant, so that UA can return whatever value it feels comfortable > with when the getter is invoked. Maybe in the future, we can even have an > event to notify the script that the number has been changed. > Yes, if a user agent wants to return a lower number (ie so a well-behaved application leaves a CPU free), it's free to do so. I'm unsure if the event is needed but that can be addressed later. > In addition, considering that WebKit has landed this feature, and Blink is > also going to implement that, it is not a bad idea for us to have the > attribute as well. > The WebKit patch limits the maximum number to 8. The blink patch currently does not limit what it returns. My proposed mozilla patch [4] makes the maximum return value configurable through a "dom.maxHardwareConcurrency" preference key. It currently has a default value of 8. 1: http://ark.intel.com/products/63697 http://ark.intel.com/products/77780 2: http://products.amd.com/en-us/DesktopCPUDetail.aspx?id=811&f1=&f2=&f3=&f4=&f5=&f6=&f7=&f8=&f9=&f10=&f11=&f12= 3: http://www.samsung.com/global/business/semiconductor/minisite/Exynos/products5hexa.html 4: https://bugzilla.mozilla.org/show_bug.cgi?id=1008453 > On Mon, May 19, 2014 at 9:23 AM, Rik Cabanier <caban...@gmail.com> wrote: > >> 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 >> > > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
