[HN Gopher] On the lack of progress reports from the Mill project
___________________________________________________________________
On the lack of progress reports from the Mill project
Author : signa11
Score : 62 points
Date : 2021-07-25 09:07 UTC (13 hours ago)
(HTM) web link (millcomputing.com)
(TXT) w3m dump (millcomputing.com)
| monocasa wrote:
| I don't understand why they need the giant funding anymore for
| this stage in their development. We're in the middle of a very
| transformative place in democratization of semi conductors. A
| couple of grad students were able to make a competitive (for the
| gate count) open source OoO core with BOOM. There's an open
| source PDK floating around now. It's albeit for 130nm, but that's
| good enough for a pentium III level core and they should be very
| very good with that gate count without paying a cent.
|
| It's not 2004 anymore, they should be able to make progress to
| making a chip at the gate counts they've been pitching with very
| little capital investment because of how much democratization of
| chip tech has happened over the past few years.
|
| Plus I was under the impression that VCs want to at least see
| something running in an FPGA for a chip startup. The space is
| filled with software engineers that have trouble synthesizing
| their HDL. Cut out the fancy meta chip generator, sit down and
| write some HDL enough for a 'bronze' core and then I imagine the
| money will start flowing for the money for a leading edge node
| where the arch will really shine.
| artemonster wrote:
| ...or, alternatively, this is all vaporware and that is the
| sole reason why nothing that you have mentioned is actually
| being done :)
| monocasa wrote:
| Yeah, that's for sure a possibility. I've got a huge soft
| spot for them though (and no skin in the game) and wish to
| see them do well.
|
| And I've seen a few times in the industry where marketing
| claims are taken at face value by later engineers who then
| actually live up to said claims thinking "well they did it,
| there has to be a way". The positive outlook by being sure
| that there is a way rather than just having a nagging
| suspension that it isn't possible is huge. Even if the Mill
| is vaporware at the end of the day, they're probably more
| valuable to the industry as a pining for what could have been
| (taken at face value) rather than an example of what not to
| do like most vaporware.
|
| So staying positive is probably best for us all.
| javajosh wrote:
| Somehow the pandemic shut them down; I would have expected the
| opposite, that it would focus them on getting something
| working.
|
| It sounds to me like The Mill is an effort being driven by
| people who are unwilling to get their hands dirty in anything
| they don't personally know and enjoy doing, which is never a
| good sign for a startup, IMHO. OTOH if they can convince the
| money to spend big on an organization prior to having a
| product, well, good for them! On general principal I'm in favor
| of transferring wealth from financiers to tech people.
| infogulch wrote:
| Some of my favorite concepts from the Mill:
|
| * Function calls as the primary built-in control flow mechanism.
| This is so obviously better its insane, _this_ should be the base
| unit of control flow in an ISA. No inventing incompatible
| "conventions" for calls, no manually saving & restoring registers
| (or need to eke out optimizations by avoiding using registers),
| no accidentally trampling on external state. Called functions
| receive parameters in a consistent location and returned values
| are output in a consistent location, other incidental state not
| part of the parameters is _inaccessible_ , upon return the
| caller's state is automatically restored as if it had just
| executed a 1-cycle cpu instruction. All for an overhead of 1
| cycle.
|
| * Instructions and functions can have _multiple return values_.
| No stupid out params just to return both an error and value or a
| value that is bigger than one word. CPU instructions use multiple
| return values for things that obviously need them instead of
| overloading stateful flags ( _eww_ ) or interrupts ( _heave_ ).
|
| * Unified address space & address translation pushed down to the
| memory controller. This solves so many problems it's not even
| funny. Cached _writes_ to memory can unblock as soon as it hits
| L1, reading from uninitialized memory gives you a pre-zeroed page
| -- _instantly_ -- not in 300 cycles, the previous two means that
| it 's possible to allocate + write + read + deallocate a memory
| page where it _never actually touches main memory and is entirely
| served by cpu cache hierarchy_ , ejects expensive TLB address
| translation out of the hot path of memory accesses instructions,
| memory protection-based access control can be done _in parallel_
| with the fetch instead of the fetch being delayed until
| translation is calculated. (A process should not assume its the
| only thing that exists and that its starting address is always
| the same, ASLR should be on by default. Arguing that per-program
| virtual memory is a security feature is like arguing that NAT is
| a security feature. Access and addressing can be separated
| securely.)
|
| * Machine code is basically a directly encoded form of Static
| Single Assignment (SSA) which is typically a compiler
| Intermediate Representation (IR) _middle step_ in the compilation
| process, but the Mill consumes SSA directly which means that a
| lot of data flow information is preserved during the lowering to
| machine code and doesn 't have to be inferred or guessed
| dynamically by the CPU during execution.
| richardfey wrote:
| What the post author is measuring is simply the absence of
| momentum and passion from whoever was curating the
| news/communication at the time. A company with dedicated staff
| for this purpose would have kept the news flowing regularly for
| PR reasons.
| ricardobeat wrote:
| VCs have been doling out cash by the kilo since 2020. Why haven't
| they been able to secure funding, even for the modest goal of
| making a FPGA proof of concept?
| im_down_w_otp wrote:
| I assume it's because there's nothing reaching the strata of
| VCs that tells them that Mill Computing's thesis is a slam dunk
| for a VC thesis. VCs invest mostly as a herd, not as pioneering
| eccentric outliers. Unless a company is doing a thing that is
| already inbounds of where the herd is at or where its vanguard
| is headed, then those companies will have a comparatively very
| hard time raising VC money.
|
| It might look to you like VCs are just throwing gobs of money
| around at anything with a pulse, but they're not. They're not
| throwing money at 100,000 distinctly unique kinds of market
| making or new category creating ventures. They're throwing lots
| of money at slightly different flavors of parallel attempts at
| iterative improvements in mostly established markets.
|
| For what Mill Computing is portending to do, I'd expect
| government grants and _maybe_ strategic investment from
| industry CVCs to be their only real viable bet. That or finding
| extremely "smart" or extremely "dumb" money in the VC
| marketplace, because I'd be very surprised if anybody in
| between is going to be looking for a Mill Computing to fill out
| their portfolio. It's way too esoteric. That's not an
| indictment of Mill Computing of VCs. Neither of them seems like
| they're in the right place for the other.
| tyingq wrote:
| Perhaps it's hard to scale up a small team with their policy of
| paying only in equity.
| ghoward wrote:
| That's only one part of the problem. I contacted them asking
| if they needed my help because I was interested in the
| project, and they wanted my help. However, they said I would
| have to spend at least 5 hours a week on it, every week. They
| demanded that.
|
| Well, that wasn't something I could promise to something I
| would do on my spare time, so I had to decline.
| rowanG077 wrote:
| I used to be quite excited for the mill. But nowadays I don't
| believe it will go anywhere. The mill has been in development for
| almost 20 years and it has literally nothing of substance to show
| for it. Not even something you can run on an FPGA.
|
| For reference when the mill project was started Intel was
| releasing pentium 4.
| h0l0cube wrote:
| I'm really interested in the Mill architecture too, but I've
| always wondered what it's target market would be. Does it offer
| a power-performance-price profile that hasn't been serviced
| yet? Or maybe it's faster/cheaper/less-power all-round compared
| to any other general purpose CPU? It's hard to know without
| real performance metrics.
| meltedcapacitor wrote:
| Also curious nobody else tried to implement the core ideas
| independently in that time.
| h0l0cube wrote:
| https://millcomputing.com/patents/
| Filligree wrote:
| So once again patents have locked up something useful.
| h0l0cube wrote:
| To be fair, it's a number of useful innovations that have
| taken decades of research, and would not have otherwise
| been done without property rights grants some sort of
| pay-out at the end. And many of the ideas would require a
| dramatic overhaul of how compilers generate and optimize
| code, and so they couldn't just be co-opted by existing
| processor families without breaking compatibility.
| Woodi wrote:
| Ah, so they jus waiting until their patents expire ? Or
| maybe they waiting until some needed-by-them patent expire
| ?
|
| Look: MS did not manufacture mouses until mouse patend got
| famous for making no money. And then it was global must to
| have. It was impossible to make singleton in C++ in 200x
| but atomics was described in literature (even in SICP) and
| only when patent expired Intel made it everyday tool...
|
| Patents should be automatically invalidated before half
| human life time is wasted.
| SAI_Peregrinus wrote:
| IMO patents should have mandatory FRAND (Fair,
| Reasonable, And Non-Discriminatory) licensing. With
| higher (2x?) license fees allowed if a working prototype
| has been submitted to the patent office instead of just a
| design.
|
| Incentivize new inventions, but keep profits fair.
| Incentivize working designs over on-paper ideas. Promote
| the progress of useful inventions over rent-seeking.
| rasz wrote:
| >MS did not manufacture mouses until mouse patend got
| famous for making no money
|
| MS started making mice in 1983 when they released Word.
| sebzim4500 wrote:
| The series of videos about the Mill on youtube are fascinating
| and they got me interested in hardware. It is very sad that
| nothing seems to have come of it, especially since one of their
| architecture was supposed to be easier to build in hardware than
| existing architectures. It would be valuable as an experiment
| even if it never ends up being better than e.g. the M1, negative
| results are useful too.
|
| Is it really so hard to them to raise money? Look at some of the
| stupid ideas that have raised tens to hundreds of millions of
| dollars over the last few years.
| MontyCarloHall wrote:
| > Is it really so hard to them to raise money? Look at some of
| the stupid ideas that have raised tens to hundreds of millions
| of dollars over the last few years.
|
| Yes. I think it's hard for them because they probably aren't
| pitching to VCs correctly. The Mill folks desperately need some
| elevator pitch material. Ivan Goddard mentioned [0] that
| they're having problems raising VC money, in a world where VC
| money has been flowing like water.
|
| Every single video/document from Mill Computing has been
| targeted towards highly technical audiences. I've seen zero
| material from them targeted to laypeople. You're never going to
| secure any funding if your website only consists of a series of
| highly technical slides and lecture videos. This [1] is their
| "high level" overview page, which is already way too technical.
|
| [0] https://millcomputing.com/topic/news/#post-3684
|
| [1] https://millcomputing.com/#_Technology
| im_down_w_otp wrote:
| Anything that's a sufficient departure from the norm is going
| to have a very hard time raising VC money from all but a very
| small handful of VCs that take really big transformative
| swings. That's not to say that Mill Computing doesn't need to
| do a better job at making material for laypersons to help
| build a zeitgeist around their thesis and what they're doing,
| but it should also be considered that they're doing something
| that VCs don't have much interest in for reasons that have
| nothing to do with the existential merits of Mill Computing.
| Which is just the long-winded way of saying, VC money is
| probably the wrong money for them.
| b9a2cab5 wrote:
| Mill really needed to be proven in academia with a physical
| implementation before going the startup route. If you look
| at RISC-V, that's been a proven path towards derisking the
| challenges of a clean sheet design+ISA.
| atq2119 wrote:
| I've been reading about the Mill for many years now and was
| fascinated by many of their ideas. However, the more deeply I
| learn about the details of how CPUs and GPUs work, the more I'm
| convinced that we're not going to see the kind of paradigm shift
| that they're touting.
|
| They have some cool ideas, but many are incompatible with
| existing software, e.g. all the memory protection stuff. Other
| ideas like how memory loads work could be integrated (and have
| been in place in GPUs for a long time, though not in CPUs) but
| still depend on compiler changes, which presumably they've done,
| but past experience with hardware projects that rely on compiler
| changes is that the compiler changes aren't performing well
| enough in practice. Or perhaps compilers improve so slowly that
| traditional architectures can easily absorb the ideas in time.
|
| Another example is that Apple's M1 proves that wider frontends
| are possible in traditional architectures, as long as the
| instruction size is fixed. There's no particular reason to
| believe that the Mill would be inherently better at this than a
| traditional architecture.
|
| If you have a lay person's interest in hardware architecture and
| haven't looked at their docs yet, do so. The ideas will likely
| tickle your brain in a good way -- they did for me. But don't
| expect much, if anything, from them in production.
| h0l0cube wrote:
| > past experience with hardware projects that rely on compiler
| changes is that the compiler changes aren't performing well
| enough in practice.
|
| > Another example is that Apple's M1 proves that wider
| frontends are possible in traditional architectures, as long as
| the instruction size is fixed.
|
| Doesn't the M1 prove that you can transpile code from one
| architecture to another and gain performance benefits? As in,
| Rosetta code works at comparable or better speed at far lower
| power consumption?
| sitkack wrote:
| Dynamic Binary Translation was shown effective back in the
| 90s
|
| https://www.hpl.hp.com/techreports/1999/HPL-1999-77.html
| tyingq wrote:
| Transmeta is another example.
| analognoise wrote:
| If I remember right, the thing that stopped people in their
| tracks was patents, not necessarily technology.
| jlokier wrote:
| Indeed, it may not be a coincidence that the M1 was
| released about the same time as Transmeta's patents
| expired.
| monocasa wrote:
| It wouldn't have been Transmeta's patents, but older
| ones. IBM's DAISY and HP's Dynamo stand out, but there
| are probably even older examples depending on what
| exactly is being patented.
|
| The original Rosetta used the same underlying tech with
| the exception of the memory model stuff, but Transmeta
| never had to deal with that since they only handled
| single cores. (And Sparc shipped TSO/WMO switch from a
| control register all the way back in the mid 90s).
| magicalhippo wrote:
| While I'm also feel a mix of enthusiasm and skepticism, I feel
| it would be a shame for the Mill team not to have a proper shot
| at getting to hardware.
|
| To see if it, against the odds, can provide some significant
| benefit or not. The proof is in the pudding, I hope they get to
| make the pudding.
| calmd wrote:
| Their ideas will become more widespread but it may be done by a
| different team at this point.
| monocasa wrote:
| Not for 17 years since their patents go up to 2018.
| thesz wrote:
| The very RISC paradigm relied on compiler change.
|
| The change happened, but not as fast as we would like it to.
| Animats wrote:
| Oh, I thought it was about the people claiming to be building a
| replica of Babbage's analytical engine, where the CPU is called
| "The Mill" [1] 11 years on, it's still all hype. They haven't
| even posted design documents, let alone built anything. Or even
| posted an annotated archive of the original documents.
|
| When that started, I contacted them and asked how many part
| numbers the Analytical Engine needed. That's a basic number for
| sizing the build job. They didn't have an estimate. (In
| manufacturing, a part is one object, and a "part number" is the
| term for a part design from which many parts are made.
| Engineering and tooling effort is driven by the number of unique
| part numbers.)
|
| If they were serious, they could start posting drawings and
| getting people to model them in SolidWorks or Fusion 360.
| Somebody would probably CNC machine the parts and make a sample
| storage register.
|
| [1] http://plan28.org/
___________________________________________________________________
(page generated 2021-07-25 23:02 UTC)