derf_

Basically every DSP uses two's complement, and pretty much everything else besides, and has for decades. Most things that give different results based on the representation of negative numbers are merely implementation-defined, anyway. Signed overflow is undefined for a different reason.

  for (i = 0; i < n; i++) {
    foo();
  }

In general I agree with your point, though. If those kinds of optimizations don't matter to you, you shouldn't be using C. If you want the option for your loops to run (4,294,967,296 + n) times in C, use unsigned arithmetic. Its overflow behavior is well-defined.

On the contrary, the slowdown of Moore's Law means the future has never been brighter for open hardware. Someone could actually design something for a process that hasn't been obsolete for over two years and still have a hope of getting it manufactured before it becomes that way.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1109475

Slide 20 lists no less than 8 toolchain bugs found with a codebase of less than 50k lines of C code (no C++), using only thoroughly trodden language features, without "massive functions" or anything else. Admittedly 4 of those bugs were in pre-release versions of gcc, but the rest weren't.

1. Your job application probably has language that discourage women from applying [1].

2. Men tend to apply for jobs even though they don't meet all of the qualifications, whereas women tend not to [2].

So there's bias introduced before you even see the list of applicants, and given no other information, it would not be that surprising to find a randomly selected woman from that candidate pool would be more qualified than a randomly selected man.

[1] http://www.huffingtonpost.com/2015/06/02/textio-unitive-bias...

[2] http://www.theatlantic.com/magazine/archive/2014/05/the-conf...

Something like > 90% (number hazy based on vague recollection) of images produced results that had gross, glaring errors that would be unacceptable to a human. Errors like, "We added a horizon line where there wasn't one in the actual image," etc. But a few images produced compellingly plausible results.

It's still very interesting stuff, and some of his later work on using this as an additional prior for more normal structure-from-motion pipelines looked pretty promising. In the form reported in this paper it wasn't something ready to be productized. Although it's also completely possible that I just screwed something up.

The output needs a bit of manual review (see the mixing of 32-bit and 16-bit accesses to the same register in the second example), but it was definitely able to find something non-obvious in a sequence far too long for exhaustive search.

https://arewecompressedyet.com/?r[]=master-2016-01-01-082473...

Select "Entire curve (old method)" to see BD-rate numbers (the new method requires data overlap in all three bitrate ranges in order to work, which the old curve does not have).

On desktop, at least, you can fix this by making your browser window wider (just resize the window: you'll find a threshold past which the hierarchy appears or disappears).

That doesn't help much for mobile, where you can't really resize windows.

This misses one more optimization: if you consume bits by shifting them off the end of your word, then you are shifting in zeros in their place. If your semantics are that all reads past the end of the buffer return zeros, then once you have hit that end, you can just set bitcount to LOTS_OF_BITS (an arbitrarily large constant).

That is, you pretend your 32-bit word has a lot more than 32 bits in it. Then you're extremely unlikely to ever hit the refill code again. For extra points, you can make the constant something that can easily be represented as an ARM immediate, like 0x40000000.

We do this in the bitreaders for Theora, Opus, and Daala (thanks to Simon Hosie for contributing the idea to Theora back in the day).

So, I had all kinds of lucky things.

-Warren Buffett, 4 Oct. 2011 [1]

Certainly Michael Burry had enormous luck. But there were plenty of others with the same amount of luck who did not see the crisis coming or who did nothing about it.

[1] http://fortune.com/2011/10/04/warren-buffett-at-fortunes-mos...

See https://news.ycombinator.com/item?id=10410676 for previous discussion.

http://www.economicsjunkie.com/inflation-deflation-revisited... has some good explanations of why.

There's also what you measure: consumer prices do not reflect increases in asset prices, and the latter have grown very quickly in the past few years (as credit has recovered).

Everyone wins with this approach. Sure, those lazy bums didn't consider cases X, Y, and Z, but then no one else had solved the problem regardless of whether or not they handled X, Y, or Z. That's how A, B, and C's results got published!

You're building on their work. You look better for acknowledging it rather than trying to knock down those who came before. They are likely to be respected quite a bit better than you are. Also, researchers A, B, and C are the most likely candidates to be reviewing your paper. So there's that.

This is, of course, orthogonal to the issue of unreproducible experimental results.

In a binary-heap ("Eytzinger") layout, the next node to consider is at either index (2i + 1) or (2i + 2). That means you can perfectly predict the next cache line to load. This continues to be true up to four iterations in advance (assuming proper alignment, for 4-byte data with 64-byte cache lines, holding 16 values each). Speculative execution will begin these loads early, regardless of whether the branch prediction is ultimately successful. A branch-free algorithm can do the same with explicit prefetch instructions to avoid the pipeline stalls of mis-prediction. However, in each cache line, you only look at one value (1/16th of the data transferred).

You can attempt to pack the data for several iterations into a single cache line to increase utilization. However, because a complete binary tree has 2^n - 1 values (i.e., because it is odd), there are some small inefficiencies. For example, four iterations of a binary search require (1 + 2 + 4 + 8) = 15 possible values, of which you will look at four (1/4 of the data transferred, given the same 16-element cache line size). But either you include an extra element and thus sometimes need 5 comparisons instead of 4 (B-tree algorithm), or you mis-align the subtrees with cache line boundaries (van Emde Boas algorithm), or you waste space by only putting 15 values in a cache line (not tested). And you can't issue the load for the next cache line until the current subtree search completes.

Even though the latter approaches have up to four times better utilization of the data they load, as long as the bandwidth-delay product is at least 4 cache lines (i.e., you can issue 4 requests in parallel without slowing any of them down), the Eytzinger approach will win. They measured the bandwidth-delay product at 4.7 on their machine, and overall algorithm comparisons seem to be consistent across over 100 different CPUs.

If the data fits in L2 cache (2^16 values), a branchless prefetching algorithm on a simple sorted array is still slightly faster than using the Eytzinger ordering, just because of constant factors. The difference is small (15%ish on average, estimating from the plots).

Some broken CPUs (Phenom II, Celeron J1900, E3-1230) seem to cause large slowdowns when prefetching invalid addresses. Masking the address fixes the problem with no measurable performance impact on non-broken CPUs.

After two failed attempts, I left the station and caught a taxi.

I am not saying Paris does not have a very good train system compared to many places, but it seems to me it would not be so easy to expect it to handle all of the people who currently drive.

It is enough to get access to potentially sensitive partner information (as can be seen from the posted screenshot), but those are usually a different class of bugs from security bugs.

Further, we now classify security bugs by the area of the code they affect, and give engineers access to just the areas for which they are responsible, rather than blanket access to all security bugs. This is a process that began even before the recent attacks, but we have been pushing it more aggressively in their wake.

I often go back, edit the code to add something like

  if (condition) {
     foo = foo;
  }

You may also be interested in https://hacks.mozilla.org/2013/02/defending-opus/ (warning: contains discussion of specific, unexpired patents).

One of the things that made Opus a success was the contributions of others. We certainly don't have a monopoly on good ideas. We'll take pieces of Daala and stick them in Thor and pieces of Thor and stick them in Daala, and figure out what works best. Some of that experimentation has already begun:

https://github.com/cisco/thor/pull/8

https://review.xiph.org/874/

https://www.ietf.org/proceedings/93/slides/slides-93-netvc-5...

Because none of us have a financial incentive to get our patents into the standard, we're happy to pick whatever technology works best, as long as we end up with a great codec at the end. Hopefully NETVC can replicate the success of Opus this way.

Berkshire is composed of pre-existing businesses that were themselves successful before being purchased. They are not experimental ventures that need to be subsidized. It is exactly the opposite: money is plowed into the strongest businesses. They each generate excess cash, and it is easier to reinvest that cash in some places than others. The conglomerate structure makes it possible to put the cash where it gets the best returns without having to pay taxes or transaction fees.

Alphabet has none of these properties, except the ability to allocate capital tax-free, but they already had that as Google.

So much for no lawsuits.

Charts of 2007-2015 Q1: https://www.bea.gov/newsreleases/international/intinv/intinv...

More detailed data back to 1976: https://www.bea.gov/international/bp_web/tb_download_type_mo...

In short, the U.S. is now $7 trillion in the hole (39% of GDP), and most of that damage has been done in the past 5 years. In 2007 that hole was just $1.35 trillion. In 2014 alone the U.S. position worsened by $1.7 trillion.

-$1.2 trillion of this was due to exchange rates: other countries are running their printing presses faster than the U.S. is, so it is losing the competitive currency debasement race kicked off in 2008. This is not news, but it makes this number worse because it causes U.S. assets held by foreigners to appreciate faster relative to foreign assets held by U.S. citizens.

Price changes contributed another -$0.35 trillion. That is, even in local currencies, U.S. investments made by foreigners had a better return than foreign investments held by U.S. citizens.

Then all the way down at -$0.24 trillion was "net financial transactions", or the trade deficit, which is the thing Buffett's IC proposal would actually be able to control.

In other words, unless I have misunderstood something, balancing the trade deficit, or even running a substantial surplus is not going to solve these problems at the rate they are going. The question is how much of the current trends are sustainable.