4 ms·

Chip designers have noticed this similarity in the past have and attempted to push some of the work done by the CPU back into the compiler. Itanium and the Mill

by nickcw 4y ago

Chip designers have noticed this similarity in the past have and attempted to push some of the work done by the CPU back into the compiler. Itanium and the Mill CPU both work(ed) like this I believe.

MayeulC 4y ago
You can argue that it's the RISC approach, to some extent.
terafo 4y ago
Mill CPU never existed in silicon, so there are questions to that. But IIRC Ivan said that they didn't do anything that compilers didn't do already for DPSs. He specifically mentioned that they don't want to be like Itanic.
tormeh 4y ago
This will never work due to incentive structure, unless the compiler devs are working for the same company that makes the CPU. Otherwise, compiler devs will target a lowest common denominator and call it a day. And even if the compiler devs perfectly support new CPU instructions, compiler users usually want a single binary that can run on as many CPUs as possible, and so will use the lowest common denominator once again. Currently, your CPU will 99% of the time run basic AMD64 instructions, regardless of its capabilities. So Intel and AMD try to make their CPUs really good at running AMD64 code.
- avianes 4y ago
  > 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
- JonChesterfield 4y ago
  It's quite complicated. Sometimes hardware instructions are awkward or redundant enough that compilers ignore them. Or they're broken in hardware and the compiler tries to patch around them. Sometimes there are invariants that are easy for compilers and really annoying for assembly programmers. A given sequence of instructions may execute correctly on multiple (sub)architectures with widely divergent performance behaviour. The one binary that does minimal to no self modification on boot is popular with users but intrinsically slower. Arm's variable length vector instructions are catering to that. One binary that is specialised to hardware and expected arguments is the fastest you can do without optimising while the program is starting/running. However hardware usually changes slower than software. Specifically if a program starts running on a specific x64 chip it's likely to stay on that chip until it finishes running. Linux used to patch itself on boot to pick a faster memcpy (may still do). It seems obvious that fastest for sufficiently long running processes is to ship a compiler IR, specialise first to the hardware and second to patterns in the data. OpenCL/spir-v have a finaliser premise where you lower to a given GPU just before running on it. Specialising on program data is branded JIT compilation. I don't know of anything doing both yet.
- yencabulator 4y ago
  > Otherwise, compiler devs will target a lowest common denominator and call it a day. Mill's idea for that is that compiler outputs a multi-target binary, which is specialized to the current CPU at install/first-run time, by fixing the size of the belt and other such hardware details. > "genAsm is a dataflow language, essentially a programmable representation of a single-assignment compiler IR." https://millcomputing.com/docs/compiler/ https://millcomputing.com/docs/compiler/
JonChesterfield 4y ago
All of them. And the compiler engineers try to push work into the CPU.
lanstin 4y ago
I used to enjoy the Mill CPU videos. Is there some good post-mortem explaining what happened to that project?
- ahartmetz 4y ago
  It is reportedly still alive according to their website, but it's not very convincing.
- yencabulator 4y ago
  https://millcomputing.com/topic/what-is-your-roadmap-for-2023/ https://millcomputing.com/topic/what-is-your-roadmap-for-202... https://millcomputing.com/topic/on-the-lack-of-progress-reports-from-the-mill-project/ https://millcomputing.com/topic/on-the-lack-of-progress-repo...

by nickcw 4y ago

Chip designers have noticed this similarity in the past have and attempted to push some of the work done by the CPU back into the compiler. Itanium and the Mill CPU both work(ed) like this I believe.

MayeulC 4y ago

You can argue that it's the RISC approach, to some extent.

terafo 4y ago

Mill CPU never existed in silicon, so there are questions to that. But IIRC Ivan said that they didn't do anything that compilers didn't do already for DPSs. He specifically mentioned that they don't want to be like Itanic.

tormeh 4y ago

This will never work due to incentive structure, unless the compiler devs are working for the same company that makes the CPU. Otherwise, compiler devs will target a lowest common denominator and call it a day. And even if the compiler devs perfectly support new CPU instructions, compiler users usually want a single binary that can run on as many CPUs as possible, and so will use the lowest common denominator once again. Currently, your CPU will 99% of the time run basic AMD64 instructions, regardless of its capabilities. So Intel and AMD try to make their CPUs really good at running AMD64 code.

avianes 4y ago
> 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
JonChesterfield 4y ago
It's quite complicated. Sometimes hardware instructions are awkward or redundant enough that compilers ignore them. Or they're broken in hardware and the compiler tries to patch around them. Sometimes there are invariants that are easy for compilers and really annoying for assembly programmers. A given sequence of instructions may execute correctly on multiple (sub)architectures with widely divergent performance behaviour. The one binary that does minimal to no self modification on boot is popular with users but intrinsically slower. Arm's variable length vector instructions are catering to that. One binary that is specialised to hardware and expected arguments is the fastest you can do without optimising while the program is starting/running. However hardware usually changes slower than software. Specifically if a program starts running on a specific x64 chip it's likely to stay on that chip until it finishes running. Linux used to patch itself on boot to pick a faster memcpy (may still do). It seems obvious that fastest for sufficiently long running processes is to ship a compiler IR, specialise first to the hardware and second to patterns in the data. OpenCL/spir-v have a finaliser premise where you lower to a given GPU just before running on it. Specialising on program data is branded JIT compilation. I don't know of anything doing both yet.
yencabulator 4y ago
> Otherwise, compiler devs will target a lowest common denominator and call it a day. Mill's idea for that is that compiler outputs a multi-target binary, which is specialized to the current CPU at install/first-run time, by fixing the size of the belt and other such hardware details. > "genAsm is a dataflow language, essentially a programmable representation of a single-assignment compiler IR." https://millcomputing.com/docs/compiler/ https://millcomputing.com/docs/compiler/

JonChesterfield 4y ago

All of them. And the compiler engineers try to push work into the CPU.

lanstin 4y ago

I used to enjoy the Mill CPU videos. Is there some good post-mortem explaining what happened to that project?

ahartmetz 4y ago
It is reportedly still alive according to their website, but it's not very convincing.
yencabulator 4y ago
https://millcomputing.com/topic/what-is-your-roadmap-for-2023/ https://millcomputing.com/topic/what-is-your-roadmap-for-202... https://millcomputing.com/topic/on-the-lack-of-progress-reports-from-the-mill-project/ https://millcomputing.com/topic/on-the-lack-of-progress-repo...