Mill Computing, Inc. › Forums › The Mill › Implementation › Transistor counts?
- AuthorPosts
- #3690 |
Is there an implementation document describing the transistor counts of various implementations of the Mill CPU?
I’m particularly interested in the transistor count of the Mill implementations with lower transistor counts, sans shared cache memory, targeting multicore chips.
No counts are available. The hardware folks are targeting an FPGA implementation first, as a proof-of-principle. Even when they shift to real chips the gate count is likely to be not very meaningful – so much depends on process, design rules and so on, and things like choice of cache sizes. We do expect to publish area and power numbers, and I suppose gate counts for anyone who’s interested, but all that will be for shipping chips, when we have them.
Maybe the question needs rephrasing. People expect something graspable to compare two CPUs even if they are based on totally different concepts. Transistor counts seems trivial enough and x86 CPU counts are usually available. Complications arise when one CPU uses 4T, other 10T cells for SRAM. Performance is different, but so is area usage, which indirectly relates to transistor count.
It will never be a fair apples to apples. I guess we cannot compare Mill to x86 before it can play Crysis 🙂
@Madis Kalme:
Crysis is a fair comparison 🙂 Benchmarks are no substitute for real use.This is a real problem for the Mill: we can measure micro-benchmarks by counting cycles in the sim. But much of the gain from the Mill comes at system level, and especially on heavy load, things like implicit zero and very cheap system calls and task switches. The biggest incompatibility though is in RAS – the Mill architecture is immune to many exploits and cheaply defends against others – but how do you benchmark security?
@jabowery:
Mill can of course do mining, but it is a poor choice for that. It’s a general purpose CPU and mining is a heavy enough load that it needs a special-purpose architecture (matrix multiply, especially) that’s dedicated to the application to be economically competitive. A GPU or similar architecture will always out-perform a general purpose CPU for such things, Mill included.
My motivation for asking is that I just returned from Bitcoin 2021 in Miami where I met up with an executive with a mining chip manufacturer. Elon Musk’s May 12 tweet about exhorbitant cryptocurrency energy usage caused a quarter trillion dollar loss of market capitalization to Bitcoin alone. I wanted to explore alternative proof-of-work algorithms based on Mill architecture in a IRAM chip featuring a large number of cores, but had no idea how to estimate how much real estate it would take to achieve given levels of performance.
Choice of mining hardware depends on the choice of proof-of-work algorithm. As the guy who came up with the idea for The Hutter Prize for Lossless Compression of Human Knowledge clear back in 2005, I’m rather distressed at the direction taken by the machine learning industry which elides the algorithmic information theoretic foundations. I convinced the mining chip executive that the ML industry’s foundation in matrix multiplication needs to be replaced with algorithmic information search. Automacoin is somewhat related to the direction I’d like to see the mining industry take.
You are way beyond me w/r/t coins and mining tech, but the underlying designguidance holds true: use a general purpose CPU like a Mill when you don’t know what code it is to run, other than lots of it all different. Use a special-purpose ASIC when its the same algorithm over and over .. and over.
Mill does have a place in such application purposes: as the control plane processor, feeding and controlling all those ASICs.
Algorithmic information is the shortest program that outputs a given set of data. Searching for that algorithmic information requires a universal Turing machine equivalent upon which to run that program. There’s no escaping the universality requirement for algorithmic information search. Moreover, scientific induction can’t do better than algorithmic information, which is why its the proper basis for ML.
Energy constrains the economics of proof-of-work.
- This reply was modified 3 years, 4 months ago by jabowery.
- AuthorPosts
You must be logged in to reply to this topic.