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