Live data from Hacker News

Top researchers leave Intel to build startup with 'the biggest, baddest CPU'

oregonlive.com

41–50 of 142 posts

Re: Top researchers leave Intel to build startup with 'the biggest, baddest CPU'

#42

Earlier quoted context omitted.

Most of the work that goes into chip design isn't related to the ISA per se. So, it's entirely plausible that some talented chip engineers could design something that implements RISC-V in a way that is quite powerful, much like how Apple did with ARM. The biggest roadblock would be lack of support on the software side.

Yeah sure, but the question remains if it's going to be a huge amount of small cores or a moderate amount of huge cores. What it can't be is something like the Mill if they implement the RISC-V ISA.

For those that don't know about the Mill see https://millcomputing.com/

I came to this thread looking for a comment about this. I've been patiently following along for over a decade now and I'm not optimistic anything will come from the project :(

Re: Top researchers leave Intel to build startup with 'the biggest, baddest CPU'

#47

Earlier quoted context omitted.

> make sure compiler support is good enough Do compilers optimize for specific RISC-V CPUs, not just profiles/extensions? Same for drivers and kernel support. My understanding was that if it's RISC-V compliant, no extra work is needed for existing software to run on it.

You want to optimize for specific chips because different chips have different capabilities that are not captured by just what extensions they support. A simple example is that the CPU might support running two specific instructions better if they were adjacent than if they were separated by other instructions ( https://en.wikichip.org/wiki/macro-operation_fusion ). So the optimizer can try to put those instructions…

Wonder if we could generalize this so you can just give the optimizer a file containing all this info, without needing to explicitly add support for each cpu

Re: Top researchers leave Intel to build startup with 'the biggest, baddest CPU'

#48
post #15

Earlier quoted context omitted.

A GPU is a very different beast that relies much more heavily on having a gigantic team of software developers supporting it. A CPU is (comparatively) straightforward. You fab and validate a world class design, make sure compiler support is good enough, upstream some drivers and kernel support, and make sure the standard documentation/debugging/optimization tools are all functional. This is incredibly difficult, but…

It's not the GPU I want per se but its ability to run ML tasks. If you can do that with your CPU fine!

I mean you most certainly can. Pretty much every ml library has cpu support

Re: Top researchers leave Intel to build startup with 'the biggest, baddest CPU'

#49
post #44

If Intel were smart (cough), they'd fund lots of skunkworks startups like this that could move quickly and freely, but then be "guided home" into intel once mature enough.

That creates a split between those who get to work on skunk works and those stuck on legacy. It’s very possible to end up with a google like situation where no-one wants to keep the lights on for old projects as doing so would be career suicide. There have been some attempts at other companies at requiring people to have a stake in multiple projects in different stages of the lifecycle but I’ve never seen a stable version of this, as individuals benefit from bending the rules.

Re: Top researchers leave Intel to build startup with 'the biggest, baddest CPU'

#50
One of the biggest problems with CPUs is legacy. Tie yourself to any legacy, and now you're spending millions of transistors to make sure some way that made sense ages ago still works.

Just as a thought experiment, consider the fact that the i80486 has 1.2 million transistors. An eight core Ryzen 9700X has around 12 billion. The difference in clock speed is roughly 80 times, and the difference in number of transistors is 1,250 times.

These are wild generalizations, but let's ask ourselves: If a Ryzen takes 1,250 times the transistor for one core, does one core run 1,250 times (even taking hyperthreading in to account) faster than an i80486 at the same clock? 500 times? 100 times?

It doesn't, because massive amounts of those transistors go to keeping things in sync, dealing with changes in execution, folding instructions, decoding a horrible instruction set, et cetera.

So what might we be able to do if we didn't need to worry about figuring out how long our instructions are? Didn't need to deal with Spectre and Meltdown issues? If we made out-of-order work in ways where much more could be in flight and the compilers / assemblers would know how to avoid stalls based on dependencies, or how to schedule dependencies? What if we took expensive operations, like semaphores / locks, and built solutions in to the chip?

Would we get to 1,250 times faster for 1,250 times the number of transistors? No. Would we get a lot more performance than we get out of a contemporary x86 CPU? Absolutely.

Post reply on HN