Show me the actual language that functionally runs this "logic in memory" or those "hardware accelerators".
You don't understand what a hardware accelerator is. There is no language. There is only a thin layer of programmable registers, typically. That is what we do when we really want performance that a softcore/processor cannot deliver. Furthermore, we can use logic-in-memory to make these accelerators even better, with distributed and smart memory access that is orders of magnitude better than multi-level cache.
This is the NORM for any and all modern SoCs: a bunch of cores and some memory, with the heavy load pushed to specialised accelerators. Show me how your tremendously naive architecture can perform better than a god damn specialized accelerator, I dare you. You can't, because that is impossible. Show me how your extremely naive architecture can replace the cores we have on today's SoCs, I dare you. You can't, because no one is going to write software differently such that it fits your architecture.
Congratulations, you achieved a grand total of zero innovation.
Dead topic, please close.
Let me know when someone funds this... yawn.
"Someone is wrong on the internet, I cannot rest!"
A visionary? Dear lord, you surely think highly of yourself.
Parallel processors are implemented in today's computers. To the degree it speeds things up, they are an assist, of course. However we don't see ads for a computer 'containing not 2, not 4, but 23 CPUs!' Not yet anyway. It turns out that computer design has changed along the path that suits a global market overall. A revolutionary design needs to adjust to real-world situations. It would be nice if we could split up all theoretical chessboard scenarios (eight moves deep), among 23 processors each one playing out a different scenario. But they need to be connected electronically. Wiring them together sounds like a formidable job, don't you think? Whereas they did manage to build a Deep Blue computer years ago in real life, which beat a chess grandmaster.
And it did it byan algorithm of examining all possible scenarios several moves deep.
I find myself torn between two choices here. 4P seems to be a mix of different workable technologies but not a complete answer to any of them. The concept of massive parallel processing is not new, Inmos tried it with the 'Transputer' processors which in theory were expandable but, fast as they were, all they really did was pass the bottleneck to the arbitration hardware. Something still had to decide which Transputer did which task.
I also see similarity to bit-slice processing (for those aged under 100, it was a a single bit programmable arithmetic module) which again was expandable but mostly due to the technology of the day, was power hungry and limited in speed by it's size.
If the 4P is an expandable array of 'normal' CPUs it may have massive processing power and ability to handle simultaneous instructions but how do those instructions get passed to the core? If it is in the fastest possible way, as in the instruction bus of Harvard processors, the instruction width is the same as the bus width so expanding it would require 'wider' instructions or some other mechanism to steer the instructions to the destination processor.
More processing power is obviously appealing but how do the smaller component cores cooperate with each other without some supervisory mechanism still slowing things down?
Brian.
I find myself torn between two choices here. 4P seems to be a mix of different workable technologies but not a complete answer to any of them.
Requesting even more clarification: I'm still mixed about this, we both see the pitfalls of simply adding more land to the farm. It doesn't make it more productive if you haven't got the ability to bring a bigger harvest in.
Are you proposing 'parallel programs running simultaneously' rather than 'parallel processors running one program'? In other words duplicating the building block of a bigger system into the architecture of a single silicon device. That seems to be VLSI with more than one core embedded into it. If that is the explanation, passing the program to each individual core would be a huge task and re-programming on the fly would hold up other processes as it took place. Besides, unless the sheer scale is different, that technology has been around for years and is used in almost all Intel/AMD/ARM and other devices.
Brian.
Sorry about the disabled messaging, I started getting as many as 300 messages a day from users and it simply became impossible to read them all while busy working on other things. I had no option but to turn it off. All the moderators here are volunteers so we have to weave our duties into available free time.
Also sorry about censuring, we (moderators) have a difficult task of keeping the forum dedicated to the intended purpose and we delete many messages every day. Most are pure spam but we also have a significant number of 'repeat offenders' who deliberately post technical but poorly thought out questions with no apparent purpose but to waste our time. We also see some very good and topical questions that contain links to examples that sell certain 'health supplements' so we have to be very careful to check and filter what gets shown to readers. Sometimes we get it wrong.
Brian.
I understand and empathize.
This is a good forum for a good purpose.
I gladly forgo minor inconvenience from time to time for the greater good of keeping the discussions technically relevant leading to better discourse as I find is the case here.
Could you please provide the transistor count for a DFF with scan?
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?