15 ms·

Mill Computing in 2017

230 points by reitzensteinm 10y ago

em3rgent0rdr 10y ago
> "We considered going out for our next funding round round earlier, but decided to wait until our technology was confirmed by issued patents" An example of patents slowing down innovation rather than promoting it.
pja 10y ago
I’m slightly surprised that they didn’t have an FPGA implementation running as proof of concept already. Regardless, I’m looking forward to seeing what MillComputing can deliver in the real world.
pawadu 10y ago
I haven't followed mill after attending a few lectures years ago. Does anyone think this is commercially viable? Or are we looking at a new Transputer?
- the_duke 10y ago
  There really hasn't been anything to follow apart from the video lectures (https://millcomputing.com/technology/docs/ https://millcomputing.com/technology/docs/).
- jlouis 10y ago
  The Mill architecture has lots of ideas which are really good on paper. We've had the same situation before, around 2000 with Itanium. There were many parts of that CPU which looked good on paper. In hindsight, the Itanium was too complex. Commercial viability of the architecture depends on how X86-64 and ARM fares in the coming years. If they stagnate and can't produce faster single-CPU cores and people continue writing software which lives in a single-core world, then there is a room for a CPU delivering a 10-fold increase in performance per watt per dollar. If on the other hand, most of the heavy computation are moved into either SIMD-style GPUs, or MIMD style Adapteva (Parallela) like solutions, where you have a thousand cores, then the Mill is less likely to have success. I'm optimistic that someone are trying to rethink how to handle CPU design from the bottom up. It is a gamble, but if we don't try, we won't really learn if there is anything better out there than the current generation of out-of-order executing chips. I'm pessimistic because Mill smells of Itanium. It is a mix of many new, unproven, ideas inside a single solution. Some of the ideas are genuinely good and might stick if thrown at a wall. But if you are gambling on having many new ideas at the same time, it is likely that some of them will turn out to be bad ideas. I'd place the majority of my money on simple ISA designs, such as ARM or RISC-V, preferably in a many-core design, but I'd hedge a good sum on Mill as well.
  - greglindahl 10y ago
    Fred Chow, who's great at compilers, expressed the opinion that the Itanium added instructions for many things that were already easy for compilers to deal with. That's not exactly a ringing endorsement. Mill appears to do a lot of stuff that's actually helpful to compilers.
  - the_duke 10y ago
    In one of the talks Godard said the Itanium concept wasn't brought to conclusion mostly because the chief architect died. Don't remember the name. Of course that should be taken with a grain of salt. One of the most interesting things to me is the security model with the promise (unproven, maybe very over-optimistic) of the equaivalent of context switches costing no more than regular function calls (for which there is a dedicated instruction). That would be HUGE for microkernel architectures.
    - elihu 10y ago
      > One of the most interesting things to me is the security model with the promise (unproven, maybe very over-optimistic) of the equaivalent of context switches costing no more than regular function calls... In theory, we should be able to do something like that now on ordinary CPUs if we write our user-mode software in a memory-safe language such as Rust. Current CPUs go to great lengths to isolate process address spaces so that one bad behaving application can't crash the computer. However, if the compiler also guarantees that the application can't access memory it doesn't own (because the language provides no mechanism by which to do that), then the hardware memory isolation is redundant. The OS could maintain metadata about each binary and what it was compiled with. If it wasn't compiled with a trusted compiler, then it runs inside an isolated process and pays the cost of context switches or it runs inside a CPU emulator at something like 1% performance. This assumes there are no unsafe code blocks in "trusted" user-space code; in practice, this would mean that everything that can be made more efficient by doing it in an unsafe way moves into a standard library that's trusted. So, an unsafe code block would be like an suid-root binary or a kernel module. Having user space process and the kernel run in the same address space means that system calls are just function calls (which could be inlined by the compiler) and we could support things like Infiniband network interfaces (that map their hardware registers directly into user-space memory to avoid system call overhead) through an OS API, just like a regular network adapter instead of them being a weird special case.
notacoward 10y ago
For the uninitiated, the bringup of a new processor is very complex - from compiler to libraries to kernel, from emulation to real hardware. The process described here is very similar to the one I was able to observe at SiCortex, though that chip was based on an existing one and so there was no FPGA stage. I'll bet they even use some of the same tools, such as the emulator. Kudos to them for not rushing ahead before their foundation is ready, and I look forward to seeing how this all works out.
- deleted 10y ago
  [deleted]
- the_duke 10y ago
  Is it reasonably to still not be running on an FPGA after like 12+ years of working on it?
  - pjc50 10y ago
    It seems that they're working on it somewhat part-time, and have prioritised getting the patents first. Which makes some sense as it's their only way to avoid being instantly destroyed by Intel.
    - willvarfar 10y ago
      (Mill team) Too right! 2017 is the year we get funding to go full-time and implement what we've been plotting at our Tuesday evening meetings for 10 years :)
      - ChuckMcM 10y ago
        And when you show a reference design for a smart phone with provably strong security capabilities its going to get very real indeed. Kudos for continuing the push toward real parts.
      - DennisP 10y ago
        Hmm, if you had a model with 128-bit words that skipped floating point, and left out the sneaky stuff that makes some people distrust Intel and AMD processors, you'd have an almost ideal chip for Ethereum nodes. (Make it 256-bit words and it'd really be ideal.) Not that that's a huge market at this point, but apparently there's a lot of Fortune 500 interest so maybe that'll change by the time you're in production.
Nullabillity 10y ago
> So far our patent experience has been excellent. We have successfully refuted all the prior art cited by the Examiners. While we have rephrased our applications to suit the Examiner in several cases, the substance of our claims have been allowed without exception. The Mill is truly novel – and we now have the USPTO imprimatur to confirm that. So it won't be useful for another 20ish years. Yay? > It will, naturally enough, break. However, by hosting it ourselves we can capture what failed, and use that as raw feed for our test/debug team. Wow, this is gettting more and more depressing.
- jacobolus 10y ago
  Here’s a team of world-class experts who have spent 10+ years of their lives completely redesigning all the parts of the CPU from scratch, along with a completely new low-level software stack on top of it. They’ve taken no salaries during that time. If they had no chance of any reward for their efforts, but expected their decades of work to make some already wealthy chip vendors a bit richer, you think they would bother? This kind of thing is the best possible use of the patent system: it’s supporting extremely novel and creative technical invention and engineering, not preventing anyone else’s work (nobody was intending to make anything remotely similar), and putting the details of the new inventions into the public sphere for anyone’s study now and free use in 20 years. To make use of these inventions requires billions of dollars of capital investment in chip fabrication infrastructure. Anyone with serious intentions can approach the Mill people and ask to license their technology.
  - rasz_pl 10y ago
    >team of world-class experts who have spent 10+ years of their lives completely redesigning all the parts of the CPU from scratch, along with a completely new low-level software stack on top of it. They’ve taken no salaries during that time. reminds me of gimp, or emacs
    - vosper 10y ago
      Except for, you know, the main part of your quote: "completely redesigning all the parts of the CPU from scratch, along with a completely new low-level software stack on top of it." Hardware is harder than software.
sporkenfang 10y ago
Silly question: does this company retain full-time people, or is their work primarily done by folks employed elsewhere? Maybe I just haven't reached whatever point in life where a salary is no longer necessary, but I was surprised by their About page.
- igodard 10y ago
  Both. Both full- and part-timers are on sweat-equity, no cash, although we will be switching to cash-optional with the next funding round.
- deleted 10y ago
  [deleted]
- seibelj 10y ago
  My understanding is that it's a group of enthusiasts and volunteers who are donating sweat equity out of enjoyment and the gentlemen's agreement of full-time employment once the company really gets going.
  - analognoise 10y ago
    Also known as a scam.
    - sblom 10y ago
      Or a technical collective. This isn't necessarily sinister.
unwind 10y ago
My only exposure to Mill (besides this page link) has been random comments in various stories here over the years. They typically start with ("Mill team"), and then the rest sounds like it came from the future. It's all about getting the flux capacitors charged. Can anyone post some low-level code (in assembly, or the closest equivalent if that term is no longer relevant with Mill) implementing some well-known simple algorithm on the Mill? Just to quickly get a feel of what it's all about, how it looks. Something like computing n! for word-sized integers, or strcmp(), or whatever. Does anyone have a quick link to something like that?
- white-flame 10y ago
  Consider the CPU as a pile of ALUs, FPUs, load & store units, internal buffers, and the like. Each "instruction" is a variable-size set of parallel instructions, directing which output goes into which input for various stages of that clock cycle. The layer that humans and HLL compiler developers end up with at the lowest seems to resemble a dataflow graph, and the system-specific code converts that into the parallel binary code stream. The notion of the "belt" helps arrange how long data sticks around in live outputs & buffers, but isn't a physical element in the chip.
  - igodard 10y ago
    Yes
- marcosdumay 10y ago
  From the talks, Mill assembly is ill-defined, it varies a lot from model to model. They have an intermediary representation, that I think is more like JVM bytecode than assembly, but I don't think they ever showed what it looks like.
- nightcracker 10y ago
  In one of their talks they show what strcpy would look like on the Mill: https://youtu.be/DZ8HN9Cnjhc?t=3416 https://youtu.be/DZ8HN9Cnjhc?t=3416
WhitneyLand 10y ago
It's exciting to think about a 10x improvement in CPUs. This would literally change our lives. For anyone considering getting involved or investing could you fill in a couple of bio details? >Ivan Godard has designed, implemented or led teams for...an operating system, an object-oriented database Cool, which OS and database? >taught computer science at graduate and post-graduate level at Carnegie-Mellon University Which courses?
- codezero 10y ago
  Someone asked something similar a while ago: http://blog.kevmod.com/2014/07/the-mill-cpu/ http://blog.kevmod.com/2014/07/the-mill-cpu/ Ivan responded to the post but didn't address the questions about his bio at all, but perhaps he doesn't feel the need to. For the curious, his name apparently was Mark Rain for some time in the 70s/80s [1] – there are a number of publications under that name. [1] http://newsgroups.derkeiler.com/Archive/Comp/comp.arch/2012-08/msg00444.html http://newsgroups.derkeiler.com/Archive/Comp/comp.arch/2012-...
  - WhitneyLand 10y ago
    Why would he not feel a need to? All of us have to maintain detailed bios when seeking funding, trying to build a team, or building corporate partnerships, all of which appear to be on the table.
    - igodard 10y ago
      Our industry is a surprisingly small pond, at the top anyway. No one would invest in the Mill based on my formal bio "College dropout; never took a CS course in his life" :-) Instead they invest based on our technology, most of which (and eventually all) we make publicly available. You may not be able to judge it, but any potential partner has people who can. One of the things that encouraged us in our long road is that the more senior and more skilled the reviewer, the more they loved the Mill. Quotes like "This thing is the screwiest thing I've ever seen, but it would work - and I could build it".
riazrizvi 10y ago
According to the CTO, 80% of software operations are loops (https://youtu.be/QGw-cy0ylCc?t=454 https://youtu.be/QGw-cy0ylCc?t=454)? I need convincing of that before I watch the rest of the talk. I suspect it would be a fundamental premise for the architecture of the chip. If it's not true, the stats are probably skewed for an unusual benchmark.
- naasking 10y ago
  Their docs say that in most programs, 80% of executed operations are in loops, which makes sense.
- kainolophobia 10y ago
  100% of software operations are loops, it's just that some of them are only run once ;) Joking aside, computers help us handle loops more efficiently; that's it. The 20% "non-loop operations" are just the fabric that tie the loops together.
lacampbell 10y ago
I am glad this is still going - if only for the reason that different computer architectures fascinate me. IIRC they said the belt machine thing maps well to SSA - you specify your operands by position, but the destination register is implicitly the back of the queue - in kind of the same way that each "a op b" in SSA is saved to a new variable. http://millcomputing.com/wiki/Belt http://millcomputing.com/wiki/Belt
- greglindahl 10y ago
  Ivan is a compiler guy, and I've always seen a huge impact of "compiler guy" thinking on Mill -- in a much smarter way than how "compiler guy" thinking sank Itanium.
fithisux 10y ago
Instead of bashing Mill, the true question is what we open source developers can do to help them? Implement algorithms? Improve FOSS tools? @Mill team, can you set up a list of FOSS projects that we can contribute in order to help? I specialize in implementing algorithms, especially optimization and other stuff.
- igodard 10y ago
  See https://millcomputing.com/#JoinUs https://millcomputing.com/#JoinUs NDA and sweat-equity agreement required; you get full-vested long-term options monthly; expected to be actual stock monthly after the next round. To help in a FOSS context: we are not yet ready to put out an SDK to the FOSS community, or to anyone really. That will wait until after our cloud environment is up - and a few more patents have been filed (the ISE exposes things we want to protect). In the meantime, the most help would be to support existing microkernel operating system efforts such as L4 (https://en.wikipedia.org/wiki/L4_microkernel_family https://en.wikipedia.org/wiki/L4_microkernel_family). The Mill will have a big impact on conventional OSs like Linux, but those suffer from built-in assumptions that open security holes and makes the OS a dog that the Mill can only train a little. The big win is in microkernels, which can take advantage of the Mill's tight security and ultra-fast context switching. Or support languages that have central micro-thread concepts, such as Go https://en.wikipedia.org/wiki/Go_(programming_language) https://en.wikipedia.org/wiki/Go_(programming_language), for the same reason. But whatever you do, don't tune the microkernels or microthreads for a conventional core; instead, do it right, and we'll be along to help eventually :-)

230 points by reitzensteinm 10y ago

> "We considered going out for our next funding round round earlier, but decided to wait until our technology was confirmed by issued patents" An example of patents slowing down innovation rather than promoting it.

pja 10y ago

I’m slightly surprised that they didn’t have an FPGA implementation running as proof of concept already. Regardless, I’m looking forward to seeing what MillComputing can deliver in the real world.

pawadu 10y ago

I haven't followed mill after attending a few lectures years ago. Does anyone think this is commercially viable? Or are we looking at a new Transputer?

the_duke 10y ago
There really hasn't been anything to follow apart from the video lectures (https://millcomputing.com/technology/docs/ https://millcomputing.com/technology/docs/).
jlouis 10y ago
The Mill architecture has lots of ideas which are really good on paper. We've had the same situation before, around 2000 with Itanium. There were many parts of that CPU which looked good on paper. In hindsight, the Itanium was too complex. Commercial viability of the architecture depends on how X86-64 and ARM fares in the coming years. If they stagnate and can't produce faster single-CPU cores and people continue writing software which lives in a single-core world, then there is a room for a CPU delivering a 10-fold increase in performance per watt per dollar. If on the other hand, most of the heavy computation are moved into either SIMD-style GPUs, or MIMD style Adapteva (Parallela) like solutions, where you have a thousand cores, then the Mill is less likely to have success. I'm optimistic that someone are trying to rethink how to handle CPU design from the bottom up. It is a gamble, but if we don't try, we won't really learn if there is anything better out there than the current generation of out-of-order executing chips. I'm pessimistic because Mill smells of Itanium. It is a mix of many new, unproven, ideas inside a single solution. Some of the ideas are genuinely good and might stick if thrown at a wall. But if you are gambling on having many new ideas at the same time, it is likely that some of them will turn out to be bad ideas. I'd place the majority of my money on simple ISA designs, such as ARM or RISC-V, preferably in a many-core design, but I'd hedge a good sum on Mill as well.
- greglindahl 10y ago
  Fred Chow, who's great at compilers, expressed the opinion that the Itanium added instructions for many things that were already easy for compilers to deal with. That's not exactly a ringing endorsement. Mill appears to do a lot of stuff that's actually helpful to compilers.
- the_duke 10y ago
  In one of the talks Godard said the Itanium concept wasn't brought to conclusion mostly because the chief architect died. Don't remember the name. Of course that should be taken with a grain of salt. One of the most interesting things to me is the security model with the promise (unproven, maybe very over-optimistic) of the equaivalent of context switches costing no more than regular function calls (for which there is a dedicated instruction). That would be HUGE for microkernel architectures.
  - elihu 10y ago
    > One of the most interesting things to me is the security model with the promise (unproven, maybe very over-optimistic) of the equaivalent of context switches costing no more than regular function calls... In theory, we should be able to do something like that now on ordinary CPUs if we write our user-mode software in a memory-safe language such as Rust. Current CPUs go to great lengths to isolate process address spaces so that one bad behaving application can't crash the computer. However, if the compiler also guarantees that the application can't access memory it doesn't own (because the language provides no mechanism by which to do that), then the hardware memory isolation is redundant. The OS could maintain metadata about each binary and what it was compiled with. If it wasn't compiled with a trusted compiler, then it runs inside an isolated process and pays the cost of context switches or it runs inside a CPU emulator at something like 1% performance. This assumes there are no unsafe code blocks in "trusted" user-space code; in practice, this would mean that everything that can be made more efficient by doing it in an unsafe way moves into a standard library that's trusted. So, an unsafe code block would be like an suid-root binary or a kernel module. Having user space process and the kernel run in the same address space means that system calls are just function calls (which could be inlined by the compiler) and we could support things like Infiniband network interfaces (that map their hardware registers directly into user-space memory to avoid system call overhead) through an OS API, just like a regular network adapter instead of them being a weird special case.

notacoward 10y ago

For the uninitiated, the bringup of a new processor is very complex - from compiler to libraries to kernel, from emulation to real hardware. The process described here is very similar to the one I was able to observe at SiCortex, though that chip was based on an existing one and so there was no FPGA stage. I'll bet they even use some of the same tools, such as the emulator. Kudos to them for not rushing ahead before their foundation is ready, and I look forward to seeing how this all works out.

deleted 10y ago
[deleted]
the_duke 10y ago
Is it reasonably to still not be running on an FPGA after like 12+ years of working on it?
- pjc50 10y ago
  It seems that they're working on it somewhat part-time, and have prioritised getting the patents first. Which makes some sense as it's their only way to avoid being instantly destroyed by Intel.
  - willvarfar 10y ago
    (Mill team) Too right! 2017 is the year we get funding to go full-time and implement what we've been plotting at our Tuesday evening meetings for 10 years :)
    - ChuckMcM 10y ago
      And when you show a reference design for a smart phone with provably strong security capabilities its going to get very real indeed. Kudos for continuing the push toward real parts.
    - DennisP 10y ago
      Hmm, if you had a model with 128-bit words that skipped floating point, and left out the sneaky stuff that makes some people distrust Intel and AMD processors, you'd have an almost ideal chip for Ethereum nodes. (Make it 256-bit words and it'd really be ideal.) Not that that's a huge market at this point, but apparently there's a lot of Fortune 500 interest so maybe that'll change by the time you're in production.

Nullabillity 10y ago

> So far our patent experience has been excellent. We have successfully refuted all the prior art cited by the Examiners. While we have rephrased our applications to suit the Examiner in several cases, the substance of our claims have been allowed without exception. The Mill is truly novel – and we now have the USPTO imprimatur to confirm that. So it won't be useful for another 20ish years. Yay? > It will, naturally enough, break. However, by hosting it ourselves we can capture what failed, and use that as raw feed for our test/debug team. Wow, this is gettting more and more depressing.

jacobolus 10y ago
Here’s a team of world-class experts who have spent 10+ years of their lives completely redesigning all the parts of the CPU from scratch, along with a completely new low-level software stack on top of it. They’ve taken no salaries during that time. If they had no chance of any reward for their efforts, but expected their decades of work to make some already wealthy chip vendors a bit richer, you think they would bother? This kind of thing is the best possible use of the patent system: it’s supporting extremely novel and creative technical invention and engineering, not preventing anyone else’s work (nobody was intending to make anything remotely similar), and putting the details of the new inventions into the public sphere for anyone’s study now and free use in 20 years. To make use of these inventions requires billions of dollars of capital investment in chip fabrication infrastructure. Anyone with serious intentions can approach the Mill people and ask to license their technology.
- rasz_pl 10y ago
  >team of world-class experts who have spent 10+ years of their lives completely redesigning all the parts of the CPU from scratch, along with a completely new low-level software stack on top of it. They’ve taken no salaries during that time. reminds me of gimp, or emacs
  - vosper 10y ago
    Except for, you know, the main part of your quote: "completely redesigning all the parts of the CPU from scratch, along with a completely new low-level software stack on top of it." Hardware is harder than software.

sporkenfang 10y ago

Silly question: does this company retain full-time people, or is their work primarily done by folks employed elsewhere? Maybe I just haven't reached whatever point in life where a salary is no longer necessary, but I was surprised by their About page.

igodard 10y ago
Both. Both full- and part-timers are on sweat-equity, no cash, although we will be switching to cash-optional with the next funding round.
deleted 10y ago
[deleted]
seibelj 10y ago
My understanding is that it's a group of enthusiasts and volunteers who are donating sweat equity out of enjoyment and the gentlemen's agreement of full-time employment once the company really gets going.
- analognoise 10y ago
  Also known as a scam.
  - sblom 10y ago
    Or a technical collective. This isn't necessarily sinister.

unwind 10y ago

My only exposure to Mill (besides this page link) has been random comments in various stories here over the years. They typically start with ("Mill team"), and then the rest sounds like it came from the future. It's all about getting the flux capacitors charged. Can anyone post some low-level code (in assembly, or the closest equivalent if that term is no longer relevant with Mill) implementing some well-known simple algorithm on the Mill? Just to quickly get a feel of what it's all about, how it looks. Something like computing n! for word-sized integers, or strcmp(), or whatever. Does anyone have a quick link to something like that?

white-flame 10y ago
Consider the CPU as a pile of ALUs, FPUs, load & store units, internal buffers, and the like. Each "instruction" is a variable-size set of parallel instructions, directing which output goes into which input for various stages of that clock cycle. The layer that humans and HLL compiler developers end up with at the lowest seems to resemble a dataflow graph, and the system-specific code converts that into the parallel binary code stream. The notion of the "belt" helps arrange how long data sticks around in live outputs & buffers, but isn't a physical element in the chip.
- igodard 10y ago
  Yes
marcosdumay 10y ago
From the talks, Mill assembly is ill-defined, it varies a lot from model to model. They have an intermediary representation, that I think is more like JVM bytecode than assembly, but I don't think they ever showed what it looks like.
nightcracker 10y ago
In one of their talks they show what strcpy would look like on the Mill: https://youtu.be/DZ8HN9Cnjhc?t=3416 https://youtu.be/DZ8HN9Cnjhc?t=3416

WhitneyLand 10y ago

It's exciting to think about a 10x improvement in CPUs. This would literally change our lives. For anyone considering getting involved or investing could you fill in a couple of bio details? >Ivan Godard has designed, implemented or led teams for...an operating system, an object-oriented database Cool, which OS and database? >taught computer science at graduate and post-graduate level at Carnegie-Mellon University Which courses?

codezero 10y ago
Someone asked something similar a while ago: http://blog.kevmod.com/2014/07/the-mill-cpu/ http://blog.kevmod.com/2014/07/the-mill-cpu/ Ivan responded to the post but didn't address the questions about his bio at all, but perhaps he doesn't feel the need to. For the curious, his name apparently was Mark Rain for some time in the 70s/80s [1] – there are a number of publications under that name. [1] http://newsgroups.derkeiler.com/Archive/Comp/comp.arch/2012-08/msg00444.html http://newsgroups.derkeiler.com/Archive/Comp/comp.arch/2012-...
- WhitneyLand 10y ago
  Why would he not feel a need to? All of us have to maintain detailed bios when seeking funding, trying to build a team, or building corporate partnerships, all of which appear to be on the table.
  - igodard 10y ago
    Our industry is a surprisingly small pond, at the top anyway. No one would invest in the Mill based on my formal bio "College dropout; never took a CS course in his life" :-) Instead they invest based on our technology, most of which (and eventually all) we make publicly available. You may not be able to judge it, but any potential partner has people who can. One of the things that encouraged us in our long road is that the more senior and more skilled the reviewer, the more they loved the Mill. Quotes like "This thing is the screwiest thing I've ever seen, but it would work - and I could build it".

riazrizvi 10y ago

According to the CTO, 80% of software operations are loops (https://youtu.be/QGw-cy0ylCc?t=454 https://youtu.be/QGw-cy0ylCc?t=454)? I need convincing of that before I watch the rest of the talk. I suspect it would be a fundamental premise for the architecture of the chip. If it's not true, the stats are probably skewed for an unusual benchmark.

naasking 10y ago
Their docs say that in most programs, 80% of executed operations are in loops, which makes sense.
kainolophobia 10y ago
100% of software operations are loops, it's just that some of them are only run once ;) Joking aside, computers help us handle loops more efficiently; that's it. The 20% "non-loop operations" are just the fabric that tie the loops together.

lacampbell 10y ago

I am glad this is still going - if only for the reason that different computer architectures fascinate me. IIRC they said the belt machine thing maps well to SSA - you specify your operands by position, but the destination register is implicitly the back of the queue - in kind of the same way that each "a op b" in SSA is saved to a new variable. http://millcomputing.com/wiki/Belt http://millcomputing.com/wiki/Belt

greglindahl 10y ago
Ivan is a compiler guy, and I've always seen a huge impact of "compiler guy" thinking on Mill -- in a much smarter way than how "compiler guy" thinking sank Itanium.

fithisux 10y ago

Instead of bashing Mill, the true question is what we open source developers can do to help them? Implement algorithms? Improve FOSS tools? @Mill team, can you set up a list of FOSS projects that we can contribute in order to help? I specialize in implementing algorithms, especially optimization and other stuff.

igodard 10y ago
See https://millcomputing.com/#JoinUs https://millcomputing.com/#JoinUs NDA and sweat-equity agreement required; you get full-vested long-term options monthly; expected to be actual stock monthly after the next round. To help in a FOSS context: we are not yet ready to put out an SDK to the FOSS community, or to anyone really. That will wait until after our cloud environment is up - and a few more patents have been filed (the ISE exposes things we want to protect). In the meantime, the most help would be to support existing microkernel operating system efforts such as L4 (https://en.wikipedia.org/wiki/L4_microkernel_family https://en.wikipedia.org/wiki/L4_microkernel_family). The Mill will have a big impact on conventional OSs like Linux, but those suffer from built-in assumptions that open security holes and makes the OS a dog that the Mill can only train a little. The big win is in microkernels, which can take advantage of the Mill's tight security and ultra-fast context switching. Or support languages that have central micro-thread concepts, such as Go https://en.wikipedia.org/wiki/Go_(programming_language) https://en.wikipedia.org/wiki/Go_(programming_language), for the same reason. But whatever you do, don't tune the microkernels or microthreads for a conventional core; instead, do it right, and we'll be along to help eventually :-)