3 ms·

Both mechagodzilla and TheOtherHobbes have pretty much covered my response. The only thing I wanted to add was that you're acting incredibly defensive to essent

by kevinnk 11y ago

Both mechagodzilla and TheOtherHobbes have pretty much covered my response. The only thing I wanted to add was that you're acting incredibly defensive to essentially a request for context. The 9:1 speedup you quoted doesn't exist in a vacuum (and repeating the phrase "general purpose code" doesn't fix that.)

graycat 11y ago
We all know quite well what "general purpose code" is. I'm sorry about Itanium, but VLIW has to remain a possible path to faster cores. That my information is old does not mean it is wrong: The guy got 9:1 speedup on 24-way VLIW. Saying that the tricks of branch prediction, out of order execution, speculative execution, register renaming, etc. make VLIW forever obsolete is shaky without some solid references. Moreover, if we want faster cores, then obvious, right in front of us, are two possibilities: (1) Design instruction sets that make VLIW easier to do and more productive. (2) Integrate and coordinate up and down the stack, that is, from application, e.g., collection classes, string operations, function calling, memory management, exceptional condition handling, to compilers to instructions to VLIW to the gate level logic and look for speedups. E.g., the now famous instruction sets look like they were designed for assembly language programming, and likely no compiler makes good use of all the instructions. E.g., C code, supposedly fast, forces the programmer to do the multidimensional array indexing arithmetic themselves, and to the machine language it all looks like normal work. In fact, that addressing is necessarily ubiquitous across computing, so maybe have an instruction for it. Same for string compare -- the usual C approach is just comparing one character at a time in a loop -- bummer. In tool making, a key is to design the right tools. Else end up with a huge toolbox where most of the tools are used little or not at all. IMHO, we are still looking for the right tools in the stack from logic gates to microcode, register sets, instructions, caches, compilers, and applications. Then, VLIW in some form needs to be kept in mind.

by kevinnk 11y ago

graycat 11y ago

We all know quite well what "general purpose code" is. I'm sorry about Itanium, but VLIW has to remain a possible path to faster cores. That my information is old does not mean it is wrong: The guy got 9:1 speedup on 24-way VLIW. Saying that the tricks of branch prediction, out of order execution, speculative execution, register renaming, etc. make VLIW forever obsolete is shaky without some solid references. Moreover, if we want faster cores, then obvious, right in front of us, are two possibilities: (1) Design instruction sets that make VLIW easier to do and more productive. (2) Integrate and coordinate up and down the stack, that is, from application, e.g., collection classes, string operations, function calling, memory management, exceptional condition handling, to compilers to instructions to VLIW to the gate level logic and look for speedups. E.g., the now famous instruction sets look like they were designed for assembly language programming, and likely no compiler makes good use of all the instructions. E.g., C code, supposedly fast, forces the programmer to do the multidimensional array indexing arithmetic themselves, and to the machine language it all looks like normal work. In fact, that addressing is necessarily ubiquitous across computing, so maybe have an instruction for it. Same for string compare -- the usual C approach is just comparing one character at a time in a loop -- bummer. In tool making, a key is to design the right tools. Else end up with a huge toolbox where most of the tools are used little or not at all. IMHO, we are still looking for the right tools in the stack from logic gates to microcode, register sets, instructions, caches, compilers, and applications. Then, VLIW in some form needs to be kept in mind.