4 ms·

That is usually a strong crackpot indicator.

by thomasz 12y ago

peterfirefly 12y ago
It might not work as well as they hope for but there is nothing crackpottery about the Mill so far. Or, to put it differently, there might be crackpottery in some of the things they haven't revealed yet. Who knows. (Naturally, this says nothing about whether it will ever actually be built or whether any actual silicon will actually run fast -- there are so many other reasons besides the purely architectural reasons why it might not. Chips are hard.) A concrete example of something the Mill does better (at least on paper and in a simulator): it does spills and reloads of values differently, in a way that doesn't go through the data caches. The same mechanism also handles local values in many cases. If they don't pollute the data caches, you can get by with smaller and/or higher-latency caches and still get the same (or higher) performance. The loads that are still there on the Mill are those that really have to be there (and are there in the compiler's intermediate representation, before register allocation). There are also some innovations in the instruction encoding: they can put immediates inline in the instructions, like on the x86 and other Old Skool CISC architectures. They can even do that for quite large immediates. That's better than having to spend several instructions "building" the constants or having to load them at runtime from a table, as the RISC architectures do. They do this with a very regular encoding while keeping the encoding very tight (and variable-width). The way they pack many operations into each instruction means that even if the instructions are byte-aligned, the individual operations don't have to be. If the operations only need 7 bits for their encodings, then that's what you get. (The bit length is fixed per "slot" in the encoding so it's not as variable -- and slow -- as it sounds.) Instruction decoding and execution is pipelined: the first part of the instruction is decoded first and starts executing while the rest of the instruction gets decoded. This ties in with the way call/return/branch is handled so the last part of the instruction effectively overlaps its execution with decoding and execution of the first part of the instruction at the new site. This works for loops as well so the end of the loop executes overlapped with the start of the loop and so that the prolog/epilog overlaps with the body. You can think of it as a very strong form of branch delay slots -- or as branch delay slots on acid. This is combined with an innovation that allows vectorized loops with very cheap prologs/epilogs so you can opportunistically vectorize practically all your loops. If a loop only executes twice (or thereabouts) you break even.

That is usually a strong crackpot indicator.

by thomasz 12y ago

That is usually a strong crackpot indicator.

It might not work as well as they hope for but there is nothing crackpottery about the Mill so far. Or, to put it differently, there might be crackpottery in some of the things they haven't revealed yet. Who knows. (Naturally, this says nothing about whether it will ever actually be built or whether any actual silicon will actually run fast -- there are so many other reasons besides the purely architectural reasons why it might not. Chips are hard.) A concrete example of something the Mill does better (at least on paper and in a simulator): it does spills and reloads of values differently, in a way that doesn't go through the data caches. The same mechanism also handles local values in many cases. If they don't pollute the data caches, you can get by with smaller and/or higher-latency caches and still get the same (or higher) performance. The loads that are still there on the Mill are those that really have to be there (and are there in the compiler's intermediate representation, before register allocation). There are also some innovations in the instruction encoding: they can put immediates inline in the instructions, like on the x86 and other Old Skool CISC architectures. They can even do that for quite large immediates. That's better than having to spend several instructions "building" the constants or having to load them at runtime from a table, as the RISC architectures do. They do this with a very regular encoding while keeping the encoding very tight (and variable-width). The way they pack many operations into each instruction means that even if the instructions are byte-aligned, the individual operations don't have to be. If the operations only need 7 bits for their encodings, then that's what you get. (The bit length is fixed per "slot" in the encoding so it's not as variable -- and slow -- as it sounds.) Instruction decoding and execution is pipelined: the first part of the instruction is decoded first and starts executing while the rest of the instruction gets decoded. This ties in with the way call/return/branch is handled so the last part of the instruction effectively overlaps its execution with decoding and execution of the first part of the instruction at the new site. This works for loops as well so the end of the loop executes overlapped with the start of the loop and so that the prolog/epilog overlaps with the body. You can think of it as a very strong form of branch delay slots -- or as branch delay slots on acid. This is combined with an innovation that allows vectorized loops with very cheap prologs/epilogs so you can opportunistically vectorize practically all your loops. If a loop only executes twice (or thereabouts) you break even.