On Tue, May 13, 2014 at 9:55 AM, Tom Schuster <t...@schuster.me> wrote:
> I recently saw this bug about implementing navigator.getFeature, wouldn't > it make sense for this to be like hardware.memory, but hardware.cores? > Is this a feature that is adopted across browsers? Interesting that Firefox exposes this. Was there a discussion thread? It seems that property would face the same (or even stronger) objections than navigator.hardwareConcurrency > On Tue, May 13, 2014 at 6:25 PM, Rik Cabanier <caban...@gmail.com> wrote: > >> On Tue, May 13, 2014 at 8:20 AM, Ehsan Akhgari <ehsan.akhg...@gmail.com >> >wrote: >> >> > On Tue, May 13, 2014 at 2:37 AM, Rik Cabanier <caban...@gmail.com> >> wrote: >> > >> >> On Mon, May 12, 2014 at 10:15 PM, Joshua Cranmer 🐧 < >> pidgeo...@gmail.com >> >> >wrote: >> >> >> >> > On 5/12/2014 7:03 PM, Rik Cabanier wrote: >> >> > >> >> >> *Concerns* >> >> >> >> >> >> The original proposal required that a platform must return the exact >> >> >> number >> >> >> of logical CPU cores. To mitigate the fingerprinting concern, the >> >> proposal >> >> >> was updated so a user agent can "lie" about this. >> >> >> In the case of WebKit, it will return a maximum of 8 logical cores >> so >> >> high >> >> >> value machines can't be discovered. (Note that it's already possible >> >> to do >> >> >> a rough estimate of the number of cores) >> >> >> >> >> > >> >> > The discussion on the WHATWG mailing list covered a lot more than the >> >> > fingerprinting concern. Namely: >> >> > 1. The user may not want to let web applications hog all of the cores >> >> on a >> >> > machine, and exposing this kind of metric makes it easier for >> >> (good-faith) >> >> > applications to inadvertently do this. >> >> > >> >> >> >> Web applications can already do this today. There's nothing stopping >> them >> >> from figuring out the CPU's and trying to use them all. >> >> Worse, I think they will likely optimize for popular platforms which >> >> either >> >> overtax or underutilize non-popular ones. >> >> >> > >> > Can you please provide some examples of actual web applications that do >> > this, and what they're exactly trying to do with the number once they >> > estimate one? (Eli's timing attack demos don't count. ;-) >> > >> >> Eli's listed some examples: >> http://wiki.whatwg.org/wiki/NavigatorCores#Example_use_cases >> I don't have any other cases where this is done. Maybe PDF.js would be >> interested. They use workers to render pages and decompress images so I >> could see how this is useful to them. >> >> >> > > 2. It's not clear that this feature is necessary to build high-quality >> >> > threading workload applications. In fact, it's possible that this >> >> technique >> >> > makes it easier to build inferior applications, relying on a >> potentially >> >> > inferior metric. (Note, for example, the disagreement on figuring out >> >> what >> >> > you should use for make -j if you have N cores). >> >> >> >> >> >> Everyone is in agreement that that is a hard problem to fix and that >> there >> >> is no clear answer. >> >> Whatever solution is picked (maybe like Grand Central or Intel TBB), >> most >> >> solutions will still want to know how many cores are available. >> >> Looking at the native platform (and Adobe's applications), many query >> the >> >> operating system for this information to balance the workload. I don't >> see >> >> why this would be different for the web platform. >> >> >> > >> > I don't think that the value exposed by the native platforms is >> > particularly useful. Really if the use case is to try to adapt the >> number >> > of workers to a number that will allow you to run them all concurrently, >> > that is not the same number as reported traditionally by the native >> > platforms. >> > >> >> Why not? How is the web platform different? >> >> >> > If you try Eli's test case in Firefox under different workloads (for >> > example, while building Firefox, doing a disk intensive operation, >> etc.), >> > the utter inaccuracy of the results is proof in the ineffectiveness of >> this >> > number in my opinion. >> > >> >> As Eli mentioned, you can run the algorithm for longer and get a more >> accurate result. Again, if the native platform didn't support this, doing >> this in C++ would result in the same. >> >> >> > Also, I worry that this API is too focused on the past/present. For >> > example, I don't think anyone sufficiently addressed Boris' concern on >> the >> > whatwg thread about AMP vs SMP systems. >> > >> >> Can you provide a link to that? Are there systems that expose this to the >> user? (AFAIK slow cores are substituted with fast ones on the fly.) >> >> >> > This proposal also assumes that the UA itself is mostly contempt with >> > using a single core, which is true for the current browser engines, but >> > we're working on changing that assumption in Servo. It also doesn't >> take >> > the possibility of several ones of these web application running at the >> > same time. >> > >> >> How is this different from the native platform? >> >> >> > Until these issues are addressed, I do not think we should implement or >> > ship this feature. >> > >> >> FWIW these issues were already discussed in the WebKit bug. >> I find it odd that we don't want to give authors access to such a basic >> feature. Not everything needs to be solved by a complex framework. >> _______________________________________________ >> 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
