Neural network spotted deep inside Samsung's Galaxy S7 silicon brain

Either it's doing a read or it's doing a write, there is no option to use the bus unused. So the 6502 spams dummy reads and occasionally dummy writes whenever it's doing something internally.

Edit: And that's not the only interesting thing I've learned recently about the 6502, There is a very good reason why the stack is on page 1 and not some other constant page. There are only 3 constant values which can be pushed on the SB/ADH buses, 0xff, 0x00 and 0x01.

Ox00 is loaded into upper address register for zero page instructions. For Push operations, it loads 0x01 into the upper address register and puts the stack pointer + 0xff into the adder, which subtracts one from the stack pointer. (The 0xff is just the default bus value, if nothing else is pulling it low, so you get it for free)

For Pop operations, it pushes the same 0x01 into both the upper address register and the adder, at the same time.

So if they wanted to put the stack page at another constant page, or at a variable page they would also need to provide more gates to provide another constant one somewhere.

> The perceptrons are trained by an algorithm that increments a weight when the branch outcome agrees with the weight’s correlation and decrements the weight otherwise.

A "perceptron" seems to be a single linear function, akin to a single neuron in a neural network. So complex learning algorithms like back-propagation don't apply here.

The complete process, from the paper, is:

> 1. The branch address is hashed to produce an index "i" into the table of perceptrons.

> 2. The "i"th perceptron is loaded from the table into a vector register "P" of weights.

> 3. The value of "y" is computed as the dot product of "P" and the global history register. [This is a shift register containing values of -1 or 1 for the last N branches seen. -1 means not taken, and 1 means taken.]

> 4. The branch is predicted "not taken" when "y" is negative, or "taken" otherwise.

> 5. Once the actual outcome of the branch becomes known, the training algorithm uses this outcome and the value of "y" to update the weights in "P".

> 6. "P" is written back to the "i"th entry in the table.

The article says that AMD's microarchitecture uses a hashed perceptron system in its branch prediction. So, from the above, it seems that "hashed" means that you hash the branch address to pick which perceptron (model) to use, and "perceptron" is just a dot product. (Actually the wikipedia article[2] suggests that the name "perceptron" refers to the training algorithm, i.e. how you update the weights.)

[1]: Daniel A. Jiménez and Calvin Lin. 2002. Neural Methods for Dynamic Branch Prediction. https://www.cs.utexas.edu/~lin/papers/tocs02.pdf

[2]: https://en.wikipedia.org/wiki/Perceptron

The test is a valid observation, but is irrelevant to this article, or to the technology.

Why measure something that doesn't show up in a standard user's test? Here are some examples: lower power usage, lower latency of small operations (rather than throughput of large actions), smaller design (saving chip space), etc. And finally - if this is a good technology, Apple can use it too and get even faster.

Bringing up user experience when talking about branch predictors is meaningless. Just as bringing up branch predictors when talking about perceived performance. (unless you're proving that this exact feature being available/not available, with other things being controlled for, makes a major difference in the test)

If you are specifically comparing two specific phones against each other then yes this is the only sort of test that matters, and if you are comparing manufacture's flagship models then that is what you are doing.

From every other point of view, either comparing performance of individual components or comparing like-for-like performance of devices with very similar spec it is less valid though: the screen resolution is a huge variable for a game so it isn't a "fair" test to compare performance of two devices like that. You could equally state that the higher resolution produces a better result because of the resolution difference and you would similarly be called to task by for not comparing like for like. Maybe the a device with the same hardware other than the better screen would outperform the iDevice on the test, or at least not appear to underperform by as much, this test can't tell us that.

This is difficult of course because few phone models are practically identical and few vary by just one factor, and can make a developers life more difficult when trying to support a varied market like Android based devices.

Better understanding individual components lets engineers build better overall systems. Millions of choices and decisions go into something like a phone, most of which can't have their result easily measured by just looking at the end result. But if enough of them are good, you end up with the iPhone.

If enough of them are bad, you end up with mass recalls, and a class action lawsuit because your phones catch fire when charged overnight because your engineers didn't think to test that specific use case, didn't test their capacitors, didn't test their QA process, didn't unit test their battery management code, or otherwise failed to indulge their "fetish" (read: job.)

Proper hardware tests might be pointless to end users, but that doesn't make them pointless.

Because Android is usually developed by at least two companies: Google does generics and OEM which is responsible that Android runs smoothly on their hardware. Sure, given enough time and resources, you could do optimization for every hardware combination possible, but that is not how things work in real world, especially where release cycles are such insane as in smartphones market.

Now the original iphone was probably 80% Samsung design and manufacturing, but these days the design part is closer to 0%.