3 ms·

>Now the only way to make your machine faster and cost less is to write more efficient software. Were still a long way away from that. Switching over to SSDs r

>Now the only way to make your machine faster and cost less is to write more efficient software. Were still a long way away from that. Switching over to SSDs represents a huge speed boost, and given how young SSDs are, I suspect that there is still room for improvement in their speed. Also, there is likely improvements to be made in CPU architecture. We are still using x86, which has been improving incrementally with backwards compatible changes since the 70s. I'm not fammiliar with CPU architecture, but I suspect this means that there is room for significant improvements in terms of per transistor efficiency with the use of a novel CPU architecture. We could also see a drop in prices due to economical, not technological forces. For example, the price of a CPU is significantly higher than the cost to produce one. This is because you are paying for the development of the CPU. Without continuing fundamental improvements, we would expect to see the cost of CPUs fall to their marginal cost as development would no longer be necessary.

bhouston 13y ago
With the rise of iOS, Android, and ChromeOS which hide the CPU architecture completely from the user (especially when running Java or JavaScript applications), there are opportunities to change CPU architectures in more radical ways in the future. But then again, the gains possible may be more limited that you suggest because the transition from x86 to x86-64 did involve a number of major efficiency gains from changing register counts and how FP calculations where done. There may not be huge efficiency gains left that are easy. With LLVM basically being a new runtime in some cases, we can do more complex compilation strategies such as was attempted with the Itanium architecture: https://en.wikipedia.org/wiki/Very_long_instruction_word https://en.wikipedia.org/wiki/Very_long_instruction_word Who knows... I'm just brainstorming today. Happy New Years!
- gizmo686 13y ago
  The transition from x86 to x86-64 did not seem like a radical redesign of the architecture. The x86-64 bit chips are still capable of running code written for x86 chips without modification (even the 16 bit code I believe). Furthermore, the programming model (as exposed to assembly) did not seem to change between the two architectures.
zhemao 13y ago
As far as architectural improvements for increasing single-core performance go, we've already reached somewhat of a dead end. Intel x86 chips already do crazy things like rearranging instructions and executing 3-4 instructions at a time. With stuff like multi-core and SIMD now, we'll need compiler improvements to take advantage of the architecture improvements.
- zhemao 13y ago
  Not that compilers don't already make these optimizations. But it's pretty hard to map sequential languages like C to a many-core processor with really large SIMD units. Any abstraction that tries to make code still look sequential even if it is being executed on many cores is going to be leaky.
tomlu 13y ago
> I suspect this means that there is room for significant improvements in terms of per transistor efficiency with the use of a novel CPU architecture. I seem to recall a comment a while back from an Intel chip designer guy saying that the x86 tax isn't as high as people think. Sure, the instruction set is super-crufty, but according to this guy they had found ways to implement most of the backwards compatible stuff in a way that's transistor efficient. He may have been biased, but didn't think the overhead compared to ARM was too significant. I tried to google for the comment but couldn't find it, apologies for that. If someone with direct processor design experience would chime in that would be great.

bhouston 13y ago

With the rise of iOS, Android, and ChromeOS which hide the CPU architecture completely from the user (especially when running Java or JavaScript applications), there are opportunities to change CPU architectures in more radical ways in the future. But then again, the gains possible may be more limited that you suggest because the transition from x86 to x86-64 did involve a number of major efficiency gains from changing register counts and how FP calculations where done. There may not be huge efficiency gains left that are easy. With LLVM basically being a new runtime in some cases, we can do more complex compilation strategies such as was attempted with the Itanium architecture: https://en.wikipedia.org/wiki/Very_long_instruction_word https://en.wikipedia.org/wiki/Very_long_instruction_word Who knows... I'm just brainstorming today. Happy New Years!

gizmo686 13y ago
The transition from x86 to x86-64 did not seem like a radical redesign of the architecture. The x86-64 bit chips are still capable of running code written for x86 chips without modification (even the 16 bit code I believe). Furthermore, the programming model (as exposed to assembly) did not seem to change between the two architectures.

zhemao 13y ago

As far as architectural improvements for increasing single-core performance go, we've already reached somewhat of a dead end. Intel x86 chips already do crazy things like rearranging instructions and executing 3-4 instructions at a time. With stuff like multi-core and SIMD now, we'll need compiler improvements to take advantage of the architecture improvements.

zhemao 13y ago
Not that compilers don't already make these optimizations. But it's pretty hard to map sequential languages like C to a many-core processor with really large SIMD units. Any abstraction that tries to make code still look sequential even if it is being executed on many cores is going to be leaky.

tomlu 13y ago

> I suspect this means that there is room for significant improvements in terms of per transistor efficiency with the use of a novel CPU architecture. I seem to recall a comment a while back from an Intel chip designer guy saying that the x86 tax isn't as high as people think. Sure, the instruction set is super-crufty, but according to this guy they had found ways to implement most of the backwards compatible stuff in a way that's transistor efficient. He may have been biased, but didn't think the overhead compared to ARM was too significant. I tried to google for the comment but couldn't find it, apologies for that. If someone with direct processor design experience would chime in that would be great.