7 ms·
Jim Keller is an engineer that worked on the AMD K8 architecture and the Apple A5 processors. Sam Zeloof is known from his YouTube channel[1] where he shows ho
by Genbox 4y ago
Jim Keller is an engineer that worked on the AMD K8 architecture and the Apple A5 processors.
Sam Zeloof is known from his YouTube channel[1] where he shows how to build microprocessors in detail.
I hope that this step is the first of many to build an efficient processor with fresh ideas and innovation.
[1] https://www.youtube.com/@SamZeloof https://www.youtube.com/@SamZeloof
- zargon 4y agoJim Keller was also famously involved in DEC Alpha, x86-64, and Zen. Sam Zeloof is the kid who manufactures transistors in his garage.
- KingOfCoders 4y agoLoved the Alpha I've used at university.
- jacquesm 4y agoI bought an Alpha for a project that needed a lot of directly addressable memory, it was the first 64 bit architecture that was affordable and ran RedHat on it. That box paid for itself within the first week.
- tambourine_man 4y agoThat’s so cool, I’d love read more of that if you can share.
- jacquesm 4y agoIt's quite simple, actually: a customer needed a very large database (> 4G) and one proposal was to create some kind of sharding mechanism because all of the ways that they could think of to do this in RAM meant that they had to use a pretty large number of machines, complicating all of the ways in which updates, queries and keeping it all synchronized would have to be done, besides requiring a rack full of hardware. The Alpha made all of that moot because in one fell stroke it increased the amount of RAM that could be addressed directly to the point where the whole thing could happen in memory without any cluster communications overhead. It was still an expensive machine but it cost a fraction of the setup that it replaced, and performed really very well. A nice example of how vertical scaling can be a very viable option. The 64 bit file system also allowed for much larger files, which helped the project in different ways. One downside was that spare hardware was difficult to obtain but the system was built like a tank and ran for many years until there were many other suppliers of 64 bit systems. It was way ahead of the anything else in the 'affordable' range of computers. Though it still cost as much as a nice car fully decked out, especially the RAM was quite expensive.
- nickik 4y agoHaving a 64 bit system at that time could have also really helped with implementing super fast virtual machines. You have so much space to store information in pointers. Azul later realized some of these things on Java. Building a virtual machine and even language to take advantage of that from the ground up would have been cool.
- KMag 4y agoIt was also the first (non-research) processor I'm aware of that was designed from the ground up to be 64-bit, without 32-bit addressing. Of course, as long as you can get the OS to allocate only within a given 4 GB range, you could emulate 32-bit pointers by storing only 32-bit offsets. The processor's firmware (PALCode) was essentially a single-tenant hypervisor, and the OS kernel made upcalls to the firmware in order to perform any privileged instructions. Had the architecture survived longer, this would have been handy for virtualization. Modern OS kernels have special cases for upcalls when running on top of hypervisors in order to avoid some of the overhead of the trap-and-emulate code in the hypervisor. The designers were brutal in only including instructions that could show a performance improvement in simulations. The first versions of the processor didn't have single byte loads or stores, presuming that the standard library string functions would load and store 64-bit words at a time and perform any necessary bit manipulations in registers. They later relented and included an instruction set extension for single-byte operations. They were also famously brutal in their memory model, leaving as much leeway as possible for hardware to re-order operations. As long as you're correctly using mutexes to protect shared state, the mutex acquisition and releasing code will properly synchronize all of your memory operations. However, if you're implementing lockfree data structures, the Alpha is particularly liberal in its read ordering, and you need read fences on the reader side of lockfree structures, which is unusual. Experience has shown that for most code, the potential performance improvements aren't very significant, especially considering the increased potential for concurrency bugs.
- jacquesm 4y agoI loved that box. It worked for many years and when we finally shut it down it really felt like the end of an era. This was when I emigrated to Canada where I stayed until 2007, it would have been nice to take it along but we were shipping enough stuff across the Atlantic as it was. I'm pretty sure that if you had dropped that from the 10th floor of a random office building you'd be fined for damage to the pavement but that machine would have still worked ;) It also took two people to lift it.
- kjs3 4y agoI had a couple of Alphas in my home lab up until about 9-10 years ago (a largish DEC3000, a 'generic' 164PC, a DS20). Even as elderly boxes they were astonishingly well built, performant enough to do real work on, and gave a useful 'not an x86' check when I was testing for portability and such. However, I figured out they used a significant fraction of all the power consumed in the lab and generated heat like furnaces. When I did a tech refresh regrettably they needed to go. The 3000 in particular seemed like it was designed to go into combat.
- KingOfCoders 4y agoI mostly played around as a student, but I did write a realtime raytracer with our Alpha Cluster I'm still proud of.
- Axien 4y agoHeavy as hell. Why exactly was it so heavy?
- amelius 4y agoIsn't this a patent minefield?
- nielsole 4y agoNot if you build >100nm chips, I suppose
- comboy 4y agoK8 seems pretty small after he made the fucking Zen architecture (and Tesla AI). Lex has good interviews with Jim[1], he's not just very smart, he is wise. He started Tenstorrent some time ago with Ljubisa Bajic so I'm assuming this fab is related. Here is youtube channel for Tenstorrent[2], and last time I checked it was getting under 100 views per video... Ian also interviewed him[3] some time ago. Long story short if I had money that would be relevant in this context I would invest really hard into Tenstorrent. Investing time to listen to the guy seems to be not worse. 1a. https://www.youtube.com/watch?v=Nb2tebYAaOA https://www.youtube.com/watch?v=Nb2tebYAaOA 1b. https://www.youtube.com/watch?v=G4hL5Om4IJ4 https://www.youtube.com/watch?v=G4hL5Om4IJ4 2. https://www.youtube.com/watch?v=gzgyksS5pX8 https://www.youtube.com/watch?v=gzgyksS5pX8 3. https://www.youtube.com/watch?v=AFVDZeg4RVY https://www.youtube.com/watch?v=AFVDZeg4RVY
- robert_foss 4y agoJim certainly didn't start Tenstorrent, but he did join it a while back. Some former AMD employees started it.
- comboy 4y agoLjubisa here[1] says they incorporated only after Jim put money in it and it was a few months after they started thinking. 1. https://youtu.be/sMvudTBBQNw?t=289 https://youtu.be/sMvudTBBQNw?t=289
- robert_foss 4y agoYou're right, he may have been an early investor too.
- IanCutress 4y agoJim was the Angel investor, so to speak.
- scrlk 4y ago> he made the fucking Zen architecture From Jim himself: > IC: A few people consider you 'The Father of Zen', do you think you’d scribe to that position? Or should that go to somebody else? > JK: Perhaps one of the uncles. There were a lot of really great people on Zen. There was a methodology team that was worldwide, the SoC team was partly in Austin and partly in India, the floating-point cache was done in Colorado, the core execution front end was in Austin, the Arm front end was in Sunnyvale, and we had good technical leaders. I was in daily communication for a while with Suzanne Plummer and Steve Hale, who kind of built the front end of the Zen core, and the Colorado team. It was really good people. Mike Clark's a great architect, so we had a lot of fun, and success. Success has a lot of authors - failure has one. So that was a success. Then some teams stepped up - we moved Excavator to the Boston team, where they took over finishing the design and the physical stuff, Harry Fair and his guys did a great job on that. So there were some fairly stressful organizational changes that we did, going through that. The team all came together, so I think there was a lot of camaraderie in it. So I won't claim to be the ‘father’ - I was brought in, you know, as the instigator and the chief nudge, but part architect part transformational leader. That was fun. https://www.anandtech.com/show/16762/an-anandtech-interview-with-jim-keller-laziest-person-at-tesla https://www.anandtech.com/show/16762/an-anandtech-interview-...
- nickysielicki 4y agoHe’s also the brother-in-law of Jordan B. Peterson. Small world.
- deleted 4y ago[deleted]
- ThrowawayTestr 4y agoOne of the smartest CPU designers ever plus a dude that made his own transistors in his garage. This could lead to some interesting things.
- libraryatnight 4y agoThat'd be cool. The skeptic in me feels like this is the electronics equivalent of when someone who directed a famous MMO starts up a new game company with some other famous cool game designer/developer that everyone loves, and then they take in a whole bunch of money and never actually do anything (not that their fans would ever admit it). Different spaces, different people, but I'm going to sit back and observe I think. I'm just kind of done being excited by people announcing the partnerships, once the partnership bears fruit I will have a look and then decide if I'm excited.