4 ms·
I remember the DEC Alpha. Intel (and HP) countered with Itanium, which was a break from (i.e. incompatible with) the x86 architecture (IA64). It tanked. AMD c
by wenc 6y ago
I remember the DEC Alpha.
Intel (and HP) countered with Itanium, which was a break from (i.e. incompatible with) the x86 architecture (IA64). It tanked.
AMD created AMD64 which was x86 compatible. They released chips like the Athlon which were very popular. This turned out to be the winning strategy.
In a strange twist, Intel was forced by the market to adopt the AMD64. It released it's own version, Intel64.
Intel messed up there too in the 90s too. It wasn't until the Core CPU roadmap that Intel regained its lead.
There seems to be a link -- Jim Keller [1] was involved in the design of DEC Alpha chips, and then moved to AMD to work on the K8 and then co-wrote the AMD64 instruction set. He also worked on Apple's chips and Tesla's HW. He recently just left Intel. What a career.
[1] https://en.wikipedia.org/wiki/Jim_Keller_(engineer) https://en.wikipedia.org/wiki/Jim_Keller_(engineer)
- burnte 6y ago> It released it's own version, Intel64. Well, they licensed AMD's and CALLED it their own.
- garmaine 6y agoIt was their own implementation.
- ivalm 6y agoWas it ever understood why Keller left intel recently?
- thu2111 6y agoNo. The announcement was the usual platitudes. We can infer from the unexpected and apparently sudden nature that there was some bust-up or dispute but nobody knows why. The interview with Fridman may offer a bit of insight. Keller is a firm believer in Moore's Law, that it'll continue for a long time yet. He believes you have to redesign things nearly from scratch on a regular basis, to benefit from this firm progress. Intel, meanwhile, is struggling with Moore's Law. First 10nm, now this. Backporting architectures to older nodes. It may be that Keller realised how deep the production issues went (perhaps he learned that 7nm was starting to fail too) and concluded he wasn't going to be able to achieve what he wanted to achieve when constrained by Intel's fabs.
- BbzzbB 6y agoSince you brought up Keller, if anyone is interested here is a great podcast/conversation/interview with Lex Fridman: https://youtu.be/Nb2tebYAaOA https://youtu.be/Nb2tebYAaOA
- jiggawatts 6y agoOne of the best bits I took away from that interview is Jim's comment that a lot of things need to be "rearchitected every decade, or even faster". It's such a throwaway comment, but I think there's deep insight behind it from someone with extensive experience in the matter. I also feel it applies to many other things, not just ASIC design. For example, every customer I go to manages their VMware farm just like they managed their bare metal boxes in the past. Just as they're oh-so-slowly wrapping their heads around the design concepts that are a better fit for virtualisation, they're moving to the cloud. So of course, they deploy everything in the cloud just like they're used to in their on-premises VMware environment. It's shocking how much low-hanging fruit is out there, just waiting to be rearchitected by someone with understanding and a clear vision. As a random example: I just saw a bunch of Azure servers with empty 1TB "Application" D:\ drives. The team that built it was used to how VMware thin-provisioned drives only allocate 2MB blocks at a time, so the 1TB max capacity is just a high water mark that has no real cost. Meanwhile, Azure bills based on capacity, not usage, so that 1TB is burning money. It seems like a small thing, but if you store 1GB in a 1TB volume in the cloud, you're not paying $123/TB/month, you're actually paying $12,288 per terabyte of data stored per month! If you look around, it turns out that everywhere you look, people are doing "what they've always done", and it leads to crazy inefficiencies.
- devonkim 6y agoThe reality is most places keep running software architected for an era over 2 decades ago now and it’s ossifying harder if it’s still carrying enough business inertia. Those workflows of bootstrapping VMs and EC2 instances like it’s 1996 are not going away because to do anything cloud native in your architecture you need cloud native software, and usually if you can get a container you can get an RPM or Deb and play package jockey rejecting the new technologies literally meant to do half the work for you. In most of the cases where places just dump money it’s usually a question of labor cost spent to optimize vs the gains, and unless your business is built around scaling a lot of small customers like the usual SaaS unicorns customer acquisition is super long, painful, and technical inefficiency is the default for enterprise as a rule. It’s worth paying $200 for a $1 part because the overhead and risk of renegotiating anything is not worth it. When an hour long meeting essentially costs a minimum of $1000 to a company essentially, it’d better be worth it. When it comes to ASIC designs and VLSI the technical debt is pretty different because each generation of hardware has past benchmarks primarily to drive it forward. Oftentimes in software people tend to want to keep things the same which discourages innovation or touching.
- leoc 6y agoAnd Itanium wasn’t Intel’s first or even second attempt to follow up x86 with an incompatible clean-sheet architecture iirc.