I've heard this song before. RISC was supposed to be far more efficient than CISC, and magic compilers were the key to making that happen. It didn't really turn out that way in the end.
Pretty much every high-power high-efficiency core (whether x86 or arm or PowerPC or whatever) breaks instructions up into an extremely reduced instruction and executes those. There was a point where Pentium processors were effectively just executing RISC. There's a great write-up about it here: https://fanael.github.io/is-x86-risc-internally.html
Is this the return if Itanium? static scheduling and pushing everything to the compiler it sounds like it.
No, but multiple GPU shader architectures use VLIW instructions. It's totally doable with modern compilers, but it's only adventageous to parallelizable tasks, hence the use in GPUs.
Though I'm sure this is valuable in certain instances, thinking about many embedded designs today, is the CPU/micro really the energy hog in these systems? We're building an EEG headband with bone-conduction speaker so in order of power, our speaker/sounder and LEDs are orders of magnitude more expensive than our microcontroller. In anything with a screen, that screen is going to suck all the juice, then your radios,…
The question for any given application is: How slow does the processor need to be, before its power consumption is no longer a factor?
Increasing the processing power at that near-marginal power consumption broadens the range of battery-powered applications that are possible.
That minimizes the data transfer distance from that bit of memory to that bit of compute. But it increases the distance between that bit of (memory and compute) and all the other bits of (memory and compute). If your problem is bigger than one bit of memory, such a configuration is probably a net loss, because of the increased data transfer distance between all the bits. Your last paragraph... you're right that, soon…
So do both. Put a bunch of small processors on every DIMM.
Long ago I thought that, at least for very generic / task-agnostic operations such as wiping, moving, duplicating chunks of memory, a chip-on-dimm could be of use (but maybe this is already the case and I don't know about it)
So do both. Put a bunch of small processors on every DIMM.
Long ago I thought that, at least for very generic / task-agnostic operations such as wiping, moving, duplicating chunks of memory, a chip-on-dimm could be of use (but maybe this is already the case and I don't know about it)
And encryption, hashing. Hashing could be used for deduplication and caching.
Long ago I thought that, at least for very generic / task-agnostic operations such as wiping, moving, duplicating chunks of memory, a chip-on-dimm could be of use (but maybe this is already the case and I don't know about it)
And encryption, hashing. Hashing could be used for deduplication and caching.
I've heard this song before. RISC was supposed to be far more efficient than CISC, and magic compilers were the key to making that happen. It didn't really turn out that way in the end.
Pretty much every high-power high-efficiency core (whether x86 or arm or PowerPC or whatever) breaks instructions up into an extremely reduced instruction and executes those. There was a point where Pentium processors were effectively just executing RISC. There's a great write-up about it here: https://fanael.github.io/is-x86-risc-internally.html
Yes, I knew that. Was thinking of mentioning it but decided it muddled the message. RISC didn't win in the end, it just created techniques that got borrowed to make CISC better.
Though I'm sure this is valuable in certain instances, thinking about many embedded designs today, is the CPU/micro really the energy hog in these systems? We're building an EEG headband with bone-conduction speaker so in order of power, our speaker/sounder and LEDs are orders of magnitude more expensive than our microcontroller. In anything with a screen, that screen is going to suck all the juice, then your radios,…
The question for any given application is: How slow does the processor need to be, before its power consumption is no longer a factor? Increasing the processing power at that near-marginal power consumption broadens the range of battery-powered applications that are possible.
particularly solar/outdoor/remote applications. I run ESP32s from super-cheap USBC solar panels with integrated battery/BMS for various measurements, keeps them running 24/7 regardless of weather due to how little they consume. They pop on every 4 minutes, power the sensors, connect to the WiFi network, beep out their data, then go back to sleep. Seeed's ~$6 ESP32C3/C6 boards have onboard BMS for 3.7V cell even, if I didn't prefer the integrated panel/battery method.