I am not that person, but I can probably explain anyway.
The whole point of the web is to be a common runtime. You can use it from any browser and any device. You avoid the situation where you prefer browser X because it has some feature that is critical to you, but you have to use browser Y for some web sites. (So in the end, you'll use browser Y for all sites so that your user agent can actually be your agent by eg remembering your history/passwords. Or worse, you will be forced to use multiple browsers due to multiple incompatible websites.) You also avoid the situation where a new hardware platform or browser engine can never be released because there's no way to make it compatible with the current web.
In short, if a "web site" does not work in a strictly standards-compliant browser, then it's not part of the Web. It may be linked to from the web, and it may almost be part of the web, but it's really something else hanging off of it.
There are many such things. Flash apps are a common type. Heck, PDFs are too and until recently all videos were. There's nothing inherently wrong with them existing, as long as they aren't claiming to be part of the Web.
In this case, it may only be a QA shortcoming with respect to a 0.7% market share device. Inbox is not so benign, since the compatibility delay is a pretty strong indicator of corporate priority and policy.
And that's the danger, and the probable reason for the downvote. If you accept non-web things on the web, only thinking of the convenience and added functionality you gain (because your particular user agent is fine with it and makes it appear to be part of the web), then lockin will gradually set in, standards will lose their meaning, browser makers will start having to implement each other's half-baked experimental features that don't interoperate with everything else, cats and dogs will start living together, and there will be no reason not to gain the extra 10% in performance and functionality you get from a native app because your web sites don't run universally anymore anyway. So developers get to start maintaining half a dozen separate code bases because we've pissed away our opportunity to make a single codebase work everywhere. The blasé acceptance of that possibility is what earns downvotes.
The movement in this direction is already well under way on the mobile web, so I'm not just dreaming up imaginary hypothetical scaremongering.
Fitting to a statistical model superficially makes sense. But I think the details kill it.
The outcome you are measuring is the change in test score from before having a teacher and after. VAM attempts to statistically estimate the teacher's contribution to that change.
Presumably, the test is of something that theoretically the students will not know beforehand. Which means the teachers don't want students who study on their own (or participate in activities where that knowledge might be useful). And they don't want students who aren't going to learn it -- whoops, that was a leap, I meant to say who aren't going to test higher at the end. So you don't really want the top tier nor bottom tier coming into your class.
Nonspecific to VAM, but a result of standardized test results being used for anything meaningful to the teacher (salary, tenure, etc.) is that anything not on the test has an opportunity cost, and so will be omitted in favor of test prep. The more statistical validity that VAM has, the stronger this effect will be. If the teacher shows the students how to incorporate their new knowledge into a broader perspective, it may make the school's scores improve but it will screw over the next teacher in line (because the before test will be higher). So there's some peer pressure to make sure the students learn nothing that they're "supposed" to learn later.
If you consider a subject like math, what happens is that at some point many students fall behind. This makes the later topics much, much harder, because they build on what they never quite understood. A perfect teacher would figure out what balance of old and new material to give each individual student. That perfect teacher would score poorly on VAM compared to a teacher who crammed in test-specific mechanics and regurgitation, relying on dismal beginning test scores to make poor but not awful ending test scores look good. The system would gradually optimize for squeezing incremental gains out of improperly taught students.
And don't forget that the outcome is what's measured, and what's measured is crap. In football, you can look at a score (or just who won). Here, the structure is tuned to produce students who can do well on year-end tests but nothing else, certainly not on their ability to apply their knowledge to situations not likely to show up on a test.
Ok, this became more of a rant against standardized testing, but it just bothers me that adding statistical power magnifies the problems. You'd be better off throwing in a large random component, so that teachers' innate desires to teach well have a chance at winning out over gaming the system. Because even if your population of teachers is really conscientious, you're actively selecting for those most willing to play the game. And selection always wins in the end.
I think this is pretty common. In fact, this can happen even if neither browser changes at all. Your profile builds up and your history searches etc. slow down, so you switch browsers and get a clean profile to start with. Repeat. (I'm not saying that that is what you are experiencing, but I think it's a factor for every browser user.)
I don't want my bookmarking completely separated from browsers, but I would like it to sync to shared browser-portable cloud storage. I'd also like the distinction between tabs, bookmarks, and history to go away and be replaced by some categories that are more relevant to me.
I agree. IE kicked everyone else's butt first (in terms of market share), and the Web stagnated. Then Firefox kicked IE's butt, and the Web didn't stagnate quite as much, but let's be honest -- it stagnated. At the moment, Chrome is dominant but no browser is really trampling its competition, especially not in terms of overall quality. And the Web is improving faster than it ever has. (Well, not quite -- the "catch up" phases of the browser wars probably saw faster improvement while they were happening.)
Don't look at asm.js benchmarks if you're interested in real-world JS. Look at them if you want to know something about the performance of C++ code transpiled to run in a browser, which is an interesting thing to know. And it's getting to be more and more relevant these days. (Even "real-world JS" is going to start using asm.js libraries, I bet.)
But asm.js execution is very different from JS execution, even in browsers that don't have specialized asm.js paths. Executing regular JS is all about balancing compile time and garbage collection with code execution. asm.js barely uses GC, and allows lots of opportunities to cache compilation in ways that would be invalid for regular JS. So the whole space of tradeoffs is different.
I agree. If you accept the reasonable premise that incremental GC trades worse throughput for better latency, then splay-latency rewards low throughput.
That isn't as awful as it sounds, it's just that there's nothing in the benchmark that tells the JS engine that penalizing throughput is the right thing to do. It needs some kind of marker that we can agree means "even though it's the wrong thing to do given just the code that you're seeing, pretend like this is running in an environment where you should prioritize throughput below latency between these semi-arbitrary points." We are discussing perhaps treating Date.now or window.performance.now as meaning that, because if you're measuring the jitter between things, you'll be grabbing the current time at exactly those points where you're mimicking ending one turn and starting the next. But that's still not really correct, because you're also asserting that there would be zero idle time in between turns, which is generally not true in a real application.
The main difference from what is shown in those slides is that V8 uses a semispace collector. The SpiderMonkey collector just has a single nursery.
Jon Coppeard implemented a semispace collector for SpiderMonkey, but the added complexity made it a net loss in performance. So we scrapped it for now. It means we get a few objects unfairly tenured, but our measurements showed the actual number was pretty low and not worth the overhead.
It's totally workload dependent, and further GGC tuning (there's a lot to go!) may reverse that balance.
It has some impact on overall execution time (throughput), mostly through being able to bump allocate. The benchmark I used in the article shows a large gain, though the real-world effect is much less.
But GGC is mostly about reducing pause times (latency). (And yes, people have taken to calling that "jank". I still resist the term when I can, since it's no more precise than anything that came before but people seem to think it must mean something specific.)
[SpiderMonkey dev here. I remember the talk you gave at Mozilla, quite a good talk. I work on the GC much more than the compiler, which I don't know that much about, but I'm only going to talk about the compiler. Ironic, given that you were talking about the GC.]
What's your actual goal here? You gave an example of a pathological function that takes a long time to compile. Does that matter?
We care a lot about compilation time. It matters a lot for Web workloads, and distinguishes JS compilers from AOT compilers. But why do you care, especially in this particular case? Do you have "real" code that is hitting the same bottlenecks? Because if not, you have two easy solutions to this case: first, leave everything as is. In a production system, you can be doing this sort of compile in the background, and only switch over to it from the fast-start interpreter when it's done. The second straightforward option is to just give up. Fail to compile if things get too big or slow, and let it run in the interpreter (or some other lower tier.)
If this does resemble a realistic scenario, then we can get a little more nuanced. We face the same problem in SpiderMonkey -- big functions can take too long to compile and/or will blow out memory (which, honestly, is the bigger concern. More on that later.) In JaegerMonkey days, we had "chunked" compilation, where it artificially broke big functions down into pieces and compiled them separately, essentially spilling all state between them. I know we've talked about doing the same for IonMonkey; I'm not sure if it has been implemented. In particular, asm.js hits this a lot because autogenerated functions can easily get enormous. Luke has definitely talked a lot about chunking asm.js compilation; I don't know if he ever got around to implementing it yet. [You remember Luke; you sat behind him for a while in the Mountain View office.]
Or how about doing it at a finer granularity? We have a number of places where we start out trying to do the smart and clever thing, but when things gett out of hand we abort and fall back on something stupid but fast and small. Here, that might mean being very pessimistic about your live ranges and pessimistically chopping them up into small pieces. Could you keep your 2d matrix, but cap its dimensions? You only track up to K variables at a time, and if you exceed K you spill one and reuse its slot for the new one. Obviously, your phi nodes (join points) would need to agree on a set of variables, so maybe this gets too complicated or just doesn't work.
But anyway, I'm still wondering what you're after. You have a research compiler. There is no need for it to be better than a production compiler in all ways. Pick something it is better at, such as producing really fast code. The learnings from that will be more likely to be useful in a production system anyway, because all current leading JS compilers are multi-tier -- you have a fast-start interpreter, usually a still pretty quick-start baseline compiler, and then an optimizing compiler. The distribution of static code across those is something like 90%/9%/1% anyway -- the majority of downloaded code is executed at most once anyway, so there's no point in spending time optimizing it. But that means the optimizing compiler is free to spend some time thinking about things. If your compiler is really slow, just claim it's meant for a 4th tier that only kicks in for really hot code. :) And it can compile in the background.
Unless it burns too much memory. That won't stay isolated from the execution thread. It'll pollute caches, hog the memory bus, and make fun of your mother. So I'd worry more about capping memory usage to a reasonable level than worrying about compile time, even if it means giving up or dropping down to a dumber algorithm when things start to get big.
One other effect of being a later tier is that you can stick to compiling simpler programs. By the time it makes it to your tier, you'll have observed the actual types and behavior of the function for a while, and so you can assume that it'll continue to behave the same way. This allows you to ignore many of the numerous quirks of the JS language. You don't need to handle getters if your hot code never sees them (or rather, you only have to handle them in the parts that do see them.) The global object probably won't get mutated, and almost certainly won't have properties deleted. You will need mechanisms to discard your compiled program if any of these things change, and you'll have to be clever about noticing these sorts of mutations, but it's great to be able to assume that nothing too crazy will happen. Even if you have to guard all those assumptions.
The GC does matter for both time and space, though. An advantage of a generational collector isn't just shorter pauses, it's also that you can use simple bump allocation in the nursery since you never need to do partial deletes. Also, if you're creating a lot of short-lived junk then it can reduce your peak memory usage by quite a bit, which is important for a 3rd or 4th tier background compiler.
Reading the comments here suggests that it would be cool to use both of the chips together. If it is true that spiking does well with unsupervised learning, then you could feed a bunch of input to a spiker, then scan it for components that could be mostly mimicked with a convolutional chip and reroute the inputs/outputs. (Yeah, the interconnect would suck.) The point is not to come up with some magic better-performing hybrid, but rather to explore an intermediate point in the design space of augmenting/replacing actual neurons with silicon. The IBM chip isn't that close to biology, but it's closer than a convolutional network, and a convolutional network is a much smaller step than a general purpose processor. We might learn about some simple augmentations that are likely to work in practice.
Also, the whole "airplanes don't flap their wings" analogy can be taken too far. Little flying things are qualitatively different from big flying things. You'll notice that a lot of small artificial flying things are flapping, and the biggest natural fliers tend to glide a lot. There are other reasons why nature didn't evolve large fliers. (Although I'm willing to believe some large fliers may occasionally have hot gases shooting out of their back ends, I do not believe propulsion is their purpose.)
Use a decent language like JavaScript. You are correct that terrible JavaScript is available and widely used, but all of the platforms support both, so you may as well use decent JavaScript instead. :-)
What's the use of an uncategorized bookmark? I always drag the url into a bookmark folder in the toolbar (which I always have open; apparently come people hate that.) For uncategorized stuff, well, I guess that's why I have 300+ tabs open right now...
And Tree Style Tabs. Cannot live anymore without TST. That really ought to be in the core. Especially since it's sometimes a little buggy, though that may be because FF is changing underneath it.
Oddly, I'm on Nightly, and the star button is to the right of my url bar. I don't remember moving it back there, and I don't know why I would, since I never use it.
The whole point of the web is to be a common runtime. You can use it from any browser and any device. You avoid the situation where you prefer browser X because it has some feature that is critical to you, but you have to use browser Y for some web sites. (So in the end, you'll use browser Y for all sites so that your user agent can actually be your agent by eg remembering your history/passwords. Or worse, you will be forced to use multiple browsers due to multiple incompatible websites.) You also avoid the situation where a new hardware platform or browser engine can never be released because there's no way to make it compatible with the current web.
In short, if a "web site" does not work in a strictly standards-compliant browser, then it's not part of the Web. It may be linked to from the web, and it may almost be part of the web, but it's really something else hanging off of it.
There are many such things. Flash apps are a common type. Heck, PDFs are too and until recently all videos were. There's nothing inherently wrong with them existing, as long as they aren't claiming to be part of the Web.
In this case, it may only be a QA shortcoming with respect to a 0.7% market share device. Inbox is not so benign, since the compatibility delay is a pretty strong indicator of corporate priority and policy.
And that's the danger, and the probable reason for the downvote. If you accept non-web things on the web, only thinking of the convenience and added functionality you gain (because your particular user agent is fine with it and makes it appear to be part of the web), then lockin will gradually set in, standards will lose their meaning, browser makers will start having to implement each other's half-baked experimental features that don't interoperate with everything else, cats and dogs will start living together, and there will be no reason not to gain the extra 10% in performance and functionality you get from a native app because your web sites don't run universally anymore anyway. So developers get to start maintaining half a dozen separate code bases because we've pissed away our opportunity to make a single codebase work everywhere. The blasé acceptance of that possibility is what earns downvotes.
The movement in this direction is already well under way on the mobile web, so I'm not just dreaming up imaginary hypothetical scaremongering.
(disclaimer: I am a Firefox platform developer)