Tldr: RISC-V ASICs
Top researchers leave Intel to build startup with 'the biggest, baddest CPU'
51–60 of 142 posts
Re: Top researchers leave Intel to build startup with 'the biggest, baddest CPU'
#52I like the retro-ish and out of trend name they've chosen: AheadComputing.
Together Compute
SFCompute
And so on … definitely not out of trend
Re: Top researchers leave Intel to build startup with 'the biggest, baddest CPU'
#53Earlier quoted context omitted.
> RISC-V is newer but my understanding is it's still based around ARM, just without royalties (and thus isn't bringing many new ideas to the table per say) RISC-V is the fifth version of a series of academic chip designs at Berkeley (hence it's name). In terms of design philosophy, it's probably closest to MIPS of the major architectures; I'll point out that some of its early whitepapers are explicitly calling out AR…
Theoretically wouldn't MIPS be worse, since it was designed to help students understand CPU architectures (and not to be performant)? Also I don't meet to come off confrontational, I genuinely don't know
MIPS has a few weird features such as delay slots, that RISC-V sensibly dispenses with. There's been also quite a bit of convergent evolution in the meantime, such that AArch64 is significantly closer to MIPS and RISC-V compared to ARM32. Though it's still using condition codes where MIPS and RISC-V just have conditional branch instructions.
Re: Top researchers leave Intel to build startup with 'the biggest, baddest CPU'
#54Good luck not infringing on any patents! And that's not sarcasm, I'm serious.
Intel restructures into patent troll, hiring reverse engineers and investing in chip sanding and epoxy acids.
Re: Top researchers leave Intel to build startup with 'the biggest, baddest CPU'
#55As someone who knows almost nothing about CPU architecture, I've always wondered if there could be a new instruction set, better suited to today's needs. I realize it would require a monumental software effort but most of these instruction sets are decades old. RISC-V is newer but my understanding is it's still based around ARM, just without royalties (and thus isn't bringing many new ideas to the table per say)
I think the ideal would be something like a Xilinx offering, tailoring the CPU- regarding cache, parallelism and in hardware execution of hotloop components, depending on the task. Your CPU changes with every app, tab and program you open. Changing from one core, to n-core plus AI-GPU and back. This idea, that you have to write it all in stone, always seemed wild to me.
You should definitely look into AMD's Instict, Xynq, and Versal lines, then.
Re: Top researchers leave Intel to build startup with 'the biggest, baddest CPU'
#56Earlier quoted context omitted.
I hope to see dedicated GPU coprocessors disappear sooner rather than later, just like arithmetic coprocessors did.
Arithmetic co-processors didn't disappear so much as they moved onto the main CPU die. There were performance advantages to having the FPU on the CPU, and there were no longer significant cost advantages to having the FPU be separate and optional. For GPUs today and in the foreseeable future, there are still good reasons for them to remain discrete, in some market segments. Low-power laptops have already moved entire…
By "GPU" they probably mean "matrix multiplication coprocessor for AI tasks", not actually a graphics processor.
Re: Top researchers leave Intel to build startup with 'the biggest, baddest CPU'
#57One 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 transistor…
> and the difference in number of transistors is 1,250 times
I should've written per core.
Re: Top researchers leave Intel to build startup with 'the biggest, baddest CPU'
#58One 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 transistor…
GPUs scaled wide with a similar number of transistors to a 486 and just lots more cores, thousands to tens of thousands of cores averaging out to maybe 5 million transistors per core.
CPUs scaled tall with specialized instruction to make the single thread go faster, no the amount done per transistor does not scale anywhere near linearly, very many of the transistors are dark on any given cycle compared to a much simpler core that will have much higher utilization.
Re: Top researchers leave Intel to build startup with 'the biggest, baddest CPU'
#59One 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 transistor…
> 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?
I'm pretty sure that these goals will conflict with one another at some point. For example, the way one solves Spectre/Meltdown issues in a principled way is by changing the hardware and system architecture to have some notion of "privacy-sensitive" data that shouldn't be speculated on. But this will unavoidably limit the scope of OOO and the amount of instructions that can be "in-flight" at any given time.
For that matter, with modern chips, semaphores/locks are already implemented with hardware builtin operations, so you can't do that much better. Transactional memory is an interesting possibility but requires changes on the software side to work properly.