11–20 of 32 posts
Don was a pretty amazing guy. He was the chairman at NetApp when I was there and told me I was crazy to be pushing NetApp to use an untested AMD processor (Opteron) for the high end filer of the time. What resulted was a solid discussion that ranged from how reliable AMD was to how important Intel was to Netapp, and how to measure the "betterness" of one technology over another. I really respected that he could be op…
Don was a pretty amazing guy. He was the chairman at NetApp when I was there and told me I was crazy to be pushing NetApp to use an untested AMD processor (Opteron) for the high end filer of the time. What resulted was a solid discussion that ranged from how reliable AMD was to how important Intel was to Netapp, and how to measure the "betterness" of one technology over another. I really respected that he could be op…
Great share. I remember the inflection point that Opteron was. Essentially, it killed Sparc, PA-RISC, Alpha, Itanium, etc. That was a unique moment in time. Hearing a personal anectode between someone relatively junior at the time, and a legend, is very interesting to me. It was, really, the moment Linux/x86 "won". That 64 bit hurdle defined where we are today. At the time, it inspired me to make a pitch that "RISC w…
Is it? The microarchitectures of the big MPUs is essentially RISC -- as it always has been, but microcode isn't written 100% by scratch any more.
At the compiler level it's kind of true, and for what turned out to be generally good reasons such as compilers aren't as smart as Radin & co thought they'd be, or concomitant ideas like delay slots turned out to be incompatible with advances in memory architecture. So in that regard I'd say that it isn't technically superior at all, which was a surprise to me and many may people.
However CISC evolved too. The original CISC architectures that RISC was a reaction to had lots of features for programmers (think VAX string processing or function call instruction!). Nobody writes code like that (except for MPUs); those residual instructions are in fact much slower than compiled code because Intel et al won't pay anyone to optimize them. Instead the focus (apart from vector and some housekeeping) has been on writing instructions that communicate better to the CPU's instruction interpreter and scheduler what the programmer's overall intent was. And structured in a way that is easier for compilers than for humans.
So which won?
One of his great talks at Stanford: “Target Big Markets” https://youtu.be/nKN-abRJMEw
I loved watching this talk — After watching this I gained a new level of appreciation for the VC model they pioneered.
An excellent snapshot of Silicon Valley and a glimpse of Don Valentine’s role in it.
http://blog.modernmechanix.com/high-tech-high-risk-and-high-...
Risk/Venture Capital, despite valid criticisms of it, has had an outsized effect on our world in the last 50+ years.
And Don Valentine played an outsized role in it.
Don was a pretty amazing guy. He was the chairman at NetApp when I was there and told me I was crazy to be pushing NetApp to use an untested AMD processor (Opteron) for the high end filer of the time. What resulted was a solid discussion that ranged from how reliable AMD was to how important Intel was to Netapp, and how to measure the "betterness" of one technology over another. I really respected that he could be op…
Did he yield?
It became NetApp's best selling product at the time. I don't deserve any credit for that of course, the folks to did the work to get it out the door and sell it get the credit. My job was to do what the Army engineers do, land on the beach and clear the obstacles between the beach and the objective so that the main force can do what they came for.
When I interview managers I ask them why they want to be a manager. It is not uncommon for them to say, "Because I want to be able to make the right decisions." And I ask them, "And if they are the wrong decisions, are you prepared to be told to leave?" It is a good litmus test.
Don was a pretty amazing guy. He was the chairman at NetApp when I was there and told me I was crazy to be pushing NetApp to use an untested AMD processor (Opteron) for the high end filer of the time. What resulted was a solid discussion that ranged from how reliable AMD was to how important Intel was to Netapp, and how to measure the "betterness" of one technology over another. I really respected that he could be op…
Great share. I remember the inflection point that Opteron was. Essentially, it killed Sparc, PA-RISC, Alpha, Itanium, etc. That was a unique moment in time. Hearing a personal anectode between someone relatively junior at the time, and a legend, is very interesting to me. It was, really, the moment Linux/x86 "won". That 64 bit hurdle defined where we are today. At the time, it inspired me to make a pitch that "RISC w…
Earlier quoted context omitted.
Great share. I remember the inflection point that Opteron was. Essentially, it killed Sparc, PA-RISC, Alpha, Itanium, etc. That was a unique moment in time. Hearing a personal anectode between someone relatively junior at the time, and a legend, is very interesting to me. It was, really, the moment Linux/x86 "won". That 64 bit hurdle defined where we are today. At the time, it inspired me to make a pitch that "RISC w…
> At the time, it inspired me to make a pitch that "RISC was dead", despite it's technical superiority. Is it? The microarchitectures of the big MPUs is essentially RISC -- as it always has been, but microcode isn't written 100% by scratch any more. At the compiler level it's kind of true, and for what turned out to be generally good reasons such as compilers aren't as smart as Radin & co thought they'd be, or concom…
CISC always decoded to simple more or less single cycle ops internally, that's how microcode works. The RISC shtick was to get rid of that decoding into simple ops in the first place. Originally that didn't make sense because those ops' fetch bandwidth would be competing with data bandwidth. But notice how RISC popped up the same time as ubiquitous instruction caches? They solved the same problem in a more general way; the I$ means that your I fetch isn't competing with data on hot paths. You can also see this in how all of the early CISC archs would have single instruction versions of memset/memcpy/etc. The goal here is to get the cycle by cycle instructions out of the main bus data path by sticking them in microcode.