Re: Intent to implement and ship: navigator.hardwareConcurrency

On 21.05.2014 01:27, Rik Cabanier wrote: Likewise here. I don't think anyone is saying that "hardwareConcurrency" is failing on the grounds of exposing too much system information alone. The way I read this thread, people either aren't convinced that it's the right compromise given its usefulness

Re: Intent to implement and ship: navigator.hardwareConcurrency

On Tue, May 20, 2014 at 4:16 PM, Daniel Holbert wrote: > On 05/20/2014 04:06 PM, Daniel Holbert wrote: > > On 05/20/2014 03:50 PM, Rik Cabanier wrote: > >> I agree that there's a risk since this will make it super easy to get to > >> the core count. > >> I don't have the exact number but I suspect

Re: Intent to implement and ship: navigator.hardwareConcurrency

On Tue, May 20, 2014 at 5:20 AM, Benoit Jacob wrote: > > > > 2014-05-19 23:37 GMT-04:00 Rik Cabanier : > > >> >> >> On Mon, May 19, 2014 at 6:46 PM, Benoit Jacob >> wrote: >> >>> +1000! Thanks for articulating so clearly the difference between the >>> Web-as-an-application-platform and other appl

Re: Intent to implement and ship: navigator.hardwareConcurrency

On 05/20/2014 04:06 PM, Daniel Holbert wrote: > On 05/20/2014 03:50 PM, Rik Cabanier wrote: >> I agree that there's a risk since this will make it super easy to get to >> the core count. >> I don't have the exact number but I suspect that very few machines will >> have more than 8 cores which makes

Re: Intent to implement and ship: navigator.hardwareConcurrency

On 05/20/2014 03:50 PM, Rik Cabanier wrote: > I agree that there's a risk since this will make it super easy to get to > the core count. > I don't have the exact number but I suspect that very few machines will > have more than 8 cores which makes them valuable for targeted marketing. (To be clear

Re: Intent to implement and ship: navigator.hardwareConcurrency

On Tue, May 20, 2014 at 11:10 AM, Gavin Sharp wrote: > On Tue, May 20, 2014 at 10:46 AM, Eli Grey wrote: > >> Gavin: The fingerprinting entropy exposed by Rik's patch is actual >> *magnitudes* less than the entropy exposed on >> http://renderingpipeline.com/webgl-extension-viewer/ >> > I didn't

Re: Intent to implement and ship: navigator.hardwareConcurrency

On Tue, May 20, 2014 at 3:26 PM, Daniel Holbert wrote: > On 05/20/2014 03:13 PM, Rik Cabanier wrote: > > On Tue, May 20, 2014 at 9:16 AM, Gavin Sharp > wrote: > >> Arguing that the incremental fingerprinting risk > >> is negligible is reasonable, but you lose credibility if you suggest > >> it do

Re: Intent to implement and ship: navigator.hardwareConcurrency

On Tue, May 20, 2014 at 6:22 AM, Joshua Cranmer 🐧 wrote: > On 5/20/2014 1:02 AM, Rik Cabanier wrote: > >> That is unlikely. The OS scheduler (I assume that will still exist), will >> take care of that problem. At the end, more work will be done which is all >> we're looking after. >> > > I'm not s

Re: Intent to implement and ship: navigator.hardwareConcurrency

On 05/20/2014 03:13 PM, Rik Cabanier wrote: > On Tue, May 20, 2014 at 9:16 AM, Gavin Sharp wrote: >> Arguing that the incremental fingerprinting risk >> is negligible is reasonable, but you lose credibility if you suggest >> it doesn't exist. > > > I don't follow. Where did I say that the finger

Re: Intent to implement and ship: navigator.hardwareConcurrency

On Tue, May 20, 2014 at 9:16 AM, Gavin Sharp wrote: > I think it might help your case to acknowledge the often significant > difference between "technically possible, but expensive and > unreliable" and "extremely simple and 100% reliable". That something > is already technically possible does no

Re: Intent to implement and ship: navigator.hardwareConcurrency

On 5/20/2014 1:58 PM, Eli Grey wrote: In practice, this is what parallel applications *currently* do as they have no other choice without this API. The OS scheduler can handle balancing the load fine to keep your system responsive, but it can't optimize your algorithm to more efficiently take adv

Re: Intent to implement and ship: navigator.hardwareConcurrency

On Tue, May 20, 2014 at 2:10 PM, Joshua Cranmer 🐧 wrote: > And it also presumes that all of the CPUs are going to be more or less > available Please clarify what you are referring to by "more or less available". "more or less" makes me think you're referring to a fractional value, such as load.

Re: Intent to implement and ship: navigator.hardwareConcurrency

On Tue, May 20, 2014 at 10:46 AM, Eli Grey wrote: > Gavin: The fingerprinting entropy exposed by Rik's patch is actual > *magnitudes* less than the entropy exposed on > http://renderingpipeline.com/webgl-extension-viewer/ > I didn't claim otherwise - personally I don't think the fingerprinting ar

Re: Intent to implement and ship: navigator.hardwareConcurrency

On 5/20/2014 12:46 PM, Eli Grey wrote: Your worker threadpool will always stay the same size, but it will have different performance characteristics throughout it's lifetime based on varying system load. This is okay. The OS scheduler balances your load with everything else. If you want constant

Re: Intent to implement and ship: navigator.hardwareConcurrency

On 2014-05-15, 4:26 AM, Rik Cabanier wrote: On Wed, May 14, 2014 at 11:39 AM, Ehsan Akhgari mailto:ehsan.akhg...@gmail.com>> wrote: On 2014-05-13, 9:01 PM, Rik Cabanier wrote: ... The problem is that the API doesn't really make it obvious that you're no

Re: Intent to implement and ship: navigator.hardwareConcurrency

Gavin: The fingerprinting entropy exposed by Rik's patch is actual *magnitudes* less than the entropy exposed on http://renderingpipeline.com/webgl-extension-viewer/ I don't need the extra less-than-a-bit of entropy from my proposal to reliably fingerprint you, as the above URL + Panopticlick is a

Re: Intent to implement and ship: navigator.hardwareConcurrency

I think it might help your case to acknowledge the often significant difference between "technically possible, but expensive and unreliable" and "extremely simple and 100% reliable". That something is already technically possible does not mean that making it easier has no consequences. Arguing that

Re: Intent to implement and ship: navigator.hardwareConcurrency

On 5/20/2014 1:02 AM, Rik Cabanier wrote: That is unlikely. The OS scheduler (I assume that will still exist), will take care of that problem. At the end, more work will be done which is all we're looking after. I'm not sure what you're trying to argue any more. When pointed out that the not

Re: Intent to implement and ship: navigator.hardwareConcurrency

2014-05-19 23:37 GMT-04:00 Rik Cabanier : > > > > On Mon, May 19, 2014 at 6:46 PM, Benoit Jacob wrote: > >> +1000! Thanks for articulating so clearly the difference between the >> Web-as-an-application-platform and other application platforms. >> > > It really surprises me that you would make this

Re: Intent to implement and ship: navigator.hardwareConcurrency

On Tue, May 20, 2014 at 12:29 AM, Jonas Sicking wrote: > On Mon, May 19, 2014 at 8:14 PM, Rik Cabanier wrote: > > On Mon, May 19, 2014 at 6:35 PM, Jonas Sicking wrote: > >> > >> On Mon, May 19, 2014 at 4:10 PM, Rik Cabanier > wrote: > >> > I don't see why the web platform is special here and w

Re: Intent to implement and ship: navigator.hardwareConcurrency

On Tue, May 20, 2014 at 12:24 AM, Jonas Sicking wrote: > On Mon, May 19, 2014 at 7:14 PM, Mike Hommey wrote: > > On Mon, May 19, 2014 at 06:35:49PM -0700, Jonas Sicking wrote: > >> On Mon, May 19, 2014 at 4:10 PM, Rik Cabanier > wrote: > >> > I don't see why the web platform is special here and

Re: Intent to implement and ship: navigator.hardwareConcurrency

On Mon, May 19, 2014 at 8:14 PM, Rik Cabanier wrote: > On Mon, May 19, 2014 at 6:35 PM, Jonas Sicking wrote: >> >> On Mon, May 19, 2014 at 4:10 PM, Rik Cabanier wrote: >> > I don't see why the web platform is special here and we should trust >> > that >> > authors can do the right thing. >> >> I

Re: Intent to implement and ship: navigator.hardwareConcurrency

On Mon, May 19, 2014 at 7:14 PM, Mike Hommey wrote: > On Mon, May 19, 2014 at 06:35:49PM -0700, Jonas Sicking wrote: >> On Mon, May 19, 2014 at 4:10 PM, Rik Cabanier wrote: >> > I don't see why the web platform is special here and we should trust that >> > authors can do the right thing. >> >> I'

Re: Intent to implement and ship: navigator.hardwareConcurrency

On Mon, May 19, 2014 at 9:32 PM, Joshua Cranmer 🐧 wrote: > On 5/19/2014 6:10 PM, Rik Cabanier wrote: > >> Other platforms offer an API to the number of CPU's and they are able to >> use it successfully. (see the ten of thousands of examples on GitHub) I >> don't see why the web platform is special

Re: Intent to implement and ship: navigator.hardwareConcurrency

On 5/19/2014 6:10 PM, Rik Cabanier wrote: Other platforms offer an API to the number of CPU's and they are able to use it successfully. (see the ten of thousands of examples on GitHub) I don't see why the web platform is special here and we should trust that authors can do the right thing. By

Re: Intent to implement and ship: navigator.hardwareConcurrency

On Mon, May 19, 2014 at 6:46 PM, Benoit Jacob wrote: > +1000! Thanks for articulating so clearly the difference between the > Web-as-an-application-platform and other application platforms. > It really surprises me that you would make this objection. WebGL certainly would *not* fall into this "We

Re: Intent to implement and ship: navigator.hardwareConcurrency

On Mon, May 19, 2014 at 6:35 PM, Jonas Sicking wrote: > On Mon, May 19, 2014 at 4:10 PM, Rik Cabanier wrote: > > I don't see why the web platform is special here and we should trust that > > authors can do the right thing. > > I'm fairly sure people have already pointed this out to you. But the

Re: Intent to implement and ship: navigator.hardwareConcurrency

On Mon, May 19, 2014 at 06:35:49PM -0700, Jonas Sicking wrote: > On Mon, May 19, 2014 at 4:10 PM, Rik Cabanier wrote: > > I don't see why the web platform is special here and we should trust that > > authors can do the right thing. > > I'm fairly sure people have already pointed this out to you.

Re: Intent to implement and ship: navigator.hardwareConcurrency

+1000! Thanks for articulating so clearly the difference between the Web-as-an-application-platform and other application platforms. Benoit 2014-05-19 21:35 GMT-04:00 Jonas Sicking : > On Mon, May 19, 2014 at 4:10 PM, Rik Cabanier wrote: > > I don't see why the web platform is special here a

Re: Intent to implement and ship: navigator.hardwareConcurrency

On Mon, May 19, 2014 at 4:10 PM, Rik Cabanier wrote: > I don't see why the web platform is special here and we should trust that > authors can do the right thing. I'm fairly sure people have already pointed this out to you. But the reason the web platform is different is that because we allow arb

Re: Intent to implement and ship: navigator.hardwareConcurrency

On Mon, May 19, 2014 at 3:27 PM, Jonas Sicking wrote: > On Mon, May 12, 2014 at 5:03 PM, Rik Cabanier wrote: > > Primary eng emails > > caban...@adobe.com, bugm...@eligrey.com > > > > *Proposal* > > http://wiki.whatwg.org/wiki/NavigatorCores > > > > *Summary* > > Expose a property on navigator c

Re: Intent to implement and ship: navigator.hardwareConcurrency

On Mon, May 12, 2014 at 5:03 PM, Rik Cabanier wrote: > Primary eng emails > caban...@adobe.com, bugm...@eligrey.com > > *Proposal* > http://wiki.whatwg.org/wiki/NavigatorCores > > *Summary* > Expose a property on navigator called hardwareConcurrency that returns the > number of logical cores on a

Re: Intent to implement and ship: navigator.hardwareConcurrency

On Sun, May 18, 2014 at 4:51 PM, Xidorn Quan wrote: > IMO, though we may have a better model in the future, it is at least not > harmful to have such attribute with some limitation. The WebKit guys think > it is not a fingerprinting when limiting the max value to 8. I think it > might be meaningf

Re: Intent to implement and ship: navigator.hardwareConcurrency

IMO, though we may have a better model in the future, it is at least not harmful to have such attribute with some limitation. The WebKit guys think it is not a fingerprinting when limiting the max value to 8. I think it might be meaningful to also limit the number to power of 2 (very few people has

Re: Intent to implement and ship: navigator.hardwareConcurrency

FYI this attribute landed in WebKit today: http://trac.webkit.org/changeset/169017 On Thu, May 15, 2014 at 1:26 AM, Rik Cabanier wrote: > > > > On Wed, May 14, 2014 at 11:39 AM, Ehsan Akhgari > wrote: > >> On 2014-05-13, 9:01 PM, Rik Cabanier wrote: >> >>> ... >>> >>> The problem is that t

Re: Intent to implement and ship: navigator.hardwareConcurrency

> > Do you think it would be feasible that the browser fires events every time > > the number of cores available for a job changes? That might allow to build > > an efficient event-based worker pool. > > I think this will be very noisy and might cause a lot of confusion. > Also I'm unsure how we c

Re: Intent to implement and ship: navigator.hardwareConcurrency

On Fri, May 16, 2014 at 11:03 AM, wrote: > Do you think it would be feasible that the browser fires events every time > the number of cores available for a job changes? That might allow to build > an efficient event-based worker pool. > I think this will be very noisy and might cause a lot of co

Re: Intent to implement and ship: navigator.hardwareConcurrency

Here's the naive worker pool implementation I was thinking about. It requires that the browser fires an event everytime a core becomes available (only in an active tab of course), and provide a property that tells whether or not a core is available at a given time: // a handler that runs when a

Re: Intent to implement and ship: navigator.hardwareConcurrency

Do you think it would be feasible that the browser fires events every time the number of cores available for a job changes? That might allow to build an efficient event-based worker pool. In the meantime, there are developers out there who are downloading micro-benchmarks on every client to str

Re: Intent to implement and ship: navigator.hardwareConcurrency

On May 15, 2014, at 1:26 AM, Rik Cabanier wrote: > On Wed, May 14, 2014 at 11:39 AM, Ehsan Akhgari > wrote: >>... >>> >>> Make it possible for authors to make a semi-informed decision on how to >>> divide the work among workers. >>> >> >> That can already be done using the timing attac

Re: Intent to implement and ship: navigator.hardwareConcurrency

On Wed, May 14, 2014 at 11:39 AM, Ehsan Akhgari wrote: > On 2014-05-13, 9:01 PM, Rik Cabanier wrote: > >> ... >> >> The problem is that the API doesn't really make it obvious that >> you're not supposed to take the value that the getter returns and >> just spawn N workers. IOW, the AP

Re: Intent to implement and ship: navigator.hardwareConcurrency

On 2014-05-13, 9:01 PM, Rik Cabanier wrote: On Tue, May 13, 2014 at 3:16 PM, Ehsan Akhgari mailto:ehsan.akhg...@gmail.com>> wrote: ... That is not the point of this attribute. It's just a hint for the author so he can tune his application accordingly.

Re: Intent to implement and ship: navigator.hardwareConcurrency

On Tue, May 13, 2014 at 3:16 PM, Ehsan Akhgari wrote: > >> ... >> >> >> That is not the point of this attribute. It's just a hint for the author >> so he can tune his application accordingly. >> Maybe the application is tuned to use fewer cores, or maybe more. It all >> depends... >> > > The probl

Re: Intent to implement and ship: navigator.hardwareConcurrency

As the main usage of this number is to maintain a fixed thread pool, I feel it might be better to have a higher level API, such as worker pool. I do agree that thread pool is very useful, but exposing the number of cores directly seems not to be the best solution. We could have a better abstractio

Re: Intent to implement and ship: navigator.hardwareConcurrency

On Tue, May 13, 2014 at 2:59 PM, Boris Zbarsky wrote: > On 5/13/14, 2:42 PM, Rik Cabanier wrote: > >> Why would that be? Are you burning more CPU resources in servo to do the >> same thing? >> > > In some cases, possibly yes. > > > If so, that sounds like a problem. >> > > It depends on what you

Re: Intent to implement and ship: navigator.hardwareConcurrency

On 2014-05-13, 2:42 PM, Rik Cabanier wrote: On Tue, May 13, 2014 at 10:43 AM, Ehsan Akhgari mailto:ehsan.akhg...@gmail.com>> wrote: On 2014-05-13, 9:25 AM, Rik Cabanier wrote: Web applications can already do this today. There's nothing stopping them

Re: Intent to implement and ship: navigator.hardwareConcurrency

On 5/13/14, 2:42 PM, Rik Cabanier wrote: Why would that be? Are you burning more CPU resources in servo to do the same thing? In some cases, possibly yes. If so, that sounds like a problem. It depends on what your goals are. Any sort of speculation, prefetch or prerender is burning more C

Re: Intent to implement and ship: navigator.hardwareConcurrency

On Tue, May 13, 2014 at 10:43 AM, Ehsan Akhgari wrote: > On 2014-05-13, 9:25 AM, Rik Cabanier wrote: > >> Web applications can already do this today. There's nothing >> stopping them >> from figuring out the CPU's and trying to use them all. >> Worse, I think they w

Re: Intent to implement and ship: navigator.hardwareConcurrency

On 2014-05-13, 11:14 AM, Eli Grey wrote: On Tue, May 13, 2014 at 1:57 PM, Ehsan Akhgari mailto:ehsan.akhg...@gmail.com>> wrote: No, you're wrong. An available core is a core which your application can use to run computations on. If another code is already keeping it busy with a hig

Re: Intent to implement and ship: navigator.hardwareConcurrency

Just wish to throw in my 2c... Many game engines will query the core count to determine if they should follow a simple (one main thread, one render thread, one audio thread, one streamer thread) or more parallel (multiple render threads, multiple audio threads, gameplay/physics/ai broken up in

Re: Intent to implement and ship: navigator.hardwareConcurrency

On Tue, May 13, 2014 at 1:57 PM, Ehsan Akhgari wrote: > No, you're wrong. An available core is a core which your application can > use to run computations on. If another code is already keeping it busy > with a higher priority, it's unavailable by definition. > Run this code

Re: Intent to implement and ship: navigator.hardwareConcurrency

Also note that even some popular desktop APIs that in practice expose the "hardware" thread count, choose not to call it that way. For example, Qt calls it the "ideal" thread count. http://qt-project.org/doc/qt-4.8/qthread.html#idealThreadCount IMO this suggests that we're not the only ones feel

Re: Intent to implement and ship: navigator.hardwareConcurrency

On Tue, May 13, 2014 at 1:43 PM, Ehsan Akhgari wrote: > supporting a worker pool that actually scales to how many cores you have > available 1) What is an "available core" to you? An available core to me is a core that I can use to compute. A core under load (even 100% load) is still a core I ca

Re: Intent to implement and ship: navigator.hardwareConcurrency

On 5/13/2014 12:35 PM, Eli Grey wrote: Can you back that up with a real-world example desktop application that behaves as such? The OpenMP framework? -- Joshua Cranmer Thunderbird and DXR developer Source code archæologist ___ dev-platform mailing l

Re: Intent to implement and ship: navigator.hardwareConcurrency

On 2014-05-13, 10:54 AM, Eli Grey wrote: On Tue, May 13, 2014 at 1:43 PM, Ehsan Akhgari wrote: supporting a worker pool that actually scales to how many cores you have available 1) What is an "available core" to you? An available core to me is a core that I can use to compute. A core under l

Re: Intent to implement and ship: navigator.hardwareConcurrency

On 2014-05-13, 10:44 AM, Rik Cabanier wrote: On Tue, May 13, 2014 at 9:55 AM, Tom Schuster mailto:t...@schuster.me>> wrote: I recently saw this bug about implementing navigator.getFeature, wouldn't it make sense for this to be like hardware.memory, but hardware.cores? Is this a

Re: Intent to implement and ship: navigator.hardwareConcurrency

On 2014-05-13, 10:35 AM, Eli Grey wrote: On Tue, May 13, 2014 at 11:20 AM, Ehsan Akhgari wrote: Can you please provide some examples of actual web applications that do this, and what they're exactly trying to do with the number once they estimate one? (Eli's timing attack demos don't count. ;-

Re: Intent to implement and ship: navigator.hardwareConcurrency

On Tue, May 13, 2014 at 9:55 AM, Tom Schuster wrote: > I recently saw this bug about implementing navigator.getFeature, wouldn't > it make sense for this to be like hardware.memory, but hardware.cores? > Is this a feature that is adopted across browsers? Interesting that Firefox exposes this. W

Re: Intent to implement and ship: navigator.hardwareConcurrency

On 2014-05-13, 9:55 AM, Tom Schuster wrote: I recently saw this bug about implementing navigator.getFeature, wouldn't it make sense for this to be like hardware.memory, but hardware.cores? No, because that would have all of the same issues as the current API. Cheers, Ehsan ___

Re: Intent to implement and ship: navigator.hardwareConcurrency

On 2014-05-13, 9:25 AM, Rik Cabanier wrote: Web applications can already do this today. There's nothing stopping them from figuring out the CPU's and trying to use them all. Worse, I think they will likely optimize for popular platforms which either

Re: Intent to implement and ship: navigator.hardwareConcurrency

On Tue, May 13, 2014 at 11:20 AM, Ehsan Akhgari wrote: > Can you please provide some examples of actual web applications that do > this, and what they're exactly trying to do with the number once they > estimate one? (Eli's timing attack demos don't count. ;-) One example of a website in the wil

Re: Intent to implement and ship: navigator.hardwareConcurrency

I recently saw this bug about implementing navigator.getFeature, wouldn't it make sense for this to be like hardware.memory, but hardware.cores? On Tue, May 13, 2014 at 6:25 PM, Rik Cabanier wrote: > On Tue, May 13, 2014 at 8:20 AM, Ehsan Akhgari >wrote: > > > On Tue, May 13, 2014 at 2:37 AM,

Re: Intent to implement and ship: navigator.hardwareConcurrency

On Tue, May 13, 2014 at 8:20 AM, Ehsan Akhgari wrote: > On Tue, May 13, 2014 at 2:37 AM, Rik Cabanier wrote: > >> On Mon, May 12, 2014 at 10:15 PM, Joshua Cranmer 🐧 > >wrote: >> >> > On 5/12/2014 7:03 PM, Rik Cabanier wrote: >> > >> >> *Concerns* >> >> >> >> The original proposal required that a

Re: Intent to implement and ship: navigator.hardwareConcurrency

On Tue, May 13, 2014 at 2:37 AM, Rik Cabanier wrote: > On Mon, May 12, 2014 at 10:15 PM, Joshua Cranmer 🐧 >wrote: > > > On 5/12/2014 7:03 PM, Rik Cabanier wrote: > > > >> *Concerns* > >> > >> The original proposal required that a platform must return the exact > >> number > >> of logical CPU cor

Re: Intent to implement and ship: navigator.hardwareConcurrency

On Mon, May 12, 2014 at 10:15 PM, Joshua Cranmer 🐧 wrote: > On 5/12/2014 7:03 PM, Rik Cabanier wrote: > >> *Concerns* >> >> The original proposal required that a platform must return the exact >> number >> of logical CPU cores. To mitigate the fingerprinting concern, the proposal >> was updated so

Re: Intent to implement and ship: navigator.hardwareConcurrency

On Mon, May 12, 2014 at 10:15 PM, Joshua Cranmer 🐧 wrote: > On 5/12/2014 7:03 PM, Rik Cabanier wrote: > >> *Concerns* >> >> The original proposal required that a platform must return the exact >> number >> of logical CPU cores. To mitigate the fingerprinting concern, the proposal >> was updated so

Re: Intent to implement and ship: navigator.hardwareConcurrency

On 5/12/2014 7:03 PM, Rik Cabanier wrote: *Concerns* The original proposal required that a platform must return the exact number of logical CPU cores. To mitigate the fingerprinting concern, the proposal was updated so a user agent can "lie" about this. In the case of WebKit, it will return a max

Intent to implement and ship: navigator.hardwareConcurrency

Primary eng emails caban...@adobe.com, bugm...@eligrey.com *Proposal* http://wiki.whatwg.org/wiki/NavigatorCores *Summary* Expose a property on navigator called hardwareConcurrency that returns the number of logical cores on a machine. *Motivation* All native platforms expose this property, It's