Re: [whatwg] Proposal: navigator.cores
On Wed, Jul 2, 2014 at 2:19 AM, Ryosuke Niwa rn...@apple.com wrote: On May 3, 2014, at 10:49 AM, Adam Barth w...@adambarth.com wrote: Over on blink-dev, we've been discussing [1] adding a property to navigator that reports the number of cores [2]. As far as I can tell, this functionality exists in every other platform (including iOS and Android). Some of the use cases for this feature have been discussed previously on this mailing list [3] and rejected in favor of a more complex system, perhaps similar to Grand Central Dispatch [4]. Others have raised concerns that exposing the number of cores could lead to increased fidelity of fingerprinting [5]. My view is that the fingerprinting risks are minimal. This information is already available to web sites that wish to spend a few seconds probing your machine [6]. Obviously, exposing this property makes that easier and more accurate, which is why it's useful for developers. IMHO, a more complex worker pool system would be valuable, but most systems that have such a worker pool system also report the number of hardware threads available. Examples: C++: std::thread::hardware_concurrency(); Win32: GetSystemInfo returns dwNumberOfProcessors POSIX: sysctl returns HW_AVAILCPU or HW_NCPU Java: Runtime.getRuntime().availableProcessors(); Python: multiprocessing.cpu_count() In fact, the web was the only platform I could find that didn't make the number of cores available to developers. FWIW, this property has been added to WebKit [1] and Blink [2] although that's not an indication of any browser actually shipping it for WebKit. Since there are now 2 implementations, it should be added to the spec instead of just being a wiki.
Re: [whatwg] Proposal: navigator.cores
On Wed, Jul 2, 2014 at 8:58 AM, Rik Cabanier caban...@gmail.com wrote: Since there are now 2 implementations, it should be added to the spec instead of just being a wiki. That depends on whether other vendors are objecting. Looks like that is the case: https://groups.google.com/d/msg/mozilla.dev.platform/QnhfUVw9jCI/PEFuf5a_0YQJ -- http://annevankesteren.nl/
Re: [whatwg] Proposal: navigator.cores
On Wed, Jul 2, 2014 at 10:37 AM, Anne van Kesteren ann...@annevk.nl wrote: On Wed, Jul 2, 2014 at 8:58 AM, Rik Cabanier caban...@gmail.com wrote: Since there are now 2 implementations, it should be added to the spec instead of just being a wiki. That depends on whether other vendors are objecting. Looks like that is the case: https://groups.google.com/d/msg/mozilla.dev.platform/QnhfUVw9jCI/PEFuf5a_0YQJ That thread concluded with a let's see how this feature is going to be used before we commit. Blink and WebKit certainly are in favor.
Re: [whatwg] Proposal: navigator.cores
On Wed, Jul 2, 2014 at 3:31 PM, Rik Cabanier caban...@gmail.com wrote: That thread concluded with a let's see how this feature is going to be used before we commit. I cannot find that quote. -- http://annevankesteren.nl/
Re: [whatwg] Proposal: navigator.cores
On Jul 2, 2014, at 6:31 AM, Rik Cabanier caban...@gmail.com wrote: On Wed, Jul 2, 2014 at 10:37 AM, Anne van Kesteren ann...@annevk.nl wrote: On Wed, Jul 2, 2014 at 8:58 AM, Rik Cabanier caban...@gmail.com wrote: Since there are now 2 implementations, it should be added to the spec instead of just being a wiki. That depends on whether other vendors are objecting. Looks like that is the case: https://groups.google.com/d/msg/mozilla.dev.platform/QnhfUVw9jCI/PEFuf5a_0YQJ That thread concluded with a let's see how this feature is going to be used before we commit. Blink and WebKit certainly are in favor. I'm not certain if that accurately reflects where the WebKit community stands. There was a lot of contentious discussion on the webkit-dev thread [1] and Bugzilla [2] I agree some people are in favor but I wouldn't say everyone is definitely in the favor. Also, WebKit's implementation also caps the number of cores at eight to mitigate some of the finger printing / privacy concerns raised. [1] https://bugs.webkit.org/show_bug.cgi?id=132588 [2] https://lists.webkit.org/pipermail/webkit-dev/2014-May/thread.html#26511 - R. Niwa
Re: [whatwg] Proposal: navigator.cores
On Wed, Jul 2, 2014 at 11:31 AM, Rik Cabanier caban...@gmail.com wrote: I thought that those concerns were addressed with the addition of a maximum number of cores? That doesn't address much, if anything. Also, WebKit's implementation also caps the number of cores at eight to mitigate some of the finger printing / privacy concerns raised. This is a misunderstanding of what fingerprinting is. It's not about having rare values, like the one user in a thousand with 32 cores. (That matters too, but it's not the main issue.) Fingerprinting is having data that persists for the user at all, such as whether a user has one or two or four cores, which are then combined with as many other data points as possible to create a fingerprint. Limiting the maximum exposed number of cores doesn't affect this. -- Glenn Maynard
Re: [whatwg] Proposal: navigator.cores
On 7/2/2014 8:31 AM, Rik Cabanier wrote: That thread concluded with a let's see how this feature is going to be used before we commit. Blink and WebKit certainly are in favor. I went back and looked at the later messages in that thread. Your argument implies that a plurality of engines implementing this feature would mollify the detractors, and that is certainly not my reading. People brought up serious concerns about the utility and wisdom of this API, and summaries like yours very much feel like an attempt to avoid addressing those concerns by creating facts on the ground instead. The concerns I recall off the top of my head, to wit: 1. Fingerprinting 2. Use of the API is implicitly assuming that the browser uses only one thread, which is not a safe assumption. 3. The existence and probable eventual takeover of asynchronous multiple core architectures. 4. There are better ways to achieve the desired use cases. I've personally mused that the usual motivation for this feature is essentially predicated on the notion that there is too much work to be assigned for a weak computer, yet the advocates of this API respond to comments about the problems involved with high dynamic usage of the computer with the scheduler can solve it--the same scheduler whose inability to cope with too much work is the basis for the API in the first place. -- Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth
Re: [whatwg] Proposal: navigator.cores
On 7/2/14, 3:21 PM, Rik Cabanier wrote: facts = 2 implementations. I certainly didn't say anything else. You said, and I quote: That thread concluded with a let's see how this feature is going to be used before we commit. Anyway, 2 implementations is a necessary condition for a REC, not a sufficient one. -Boris
Re: [whatwg] Proposal: navigator.cores
On Wed, Jul 2, 2014 at 9:27 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 7/2/14, 3:21 PM, Rik Cabanier wrote: facts = 2 implementations. I certainly didn't say anything else. You said, and I quote: That thread concluded with a let's see how this feature is going to be used before we commit. ah, I see now that he responded to my second message. Yes, I was off on there. Anyway, 2 implementations is a necessary condition for a REC, not a sufficient one. This is from the WHATWG site: http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F The WHATWG doesn't have a hard requirement for 2 implementations but it certainly is an indication that it should be more than just a wiki.
Re: [whatwg] Proposal: navigator.cores
Eli Grey m...@eligrey.com writes: We want to claim 6 in that situation. If the API claimed less than 6 on Samsung's Exynos 5 Hexa (2x A15 cores + 4x A7 cores), then the cores will be underutilized. Implying it is right for any application to utilize all cores available in a multi-process environment that may or may not exist within a mobile (power-limited) device? Again, this reminds me of the „How can I find out how much RAM I can maximally allocate“ questions. -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] Proposal: navigator.cores
On May 3, 2014, at 10:49 AM, Adam Barth w...@adambarth.com wrote: Over on blink-dev, we've been discussing [1] adding a property to navigator that reports the number of cores [2]. As far as I can tell, this functionality exists in every other platform (including iOS and Android). Some of the use cases for this feature have been discussed previously on this mailing list [3] and rejected in favor of a more complex system, perhaps similar to Grand Central Dispatch [4]. Others have raised concerns that exposing the number of cores could lead to increased fidelity of fingerprinting [5]. My view is that the fingerprinting risks are minimal. This information is already available to web sites that wish to spend a few seconds probing your machine [6]. Obviously, exposing this property makes that easier and more accurate, which is why it's useful for developers. IMHO, a more complex worker pool system would be valuable, but most systems that have such a worker pool system also report the number of hardware threads available. Examples: C++: std::thread::hardware_concurrency(); Win32: GetSystemInfo returns dwNumberOfProcessors POSIX: sysctl returns HW_AVAILCPU or HW_NCPU Java: Runtime.getRuntime().availableProcessors(); Python: multiprocessing.cpu_count() In fact, the web was the only platform I could find that didn't make the number of cores available to developers. FWIW, this property has been added to WebKit [1] and Blink [2] although that's not an indication of any browser actually shipping it for WebKit. [1] http://trac.webkit.org/changeset/169017 [2] https://src.chromium.org/viewvc/blink?revision=175629view=revision - R. Niwa
Re: [whatwg] Proposal: navigator.cores
On Fri, May 9, 2014 at 9:56 AM, David Young dyo...@pobox.com wrote: The algorithms don't have to run as fast as possible, they only have to run fast enough that the system is responsive to the user. If there is a motion graphic, you need to run the algorithm fast enough that the motion isn't choppy. That's not correct. For image processing and compression, you want to use as many cores as you can so the operation completes more quickly. For the rest, using more cores means that the algorithm can do a better job, giving a more accurate physics simulation, detecting motion more quickly and accurately, and so on. I think the problem that I have with this API is the number of cores that exist isn't obviously a good proxy for the number of cores that are available. It I have N cores and am already using M cores for e.g. decompressing video, N-M is probably a much better estimate of the available resources than N. I suppose for some applications e.g. games, scientific simulations, people are likely to set up their system with M=0 before they start. However that isn't obviously the common case.
Re: [whatwg] Proposal: navigator.cores
On 5/13/14, 10:11 AM, James Graham wrote: I think the problem that I have with this API is the number of cores that exist isn't obviously a good proxy for the number of cores that are available. It I have N cores and am already using M cores for e.g. decompressing video, N-M is probably a much better estimate of the available resources than N. One thing along those lines that came up in discussion of this proposal at Mozilla: this proposal seems to assume that the UA itself is using a very few cores. This is a valid-ish assumption for current UAs: as long as you have only one tab open, the UA will typically use only one core (ignoring things like parallel JIT compilation, parallel GC, etc; I did say valid-ish). But I suspect that for future UAs this will be an outright bad assumption. Certainly for Servo it is. -Boris
Re: [whatwg] Proposal: navigator.cores
On Tue, May 13, 2014 at 1:15 PM, Boris Zbarsky bzbar...@mit.edu wrote: this proposal seems to assume that the UA itself is using a very few cores The proposal does not assume anything regarding current system load. If the UA is using every core for some CPU-intensive operation, then navigator.hardwareConcurrency should still be exactly the same value. It represents maximum concurrency potential available, not currently unused concurrency. Once the UA is done with whatever CPU-intensive operations it needs to do, then threadpools previously sized with navigator.hardwareConcurrency will return to nominal performance. Let the OS scheduler do what it does best.
Re: [whatwg] Proposal: navigator.cores
On Fri, May 09, 2014 at 11:05:03AM -0500, Glenn Maynard wrote: On Fri, May 9, 2014 at 9:56 AM, David Young dyo...@pobox.com wrote: The algorithms don't have to run as fast as possible, they only have to run fast enough that the system is responsive to the user. If there is a motion graphic, you need to run the algorithm fast enough that the motion isn't choppy. That's not correct. For image processing and compression, you want to use as many cores as you can so the operation completes more quickly. Sounds like a latency goal to me. I think that it's probably a set of latency goals. For example, finish the work before the user notices (instantly---100ms or less) the user's attention is lost or patience runs out---5 to 10 seconds, depending on the user the user has finished checking their email the user is late for their lunch appointment the user has finished lunch the user wakes up the next morning If I'm going to take a coffee break or go check my email, anyway, then the difference between as quickly as possible and 150% longer than that may not even matter. Five minutes? Or seven and a half? Meh. :-) Also, a web app should use only as many threads as it takes to improve the performance. If you use too many, you may decrease performance, and I don't think a solitary number tells you how many is too many, because not all logical CPUs are created equal, and not only because their clock speeds may differ. For the rest, using more cores means that the algorithm can do a better job, giving a more accurate physics simulation, detecting motion more quickly and accurately, and so on. Again, I see an implicit latency goal, and if all of the results are late, it doesn't really matter how accurate they are. Dave -- David Young dyo...@pobox.comUrbana, IL(217) 721-9981
Re: [whatwg] Proposal: navigator.cores
On Mon, May 05, 2014 at 07:31:15PM -0400, Eli Grey wrote: I have a list of example use cases at http://wiki.whatwg.org/wiki/NavigatorCores#Example_use_cases Each of these use cases involves a parallelizable algorithm that needs to run as fast as possible on the user's system in order for the user to have a responsive experience. You can never run any of these algorithms too fast/with too many resources. It's all part of the race to sleep/idle. The algorithms don't have to run as fast as possible, they only have to run fast enough that the system is responsive to the user. If there is a motion graphic, you need to run the algorithm fast enough that the motion isn't choppy. If the user interacts with the app, then if the app responds in 100ms to commands/gestures, that's often as good as instantaneous as far as human perception goes. If you're running the algorithm any faster than the lowest responsive rate (e.g., 3,000 frames per second is probably too fast), you're taking an unnecessary share of the CPU resource. You're probably running the computer hot and loud, too. Let me suggest an approach to scaling the number of threads for performance that does not require the core count or maximum concurrency or any one-dimensional measure like that. Set a latency goal for your motion/input response. Create one worker thread for your algorithm. Track the rate of work completion. Fast enough to meet your goal? If not, create another worker thread. Fast enough? If not, create another worker. Keep tracking. At some point you will reach a point of diminishing returns---in fact, you may actually move *away* from your goal by adding threads. Add no more threads at that point. Track your performance against the goal always. If you start exceeding your goal by a large margin, cancel a worker. Various refinements to the approach are possible. For example, you could start with more than one worker thread. Also, you could increase/decrease the number of threads in a different way: double/halve, or increase in proportion to the performance boost you hope for. Is there some reason that the web platform does not support this approach? Is there some reason that this approach doesn't fit the use cases you mention? Dave -- David Young dyo...@pobox.comUrbana, IL(217) 721-9981
Re: [whatwg] Proposal: navigator.cores
On Thu, May 8, 2014 at 10:13 PM, Adam Barth w...@adambarth.com wrote: I've updated the spec proposal [1] to sanction reporting fewer than the actual number of logical cores as a fingerprinting mitigation. The spec should allow the UA to do this (the real value isn't script-visible, so it can't really prohibit it), but it shouldn't recommend effectively limiting high-end machines. This also shouldn't be confused to be a solution for fingerprinting. It would still be another axis to segment average users on. On Fri, May 9, 2014 at 9:56 AM, David Young dyo...@pobox.com wrote: The algorithms don't have to run as fast as possible, they only have to run fast enough that the system is responsive to the user. If there is a motion graphic, you need to run the algorithm fast enough that the motion isn't choppy. That's not correct. For image processing and compression, you want to use as many cores as you can so the operation completes more quickly. For the rest, using more cores means that the algorithm can do a better job, giving a more accurate physics simulation, detecting motion more quickly and accurately, and so on. -- Glenn Maynard
Re: [whatwg] Proposal: navigator.cores
FYI From the WebKit side, people are leaning towards returning the logical CPU count but limit the maximum value to 8 [1]. This should cover the vast majority of systems and use cases for this property and still not expose users that are on high value devices.. 1: https://bugs.webkit.org/show_bug.cgi?id=132588 On Tue, May 6, 2014 at 2:30 PM, Rik Cabanier caban...@gmail.com wrote: On Tue, May 6, 2014 at 8:51 AM, Joe Gregorio jcgrego...@google.comwrote: On Tue, May 6, 2014 at 7:57 AM, João Eiras jo...@opera.com wrote: ... I guess everyone that is reading this thread understands the use cases well and agrees with them. The disagreement is what kind of API you need. Many people, rightly so, have stated that a core count gives little information that can be useful. It's better to have an API that determines the optimal number of parallel tasks that can run, because who knows what else runs in a different process (the webpage the worker is in, the browser UI, plugins, other webpages, iframes, etc) with what load. Renaming 'cores' to 'parallelTaskCount' would be a start. +1 The solution proposed should actually be a solution to the problem as stated, which, from the abstract read: The intended use for the API is to help developers make informed decisions regarding the size of their worker threadpools to perform parallel algorithms. So the solution should be some information about the maximum number of parallel workers that a page can expect to run, which may have no relation to the number of cores, physical or virtual. The browser should be allowed to determine what that number is based on all the factors it has visibility to, such as load, cores, and policy. Returning the number is actually important, for example, physics engines for WebGL games, how you shard the work may depend on knowing how many parallel workers you should schedule. It seems everyone is in agreement that this API should return the number of useful parallel tasks. So far, people have proposed several names: - cores - this seems confusing since the returned number might be lower - concurrency - there can be more concurrent tasks than there are logical cores - hardwareConcurrency - parallelTaskCount Leaving the question of fingerprinting aside for now, what name would people prefer?
Re: [whatwg] Proposal: navigator.cores
Maybe we can also return their RAM, but limit it to a maximum of 640K, since no one will need more than that :-) I think in a few years the limit to 8 cores will look just as silly. On Thu, May 8, 2014 at 10:02 PM, Rik Cabanier caban...@gmail.com wrote: FYI From the WebKit side, people are leaning towards returning the logical CPU count but limit the maximum value to 8 [1]. This should cover the vast majority of systems and use cases for this property and still not expose users that are on high value devices.. 1: https://bugs.webkit.org/show_bug.cgi?id=132588 On Tue, May 6, 2014 at 2:30 PM, Rik Cabanier caban...@gmail.com wrote: On Tue, May 6, 2014 at 8:51 AM, Joe Gregorio jcgrego...@google.com wrote: On Tue, May 6, 2014 at 7:57 AM, João Eiras jo...@opera.com wrote: ... I guess everyone that is reading this thread understands the use cases well and agrees with them. The disagreement is what kind of API you need. Many people, rightly so, have stated that a core count gives little information that can be useful. It's better to have an API that determines the optimal number of parallel tasks that can run, because who knows what else runs in a different process (the webpage the worker is in, the browser UI, plugins, other webpages, iframes, etc) with what load. Renaming 'cores' to 'parallelTaskCount' would be a start. +1 The solution proposed should actually be a solution to the problem as stated, which, from the abstract read: The intended use for the API is to help developers make informed decisions regarding the size of their worker threadpools to perform parallel algorithms. So the solution should be some information about the maximum number of parallel workers that a page can expect to run, which may have no relation to the number of cores, physical or virtual. The browser should be allowed to determine what that number is based on all the factors it has visibility to, such as load, cores, and policy. Returning the number is actually important, for example, physics engines for WebGL games, how you shard the work may depend on knowing how many parallel workers you should schedule. It seems everyone is in agreement that this API should return the number of useful parallel tasks. So far, people have proposed several names: - cores - this seems confusing since the returned number might be lower - concurrency - there can be more concurrent tasks than there are logical cores - hardwareConcurrency - parallelTaskCount Leaving the question of fingerprinting aside for now, what name would people prefer?
Re: [whatwg] Proposal: navigator.cores
On Thu, May 8, 2014 at 7:07 PM, Joe Gregorio jcgrego...@google.com wrote: Maybe we can also return their RAM, but limit it to a maximum of 640K, since no one will need more than that :-) I think in a few years the limit to 8 cores will look just as silly. Once 16 is common, WebKit will be updated to 16. Maybe by then we'll also have a task scheduling framework to go along. On Thu, May 8, 2014 at 10:02 PM, Rik Cabanier caban...@gmail.com wrote: FYI From the WebKit side, people are leaning towards returning the logical CPU count but limit the maximum value to 8 [1]. This should cover the vast majority of systems and use cases for this property and still not expose users that are on high value devices.. 1: https://bugs.webkit.org/show_bug.cgi?id=132588 On Tue, May 6, 2014 at 2:30 PM, Rik Cabanier caban...@gmail.com wrote: On Tue, May 6, 2014 at 8:51 AM, Joe Gregorio jcgrego...@google.com wrote: On Tue, May 6, 2014 at 7:57 AM, João Eiras jo...@opera.com wrote: ... I guess everyone that is reading this thread understands the use cases well and agrees with them. The disagreement is what kind of API you need. Many people, rightly so, have stated that a core count gives little information that can be useful. It's better to have an API that determines the optimal number of parallel tasks that can run, because who knows what else runs in a different process (the webpage the worker is in, the browser UI, plugins, other webpages, iframes, etc) with what load. Renaming 'cores' to 'parallelTaskCount' would be a start. +1 The solution proposed should actually be a solution to the problem as stated, which, from the abstract read: The intended use for the API is to help developers make informed decisions regarding the size of their worker threadpools to perform parallel algorithms. So the solution should be some information about the maximum number of parallel workers that a page can expect to run, which may have no relation to the number of cores, physical or virtual. The browser should be allowed to determine what that number is based on all the factors it has visibility to, such as load, cores, and policy. Returning the number is actually important, for example, physics engines for WebGL games, how you shard the work may depend on knowing how many parallel workers you should schedule. It seems everyone is in agreement that this API should return the number of useful parallel tasks. So far, people have proposed several names: - cores - this seems confusing since the returned number might be lower - concurrency - there can be more concurrent tasks than there are logical cores - hardwareConcurrency - parallelTaskCount Leaving the question of fingerprinting aside for now, what name would people prefer?
Re: [whatwg] Proposal: navigator.cores
On Tue, May 6, 2014 at 9:33 PM, Rik Cabanier caban...@gmail.com wrote: What do you mean? The paper explains that fingerprinting is a problem for privacy, and here it's being used to argue fingerprinting is already so bad that we should stop trying. (I'm not saying he can't do it or that it's unethical, just that it's unpleasant.) On Thu, May 8, 2014 at 9:07 PM, Joe Gregorio jcgrego...@google.com wrote: Maybe we can also return their RAM, but limit it to a maximum of 640K, since no one will need more than that :-) I think in a few years the limit to 8 cores will look just as silly. I'd imagine that this won't be the final version of WebKit, and that they'd increase that number if 16 cores was average and 64 cores was on the outside. (At least for desktops, I'm not at all convinced that anything like that will happen, though--high-end desktop machines have been hovering around 4 cores with HT for years. I think there's just not much market demand for faster and faster CPUs like there used to be...) That said, if I spent lots of money on a 16-core processor, then I'd be pretty angry if this caused pages to only use half of it. -- Glenn Maynard
Re: [whatwg] Proposal: navigator.cores
I've updated the spec proposal [1] to sanction reporting fewer than the actual number of logical cores as a fingerprinting mitigation. I've also renamed the API from navigator.cores to navigator.hardwareConcurrency to match the proposed WebKit patch. Adam [1] http://wiki.whatwg.org/wiki/NavigatorCores On Thu, May 8, 2014 at 7:02 PM, Rik Cabanier caban...@gmail.com wrote: FYI From the WebKit side, people are leaning towards returning the logical CPU count but limit the maximum value to 8 [1]. This should cover the vast majority of systems and use cases for this property and still not expose users that are on high value devices.. 1: https://bugs.webkit.org/show_bug.cgi?id=132588 On Tue, May 6, 2014 at 2:30 PM, Rik Cabanier caban...@gmail.com wrote: On Tue, May 6, 2014 at 8:51 AM, Joe Gregorio jcgrego...@google.com wrote: On Tue, May 6, 2014 at 7:57 AM, João Eiras jo...@opera.com wrote: ... I guess everyone that is reading this thread understands the use cases well and agrees with them. The disagreement is what kind of API you need. Many people, rightly so, have stated that a core count gives little information that can be useful. It's better to have an API that determines the optimal number of parallel tasks that can run, because who knows what else runs in a different process (the webpage the worker is in, the browser UI, plugins, other webpages, iframes, etc) with what load. Renaming 'cores' to 'parallelTaskCount' would be a start. +1 The solution proposed should actually be a solution to the problem as stated, which, from the abstract read: The intended use for the API is to help developers make informed decisions regarding the size of their worker threadpools to perform parallel algorithms. So the solution should be some information about the maximum number of parallel workers that a page can expect to run, which may have no relation to the number of cores, physical or virtual. The browser should be allowed to determine what that number is based on all the factors it has visibility to, such as load, cores, and policy. Returning the number is actually important, for example, physics engines for WebGL games, how you shard the work may depend on knowing how many parallel workers you should schedule. It seems everyone is in agreement that this API should return the number of useful parallel tasks. So far, people have proposed several names: - cores - this seems confusing since the returned number might be lower - concurrency - there can be more concurrent tasks than there are logical cores - hardwareConcurrency - parallelTaskCount Leaving the question of fingerprinting aside for now, what name would people prefer?
Re: [whatwg] Proposal: navigator.cores
On Tue, 06 May 2014 01:29:47 +0200, Kenneth Russell k...@google.com wrote: Applications need this API in order to determine how many Web Workers to instantiate in order to parallelize their work. On Tue, 06 May 2014 01:31:15 +0200, Eli Grey m...@eligrey.com wrote: I have a list of example use cases at http://wiki.whatwg.org/wiki/NavigatorCores#Example_use_cases (...) I guess everyone that is reading this thread understands the use cases well and agrees with them. The disagreement is what kind of API you need. Many people, rightly so, have stated that a core count gives little information that can be useful. It's better to have an API that determines the optimal number of parallel tasks that can run, because who knows what else runs in a different process (the webpage the worker is in, the browser UI, plugins, other webpages, iframes, etc) with what load. Renaming 'cores' to 'parallelTaskCount' would be a start. On Tue, 06 May 2014 01:31:15 +0200, Eli Grey m...@eligrey.com wrote: Also, allowing webapps to set thread priority is very dangerous and can cause system lockup. Nobody mentioned giving direct unsanatized access to setting low level thread/process priority. On Tue, 06 May 2014 01:29:47 +0200, Kenneth Russell k...@google.com wrote: A prioritization API for Web Workers won't solve this problem, because all of the workers an application requests must actually be spawned for correctness purposes. There's no provision in the web worker specification for allocation of a web worker to fail gracefully, or for a worker to be suspended indefinitely. Even if a worker had its priority designated as low, it would still need to be started. You're identifying limitations in the workers API. That's good. Would be very useful to add the missing bits you're asking to the worker API. On 32-bit systems, at least, spawning too many workers will cause the user agent to run out of address space fairly quickly. That seems like a user agent with a bad implementation. Limiting the resources that an unprivileged application can use on the system is a really old idea. That's already done in browsers with disk quotas for local storage, databases and application cache, for instance. I wouldn't want to use that browser either. Typing a url into the address bar does not imply that I give the web page the permission to hog my computer or device with excess CPU and memory usage.
Re: [whatwg] Proposal: navigator.cores
On Mon, May 05, 2014 at 01:05:35PM -0700, Rik Cabanier wrote: On Mon, May 5, 2014 at 11:10 AM, David Young dyo...@pobox.com wrote: On Sat, May 03, 2014 at 10:49:00AM -0700, Adam Barth wrote: Over on blink-dev, we've been discussing [1] adding a property to navigator that reports the number of cores [2]. As far as I can tell, this functionality exists in every other platform (including iOS and Android). Some of the use cases for this feature have been discussed previously on this mailing list [3] and rejected in favor of a more complex system, perhaps similar to Grand Central Dispatch [4]. Others have raised concerns that exposing the number of cores could lead to increased fidelity of fingerprinting [5]. navigator.cores seems to invite developers to try to write web apps that make local decisions about the scheduling of work on cores when they're missing important essential knowledge about the global context: cores may not be equally fast, energy-efficient, or available; Eli already pointed out that this is not a problem. Heterogeneous systems still allow concurrency on the different cores; the faster ones will simply finish their work faster It's not so simple. It depends on what the work is, how and when you divide up the work, and the overhead of enlisting additional threads to do the work. Dave -- David Young dyo...@pobox.comUrbana, IL(217) 721-9981
Re: [whatwg] Proposal: navigator.cores
On Tue, May 6, 2014 at 7:57 AM, João Eiras jo...@opera.com wrote: ... I guess everyone that is reading this thread understands the use cases well and agrees with them. The disagreement is what kind of API you need. Many people, rightly so, have stated that a core count gives little information that can be useful. It's better to have an API that determines the optimal number of parallel tasks that can run, because who knows what else runs in a different process (the webpage the worker is in, the browser UI, plugins, other webpages, iframes, etc) with what load. Renaming 'cores' to 'parallelTaskCount' would be a start. +1 The solution proposed should actually be a solution to the problem as stated, which, from the abstract read: The intended use for the API is to help developers make informed decisions regarding the size of their worker threadpools to perform parallel algorithms. So the solution should be some information about the maximum number of parallel workers that a page can expect to run, which may have no relation to the number of cores, physical or virtual. The browser should be allowed to determine what that number is based on all the factors it has visibility to, such as load, cores, and policy. Returning the number is actually important, for example, physics engines for WebGL games, how you shard the work may depend on knowing how many parallel workers you should schedule. --joe
Re: [whatwg] Proposal: navigator.cores
On Tue, May 6, 2014 at 8:51 AM, Joe Gregorio jcgrego...@google.com wrote: On Tue, May 6, 2014 at 7:57 AM, João Eiras jo...@opera.com wrote: ... I guess everyone that is reading this thread understands the use cases well and agrees with them. The disagreement is what kind of API you need. Many people, rightly so, have stated that a core count gives little information that can be useful. It's better to have an API that determines the optimal number of parallel tasks that can run, because who knows what else runs in a different process (the webpage the worker is in, the browser UI, plugins, other webpages, iframes, etc) with what load. Renaming 'cores' to 'parallelTaskCount' would be a start. +1 The solution proposed should actually be a solution to the problem as stated, which, from the abstract read: The intended use for the API is to help developers make informed decisions regarding the size of their worker threadpools to perform parallel algorithms. So the solution should be some information about the maximum number of parallel workers that a page can expect to run, which may have no relation to the number of cores, physical or virtual. The browser should be allowed to determine what that number is based on all the factors it has visibility to, such as load, cores, and policy. Returning the number is actually important, for example, physics engines for WebGL games, how you shard the work may depend on knowing how many parallel workers you should schedule. It seems everyone is in agreement that this API should return the number of useful parallel tasks. So far, people have proposed several names: - cores - this seems confusing since the returned number might be lower - concurrency - there can be more concurrent tasks than there are logical cores - hardwareConcurrency - parallelTaskCount Leaving the question of fingerprinting aside for now, what name would people prefer?
Re: [whatwg] Proposal: navigator.cores
On 5/6/14, 5:30 PM, Rik Cabanier wrote: Leaving the question of fingerprinting aside for now, what name would people prefer? mauve? Failing that, maxUsefulWorkers? -Boris
Re: [whatwg] Proposal: navigator.cores
On Sun, May 4, 2014 at 4:49 PM, Adam Barth w...@adambarth.com wrote: You're right that Panopticlick doesn't bother to spend the few seconds it takes to estimate the number of cores because it already has sufficient information to fingerprint 99.1% of visitors: https://panopticlick.eff.org/browser-uniqueness.pdf It's pretty unpleasant to use a paper arguing that fingerprinting is a threat to online privacy as an argument that we should give up trying to prevent fingerprinting. On Mon, May 5, 2014 at 10:20 PM, Ian Hickson i...@hixie.ch wrote: of Workers today, as bz pointed out earlier). Indeed, on a high-core machine as we should expect to start seeing widely in the coming years, it might make sense for the browser to randomly limit the number of cores on a per-origin/session basis, specifically to mitigate fingerprinting. This might make sense in browser modes like Chrome's incognito mode, but I think it would be overboard to do this in a regular browser window. If I've paid for a CPU with 16 cores, I expect applications which are able to use them all to do so consistently, and not be randomly throttled to something less. On Tue, May 6, 2014 at 4:38 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 5/6/14, 5:30 PM, Rik Cabanier wrote: Leaving the question of fingerprinting aside for now, what name would people prefer? mauve? Failing that, maxUsefulWorkers? It can be useful to start more workers than processors, when they're not CPU-bound. -- Glenn Maynard
Re: [whatwg] Proposal: navigator.cores
On Tue, May 6, 2014 at 5:24 PM, Glenn Maynard gl...@zewt.org wrote: On Sun, May 4, 2014 at 4:49 PM, Adam Barth w...@adambarth.com wrote: You're right that Panopticlick doesn't bother to spend the few seconds it takes to estimate the number of cores because it already has sufficient information to fingerprint 99.1% of visitors: https://panopticlick.eff.org/browser-uniqueness.pdf It's pretty unpleasant to use a paper arguing that fingerprinting is a threat to online privacy as an argument that we should give up trying to prevent fingerprinting. What do you mean? For fingerprinting, the algorithm would not have to be precise. Instead a routine that return 1 or 2 for cheap machines and 12 for expensive machines would be enough. The fact that this is so easily accomplished today and we don't have any evidence that this is happening, tells me that it is not that valuable. On Mon, May 5, 2014 at 10:20 PM, Ian Hickson i...@hixie.ch wrote: of Workers today, as bz pointed out earlier). Indeed, on a high-core machine as we should expect to start seeing widely in the coming years, it might make sense for the browser to randomly limit the number of cores on a per-origin/session basis, specifically to mitigate fingerprinting. This might make sense in browser modes like Chrome's incognito mode, but I think it would be overboard to do this in a regular browser window. If I've paid for a CPU with 16 cores, I expect applications which are able to use them all to do so consistently, and not be randomly throttled to something less. Exactly. On Tue, May 6, 2014 at 4:38 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 5/6/14, 5:30 PM, Rik Cabanier wrote: Leaving the question of fingerprinting aside for now, what name would people prefer? mauve? Failing that, maxUsefulWorkers? It can be useful to start more workers than processors, when they're not CPU-bound. Yes. The 'hardwareConcurrency' and 'parallelTaskCount' terms feel better because they don't imply a maximum.
Re: [whatwg] Proposal: navigator.cores
On 5/4/14, 9:49 AM, Adam Barth wrote: Maybe navigator.hardwareConcurrency as a nod to the C++11 name? What is the proposed behavior of this attribute on AMP (as opposed to SMP) systems? Note that some of these are shipping in actual devices today, and I expect that to continue. -Boris
Re: [whatwg] Proposal: navigator.cores
On Sun, May 4, 2014 at 8:35 PM, Ian Hickson i...@hixie.ch wrote: On Sun, 4 May 2014, Adam Barth wrote: The world of computing has changed since 2009. At that time, the iPhone 3G had just been released and Apple hadn't even released the first iPad. The needs of the web as a platform have changed because now the web faces stiff competition from other mobile application frameworks. I'm not arguing that we shouldn't provide solid APIs that allow authors to provide multi-core solutions. I'm arguing that when we do so, we should do so while protecting the privacy of users. I feel a bit like I'm repeating myself, but I'll try to present my two arguments again concisely: 1) There is no privacy issue today. The only privacy concern people have raise is in regards to fingerprinting. Today, fingerprinting is already possible with a high degree of accuracy regardless of navigator.cores. The fingerprinting concern with navigator.cores only degrades privacy in a hypothetical future world in which we're removed all the existing fingerprinting vectors in the platform. I don't believe we'll ever live in that world, and I'm no longer willing to withhold useful tools from developer to keep that dream alive. 2) In 2009, as well as today, you've argued that we should hold out for a better solution. I agree that we should provide developers with a better solution (e.g., something analogous to Grand Central Dispatch). However, I also believe we should provide developers with a worse solution [1], and I'm sad that we didn't do that in 2009. If we had provided developers with a worse solution in 2009, they would be better off today. Similarly, developers will be better off if we provide navigator.cores today even if we manage to ship a better solution sometime before 2019. Adam [1] http://www.jwz.org/doc/worse-is-better.html
Re: [whatwg] Proposal: navigator.cores
On 5/5/14, 11:26 AM, Adam Barth wrote: On getting, the cores property should return the number of logical processors available to the user agent. For example on OS X this should be equivalent to running sysctl -n hw.ncpu. This doesn't really answer my question. What if there are six logical processors available, of which four are 10x as fast as the other two? Do we really want this API claiming 5? -Boris
Re: [whatwg] Proposal: navigator.cores
We want to claim 6 in that situation. If the API claimed less than 6 on Samsung's Exynos 5 Hexa (2x A15 cores + 4x A7 cores), then the cores will be underutilized. We already experience varying performance per core with current systems (especially mobile SoCs) using uniform core hardware, simply due to the cores being at different clocks. This does not invalidate logical processors as a measure of concurrency. Additionally, workers have no method of assigning core affinity, so the issue you bring up (cores of varying hardware performance) is already a problem in the current worker model, with or without navigator.cores. On Mon, May 5, 2014 at 11:58 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 5/5/14, 11:57 AM, Boris Zbarsky wrote: This doesn't really answer my question. What if there are six logical processors available, of which four are 10x as fast as the other two? Do we really want this API claiming 5? Er, I meant claiming 6, of course. -Boris
Re: [whatwg] Proposal: navigator.cores
On Mon, May 5, 2014 at 11:10 AM, David Young dyo...@pobox.com wrote: On Sat, May 03, 2014 at 10:49:00AM -0700, Adam Barth wrote: Over on blink-dev, we've been discussing [1] adding a property to navigator that reports the number of cores [2]. As far as I can tell, this functionality exists in every other platform (including iOS and Android). Some of the use cases for this feature have been discussed previously on this mailing list [3] and rejected in favor of a more complex system, perhaps similar to Grand Central Dispatch [4]. Others have raised concerns that exposing the number of cores could lead to increased fidelity of fingerprinting [5]. navigator.cores seems to invite developers to try to write web apps that make local decisions about the scheduling of work on cores when they're missing important essential knowledge about the global context: cores may not be equally fast, energy-efficient, or available; Eli already pointed out that this is not a problem. Heterogeneous systems still allow concurrency on the different cores; the faster ones will simply finish their work faster global scheduling decisions may be more sophisticated than, or in opposition to your local scheduling decisions. I think that a more complex system, such as Grand Central Dispatch, is probably more effective and less complicated than each web app trying independently, without any real information, to optimize its use of cores. We are now 6 years from that proposal and nothing has happened since. (Is there any data on how successful Grand Central is?) This is not an optimal solution but at least it gives authors a way to make a semi-informed decision. If this is not provided, they will either make a poor guess or just optimize for the most popular platform. As previous pointed out, a thread scheduling solution will need the optimal number of concurrent tasks too.
Re: [whatwg] Proposal: navigator.cores
Hi. I'm just taking a peek at this topic. My first impression is: why would anyone want such a low level hardware information (CPU cores and whatnot) on something as high level and abstract as a browser? This strikes me initially a useful as having the CPU architecture exposed as well. However, I do see the use cases of somehow being more forgiving with CPU usage. But this would be much better achieved with an API like defining the priority of workers (high, normal, low) and other async tasks, and let the user agent do all the resource allocation and management, because that's what user agents are built to do. In any case the user agent would make those choices better than the web developer. The only use case I can think of where a web page might want explicit hardware information is for driver download pages, benchmarks or collecting statistics. But these cases would be better solved with a specialized API requiring user consent.
Re: [whatwg] Proposal: navigator.cores
I have a list of example use cases at http://wiki.whatwg.org/wiki/NavigatorCores#Example_use_cases Each of these use cases involves a parallelizable algorithm that needs to run as fast as possible on the user's system in order for the user to have a responsive experience. You can never run any of these algorithms too fast/with too many resources. It's all part of the race to sleep/idle. Thread priority does not increase performance of these algorithms nearly as dramatically as using more threads when there are more available processors to run threads on. Currently you would use 1 thread for all of these use cases, even if the user has 4 cores, simply because you do not know how many cores the user has. Also, allowing webapps to set thread priority is very dangerous and can cause system lockup. On Mon, May 5, 2014 at 7:09 PM, João Carlos Martins Eiras jo...@opera.com wrote: Hi. I'm just taking a peek at this topic. My first impression is: why would anyone want such a low level hardware information (CPU cores and whatnot) on something as high level and abstract as a browser? This strikes me initially a useful as having the CPU architecture exposed as well. However, I do see the use cases of somehow being more forgiving with CPU usage. But this would be much better achieved with an API like defining the priority of workers (high, normal, low) and other async tasks, and let the user agent do all the resource allocation and management, because that's what user agents are built to do. In any case the user agent would make those choices better than the web developer. The only use case I can think of where a web page might want explicit hardware information is for driver download pages, benchmarks or collecting statistics. But these cases would be better solved with a specialized API requiring user consent.
Re: [whatwg] Proposal: navigator.cores
On Mon, 5 May 2014, Kenneth Russell wrote: It would be great to design a new parallelism architecture for the web, but from a practical standpoint, no progress has been made in this area for a number of years, and web developers are hampered today by the absence of this information. Progress can be made imminently. Just tell me what you need. There's no reason this has to take a long time. The only reason it isn't in the spec already is that it hasn't been requested -- as far as I'm aware, until the past week, the last person who mentioned it on the list was me, several years ago. If multiple vendors are interested in a more elaborate solution that doesn't expose more fingerprinting bits, we can do that right away. What would be most helpful to do that is detailed descriptions of use cases, common pitfalls, experience with existing systems like Apple's GCD, strawman API proposals, and criticisms thereof. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal: navigator.cores
GCD exposes core count in that you can make your jobs keep track of the current time and then count how many threads are running at the same time. A GCD-style API will enable me to replace all of Core Estimator's estimation and statistical code with a very simple counter and time tracker, while yielding fully accurate core counts. I honestly cannot think of a system that doesn't make it possible to derive core count even easier than I currently can. On Mon, May 5, 2014 at 7:46 PM, Ian Hickson i...@hixie.ch wrote: On Mon, 5 May 2014, Kenneth Russell wrote: It would be great to design a new parallelism architecture for the web, but from a practical standpoint, no progress has been made in this area for a number of years, and web developers are hampered today by the absence of this information. Progress can be made imminently. Just tell me what you need. There's no reason this has to take a long time. The only reason it isn't in the spec already is that it hasn't been requested -- as far as I'm aware, until the past week, the last person who mentioned it on the list was me, several years ago. If multiple vendors are interested in a more elaborate solution that doesn't expose more fingerprinting bits, we can do that right away. What would be most helpful to do that is detailed descriptions of use cases, common pitfalls, experience with existing systems like Apple's GCD, strawman API proposals, and criticisms thereof. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal: navigator.cores
On Mon, 5 May 2014, Kenneth Russell wrote: It would be great to design a new parallelism architecture for the web, but from a practical standpoint, no progress has been made in this area for a number of years, and web developers are hampered today by the absence of this information. On Monday, May 05, 2014 7:46 PM Ian Hickson replied: Progress can be made imminently. Just tell me what you need. There's no reason this has to take a long time. The only reason it isn't in the spec already is that it hasn't been requested -- as far as I'm aware, until the past week, the last person who mentioned it on the list was me, several years ago. If multiple vendors are interested in a more elaborate solution that doesn't expose more fingerprinting bits, we can do that right away. What would be most helpful to do that is detailed descriptions of use cases, common pitfalls, experience with existing systems like Apple's GCD, strawman API proposals, and criticisms thereof. It strikes me as though some liaison with Khronos.org might make sense: http://www.khronos.org/ There are already several score of major companies involved in the manufacture of silicon that have come together to develop specs for such things as WebGL and WebCL (Heterogeneous parallel computing in HTML5 web browsers). Regards David
Re: [whatwg] Proposal: navigator.cores
On 5/5/14, 7:29 PM, Kenneth Russell wrote: There's no provision in the web worker specification for allocation of a web worker to fail gracefully, or for a worker to be suspended indefinitely. This is not actually true. Nothing in the spec requires a UA to expose the full parallelism of the hardware to workers, so you can just start queueing them when you hit too many; that's not black-box distinguishable from limited hardware resources. Even if a worker had its priority designated as low, it would still need to be started. Sure, in the sense that the caller has to be able to postMessage to it. On 32-bit systems, at least, spawning too many workers will cause the user agent to run out of address space fairly quickly. You're assuming that each worker, as soon as it can accept messages, has a thread with its own address space dedicated to it. While this is one possible implementation strategy, it's not required by the spec (and e.g. Gecko does not use this implementation strategy). It would be great to design a new parallelism architecture for the web, but from a practical standpoint, no progress has been made in this area for a number of years, and web developers are hampered today by the absence of this information. I think it should be exposed to the platform. Again, note that currently nothing requires a UA to allow an arbitrary number of workers running at once. Gecko will certainly limit the number of in-flight workers available to a particular origin, queueing up new ones until old ones terminate. So navigator.cores on machines with a large number of cores may not actually be a useful measure, since the UA may not allow that many workers to be actively on the CPU at once for a given origin anyway. Just food for thought, Boris
Re: [whatwg] Proposal: navigator.cores
On Mon, May 5, 2014 at 7:35 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 5/5/14, 7:29 PM, Kenneth Russell wrote: There's no provision in the web worker specification for allocation of a web worker to fail gracefully, or for a worker to be suspended indefinitely. This is not actually true. Nothing in the spec requires a UA to expose the full parallelism of the hardware to workers, so you can just start queueing them when you hit too many; that's not black-box distinguishable from limited hardware resources. Even if a worker had its priority designated as low, it would still need to be started. Sure, in the sense that the caller has to be able to postMessage to it. On 32-bit systems, at least, spawning too many workers will cause the user agent to run out of address space fairly quickly. You're assuming that each worker, as soon as it can accept messages, has a thread with its own address space dedicated to it. While this is one possible implementation strategy, it's not required by the spec (and e.g. Gecko does not use this implementation strategy). It would be great to design a new parallelism architecture for the web, but from a practical standpoint, no progress has been made in this area for a number of years, and web developers are hampered today by the absence of this information. I think it should be exposed to the platform. Again, note that currently nothing requires a UA to allow an arbitrary number of workers running at once. Gecko will certainly limit the number of in-flight workers available to a particular origin, queueing up new ones until old ones terminate. So navigator.cores on machines with a large number of cores may not actually be a useful measure, since the UA may not allow that many workers to be actively on the CPU at once for a given origin anyway. This is why this API should return the number of actual parallel tasks that are allowed by the browser. There would be no point if this API would return a number that is larger than that.
Re: [whatwg] Proposal: navigator.cores
On Mon, 5 May 2014, Eli Grey wrote: GCD exposes core count in that you can make your jobs keep track of the current time and then count how many threads are running at the same time. A GCD-style API will enable me to replace all of Core Estimator's estimation and statistical code with a very simple counter and time tracker, while yielding fully accurate core counts. I honestly cannot think of a system that doesn't make it possible to derive core count even easier than I currently can. You are assuming that the system is not under load. This is a false assumption. (Your current core estimator makes the same mistake, as I and others have pointer out several times.) You're also assuming there's no potentially-variable per-origin thread limit, etc, which is also a false assumption (q.v. Gecko's implementation of Workers today, as bz pointed out earlier). Indeed, on a high-core machine as we should expect to start seeing widely in the coming years, it might make sense for the browser to randomly limit the number of cores on a per-origin/session basis, specifically to mitigate fingerprinting. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal: navigator.cores
On May 4, 2014, at 7:45, Rik Cabanier caban...@gmail.com wrote: On Sat, May 3, 2014 at 10:32 PM, Eli Grey m...@eligrey.com wrote: The proposal specifically states using logical cores, which handles all of the CPUs you mentioned properly. Intel CPUs with hyperthreading enabled report logical cores as double the hardware cores. Depending on the version and configuration of the Samsung Exynos Octa big.LITTLE CPUs, you will get either 4 logical cores (only one cluster can run at a time) or 8 logical cores (big.LITTLE MP, available in Exynos 5420 or later only). Great! Make sure this is captured when it is put in a specification. Otherwise the subtlety between an actual and a logical core might get lost. Shouldn't this also be captured in the API's name? --tobie
Re: [whatwg] Proposal: navigator.cores
On Sun, May 4, 2014 at 12:13 AM, Tobie Langel tobie.lan...@gmail.comwrote: On May 4, 2014, at 7:45, Rik Cabanier caban...@gmail.com wrote: On Sat, May 3, 2014 at 10:32 PM, Eli Grey m...@eligrey.com wrote: The proposal specifically states using logical cores, which handles all of the CPUs you mentioned properly. Intel CPUs with hyperthreading enabled report logical cores as double the hardware cores. Depending on the version and configuration of the Samsung Exynos Octa big.LITTLE CPUs, you will get either 4 logical cores (only one cluster can run at a time) or 8 logical cores (big.LITTLE MP, available in Exynos 5420 or later only). Great! Make sure this is captured when it is put in a specification. Otherwise the subtlety between an actual and a logical core might get lost. Shouldn't this also be captured in the API's name? Maybe navigator.hardwareConcurrency as a nod to the C++11 name? Adam
Re: [whatwg] Proposal: navigator.cores
On Sat, 3 May 2014, Adam Barth wrote: Over on blink-dev, we've been discussing [1] adding a property to navigator that reports the number of cores [2]. [1] https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/B6pQClqfCp4 [2] http://wiki.whatwg.org/wiki/NavigatorCores Some of the use cases for this feature have been discussed previously on this mailing list [3] and rejected in favor of a more complex system, perhaps similar to Grand Central Dispatch [4]. [3] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-November/024251.html [4] http://en.wikipedia.org/wiki/Grand_Central_Dispatch It's not clear what has changed since that discussion. Why are the concerns raised at that time no longer valid? As far as I can tell, this functionality exists in every other platform (including iOS and Android). This is true, but all those platforms have security mechanisms in place to mitigate the risk: you have to manually install the application, thus granting it either essentially full access to your machine (Win32), or you have to have it vetted by a third party (iOS), or you have to examine permissions that the application is requesting, and explicitly grant it the right to run on your machine. The Web's security model is radically different. On the Web, we assume that it is safe to run any random hostile code, and that that code cannot harm you or violate your privacy. There are flaws in the privacy protection (i.e. fingerprinting vectors) that browsers are slowly patching, but we have worked hard to avoid adding new fingerprinting vectors. We should continue to do so. Others have raised concerns that exposing the number of cores could lead to increased fidelity of fingerprinting [5]. My view is that the fingerprinting risks are minimal. This information is already available to web sites that wish to spend a few seconds probing your machine [6]. Obviously, exposing this property makes that easier and more accurate, which is why it's useful for developers. [5] https://groups.google.com/a/chromium.org/d/msg/blink-dev/B6pQClqfCp4/bfPhYPPQqwYJ [6] http://wg.oftn.org/projects/core-estimator/demo/ The core estimator is wildly inaccurate. For example, it is highly sensitive to machine load. I don't think it's fair to say well, you can get this data with poor fidelity over a few seconds, therefore providing a precise number with zero milliseconds latency is no worse. IMHO, a more complex worker pool system would be valuable, but most systems that have such a worker pool system also report the number of hardware threads available. They don't have to, though. In fact, the web was the only platform I could find that didn't make the number of cores available to developers. The Web is unique in attempting to protect users' privacy in the face of hostile code without requiring installation or a trust-granting step. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal: navigator.cores
On Sun, May 4, 2014 at 1:11 PM, Ian Hickson i...@hixie.ch wrote: On Sat, 3 May 2014, Adam Barth wrote: Over on blink-dev, we've been discussing [1] adding a property to navigator that reports the number of cores [2]. [1] https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/B6pQClqfCp4 [2] http://wiki.whatwg.org/wiki/NavigatorCores Some of the use cases for this feature have been discussed previously on this mailing list [3] and rejected in favor of a more complex system, perhaps similar to Grand Central Dispatch [4]. [3] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-November/024251.html [4] http://en.wikipedia.org/wiki/Grand_Central_Dispatch It's not clear what has changed since that discussion. The world of computing has changed since 2009. At that time, the iPhone 3G had just been released and Apple hadn't even released the first iPad. Why are the concerns raised at that time no longer valid? The needs of the web as a platform have changed because now the web faces stiff competition from other mobile application frameworks. As far as I can tell, this functionality exists in every other platform (including iOS and Android). This is true, but all those platforms have security mechanisms in place to mitigate the risk: you have to manually install the application, thus granting it either essentially full access to your machine (Win32), or you have to have it vetted by a third party (iOS), or you have to examine permissions that the application is requesting, and explicitly grant it the right to run on your machine. The Web's security model is radically different. On the Web, we assume that it is safe to run any random hostile code, and that that code cannot harm you or violate your privacy. There are flaws in the privacy protection (i.e. fingerprinting vectors) that browsers are slowly patching, but we have worked hard to avoid adding new fingerprinting vectors. We should continue to do so. My personal view is that the fingerprinting horse left the barn years ago. I don't believe vendors will succeed in patching the existing fingerprint vectors. For example, the WebKit project cataloged a number of vectors three year ago and has made very little progress patching any of them: http://trac.webkit.org/wiki/Fingerprinting Moreover, vendors are adding new state vectors all the time. For example, the HTTP2 protocol contains an explicit protocol element for persisting data on the client: http://tools.ietf.org/html/draft-ietf-httpbis-http2-12#section-6.5 The web cannot afford to avoid exposing useful, non-privacy sensitive information, such as the number of cores, to developers out of a fear of fingerprinting. Avoiding exposing this information will not improve privacy because fingerprinting is already possible. Instead, not providing developers the tools they need to build compelling web content on mobile will simply result in developers leaving the web platform for other mobile application frameworks. Others have raised concerns that exposing the number of cores could lead to increased fidelity of fingerprinting [5]. My view is that the fingerprinting risks are minimal. This information is already available to web sites that wish to spend a few seconds probing your machine [6]. Obviously, exposing this property makes that easier and more accurate, which is why it's useful for developers. [5] https://groups.google.com/a/chromium.org/d/msg/blink-dev/B6pQClqfCp4/bfPhYPPQqwYJ [6] http://wg.oftn.org/projects/core-estimator/demo/ The core estimator is wildly inaccurate. For example, it is highly sensitive to machine load. I don't think it's fair to say well, you can get this data with poor fidelity over a few seconds, therefore providing a precise number with zero milliseconds latency is no worse. You're right that Panopticlick doesn't bother to spend the few seconds it takes to estimate the number of cores because it already has sufficient information to fingerprint 99.1% of visitors: https://panopticlick.eff.org/browser-uniqueness.pdf IMHO, a more complex worker pool system would be valuable, but most systems that have such a worker pool system also report the number of hardware threads available. They don't have to, though. I didn't say they needed to. I said they did. In fact, the web was the only platform I could find that didn't make the number of cores available to developers. The Web is unique in attempting to protect users' privacy in the face of hostile code without requiring installation or a trust-granting step. I don't believe the number of cores is privacy-sensitive information. Revealing this information to web sites does not require a trust-granting step. Adam
Re: [whatwg] Proposal: navigator.cores
On Sun, May 4, 2014 at 1:11 PM, Ian Hickson i...@hixie.ch wrote: On Sat, 3 May 2014, Adam Barth wrote: Over on blink-dev, we've been discussing [1] adding a property to navigator that reports the number of cores [2]. [1] https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/B6pQClqfCp4 [2] http://wiki.whatwg.org/wiki/NavigatorCores Some of the use cases for this feature have been discussed previously on this mailing list [3] and rejected in favor of a more complex system, perhaps similar to Grand Central Dispatch [4]. [3] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-November/024251.html [4] http://en.wikipedia.org/wiki/Grand_Central_Dispatch It's not clear what has changed since that discussion. Why are the concerns raised at that time no longer valid? As far as I can tell, this functionality exists in every other platform (including iOS and Android). This is true, but all those platforms have security mechanisms in place to mitigate the risk: you have to manually install the application, thus granting it either essentially full access to your machine (Win32), Not quite true for Win32. An admin can install an application but a user with very limited privileges can run it and call the 'GetLogicalProcessorInformation' API to get information about the number of logical cores. Microsoft did not considered an API that needs additional security. OSX is the same (and likely most other OS's) or you have to have it vetted by a third party (iOS), or you have to examine permissions that the application is requesting, and explicitly grant it the right to run on your machine. The Web's security model is radically different. On the Web, we assume that it is safe to run any random hostile code, and that that code cannot harm you or violate your privacy. There are flaws in the privacy protection (i.e. fingerprinting vectors) that browsers are slowly patching, but we have worked hard to avoid adding new fingerprinting vectors. We should continue to do so. Others have raised concerns that exposing the number of cores could lead to increased fidelity of fingerprinting [5]. My view is that the fingerprinting risks are minimal. This information is already available to web sites that wish to spend a few seconds probing your machine [6]. Obviously, exposing this property makes that easier and more accurate, which is why it's useful for developers. [5] https://groups.google.com/a/chromium.org/d/msg/blink-dev/B6pQClqfCp4/bfPhYPPQqwYJ [6] http://wg.oftn.org/projects/core-estimator/demo/ The core estimator is wildly inaccurate. For example, it is highly sensitive to machine load. I don't think it's fair to say well, you can get this data with poor fidelity over a few seconds, therefore providing a precise number with zero milliseconds latency is no worse. Are you saying it's better that people use an estimator poly-fill? Authors want to know this information and will use other means to get this information. This will likely favor popular platforms. IMHO, a more complex worker pool system would be valuable, but most systems that have such a worker pool system also report the number of hardware threads available. They don't have to, though. Yes, they have to because even with worker pools, an application wants know how it can best break up the problem. In fact, the web was the only platform I could find that didn't make the number of cores available to developers. The Web is unique in attempting to protect users' privacy in the face of hostile code without requiring installation or a trust-granting step. I agree with Adam and fail to see what possible information of value could leak. This is nothing like reading pixels from the screen or giving access to a GPS device. Browsers already directly and indirectly give the author access to its capabilities. Having an optimal number of concurrent tasks should be basic information.
Re: [whatwg] Proposal: navigator.cores
On Sun, May 4, 2014 at 6:49 AM, Adam Barth w...@adambarth.com wrote: On Sun, May 4, 2014 at 12:13 AM, Tobie Langel tobie.lan...@gmail.comwrote: On May 4, 2014, at 7:45, Rik Cabanier caban...@gmail.com wrote: On Sat, May 3, 2014 at 10:32 PM, Eli Grey m...@eligrey.com wrote: The proposal specifically states using logical cores, which handles all of the CPUs you mentioned properly. Intel CPUs with hyperthreading enabled report logical cores as double the hardware cores. Depending on the version and configuration of the Samsung Exynos Octa big.LITTLE CPUs, you will get either 4 logical cores (only one cluster can run at a time) or 8 logical cores (big.LITTLE MP, available in Exynos 5420 or later only). Great! Make sure this is captured when it is put in a specification. Otherwise the subtlety between an actual and a logical core might get lost. Shouldn't this also be captured in the API's name? Maybe navigator.hardwareConcurrency as a nod to the C++11 name? That sounds reasonable. `navigator.concurrency` is not quite correct since you can have higher concurrency than the number of hardware threads.
Re: [whatwg] Proposal: navigator.cores
On Sun, May 4, 2014 at 4:11 PM, Ian Hickson i...@hixie.ch wrote: or you have to examine permissions that the application is requesting, and explicitly grant it the right to run on your machine I am not aware of this in any platforms. Can you provide one example of a platform that requests an explicit permission for access to core count? Neither iOS or Android requires any specific permissions for this information. You can create an Android application that requests absolutely no permissions that can read the core count and display it to the user.
Re: [whatwg] Proposal: navigator.cores
Adam Barth w...@adambarth.com writes: Over on blink-dev, we've been discussing [1] adding a property to navigator that reports the number of cores [2]. As far as I can tell, this functionality exists in every other platform (including iOS and Android). Some of the use cases for this feature have been discussed previously on this mailing list [3] and rejected in favor of a more complex system, perhaps similar to Grand Central Dispatch [4]. Others have raised concerns that exposing the number of cores could lead to increased fidelity of fingerprinting [5]. My view is that the fingerprinting risks are minimal. This information is already available to web sites that wish to spend a few seconds probing your machine [6]. Obviously, exposing this property makes that easier and more accurate, which is why it's useful for developers. This script pushed system load to 2.5 for 30 seconds and then estimated I have 4 cores – when running on an old Thinkpad T60 inside Chromium 33. Fact: A sticker on the laptop says “Core Solo”. /proc/cpuinfo agrees. I think it would be a bad idea to expose this information to web applications in an easier and more accurate way for two reasons: First, this enables web application authors to discriminate unduely. Web authors often try to enforce minimal specifications on User Agents if it suits their purpose. Authors often lie to make users more susceptible to tracking and advertising. Enabling authors to discriminate moves the web away from a universal medium – see for example UA string discrimination. I do not want users to see “sorry, this web page needs at least 2 cores” – it will most likely be a lie, similar to messages informing users that they need to allow cookies and JavaScript just to read a web page. Additionally, from a game theory standpoint, I think it is a bad idea to expose the processing resources a client has to applications at all. If a non-malicious application author wants to know the number of cores, then for the purpose of using as much processing power as possible. Applications that grab a maximum number of resources do not play well with other applications that may or may not follow the same strategy. I think a good real-world example how a computing system can handle constrained resources is the OOM killer in Linux. Its simple: If your application uses too much memory, it will be terminated with prejudice. Of course, authors can not know what “too much” means – systems are too diverse for that. This gives an incentive to err on the side of caution, as trying to allocate and use all available memory is most likely fatal. -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] Proposal: navigator.cores
On Sun, 4 May 2014, Adam Barth wrote: The world of computing has changed since 2009. At that time, the iPhone 3G had just been released and Apple hadn't even released the first iPad. The needs of the web as a platform have changed because now the web faces stiff competition from other mobile application frameworks. I'm not arguing that we shouldn't provide solid APIs that allow authors to provide multi-core solutions. I'm arguing that when we do so, we should do so while protecting the privacy of users. My personal view is that the fingerprinting horse left the barn years ago. I don't believe vendors will succeed in patching the existing fingerprint vectors. For example, the WebKit project cataloged a number of vectors three year ago and has made very little progress patching any of them: http://trac.webkit.org/wiki/Fingerprinting I'm not responsible for what individual browser vendors do. Moreover, vendors are adding new state vectors all the time. For example, the HTTP2 protocol contains an explicit protocol element for persisting data on the client: http://tools.ietf.org/html/draft-ietf-httpbis-http2-12#section-6.5 I'm not responsible for what editors of other standards do. The web cannot afford to avoid exposing useful, non-privacy sensitive information, such as the number of cores, to developers out of a fear of fingerprinting. Sure we can. You don't need to know how many cores a system has, you need to know how you can make optimal use of the resources of the system without affecting other tasks that the user is running. There are plenty of ways we can address this use case that don't expose the number of cores as a reliable metric. On Sun, 4 May 2014, Rik Cabanier wrote: As far as I can tell, this functionality exists in every other platform (including iOS and Android). This is true, but all those platforms have security mechanisms in place to mitigate the risk: you have to manually install the application, thus granting it either essentially full access to your machine (Win32), Not quite true for Win32. An admin can install an application but a user with very limited privileges can run it and call the 'GetLogicalProcessorInformation' API to get information about the number of logical cores. Right. You have to install the application. At that point, game over. The point is that on the Web there's no installation step. This is a feature. It's one of the Web's most critically powerful assets. Microsoft did not considered an API that needs additional security. OSX is the same (and likely most other OS's) Sure. Once you've agreed to just let the application reside on your system, then you can fingerprint the user with impunity. The Web is better than that, or at least, we should make it better. Are you saying it's better that people use an estimator poly-fill? No, I'm saying we should provide an API to address the underlying use case -- making optimal use of CPU resources -- without increasing the fingerprinting risk. On Sun, 4 May 2014, Eli Grey wrote: On Sun, May 4, 2014 at 4:11 PM, Ian Hickson i...@hixie.ch wrote: or you have to examine permissions that the application is requesting, and explicitly grant it the right to run on your machine I am not aware of this in any platforms. Can you provide one example of a platform that requests an explicit permission for access to core count? The explicit permission is you can run on this system. On iOS, Android, MacOS, Linux, Windows, and pretty much every other platform, before you can run code on the system, the user or administrator has to explicitly install your code. On the Web, all it takes is visiting a URL. There's no installation step, there's no need for the user to click through a dialog saying running native code is highly risky. Because the Web has a dramatically lower bar for running code, we have to have a dramatically higher bar for protecting the user. Neither iOS or Android requires any specific permissions for this information. You can create an Android application that requests absolutely no permissions that can read the core count and display it to the user. No, you can't. You need one explicit permission: the permission to run in the first place. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal: navigator.cores
On Sun, May 4, 2014 at 8:35 PM, Ian Hickson i...@hixie.ch wrote: On Sun, 4 May 2014, Adam Barth wrote: The world of computing has changed since 2009. At that time, the iPhone 3G had just been released and Apple hadn't even released the first iPad. The needs of the web as a platform have changed because now the web faces stiff competition from other mobile application frameworks. I'm not arguing that we shouldn't provide solid APIs that allow authors to provide multi-core solutions. I'm arguing that when we do so, we should do so while protecting the privacy of users. My personal view is that the fingerprinting horse left the barn years ago. I don't believe vendors will succeed in patching the existing fingerprint vectors. For example, the WebKit project cataloged a number of vectors three year ago and has made very little progress patching any of them: http://trac.webkit.org/wiki/Fingerprinting I'm not responsible for what individual browser vendors do. Moreover, vendors are adding new state vectors all the time. For example, the HTTP2 protocol contains an explicit protocol element for persisting data on the client: http://tools.ietf.org/html/draft-ietf-httpbis-http2-12#section-6.5 I'm not responsible for what editors of other standards do. The web cannot afford to avoid exposing useful, non-privacy sensitive information, such as the number of cores, to developers out of a fear of fingerprinting. Sure we can. You don't need to know how many cores a system has, you need to know how you can make optimal use of the resources of the system without affecting other tasks that the user is running. There are plenty of ways we can address this use case that don't expose the number of cores as a reliable metric. On Sun, 4 May 2014, Rik Cabanier wrote: As far as I can tell, this functionality exists in every other platform (including iOS and Android). This is true, but all those platforms have security mechanisms in place to mitigate the risk: you have to manually install the application, thus granting it either essentially full access to your machine (Win32), Not quite true for Win32. An admin can install an application but a user with very limited privileges can run it and call the 'GetLogicalProcessorInformation' API to get information about the number of logical cores. Right. You have to install the application. At that point, game over. No, you misunderstood. The admin install the application and has all privileges. A guest user with the most limited set of privileges can still call this API since it is considered so low risk. (This is likely also why Chrome can use it since it's process run in a very restricted sandbox.) The point is that on the Web there's no installation step. This is a feature. It's one of the Web's most critically powerful assets. Microsoft did not considered an API that needs additional security. OSX is the same (and likely most other OS's) Sure. Once you've agreed to just let the application reside on your system, then you can fingerprint the user with impunity. The Web is better than that, or at least, we should make it better. Yes, the web is like the reverse of an OS: instead of the admin/OS vendor being in charge of the machine and managing the privileges, it's the user who is in charge and who gets to decide if an application gets to use restricted features. Are you saying it's better that people use an estimator poly-fill? No, I'm saying we should provide an API to address the underlying use case -- making optimal use of CPU resources -- without increasing the fingerprinting risk. I think we already agree on that. The API should return the optimal number of concurrent threads. This doesn't need to be just related to hardware resources and I can even see it be variable depending on the state of the machine (battery - low battery - too hot - background - load) Designing a thread scheduler like one the other proposals is a different problem and much more difficult to generalize. On Sun, 4 May 2014, Eli Grey wrote: On Sun, May 4, 2014 at 4:11 PM, Ian Hickson i...@hixie.ch wrote: or you have to examine permissions that the application is requesting, and explicitly grant it the right to run on your machine I am not aware of this in any platforms. Can you provide one example of a platform that requests an explicit permission for access to core count? The explicit permission is you can run on this system. On iOS, Android, MacOS, Linux, Windows, and pretty much every other platform, before you can run code on the system, the user or administrator has to explicitly install your code. On the Web, all it takes is visiting a URL. There's no installation step, there's no need for the user to click through a dialog saying running native code is highly risky. Because the Web has a dramatically lower bar for running code, we have to
[whatwg] Proposal: navigator.cores
Over on blink-dev, we've been discussing [1] adding a property to navigator that reports the number of cores [2]. As far as I can tell, this functionality exists in every other platform (including iOS and Android). Some of the use cases for this feature have been discussed previously on this mailing list [3] and rejected in favor of a more complex system, perhaps similar to Grand Central Dispatch [4]. Others have raised concerns that exposing the number of cores could lead to increased fidelity of fingerprinting [5]. My view is that the fingerprinting risks are minimal. This information is already available to web sites that wish to spend a few seconds probing your machine [6]. Obviously, exposing this property makes that easier and more accurate, which is why it's useful for developers. IMHO, a more complex worker pool system would be valuable, but most systems that have such a worker pool system also report the number of hardware threads available. Examples: C++: std::thread::hardware_concurrency(); Win32: GetSystemInfo returns dwNumberOfProcessors POSIX: sysctl returns HW_AVAILCPU or HW_NCPU Java: Runtime.getRuntime().availableProcessors(); Python: multiprocessing.cpu_count() In fact, the web was the only platform I could find that didn't make the number of cores available to developers. Adam [1] https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/B6pQClqfCp4 [2] http://wiki.whatwg.org/wiki/NavigatorCores [3] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-November/024251.html [4] http://en.wikipedia.org/wiki/Grand_Central_Dispatch [5] https://groups.google.com/a/chromium.org/d/msg/blink-dev/B6pQClqfCp4/bfPhYPPQqwYJ [6] http://wg.oftn.org/projects/core-estimator/demo/
Re: [whatwg] Proposal: navigator.cores
On Sat, May 3, 2014 at 10:49 AM, Adam Barth w...@adambarth.com wrote: Over on blink-dev, we've been discussing [1] adding a property to navigator that reports the number of cores [2]. As far as I can tell, this functionality exists in every other platform (including iOS and Android). Some of the use cases for this feature have been discussed previously on this mailing list [3] and rejected in favor of a more complex system, perhaps similar to Grand Central Dispatch [4]. Others have raised concerns that exposing the number of cores could lead to increased fidelity of fingerprinting [5]. My view is that the fingerprinting risks are minimal. This information is already available to web sites that wish to spend a few seconds probing your machine [6]. Obviously, exposing this property makes that easier and more accurate, which is why it's useful for developers. IMHO, a more complex worker pool system would be valuable, but most systems that have such a worker pool system also report the number of hardware threads available. Examples: C++: std::thread::hardware_concurrency(); Win32: GetSystemInfo returns dwNumberOfProcessors POSIX: sysctl returns HW_AVAILCPU or HW_NCPU Java: Runtime.getRuntime().availableProcessors(); Python: multiprocessing.cpu_count() In fact, the web was the only platform I could find that didn't make the number of cores available to developers. This sound like a great addition to the platform. I agree that there are no real fingerprinting concerns and it will really benefit advanced authors that want to optimize performance. I wonder if this value should return the number of concurrent tasks (including the main thread) that the system can support, as opposed to the number of cores. For instance, Samsung's exynos octa processor [1] has 8 cores, but only 4 should be used at a time. Desktop CPU's often support hyperthreading so they support double the number of tasks per core [2] 1: http://www.samsung.com/global/business/semiconductor/minisite/Exynos/products5octa_5410.html 2: http://ark.intel.com/products/77780
Re: [whatwg] Proposal: navigator.cores
The proposal specifically states using logical cores, which handles all of the CPUs you mentioned properly. Intel CPUs with hyperthreading enabled report logical cores as double the hardware cores. Depending on the version and configuration of the Samsung Exynos Octa big.LITTLE CPUs, you will get either 4 logical cores (only one cluster can run at a time) or 8 logical cores (big.LITTLE MP, available in Exynos 5420 or later only). On Sat, May 3, 2014 at 10:39 PM, Rik Cabanier caban...@gmail.com wrote: On Sat, May 3, 2014 at 10:49 AM, Adam Barth w...@adambarth.com wrote: Over on blink-dev, we've been discussing [1] adding a property to navigator that reports the number of cores [2]. As far as I can tell, this functionality exists in every other platform (including iOS and Android). Some of the use cases for this feature have been discussed previously on this mailing list [3] and rejected in favor of a more complex system, perhaps similar to Grand Central Dispatch [4]. Others have raised concerns that exposing the number of cores could lead to increased fidelity of fingerprinting [5]. My view is that the fingerprinting risks are minimal. This information is already available to web sites that wish to spend a few seconds probing your machine [6]. Obviously, exposing this property makes that easier and more accurate, which is why it's useful for developers. IMHO, a more complex worker pool system would be valuable, but most systems that have such a worker pool system also report the number of hardware threads available. Examples: C++: std::thread::hardware_concurrency(); Win32: GetSystemInfo returns dwNumberOfProcessors POSIX: sysctl returns HW_AVAILCPU or HW_NCPU Java: Runtime.getRuntime().availableProcessors(); Python: multiprocessing.cpu_count() In fact, the web was the only platform I could find that didn't make the number of cores available to developers. This sound like a great addition to the platform. I agree that there are no real fingerprinting concerns and it will really benefit advanced authors that want to optimize performance. I wonder if this value should return the number of concurrent tasks (including the main thread) that the system can support, as opposed to the number of cores. For instance, Samsung's exynos octa processor [1] has 8 cores, but only 4 should be used at a time. Desktop CPU's often support hyperthreading so they support double the number of tasks per core [2] 1: http://www.samsung.com/global/business/semiconductor/minisite/Exynos/products5octa_5410.html 2: http://ark.intel.com/products/77780
Re: [whatwg] Proposal: navigator.cores
On Sat, May 3, 2014 at 10:32 PM, Eli Grey m...@eligrey.com wrote: The proposal specifically states using logical cores, which handles all of the CPUs you mentioned properly. Intel CPUs with hyperthreading enabled report logical cores as double the hardware cores. Depending on the version and configuration of the Samsung Exynos Octa big.LITTLE CPUs, you will get either 4 logical cores (only one cluster can run at a time) or 8 logical cores (big.LITTLE MP, available in Exynos 5420 or later only). Great! Make sure this is captured when it is put in a specification. Otherwise the subtlety between an actual and a logical core might get lost. On Sat, May 3, 2014 at 10:39 PM, Rik Cabanier caban...@gmail.com wrote: On Sat, May 3, 2014 at 10:49 AM, Adam Barth w...@adambarth.com wrote: Over on blink-dev, we've been discussing [1] adding a property to navigator that reports the number of cores [2]. As far as I can tell, this functionality exists in every other platform (including iOS and Android). Some of the use cases for this feature have been discussed previously on this mailing list [3] and rejected in favor of a more complex system, perhaps similar to Grand Central Dispatch [4]. Others have raised concerns that exposing the number of cores could lead to increased fidelity of fingerprinting [5]. My view is that the fingerprinting risks are minimal. This information is already available to web sites that wish to spend a few seconds probing your machine [6]. Obviously, exposing this property makes that easier and more accurate, which is why it's useful for developers. IMHO, a more complex worker pool system would be valuable, but most systems that have such a worker pool system also report the number of hardware threads available. Examples: C++: std::thread::hardware_concurrency(); Win32: GetSystemInfo returns dwNumberOfProcessors POSIX: sysctl returns HW_AVAILCPU or HW_NCPU Java: Runtime.getRuntime().availableProcessors(); Python: multiprocessing.cpu_count() In fact, the web was the only platform I could find that didn't make the number of cores available to developers. This sound like a great addition to the platform. I agree that there are no real fingerprinting concerns and it will really benefit advanced authors that want to optimize performance. I wonder if this value should return the number of concurrent tasks (including the main thread) that the system can support, as opposed to the number of cores. For instance, Samsung's exynos octa processor [1] has 8 cores, but only 4 should be used at a time. Desktop CPU's often support hyperthreading so they support double the number of tasks per core [2] 1: http://www.samsung.com/global/business/semiconductor/minisite/Exynos/products5octa_5410.html 2: http://ark.intel.com/products/77780
