4 ms·

> How will chiplets affect software? Naffziger: One of the goals of our architecture is to have it be completely transparent to software, because software is ha

by uticus 3y ago

> How will chiplets affect software? Naffziger: One of the goals of our architecture is to have it be completely transparent to software, because software is hard to change. This greatly amuses me. Of course the interplay between software and hardware is a dance, with drivers and responders on both sides. And of course "software" here means close to metal. But it still seems counterintuitive to say the industry is at a point where cutting-edge hardware decisions are made because of the current state of software.

kjs3 3y ago
Maybe because the vast majority of users care primarily about their software running without surprises, and don't care much at all about all the ways your hardware is 'cutting-edge' if it breaks that expectation. And they aren't wrong.
- uticus 3y ago
  Sure, but you have to admit something is funny here. Software, with its promise of being fluid and malleable, is in this case the exact opposite - so much the opposite in fact that silicone is seen as more malleable than the software. > Maybe because the vast majority of users care primarily about their software running without surprises... As a software user I don't disagree with you, but I'm contrasting "One of the goals of our architecture is to have it be completely transparent to software..." with other hardware changes in history. Being "transparent to software" wasn't a goal of adding extensions to x86, for example. Or the goal of having compilers support RISC-V, for another example. What is different here, that the hardware manufacturer desires absolutely no changes in software when pushing for a hardware change? I can only come up with two things. First, AMD must be currently focused on optimization, not innovation. Drop-in the new AMD thing and get a speed bump with your current software. Reap profits immediately from that and if it leads to opportunities for innovation perhaps they'll consider that later. These are the people that came up with x86-64 after all. Second, I suspect whereas software changes at a high level are easy, changes at a low level, near the hardware, are difficult. As for why it is difficult I'd guess it's primarily because low level software is a dependency for so much other software. Sure, low level software changes may also be difficult because of other reasons (requires more intimate knowledge of hardware, requires more focus on what the instruction set can do, etc), but those other reasons can't be the primary difficulties with AMD here because those other reasons also existed with previous hardware changes that were anything but "transparent to software." So when they say they want to be "transparent to software, because software is hard to change" that could also be read as "because software that interacts with our hardware is a dependency for so much, it would not be worthwhile to recompile even if the compiler existed today for free."
  - kjs3 3y ago
    I'll put the caveat up front: - Apple is the exception to the rule and does swap arch periodically, because they can. But with a migration phase. Which they generally did ok at. Because users care about software, not PowerPC v x86-64 v ARM. Being "transparent to software" wasn't a goal of adding extensions to x86, for example. Yes it absolutely was, and I can't possibly understand why you'd think otherwise. Can't think of a thing that quit working because SSE showed up (surely there was something, but it was a rounding error). Or AES-NI. And since you mention it, that's a big reason why x86-64 won; it minimized breakage of the software people were already using, as opposed to Itanium. Or the goal of having compilers support RISC-V, for another example. Not sure what this point is making. Compilers support all sorts of oddball archs for various reasons. When RISC-V gets an installed base to speak of outside embedded and hobbies maybe we can make specific judgements. Until then....... Drop-in the new AMD thing and get a speed bump with your current software. Which is all most users care about. Which is why the hardware vendors focus on it. Reap profits immediately from that and if it leads to opportunities for innovation perhaps they'll consider that later. 1) Reaping profits is kinda the point of having a company, and profits will go down if your idea of 'innovation' is 'this new thing we have is SO COOL...you just have to throw out all the stuff that used to run on our stuff'. 2) If you don't call what Intel and AMD are doing to get that 'speed bump' year after year for decades in processing power and power consumption 'innovation'...I don't really know what to tell you. "because software that interacts with our hardware is a dependency for so much, it would not be worthwhile to recompile even if the compiler existed today for free." Software can be recompiled for every new generation, if you want to (and can limit you users to certain generations of processors). Sometimes that makes sense and some people are constantly recompiling to maximize something (e.g. HPC folks). Have you ever looked at the number of compiler switches GCC & LLVM have to optimize for different micro-architectures? Just for x86(-64)? There's a huge continuum from "maximize performance at the expense of limiting hardware support" to "run on the maximum number of machines". Pick your poison.

by uticus 3y ago

kjs3 3y ago

Maybe because the vast majority of users care primarily about their software running without surprises, and don't care much at all about all the ways your hardware is 'cutting-edge' if it breaks that expectation. And they aren't wrong.

uticus 3y ago
Sure, but you have to admit something is funny here. Software, with its promise of being fluid and malleable, is in this case the exact opposite - so much the opposite in fact that silicone is seen as more malleable than the software. > Maybe because the vast majority of users care primarily about their software running without surprises... As a software user I don't disagree with you, but I'm contrasting "One of the goals of our architecture is to have it be completely transparent to software..." with other hardware changes in history. Being "transparent to software" wasn't a goal of adding extensions to x86, for example. Or the goal of having compilers support RISC-V, for another example. What is different here, that the hardware manufacturer desires absolutely no changes in software when pushing for a hardware change? I can only come up with two things. First, AMD must be currently focused on optimization, not innovation. Drop-in the new AMD thing and get a speed bump with your current software. Reap profits immediately from that and if it leads to opportunities for innovation perhaps they'll consider that later. These are the people that came up with x86-64 after all. Second, I suspect whereas software changes at a high level are easy, changes at a low level, near the hardware, are difficult. As for why it is difficult I'd guess it's primarily because low level software is a dependency for so much other software. Sure, low level software changes may also be difficult because of other reasons (requires more intimate knowledge of hardware, requires more focus on what the instruction set can do, etc), but those other reasons can't be the primary difficulties with AMD here because those other reasons also existed with previous hardware changes that were anything but "transparent to software." So when they say they want to be "transparent to software, because software is hard to change" that could also be read as "because software that interacts with our hardware is a dependency for so much, it would not be worthwhile to recompile even if the compiler existed today for free."
- kjs3 3y ago
  I'll put the caveat up front: - Apple is the exception to the rule and does swap arch periodically, because they can. But with a migration phase. Which they generally did ok at. Because users care about software, not PowerPC v x86-64 v ARM. Being "transparent to software" wasn't a goal of adding extensions to x86, for example. Yes it absolutely was, and I can't possibly understand why you'd think otherwise. Can't think of a thing that quit working because SSE showed up (surely there was something, but it was a rounding error). Or AES-NI. And since you mention it, that's a big reason why x86-64 won; it minimized breakage of the software people were already using, as opposed to Itanium. Or the goal of having compilers support RISC-V, for another example. Not sure what this point is making. Compilers support all sorts of oddball archs for various reasons. When RISC-V gets an installed base to speak of outside embedded and hobbies maybe we can make specific judgements. Until then....... Drop-in the new AMD thing and get a speed bump with your current software. Which is all most users care about. Which is why the hardware vendors focus on it. Reap profits immediately from that and if it leads to opportunities for innovation perhaps they'll consider that later. 1) Reaping profits is kinda the point of having a company, and profits will go down if your idea of 'innovation' is 'this new thing we have is SO COOL...you just have to throw out all the stuff that used to run on our stuff'. 2) If you don't call what Intel and AMD are doing to get that 'speed bump' year after year for decades in processing power and power consumption 'innovation'...I don't really know what to tell you. "because software that interacts with our hardware is a dependency for so much, it would not be worthwhile to recompile even if the compiler existed today for free." Software can be recompiled for every new generation, if you want to (and can limit you users to certain generations of processors). Sometimes that makes sense and some people are constantly recompiling to maximize something (e.g. HPC folks). Have you ever looked at the number of compiler switches GCC & LLVM have to optimize for different micro-architectures? Just for x86(-64)? There's a huge continuum from "maximize performance at the expense of limiting hardware support" to "run on the maximum number of machines". Pick your poison.