3 ms·

> unless the compiler devs are working for the same company that makes the CPU Every CPU manufacturing company have a compile team. > This will never work VL

> unless the compiler devs are working for the same company that makes the CPU Every CPU manufacturing company have a compile team. > This will never work VLIW processors do work, and for a while now. This type of architecture performs better for data-intensive workloads, so you don't see them in the general-purpose world. But if you are talking about Mill, yes it will never work.

JonChesterfield 4y ago
VLIW works _really_ well if you have deterministic memory timings, e.g. DSP/risc style architectures, and you're up for writing a complicated compiler.
ahartmetz 4y ago
> But if you are talking about Mill, yes it will never work. Maybe Mill Computing won't pull it off, but why do you think the approach is bad? It seems sufficiently different from Itanium to not have the exact same problems.
- marcosdumay 4y ago
  They don't have a "deliver at all costs" philosophy and they are creating a new and different CPU architecture from scratch, a task where even teams oriented at delivering at all costs tend to almost always fail. The architecture itself looks very good. If it was built in a way similar to RISC-V, it would probably become very influential. (But then, I'm not sure you can create something that innovative by the same procedures RISC-V was created.)
  - imtringued 4y ago
    The architecture looks like a dead end compared to other novel architecture like the Reduceron which reached 33% of the performance of a single core 2 duo processor core while running on an FPGA with only 90MHz without using pipelining or out of order execution. The catch is that the execution model of the Reduceron is graph reduction which basically means lambda calculus/lazy functional programming languages. The Reduceron's raw arithmetic performance isn't better, but it doesn't matter because lazy evaluation is memory intensive, the more memory intensive the algorithm, the better the Reduceron performs, which is very unlike classical C machines like x86 or ARM or RISC-V where memory intensitivity must be avoided at all costs for good performance. Where the Reduceron does a single graph reduction per clock cycle, a C machine has to do it with several sequential instructions so a massive clock rate advantage isn't worth much.
- avianes 4y ago
  Well, first of all, because it shows no results after +10 years. There is definitely no indication that it will work someday. And above all because there are too many choices that are too specific, outdated and too exotic. (e.g. the split-stream encoding is way too exotic) I work in a small company that makes processors, and I know from experience that developing a processor is a very complicated subject, you have to go step by step (Mill does not). When you come up with a new design/idea, you try to simulate it, test it and implement it. You don't pile up new ideas without getting feedback on them.
tormeh 4y ago
> Every CPU manufacturing company have a compile team Sure, but that doesn't help when all the binaries are compiled for AMD64 anyway.
- UncleEntity 4y ago
  You can compile your own binaries if max performance is the goal. Assuming you have access to the source code of course.
  - tormeh 4y ago
    Intel and AMD are so good at running AMD64 code that it's often slower to use additional instructions.
wongarsu 4y ago
And at least the Intel compiler was/is pretty good at producing a single binary that uses whatever features your CPU has available by switching to different code paths depending on the cpuid flags. At least if your CPU is an Intel CPU, it's more conservative with that on AMD CPUs.

JonChesterfield 4y ago

VLIW works _really_ well if you have deterministic memory timings, e.g. DSP/risc style architectures, and you're up for writing a complicated compiler.

ahartmetz 4y ago

> But if you are talking about Mill, yes it will never work. Maybe Mill Computing won't pull it off, but why do you think the approach is bad? It seems sufficiently different from Itanium to not have the exact same problems.

marcosdumay 4y ago
They don't have a "deliver at all costs" philosophy and they are creating a new and different CPU architecture from scratch, a task where even teams oriented at delivering at all costs tend to almost always fail. The architecture itself looks very good. If it was built in a way similar to RISC-V, it would probably become very influential. (But then, I'm not sure you can create something that innovative by the same procedures RISC-V was created.)
- imtringued 4y ago
  The architecture looks like a dead end compared to other novel architecture like the Reduceron which reached 33% of the performance of a single core 2 duo processor core while running on an FPGA with only 90MHz without using pipelining or out of order execution. The catch is that the execution model of the Reduceron is graph reduction which basically means lambda calculus/lazy functional programming languages. The Reduceron's raw arithmetic performance isn't better, but it doesn't matter because lazy evaluation is memory intensive, the more memory intensive the algorithm, the better the Reduceron performs, which is very unlike classical C machines like x86 or ARM or RISC-V where memory intensitivity must be avoided at all costs for good performance. Where the Reduceron does a single graph reduction per clock cycle, a C machine has to do it with several sequential instructions so a massive clock rate advantage isn't worth much.
avianes 4y ago
Well, first of all, because it shows no results after +10 years. There is definitely no indication that it will work someday. And above all because there are too many choices that are too specific, outdated and too exotic. (e.g. the split-stream encoding is way too exotic) I work in a small company that makes processors, and I know from experience that developing a processor is a very complicated subject, you have to go step by step (Mill does not). When you come up with a new design/idea, you try to simulate it, test it and implement it. You don't pile up new ideas without getting feedback on them.

tormeh 4y ago

> Every CPU manufacturing company have a compile team Sure, but that doesn't help when all the binaries are compiled for AMD64 anyway.

UncleEntity 4y ago
You can compile your own binaries if max performance is the goal. Assuming you have access to the source code of course.
- tormeh 4y ago
  Intel and AMD are so good at running AMD64 code that it's often slower to use additional instructions.

wongarsu 4y ago

And at least the Intel compiler was/is pretty good at producing a single binary that uses whatever features your CPU has available by switching to different code paths depending on the cpuid flags. At least if your CPU is an Intel CPU, it's more conservative with that on AMD CPUs.