> Compare recomputing something, where you never have to leave L1 cache,
Only if the data that the result depends on fits in that cache...
For example, Gecko saw a noticeably performance increase from caching the intrinsic preferred and min width for CSS blocks. Yes, it increased the memory use per block by 8 bytes. But recomputing not only used the CPU a good bit but also depended on the values of dozens of CSS properties for all descendants of the block.. which had to be read from memory.
Also, caching can sometimes change the algorithmic complexity of a problem (e.g. compare computing Fibonacci numbers via recursion with and without memoization of the results).
Buy yes, there are some limited cases where recomputing is better than caching; cases when there's a 1-1 dependency between the data you already have and the data you'd like to have are probably in this category.
> I would be quite horrified if it actually performed better on Windows
I wouldn't: if you're using plug-ins their memory usage counts as part of the browser's memory usage in a test like this (until the plug-ins start running in separate processes), and Flash on Linux leaks a lot more than Flash on Windows last I measured. I've found that browsing with the Flash plug-in disabled significantly cuts down on CPU and memory usage on Mac too.
> On Linux, you can get something pretty close by summing all the rw sections of >/proc/self/maps and then counting the r sections once
You just double-counted the shared-memory segments chrome uses for IPC, assuming you plan to sum the results over all the chrome processes involved, no? I can assure you they're rw.
The other issue with this model is that it also forces every tax filer to spend time filling out those extra two pages of tax forms and sending in the letter documenting that they were insured...
So even apart from the direct measurable costs there are productivity costs. I know it took me about a working day or two back in March to actually hunt down the relevant letters from my insurance providers. Yes, they're supposed to send it to you. No, it doesn't necessarily work out that way.
> I just can't understand why they wouldn't have done this years ago
Because it in fact is not as trivial as you make it sound. I suggest readinghttp://groups.google.com/group/mozilla.dev.apps.firefox/msg/c95940f969f07942 as a minimum, and ideally some of the other discussion of MSIs for Firefox that has happened over the years...
> nor does it remove the absolute necessity of proper testing
Oh, sure. Testing is needed to make sure people actually try to implement the spec. But testing can't ensure they actually do, so it too is not a panacea. You need both: unambiguous specs and test suites with reasonable coverage. Then you can with certainty say that the precise things being tested were in fact implemented per spec.
> you do not in fact have to generate all possible combinations of CSS or all possible CSS > documents to show that these tests will pass
Actually, you do, for black-box testing. If you happen to know something about the precise implementation details you might be able to limit the scope of testing, but if you're a standards test suite author, you have no way to know what the implementations will do.
A simple example: an implementation may have different codepaths for values of CSS property A (say "position") that affect how CSS property B (say "border-color") is handled. This isn't a hypothetical case but a pretty concrete example I pulled from a browser's bug database. Existing UAs have had just such differences, due to applying certain layout/rendering optimizations for some values of properties but not others. So sadly, you cannot test things in isolation and deduce that they will continue to work when used together, because different codepaths are used for those cases...
So a minimal testsuite for CSS2.1 conformance testing would include one test per possible set of values of all CSS properties for a given node... That would not catch issues involving containing blocks or whatnot, of course.
> The DOM Events module would like to have a word with you.
That's mostly harmed by the fact that some UAs aren't making any attempt to implement it at all. But yes, interoperability on DOM Events is much worse than it should be for the UAs that do implement it; point granted.
Interestingly, Acid3 didn't seriously test DOM Events....
> 100% support should only be a goal for those standards one claims to support.
In that case, claiming to support standards should be a non-goal. The goal should be implementing, correctly, functionality that's useful.
> finish what you start before moving on to the next shiny object.
> human language inherently introduces ambiguities that will plague standards specs until > the end of time
Specs are more heavily relying on algorithmic definitions of behavior, precisely for this reason.
> Certainly you can.
I don't think you understand.... fully testing all possible combinations of CSS2.1 features is likely to result in a total size of tests that exceeds currently available global storage capacity. It's not just a matter of "effort"; it's actually a matter of fundamental physical resource limits.
> anything that is deemed to matter
Then you're not actually testing the whole thing. You're testing some subset of it... and what matters will change over time. This way lies madness.
> The most important being HTML, CSS, ECMAScript, and the DOM
There is no "the DOM". There are 1-2 dozen different DOM specs; again, some are more important than others. Interoperability on the important ones is pretty good, forcing Acid3 to focus on the unimportant ones.
> No, it's not the case. Quite an easy statement to make, when you don't have to back > anything up.
Sure it is. By design, Acid3 does no testing of most of CSS3 Selectors. On the other hand, it tests some aspects of handling of invalid UTF-16 input (unpaired surrogates), tests some edge-cases of DOM Traversal involving the iterator throwing an exception, and tests DOM Range operations on children of a document. I can assure you that by the "anything that is deemed to matter" metric the CSS3 Selectors stuff is more important.
> what makes XBL more important than, say, CSS?
Sorry, straw man. Nowhere did I make this claim (which I happen to think is false).
> Acid3 tests real-world problems that prominent developers have been complaining about > for years
I have yet to see a single prominent developer complain about handling of unpaired UTF-16 surrogates. Got a reference? Or did you just buy the hype about what it's testing instead of actually... reading the test?
> Better still would be to make test suites that actually cover the whole standard.
Like I said above, physically impossible. You can do test suites that test features in isolation, and test some "common" combinations, but for a standard the size of CSS2.1 (or SVG of any version, or HTML of any version) testing all possible inputs is not doable.
> Acid3 -testing the parts that people care about
If that were what Acid3 were testing, I'd care a lot more about Acid3...
> If you don't pass the tests, you do not support the standard. Period.
Sure. And I don't think support for some standards should be a primary goal, even if those happen to be the ones with overhyped tests for them. In fact, I don't think 100% support for any standard should automatically be the _primary_ goal. It should depend on exactly what that 100% support entails. If the standard is just dumb (which often they are), then getting errata to happen may be a better primary goal.
> Did you hear that? Because my head just fucking exploded.
Their claim might technically be true if you include the still-to-be-reviewed tests that were recently submitted. The IE team recently contributed several thousand tests to the test suite; presumably they do pass them.
> This is why Web platforms of the future will not be based on specifications, but > on the test suites.
Actually, no. This is why people are much more careful about not writing ambiguous specifications now.
You can't "test suite" your way to full coverage of something like CSS 2.1: too many features, too many combinations, too many things to test.
> If Mozilla wants to be seen as taking standards seriously again
Which standards? Some standards are more important than others. It might just be that stuff the acid test is not testing is more important than stuff it should be... (and is in fact the case with parts of acid3).
It might also be that supporting the standard and not supporting it at all are both better options than supporting just the part that the test tests.
So no, 100% test-compliance should never be the primary goal. Support for the standards that are useful to support should be.
> To my knowledge, Linux does not consistently ship with any multimedia framework > common to all (or even most) distributions.
That's correct. At the same time, browsers want to be able to deliver video capabilities on Linux. Therefore they end up having to ship their own code to do so. Once you do that, you have less security bug exposure if you just use the same code on all platforms, since otherwise you're on the hook for not only issues in your code (which you have to ship anyway) but also any issues that might exist in the platform-provided video codecs on on whatever platforms you use them on....
The 10 year timeframe is for going to REC. Which means there are two complete interoperable implementations.
Unlike previous W3C standards, this time they're not going to publish as final it until they have evidence that it can actually be implemented, and by more than one development team. That's been a major issue with CSS2, for example: the long time CSS2.1 has been taking has been largely about fixing things that were underdefined, contradictory, or just wrong (in the sense of not making any sense) in CSS2 and that were discovered when people went to actually implement the spec.
That's a container format, not a codec. Which codec are we talking, specifically?
> Should be decodable on Linux via ffmpeg
Which isn't included by default with Linux distributions, last I checked. Which means you can't actually rely on it being there, have to ship ffmpeg yourself, and then might as well use it on all your platforms...
Which is basically what Gecko does with OGG Theora, say. They just ship liboggplay and use it on all platforms.
> But Mozilla could pay the decoder cap fee (maxes out a $5M/year next year) and allow > as many people to download a H.264-enabled Firefox as they want, no?
Yes, but then it would not be open source anymore. That is, you could download it, but not redistribute it. And you couldn't, say, ship a browser called IceWeasel that does exactly what Firefox does without paying your own licensing fees. Mozilla is not willing to do that.
Note the grandparent was very specific in talking about open-source browsers, not free (as in beer) browsers.
> His argument was that if the OS supports decoding the video format, which it will > if it's a modern consumer OS
Sadly, that assumption happens to be false. Especially if under "consumer OS" you include the sort of OS running on cell phones, Nokia's N810, etc (which are definitely platforms that browsers are targeting with video). But even if we just look at Window/Mac/Linux, it's hard to find a single video codec that makes sense on the web that all three support out of the box...
> why should every browser then implement its own media stack to provide a service that > the OS already provides
Excellent question! It shouldn't if the OS actually provides it. I think we'd all prefer it if the OS did, of course; we're just not there yet.
Name one codec that is suitable for video on the web and is actually implemented on all the platforms a browser other than Win/IE wants to support nowadays?
And if you can't, what's the point of claiming to have "video" support if there isn't actually a video one can put up that your browser will play for all its users?
Having video fully participate in the rendering pipeline (unlike the Flash situation) lets you usefully include video (we're not talking "ads" or necessarily "main content video" a la Youtube, but video that is part of a web app or a web-based game, or that the web page wants to annotate) in your web page without screwing up other parts of it...
I'm not sure what that has to do with what I said. Original claim was "now we will see what happens in an unbiased market". I said that it might look no different than what we have now, in some countries...
Actually, the #1 bottleneck to compiling Firefox in particular on Windows is performance of the OS process and file access APIs... In the case of PGO, the #2 bottleneck is the huge amount of memory the linker ends up touching.
64-bit might help with the latter, maybe. Maybe not.... Have to push more bits around.
Slashdot Mirror
> Compare recomputing something, where you never have to leave L1 cache,
Only if the data that the result depends on fits in that cache...
For example, Gecko saw a noticeably performance increase from caching the intrinsic preferred and min width for CSS blocks. Yes, it increased the memory use per block by 8 bytes. But recomputing not only used the CPU a good bit but also depended on the values of dozens of CSS properties for all descendants of the block.. which had to be read from memory.
Also, caching can sometimes change the algorithmic complexity of a problem (e.g. compare computing Fibonacci numbers via recursion with and without memoization of the results).
Buy yes, there are some limited cases where recomputing is better than caching; cases when there's a 1-1 dependency between the data you already have and the data you'd like to have are probably in this category.
> I would be quite horrified if it actually performed better on Windows
I wouldn't: if you're using plug-ins their memory usage counts as part of the browser's memory usage in a test like this (until the plug-ins start running in separate processes), and Flash on Linux leaks a lot more than Flash on Windows last I measured. I've found that browsing with the Flash plug-in disabled significantly cuts down on CPU and memory usage on Mac too.
> On Linux, you can get something pretty close by summing all the rw sections of /proc/self/maps and then counting the r sections once
>
You just double-counted the shared-memory segments chrome uses for IPC, assuming you plan to sum the results over all the chrome processes involved, no? I can assure you they're rw.
Firefox certainly does: both the size of the HTTP memory cache and the size of the back-forward history cache depend on the amount of RAM installed.
The other issue with this model is that it also forces every tax filer to spend time filling out those extra two pages of tax forms and sending in the letter documenting that they were insured...
So even apart from the direct measurable costs there are productivity costs. I know it took me about a working day or two back in March to actually hunt down the relevant letters from my insurance providers. Yes, they're supposed to send it to you. No, it doesn't necessarily work out that way.
> I just can't understand why they wouldn't have done this years ago
Because it in fact is not as trivial as you make it sound. I suggest readinghttp://groups.google.com/group/mozilla.dev.apps.firefox/msg/c95940f969f07942 as a minimum, and ideally some of the other discussion of MSIs for Firefox that has happened over the years...
> nor does it remove the absolute necessity of proper testing
Oh, sure. Testing is needed to make sure people actually try to implement the spec. But testing can't ensure they actually do, so it too is not a panacea. You need both: unambiguous specs and test suites with reasonable coverage. Then you can with certainty say that the precise things being tested were in fact implemented per spec.
> you do not in fact have to generate all possible combinations of CSS or all possible CSS
> documents to show that these tests will pass
Actually, you do, for black-box testing. If you happen to know something about the precise implementation details you might be able to limit the scope of testing, but if you're a standards test suite author, you have no way to know what the implementations will do.
A simple example: an implementation may have different codepaths for values of CSS property A (say "position") that affect how CSS property B (say "border-color") is handled. This isn't a hypothetical case but a pretty concrete example I pulled from a browser's bug database. Existing UAs have had just such differences, due to applying certain layout/rendering optimizations for some values of properties but not others. So sadly, you cannot test things in isolation and deduce that they will continue to work when used together, because different codepaths are used for those cases...
So a minimal testsuite for CSS2.1 conformance testing would include one test per possible set of values of all CSS properties for a given node... That would not catch issues involving containing blocks or whatnot, of course.
> The DOM Events module would like to have a word with you.
That's mostly harmed by the fact that some UAs aren't making any attempt to implement it at all. But yes, interoperability on DOM Events is much worse than it should be for the UAs that do implement it; point granted.
Interestingly, Acid3 didn't seriously test DOM Events....
> 100% support should only be a goal for those standards one claims to support.
In that case, claiming to support standards should be a non-goal. The goal should be implementing, correctly, functionality that's useful.
> finish what you start before moving on to the next shiny object.
I suggest reading http://www.jwz.org/doc/worse-is-better.html
> human language inherently introduces ambiguities that will plague standards specs until
> the end of time
Specs are more heavily relying on algorithmic definitions of behavior, precisely for this reason.
> Certainly you can.
I don't think you understand.... fully testing all possible combinations of CSS2.1 features is likely to result in a total size of tests that exceeds currently available global storage capacity. It's not just a matter of "effort"; it's actually a matter of fundamental physical resource limits.
> anything that is deemed to matter
Then you're not actually testing the whole thing. You're testing some subset of it... and what matters will change over time. This way lies madness.
> The most important being HTML, CSS, ECMAScript, and the DOM
There is no "the DOM". There are 1-2 dozen different DOM specs; again, some are more important than others. Interoperability on the important ones is pretty good, forcing Acid3 to focus on the unimportant ones.
> No, it's not the case. Quite an easy statement to make, when you don't have to back
> anything up.
Sure it is. By design, Acid3 does no testing of most of CSS3 Selectors. On the other hand, it tests some aspects of handling of invalid UTF-16 input (unpaired surrogates), tests some edge-cases of DOM Traversal involving the iterator throwing an exception, and tests DOM Range operations on children of a document. I can assure you that by the "anything that is deemed to matter" metric the CSS3 Selectors stuff is more important.
> what makes XBL more important than, say, CSS?
Sorry, straw man. Nowhere did I make this claim (which I happen to think is false).
> Acid3 tests real-world problems that prominent developers have been complaining about
> for years
I have yet to see a single prominent developer complain about handling of unpaired UTF-16 surrogates. Got a reference? Or did you just buy the hype about what it's testing instead of actually... reading the test?
> Better still would be to make test suites that actually cover the whole standard.
Like I said above, physically impossible. You can do test suites that test features in isolation, and test some "common" combinations, but for a standard the size of CSS2.1 (or SVG of any version, or HTML of any version) testing all possible inputs is not doable.
> Acid3 -testing the parts that people care about
If that were what Acid3 were testing, I'd care a lot more about Acid3...
> If you don't pass the tests, you do not support the standard. Period.
Sure. And I don't think support for some standards should be a primary goal, even if those happen to be the ones with overhyped tests for them. In fact, I don't think 100% support for any standard should automatically be the _primary_ goal. It should depend on exactly what that 100% support entails. If the standard is just dumb (which often they are), then getting errata to happen may be a better primary goal.
> Did you hear that? Because my head just fucking exploded.
Their claim might technically be true if you include the still-to-be-reviewed tests that were recently submitted. The IE team recently contributed several thousand tests to the test suite; presumably they do pass them.
Oh, and testing the SMIL-enabled builds is not as good as use of my time as you probably think. ;)
I think you're preaching to the choir here. As far as helping out, I am in fact running nightlies, for obvious reasons. Have to eat my own dogfood...
> This is why Web platforms of the future will not be based on specifications, but
> on the test suites.
Actually, no. This is why people are much more careful about not writing ambiguous specifications now.
You can't "test suite" your way to full coverage of something like CSS 2.1: too many features, too many combinations, too many things to test.
> If Mozilla wants to be seen as taking standards seriously again
Which standards? Some standards are more important than others. It might just be that stuff the acid test is not testing is more important than stuff it should be... (and is in fact the case with parts of acid3).
It might also be that supporting the standard and not supporting it at all are both better options than supporting just the part that the test tests.
So no, 100% test-compliance should never be the primary goal. Support for the standards that are useful to support should be.
Yep, that sounds about right as far as the security aspects go.
> To my knowledge, Linux does not consistently ship with any multimedia framework
> common to all (or even most) distributions.
That's correct. At the same time, browsers want to be able to deliver video capabilities on Linux. Therefore they end up having to ship their own code to do so. Once you do that, you have less security bug exposure if you just use the same code on all platforms, since otherwise you're on the hook for not only issues in your code (which you have to ship anyway) but also any issues that might exist in the platform-provided video codecs on on whatever platforms you use them on....
> Even if HTML 5 were rigourously defined and backed up by proper compliance testing
For what it's worth, that's one of the most important goals of HTML5.
> how long it will take for browsers to properly support it
That 10 year number in the article is actually more or less the current estimate from people like the spec editor for HTML5.
The 10 year timeframe is for going to REC. Which means there are two complete interoperable implementations.
Unlike previous W3C standards, this time they're not going to publish as final it until they have evidence that it can actually be implemented, and by more than one development team. That's been a major issue with CSS2, for example: the long time CSS2.1 has been taking has been largely about fixing things that were underdefined, contradictory, or just wrong (in the sense of not making any sense) in CSS2 and that were discovered when people went to actually implement the spec.
> MPEG (.mpg, .mpeg) has been around for eons
That's a container format, not a codec. Which codec are we talking, specifically?
> Should be decodable on Linux via ffmpeg
Which isn't included by default with Linux distributions, last I checked. Which means you can't actually rely on it being there, have to ship ffmpeg yourself, and then might as well use it on all your platforms...
Which is basically what Gecko does with OGG Theora, say. They just ship liboggplay and use it on all platforms.
> But Mozilla could pay the decoder cap fee (maxes out a $5M/year next year) and allow
> as many people to download a H.264-enabled Firefox as they want, no?
Yes, but then it would not be open source anymore. That is, you could download it, but not redistribute it. And you couldn't, say, ship a browser called IceWeasel that does exactly what Firefox does without paying your own licensing fees. Mozilla is not willing to do that.
Note the grandparent was very specific in talking about open-source browsers, not free (as in beer) browsers.
> His argument was that if the OS supports decoding the video format, which it will
> if it's a modern consumer OS
Sadly, that assumption happens to be false. Especially if under "consumer OS" you include the sort of OS running on cell phones, Nokia's N810, etc (which are definitely platforms that browsers are targeting with video). But even if we just look at Window/Mac/Linux, it's hard to find a single video codec that makes sense on the web that all three support out of the box...
> why should every browser then implement its own media stack to provide a service that
> the OS already provides
Excellent question! It shouldn't if the OS actually provides it. I think we'd all prefer it if the OS did, of course; we're just not there yet.
Name one codec that is suitable for video on the web and is actually implemented on all the platforms a browser other than Win/IE wants to support nowadays?
And if you can't, what's the point of claiming to have "video" support if there isn't actually a video one can put up that your browser will play for all its users?
If your image of video is "Youtube", then you're right. But the other approach lets you do things like these:
http://people.mozilla.com/~prouget/demos/green/green.xhtml
http://people.mozilla.com/~prouget/demos/DynamicContentInjection/play.xhtml
http://people.mozilla.com/~prouget/demos/mashup/video.xhtml
http://people.mozilla.com/~prouget/demos/round/index.xhtml
Having video fully participate in the rendering pipeline (unlike the Flash situation) lets you usefully include video (we're not talking "ads" or necessarily "main content video" a la Youtube, but video that is part of a web app or a web-based game, or that the web page wants to annotate) in your web page without screwing up other parts of it...
I'm not sure what that has to do with what I said. Original claim was "now we will see what happens in an unbiased market". I said that it might look no different than what we have now, in some countries...
Note that in some European countries IE already has minority marketshare, biased market or no....
Actually, the #1 bottleneck to compiling Firefox in particular on Windows is performance of the OS process and file access APIs... In the case of PGO, the #2 bottleneck is the huge amount of memory the linker ends up touching.
64-bit might help with the latter, maybe. Maybe not.... Have to push more bits around.
Oh, for home users totally agreed. ;)
I don't have a 64-bit windows setup, sadly...