That’s approximately right. The only correction I’d make to that characterization is that while this mutex is still proportional to log(N), the base of the log is much greater than 2 and the constant of proportionality is probably less as well. It is also likely to take a lot less real estate.
The technical risks I see are making sure:
Kirchhoff’s Laws apply at the frequencies encountered, and
the “noise” doesn’t overwhelm the digital signals.
Both of these relate to a bad scaling law (N^2) for electrical power on the shared line between diodes:
As the number of diodes increases the capacitance increases.
As the frequency of the analogue signal increases (to speed up contention resolution) the cusps on the curve representing the shared line are going to be higher frequency still.
Power has to be drained off the shared line by a resistor at a rate proportional to N^2, so the constant of proportionality better by very small to begin with or the number of contending cores will be impractically small.
I think the key to this ideas speed is that only the cores which are contending for access to a memory bank contribute to the time complexity. As opposed to a naive digital implementation which considers all of the cores, regardless of whether the cores are trying to access the bank.
What if the condition is in memory (i.e. L1/L2/L3 miss)? That can be a 1000 cycle stall for the pipeline. The “predication” trick works for a few instructions… not 100s (the waste of energy is unsustainable). Itanium proved that.
Sorry for being negative, but I could find any comparison between mill and conventional architectures able to change my mind.
I mean physical contention. When you have a shared media (iv.gr., a memory controller) and the requests start to pile up, latency grows exponentially. If the available bandwidth don’t scale with the computing elements, saturation kills your performance pretty quickly. This is well known from old shared bus systems.
Well yes, but out of order execution (OoO) computers have the exact same problem too. If the data you need is in RAM then your current thread is definitely going to stall. Neither static nor dynamic scheduling will prevent such a stall. OoO computers will try to schedule around the missing data but there is no way they’re going to fill in any where near a 1000 cycles of work with partially missing data.
Instead OoO computers will use “hyper-threading” to swap a different thread of execution into the CPU and hope that that the other thread has all of its data in-cache. Hyper-threading comes with its own trade-offs, mainly that it needs 2x the cache size to hold 2 threads worth of data. And since only one of the two threads can execute at a time, half of the cache is holding data for a thread which is in the “stalled” or “waiting-to-run” state.
Edit: the Itanium was revised in 2010 implemented hyper-threading. Itanium - Wikipedia
Sorry but no. That’s incorrect. 1st, you can speculate what path to follow (using the branch predictor. Branch predictors, which are populated with runtime information, are pretty good today… 98%+ accuracy ). Then, you have all the machinery (ROB, LSQ, etc…) to execute that patch speculatively (i.e. be able to roll-back if speculation was wrong). Current ROBs are 600+ entries… so you have room to keep going. Also, prefechers speculatively can fetch ahead the memory content.
Its called SMT or simultaneous multithreading and again, all your saying is not accurate. I think this thread is derailing from the initial discussion. I think it is not the place for these discussions. Current processors are something really complex. In any case, respectfully, if you are interested in computer architecture I suggest to you to take a look at J.L Baer [1]. Little great book. Not so recognized as H&P brick.
Yes, I know, and that’s why I pursued a single conductor, high frequency, analog resolution circuit. Did you bother to look at that circuit? What you are trying to do with OoO execution, speculative branching, etc. takes chip area that can be devoted to additional, simple, CPUs that go idle for a cycle or two in worst case. Adding memory banks to keep the ratio of CPUs to memory banks low is cheap with this architecture. Moreover, a lot of your OoO concern can be addressed along the lines of the Cyber 6600 score boarding which is very low chip area. (BTW, I worked at the Arden Hills CDC operations where I met Thornton and a lot of my thinking about the mutex circuit arose from Cray’s approach to memory controllers).
When you have a large number of CPUs and a larger number of memory banks with fast, low-area mutex crossbars, your effective memory latency is low and bandwidth is high.
Some round numbers: The Cray-1s vector computer had about 250k transistors in the CPU not counting vector registers. This is a ridiculously small number given the 50B transistor chips nowadays. 1000 Cray1s CPUs would be half a percent of the area. Add in the vector registers and you’re still probably talking an insignificant area. The rest is memory banks – lots and lots of memory banks with phased access resulting from vectorization. What happens when you have lots of memory banks phased like that is the CPUs tend to synchronize their vector streams once they hit a halt condition on a memory access – so they’re all marching across the memory banks at different phases and maximum bandwidth is approached. I don’t know what the ratio of CPU clock to memory latency would be but you can issue a bunch of memory accesses in sequence – one per CPU clock – and not have to worry too much about the already very low latency. As I recall from the national labs use of these systems, the tradeoff between vector and scalar operations was around length 3 or so – which is one reason you need the low latency: to service the short vectors and scalars.
If you have a memory bank to CPU ratio of about 5 to 1 on 50e9 transistors, you have 5000 memory banks each with about 10M transistors.