News for hackers. Stuff that matters.
Re:Intel Discontinues the Intel Developer Forum; IDF17 Cance... by bsder on Monday April 17, 2017 @04:21PM (#14134068)
Power goes as C v^2 f. At best. That doesn't change.

If you look at a particular technology node, one of the best correlations of power consumption is chip area. It's pretty much a straight line.

Now, that has probably changed a bit with how aggressively we turn chip areas off nowadays. So, we probably have to alter that to power consumption vs active chip area--but it's still a fixed line for a technology node.

Re:Intel Discontinues the Intel Developer Forum; IDF17 Cance... by rbanffy on Monday April 17, 2017 @06:16PM (#14134902)
Speaking of chip area, one possible path is designing ISAs that require less silicon to efficiently decode, reorder and retire.

It'd be, of course, totally incompatible with what we have now.

Re:Intel Discontinues the Intel Developer Forum; IDF17 Cance... by bsder on Monday April 17, 2017 @06:20PM (#14134933)
We call that MIPS or Alpha, and it lost to x86 compatibility.

Whose only competitor is ARM, which is little better in terms of decoding complexity.

Re:Intel Discontinues the Intel Developer Forum; IDF17 Cance... by wolfgke on Monday April 17, 2017 @08:12PM (#14135533)
> Whose only competitor is ARM, which is little better in terms of decoding complexity.

T32 indeed has this problem, but not A32. With ARMv8 ARM released the A64 instruction set, which is designed new from ground up and is to my knowledge also not hard to decode. Nevertheless decoding complexity is not that relevant anymore. What is much harder and involves more die area is (super-)pipelining the execution, out-of-order execution etc. But even all this together: What consumes most die area are typically the caches.

Re:Intel Discontinues the Intel Developer Forum; IDF17 Cance... by rbanffy on Tuesday April 18, 2017 @03:45AM (#14137099)
Caches are transistor-dense, it's hard to optimize them further. Maybe something like Transmeta's architecture, a hybrid software/hardware approach would yield some improvement.