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] Various autocomplete= topics
On Fri, Apr 11, 2014 at 3:36 PM, Edward O'Connor eocon...@apple.com wrote: I actually have a similar problem with purely JS-handled forms even unrelated to credentials. Because the form is never really submitted (even if we reuse the submit infrastructure, we cancel the 'submit' event and handle the work on the JS side), there's never an indication to the UA that it should save the fields, and so autofill never works right on these forms, even for things like postal addresses or e-mail addresses. In Firefox, we save the form values after validation but before the submit event is dispatched to content. This way we successfully save the form fields in form history when a script is handling the actual submission. This also helps against sites who try to manipulate the form fields upon submission to avoid having them saved (see https://bugzilla.mozilla.org/show_bug.cgi?id=257781 ). We've been doing this for a long time and I don't recall any complaints as long as I've been working on password and form manager for Firefox (since 2009). There are many websites that use click handlers on buttons outside forms instead of using form submission and those fields don't get saved in Firefox. I suspect web developers don't realize that they are losing out on form history and other benefits like being able to submit the form with the Enter key from a text input. I don't see sites that are not having their fields saved by not using form submission switching to calling a new API when they can instead use an onsubmit handler which has other benefits. Given that Firefox already saves values with preventDefault inside form submit handlers and click handlers on submit buttons, and the other benefits of sites using form submission, I don't think a new API is needed. For the pure JS case, an API (probably on the form itself) would make sense and seems relatively easy. I've filed a bug on this: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25238 This case is pretty weird. Authors are going out of their way to avoid using the built in platform features that would get them autofill saving for free. In some cases, they might be doing this precisely because they want to prevent autofill but can't count on autocomplete=off anymore. It seems like more evangelism is needed to let authors know that preventDefault inside a form submission handler is the better way to handle forms where navigation isn't wanted. The benefits are: form history, password management, better UX (allowing submission via Enter when inputs are in a form), and possibly better accessibility(?). I've been thinking about cases where we could detect the pattern of fake forms (using text inputs and buttons with click handlers together without a form) and provide notices in developer tools to help evangelize but it's looking to be tricky. -- Matthew Noorenberghe
