3 ms·

I don't think they mean that Software is hard to change, but "getting/motivating others to change their software specific for our hardware"

Dalewyn 3y ago
Software is hard to change, because there is nothing more permanent than a temporary solution. And there are lots of temporary solutions in programming.
- rat9988 3y ago
  No it's not related to that principle at all in this context.
  - Dalewyn 3y ago
    Between clickbait journalism and soundbites taken out of context, I'm only going to devote as much brain as the people devoted to the aforementioned.
    - janfoeh 3y ago
      Why do I feel reminded of the broken window theory all of a sudden?
- CyberDildonics 3y ago
  Software is hard to change because it is difficult to create and already distributed. I don't think what you said has any relation to the problem.
flohofwoe 3y ago
The Itanium (as the prime example - and I bet the quote from the interview is at least partly based on the lessons learned from Itanium) failed not because there was no will by programmers to adapt their projects, but because there's simply not enough instruction-level parallelism in general-purpose code. That's not a problem one can simply "fix" by rewriting all software, much less by rewriting all compilers from scratch.
- yvdriess 3y ago
  Correction: the lesson is that you cannot exploit the available ILP by static (compile-time) analysis. There is definitely enough ILP to exploit if you do the analysis at execution time, which is what any modern CPU does with register renaming, reorder buffers, dependency tracking etc.
CoastalCoder 3y ago
I think having good optimizing compilers goes a long way. I.e., to the extent they reduce the need for source code to cater to the underlying CPU, less effort is needed to port software to a new CPU. I think GCC and especially LLVM are really reducing the barriers to bringing new CPUs to market. Maybe for GPUs as well because of shader compilers?

Dalewyn 3y ago

Software is hard to change, because there is nothing more permanent than a temporary solution. And there are lots of temporary solutions in programming.

rat9988 3y ago
No it's not related to that principle at all in this context.
- Dalewyn 3y ago
  Between clickbait journalism and soundbites taken out of context, I'm only going to devote as much brain as the people devoted to the aforementioned.
  - janfoeh 3y ago
    Why do I feel reminded of the broken window theory all of a sudden?
CyberDildonics 3y ago
Software is hard to change because it is difficult to create and already distributed. I don't think what you said has any relation to the problem.

flohofwoe 3y ago

The Itanium (as the prime example - and I bet the quote from the interview is at least partly based on the lessons learned from Itanium) failed not because there was no will by programmers to adapt their projects, but because there's simply not enough instruction-level parallelism in general-purpose code. That's not a problem one can simply "fix" by rewriting all software, much less by rewriting all compilers from scratch.

yvdriess 3y ago
Correction: the lesson is that you cannot exploit the available ILP by static (compile-time) analysis. There is definitely enough ILP to exploit if you do the analysis at execution time, which is what any modern CPU does with register renaming, reorder buffers, dependency tracking etc.

CoastalCoder 3y ago

I think having good optimizing compilers goes a long way. I.e., to the extent they reduce the need for source code to cater to the underlying CPU, less effort is needed to port software to a new CPU. I think GCC and especially LLVM are really reducing the barriers to bringing new CPUs to market. Maybe for GPUs as well because of shader compilers?