As someone who harassed you about VP8 support in the past [0], this is really great news. Thank you for all of your hard work. I am also really happy to see the transition to Unified Plan.
2,803 karma · joined July 22, 2012
[1] https://www.itwire.com/it-people-news/enterprise/50649-the-t...
This has a built-in failure mode caused by the fact that the student is optimizing the objective function, "Reduce the potential for public embarrassment," and not the one the teacher wants, which is, "Learn the vocabulary." At some point, the student decides that the safer path is actively refusing to study and refusing to be embarrassed by this choice. No one knows if they could really learn the material or not (probably not even them), and they maintain self-respect by having the balls to stand up to someone they do not like (especially pre-university, where attendance is legally mandatory and you have little to no influence over your assigned teachers).
I have seen this play out with several obviously bright people (to counter your anecdote with another anecdote). It is particularly sad because it fails expressly for those struggling the most with formal education.
The company later was able to hire more managers and take the load off of him (and in fact he went back to being an IC eventually). But these things happen in periods of rapid growth, despite everyone knowing they're a bad idea.
Perhaps I am overreacting, but that sort of attitude on matters core to basic privacy in the post-Snowden era seems both problematic and incurable.
Mozilla has a CheckedInt (C++) type that checks all operations for overflow. You can see examples of how this is actually implemented here: <https://searchfox.org/mozilla-central/source/mfbt/CheckedInt.... You can derive similar C implementations if you work through all of the template magic.
Be warned that the definition of what is undefined, implementation-specific, and well-defined varies depending on the exact version of the C or C++ standard you use.
It also means that you don't need to pass around (a pointer to) a big table of function pointers throughout all of your functions that need to use accelerated routines. Instead you just pass a single integer index. But that is pretty minor.
It can be pretty similar to a switch in practice, but I think there are a few differences. One is function argument handling. Each version of an accelerated routine has to be an independent function, compiled in a separate compilation unit, because you have to limit the instruction sets available. So you will duplicate all of the function call setup overhead in each branch of the switch. This probably gets optimized away by a decent compiler. Even if it does, you still wind up essentially duplicating the function table at every call site. That does not seem likely to get optimized away. You could dispatch to a common thunk which selects the accelerated routine to call, but now you have two function calls instead of one. I am also not sure that switch statements handle the default case as cheaply as doing a single bitwise AND with a small, compile-time constant.
But if you have a use of function pointers that can be replaced by a simple switch statement, that is probably the better approach.
For example, in libopus we have platform-specific SIMD optimizations that are chosen at runtime.
The common solution is just to have a function pointer that points to the accelerated routine. But there are only a limited number of choices for each routine. So we put pointers to them in a static const array, which gets stored on a read-only page. Then instead of storing a pointer, we just store an index into this array. This index is chosen based on the available instruction sets detected at runtime. This lets us use the same index for every accelerated function.
Then, we pad the array size out to a power of two. To call an accelerated function, we mask off the upper bits of the index. Even if the index gets corrupted, we still call one of the functions in the array. So there's only so much damage it can do.
Obviously this doesn't apply if the set of functions you need to call is open-ended (e.g., a callback, like nginx was using). But it seems like a good pattern to follow when it applies.
The simplest, most conservative form is Bonferroni correction [1], where you just divide the required significance threshold by the number of tests you perform. In your example, if you required significance at the 99% level (1% chance a false positive, or "Type I error"), then for 100 datasets, each individual one would require significance at the 99.99% level (0.01% false positives for each data set). (99.99%)^100 = 99.005%. This does not require any assumptions about the independence of the tests. Independent tests are the worst case, so this over-corrects if there is actual correlation between the measurements.
There are other, more complicated correction methods that do not give up as much statistical power (i.e., produce fewer false negatives), but that may require making more assumptions.
But then I found <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50168>.
> I did not say that, nor do I believe it, nor is it really related.
Not even Stallman believes this [0]. He has even explicitly endorsed the use of a "lax license" when pragmatic concerns justify it [1].
[0] http://openbsd-archive.7691.n7.nabble.com/Real-men-don-t-att...
But yeah, the real reason is that MSVC will never implement VLAs.
> We'll get to them eventually.. but why shouldn't we go after the biggest business first? Wouldn't that provide the greatest reduction in harm?
There's actually a name for laws that target one individual while ignoring others guilty of the same behavior, and that's a "bill of attainder" [0]. They're banned by the US Constitution and also every state constitution, which might give you some idea that there are pretty good reasons "why not" (namely, that they're ripe for abuse, they violate someone's right to due process, and can be used by the legislature to take on judicial or executive functions, violating the separation of powers).
The GDPR is a hugely pro-Google law. Large corporations can easily afford to wade through its complexity to find ways to comply that do not have a meaningful impact on profits, up to and including getting the law changed, if necessary, ideally by making it more complex.
Their smaller competitors can't.
One thing that we have noticed in our work on our Rust AV1 encoder, rav1e, is that Rust autovectorizes a lot better than C. In particular, it does a better job of proving that slices have nice sizes (e.g., multiples of 8 or 16 elements). That allows it to leave off all of the boilerplate for handling odd sizes. Rust also does not automatically promote every arithmetic operation to an int. That makes working on 8- or 16-bit types a lot more efficient. The stronger type system, memory safety, and the preference for idioms that avoid bounds checks mean the compiler can successfully autovectorize a lot more code than C, too. We used to joke that the only C code that gets autovectorized is the initialization loops that run exactly once and just set everything to zero.
It's still not as good as hand-written SIMD (maybe within a factor of 2), but it's a lot better than no SIMD.
That said, it makes it hard to do straightforward performance comparisons with C, especially for code where you know you will write the hand-written SIMD, but you just haven't gotten to it yet. There is a lot of code like this in a freshly-implemented video encoder. Rust is using a tool, autovectorization, that it won't get to use when you manually vectorize, and C isn't. That threw off a lot of our early attempts at benchmarking Rust vs. C.
Of course, most things are not video encoders, and most code won't be manually vectorized, so the better autovectorization is an absolute win in the real world.
For example, it does adaptive entropy coding instead of explicitly coding probabilities in the header. That means that you don't need to choose between making multiple passes over the frame (one to count symbol occurrences and one to write the bitstream using R-D optimal probabilities) or encoding with sub-optimal probabilities (which can have an overhead upwards of 5% of the bitrate). libaom has always been based on a multi-pass design, as was libvpx before it, but rav1e only needs a single pass per frame (we may add multiple passes for non-realtime use cases later).
In another example, AV1 has explicit dependencies between frames. VP9 maintained multiple banks of probabilities which could be used as a starting point for a new frame. But any frame was allowed to modify any bank. So if you lost a frame, you had no idea if it modified the bank of probabilities used by the next frame. In AV1, probabilities (and all other inter-frame state) propagate via reference frames. So you're guaranteed that if you have all of your references, you can decode a frame correctly. This is important if you want to make a low-latency interactive application that never shows a broken frame.
Some of its tools also become more effective in low-complexity settings. One of the new loop filters, CDEF, gives somewhere around a 2% bitrate savings using objective metrics when tested with libaom running at its highest complexity (although subjective testing suggests the actual improvement is larger). However, when you turn down the complexity, the improvement from CDEF goes up to close to 8%. I.e., using this filter helps you to take shortcuts elsewhere in the encoder.
The real reason the reference encoder is so slow is that it searches a lot of things. You can always make things run faster by searching less. Take a look at http://obe.tv/about-us/obe-blog/item/54-a-look-at-the-bbc-uh... to see how drastically people are limiting HEVC to make it run in real time today (though if you have to go up to 35 Mbps to do so, one might wonder what the point is).
< barrbrain> atomnuker: I felt good when my patch was done and I had exactly what I set out to write.
< barrbrain> I didn't enjoy the compiler forcing me to fix all my bugs upfront.
There are also advantages other than safety to using a modern systems language that has learned something from the last 30 years of programming language design but doesn't come with all of the baggage of C++.
Currently just for the transforms and to initialize the probabilities for the entropy coder.
I think you missed the part where, "during the 1990s such costs rose substantially." To give further evidence, from 2006 to 2012 the number of patent troll lawsuits increased by a factor of six [3]. But, "the US economy has seen neither a dramatic acceleration in the rate of technological progress nor a major increase in the levels of research and development expenditure." So the answer is no, all of this litigation is not encouraging R&D spending (for some reason).
> That incorrectly assumes that the only "contribution" is producing an end-user product.
Perhaps I wasn't clear. I'm not saying that ARM doesn't contribute value. I'm saying that a system that allows the separation of "design from production" also allows patent trolls, and you have to trade the benefits of one against the costs of the other. For the benefit of your one ARM example we pay the cost of 2,900 lawsuits by trolls in the year 2012 alone [3], making up 61% of all patent cases [4] (I wish I had more recent numbers).
> If standards don't embody important technical contributions, then why don't implementers rush to create alternative, unpatented standards?
You mean like <https://aomedia.org/>? They do, but I think that there are a few reasons that this doesn't happen more often:
(a) Avoiding patent thickets once they have already been created is incredibly hard work. Much harder than just developing the technology, in my opinion.
(b) It is even harder to collaborate without incurring substantial legal liability. But no such collaboration is required to create the thickets.
(c) Standards organizations often have policies which make it difficult or impossible to achieve these results, and many participants have strong incentives to prevent you from achieving them.
(d) Even if you make something "better", it is not "the standard". Displacing entrenched incumbents is incredibly hard (again, because of the network effects).
The places where you will see this happen is where there are business models that cannot support any per-unit royalty (e.g., giving away your software for free on the internet), because that provides strong incentives to make it happen.
Laptops and routers are not such an industry. They can just pass on the cost to consumers, who are not represented when these standards are set. This is the basic public goods problem.
Again quoting the article: "Notice, too, that many patent lawsuits have a public goods aspect. Consider a case in which the plaintiff is asserting that its patent has been infringed. If the plaintiff wins the lawsuit, by confirming its monopoly position it appropriates all the benefits of winning the lawsuit. A victory by the defendant, by contrast, benefits partly itself, but also other firms that might be sued by the plaintiff for patent infringement as well as consumers who would have a more competitive market. Thus, the defendant receives only a slice of the overall benefits from winning the lawsuit, and will be willing to spend less on such lawsuits than it would if it were to receive all the benefits." The parallel with getting your patent-encumbered technology into a standard vs. some other firm trying to keep it out is exactly equivalent. The correct play is for the other firm to just file their own patents, but this tragedy-of-the-commons result isn't exactly ideal.
[3] https://www.wsj.com/articles/SB10001424127887323469804578525...
[4] https://money.cnn.com/2013/07/02/technology/enterprise/paten...
People will certainly use patent protection where it is available to them, but that doesn't mean they wouldn't have invested in those technologies solely on the basis of first mover advantage [0], and the lack of any observed effect of strengthening the patent system and increasing the scope of what is patentable on R&D spending tends to back that up.
[0] ARM would need a different business model, but it's unclear to me that other business models (i.e., Intel's) wouldn't have been just as successful, and wouldn't come with the social deadweight loss of patent trolls highlighted in the article.
1) "In less than 30 years, the flow of patents more than quadrupled. By contrast, neither innovation nor research and development expenditure nor factor productivity have exhibited any particular upward trend." In other words, more patents does not appear to encourage people to splurge on fundamental research in aggregate.
But it gets worse, "The cost of litigating patents is not insubstantial either. Bessen and Meurer (2008) used stock market event studies to estimate the cost of patent litigation: they estimate that during the 1990s such costs rose substantially until, at the end of the period, they constituted nearly 14 percent of total research and development costs." So at least we've identified where some of the money being brought in from all of these monopolies is going (it isn't to the scientists and engineers).
2) It also enables business models that allow taking money from people without contributing anything at all. "On the other hand if a patentholder does not produce a marketable product and hence cannot be countersued---like Microsoft in the phone market or other patent trolls in other markets---then patents become a mechanism for sharing the profits without doing the work. In this scenario, not only do patents discourage innovation, but they are also a pure waste from a social standpoint."
3) "The downstream blocking effect of existing monopoly grants on incentives for future innovation has greatly increased in recent decades because modern products are made up of so many different components. The recent---and largely successful---efforts of Microsoft to impose a licensing fee on the large and expanding Android phone market is but one case in point. ... Microsoft is attempting to charge a licensing fee solely over a patent involving the scheduling of meetings---a rarely used feature of modern smartphones. ... Hence, the main dynamic general equilibrium effect of a patent system is to subject future inventions to a gigantic hold-up problem: with many licenses to be purchased and uncertainty about the ultimate value of the new innovation, each patent holder, in raising the price of his "component," imposes an externality on other patent holders and so charges a higher than efficient licensing fee." The externality isn't just on patent holders. Later, quoting Bill Gates: "A future start-up with no patents of its own will be forced to pay whatever price the giants choose to impose."
Having participated in these kinds of technology sharing efforts, I can assure you that the value extracted is basically unrelated to the actual value of the innovation, and mostly defined by the (current or expected) network effects of the technology in question and the political clout of its proponents in convincing other people to require its use. I.e., you're not paying for an invention, you're paying for a standard, and making standards is not something that requires external incentives.
As for monetization: "At the opposite extreme we have, again among many, the example of the Cornish steam engine discussed in Nuvolari (2004, 2006). Here engineers exchanged nonpatented ideas for decades in a collaborative effort to improve efficiency." I don't think they monetized it via advertising.
[1] https://papers.ssrn.com/sol3/papers.cfm?abstract_id=1354849
[2] https://en.wikipedia.org/wiki/Wright_brothers_patent_war
So the Philips Curve posits that there is a relationship between the degree of slack in the labor market and inflation, and it is an empirical relationship that, while not absolutely tight, has been a consistent relationship over time, and I believe that relationship still holds.
https://www.c-span.org/video/?406675-1/federal-reserve-chair...
> there's considerable support for the idea that an inverse relationship between unemployment and inflation exists at least in the short run
Would you care to cite some? I'm certainly familiar with the post-70's forms of Phillips Curve theory (it's discussed in the very Wikipedia article I linked). But I also cited a 2017 paper from the Philadelphia Fed that looked very hard for such a relationship and couldn't find one, and which itself cites prior research going back to 2001 that agrees.
12:29 pm
The Philips Curve is alive, [Federal Reserve Chair Janet] Yellen says.