Top researchers leave Intel to build startup with 'the biggest, baddest CPU'
41–50 of 142 posts
Re: Top researchers leave Intel to build startup with 'the biggest, baddest CPU'
#42Earlier 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.
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'
#43The traitorous four.
Re: Top researchers leave Intel to build startup with 'the biggest, baddest CPU'
#44Re: Top researchers leave Intel to build startup with 'the biggest, baddest CPU'
#45And that's not sarcasm, I'm serious.
Re: Top researchers leave Intel to build startup with 'the biggest, baddest CPU'
#46Re: Top researchers leave Intel to build startup with 'the biggest, baddest CPU'
#47Earlier 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…
Re: Top researchers leave Intel to build startup with 'the biggest, baddest CPU'
#48Earlier 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!
Re: Top researchers leave Intel to build startup with 'the biggest, baddest CPU'
#49If 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.
Re: Top researchers leave Intel to build startup with 'the biggest, baddest CPU'
#50Just 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.