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] Various autocomplete= topics
Dunno if you still wanted answers to these questions, but in order to not leave you hanging here are my best attempts: On Tue, 4 Mar 2014, Evan Stade wrote: dependent-locality and locality have a fairly precise meaning in the UK. Also in a natural-language conversation, if you ask me what region of the country I live in, I'd say New England, the Midwest, or some such; certainly not the state where I reside. The descriptions for these tokens are currently pretty specific, for example they say a city would be a locality. But this is not true for Beijing or some other cities. To fix the descriptions, we'd have to change them to something like region: the highest level administrative region below country in the address and locality: the second-highest level administrative region below country in the address, sub-locality: the third-highest level administrative region [...]. With you so far. At this point, one wonders why the tokens aren't just [something]1, [something]2, etc. I don't understand how you get there. Why would you wonder this? Because if the long, more descriptive copy is first highest, second highest, etc., it follows that the concise description (i.e. the type name) match that. address-line1 | address-line2 |- street-address address-line3 | locality subsubregion subregion region country-name I don't understand why you think authors will think they need to include subregion, but won't think they need to include address-level3. I think they'll assume subregion returns something for the US if it's sandwiched between region and locality, because county is in between state and city. But in reality, subregion will return nothing. But why does this not apply to the numeric version? Because address-level1 is state and address-level2 is city, so there's no implication of something in between them. Why is that better than 1=region, 2=locality, except to a US-centric viewpoint? This would lead to a weird situation where (a) you couldn't expand past 4 levels without changing the meaning of previous levels and (b) a country such as the US would have address-level4 and address-level3 but no address-level2 or address-level1. Well, at least as far as (a) goes, we have no way to know where governments are going to introduce new levels. Who's to say that the US won't introduce something between states and towns? This problem exists whatever we do. Maybe the US and the EU will merge and there'll be a new field between country-name and region. Who knows. One can dream... You're right that changing political circumstances might put us in an awkward situation no matter what we do. But it seems to me the most likely scenario is that a government would add more administrative levels at the most granular level. Why? It seems just as likely that we'll add levels between country and region. For instance, the example above. Or, in a few years, when there are parts of countries in space, maybe there'll be a planetoid name between the country and the region. Or maybe that will go on the other side of the country. I think trying to guess how things will be extended is a fool's errand. If we use numbers, we paint ourselves into a corner with extensions anywhere but at the deepest level. Well what do we do with words? Add subsubsubregion or moderately-big-area in between two existing words? If a country experiences political turmoil and changes the number of types of administrative divisions it has, I guess it's reasonable to redefine level4 to the former level3, and add a new level5 which is the former level4. I've filed a bug on this topic; if I can get agreement from other vendors, then I'll go ahead and spec this: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25235 great!
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.
[whatwg] More URL spec feedback
Hi, I'm back with more questions on the URL spec after poking at it a bit more for various purposes. One thing I've noticed is that the specification currently aggressively fails IPv6 address matching, so, e.g., new URL(http://[::1::];) would fail. (Although it allows http://[1:2:3:4:5:6::8]/ to go through whereas RFC 5952 advises that :: MUST NOT be used to shorten just one 16-bit 0 field.) However, it doesn't apply this same logic to IPv4: new URL(http://192/;) is parsed as a perfectly valid URL. Is this intentional? -- Joshua Cranmer Source code archæologist -- Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth
[whatwg] Proposal: Event.creationTime
Hi,
Gecko's implementation of Event.timeStamp does not conform to the
spec[1] since it reports the number of milliseconds since system start
rather than 00:00:00 UTC on 1 January 1970. This is tracked as Mozilla
bug 77992 [2]. DOM Level 2 allowed this[3] but the spec has since changed.
One reason for not updating to match the spec has been concern about
using a non-monotonic clock as a time source. This can lead to bugs when
the system clock is adjusted.
Now that we have a DOMHighResTimeStamp that provides a monotonically
increasing time, I propose we add it to the Event interface.[4]
This time is measured from navigationStart which removes some of the
security concerns raised regarding using system start.[5]
navigationStart is also the point of reference being using for
Performance.now(), requestAnimationFrame and Web Animations.
As for use cases for event timestamps, apparently Youtube uses the
timeStamp on progress events to estimate download bandwidth. Another use
case is that of SMIL which seems to want to overload the timestamp from
being strictly creation time to when the event *should* have been
created in order to avoid synchronization slew.[6]
Proposal:
partial interface Event {
readonly attribute DOMHighResTimeStamp creationTime;
};
(Alternative naming suggestions are obviously most welcome.)
Semantics are as with 'timeStamp' but based on navigationStart.
Given that 'timeStamp' is currently implemented inconsistently, it might
be possible to eventually deprecate it.
Best regards,
Brian
[1] http://dom.spec.whatwg.org/#dom-event-timestamp
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=77992
[3]
http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-Event-timeStamp
[4] http://www.w3.org/TR/hr-time/
[5] https://bugzilla.mozilla.org/show_bug.cgi?id=579652#c2
[6] http://www.w3.org/TR/SMIL/smil-timing.html#q135
