massively parallel stm32duino blue pill

[turboscrew]

Too bad that blue pill doesn't have enough similar communication HW to make a "transputer".

[ag123]

well if you are happy with spi and/or i2c and/or uart you could get quite close to the 80s standards with BP,MM and maybe exceed it
https://en.wikipedia.org/wiki/Transputer

[mrburnette]

Scalable cluster using ESP32 & RPI to orchestrate.

Github

The Raspberry Pi does the heavy lifting; ESP32 nodes builds out an elastic cluster.

It is my opinion that a similar approach could work for bluepills. At current prices, the dual-core ESP32 is likely the winner in cost-performance, but if one has a drawer full of STM32F103's already, then the math could shift in favor of the STM device.


Ray

[ahull]

The ESP32 has the advantage of being multi-core, and so far as I am aware, none of the low end STM32 devices are, so while it may cost more, the ESP32 is faster and gives more bang for your buck.

Having said that, an array of say 512 bluepills, would give you a Vax MIPS rating of about 24990.72 (would that be 25 Vax GIPS ) so you would have a moderately quick 512 node massively parallel array for around $1000 which aint bad.

[zoomx]

I believe that it should be compared with a GPU.

[ahull]

I believe that it should be compared with a GPU.

True, but I guess it depends on the tasks you are trying to perform.

[mrburnette]

I believe that it should be compared with a GPU.

True, but I guess it depends on the tasks you are trying to perform.

The silicon has not evolved (yet) to pick GPU over CPU ... it is all about architecture. Future silicon is likely to muddy the waters more.

However, when thinking about such things, the $5 rPi Zero provides both CPU and GPU, Linux, and enough RAM to build a seriously powerful cluster. As the rPi Zero is a "real" Linux machine, traditional clustering techniques apply as does off-the-shelf enabling software.

Attempting to "cluster" a bunch of blueboards would in itself be a cluster, IMO. What you would end up with is a BIG I/O box... maybe we need to coin an acronym to describe such a box: MIIO or M2IO for Massively Intergrated Input Output and we could think of that as a front-end processor to a more conventional Multi-CPU machine. Multiple CPUs would spawn directed I/O requests from the little subordinate boards and local CPU power would validate and configure the datagram for easy transmission and digestion by the master computer; thus the little I/O CPU would off-load much of the "dirty" handshaking, data validation, and formatting of I/O data.


Ray

PS: I'm not really active in the STM32 space much anymore, but an injury to my dominant hand has temporarily prevented me from touch-typing and coding (quickly) ... I do seem to be OK with one-finger poking on my Android tablet, however. The only good outcome from the injury is that I am getting spousal assistance with yard work this summer.

[ag123]

as it turns out there is an ancient effort which has 'been there done that' it is - the connection machine
https://en.wikipedia.org/wiki/Connection_Machine
and the forgotten thinking machines corp
https://en.wikipedia.org/wiki/Thinking_ ... orporation
the idea is MIMD (multiple instruction, multiple data)
https://en.wikipedia.org/wiki/MIMD
i'd imagine that to do FFT (fast fourier transform) you could broadcast the data on i2c bus, all the bp/mm read the same signal
or for that matter distribute it to the bp/mm round robin on the usb bus, usb-serial would do
then each bp/mm does its share of work, oh but then you'd still need to collect them up again
erm maybe that can be done by the host perhaps let that be a raspberry pi 3 or beagle bone black
so that collects the result and present the fft results say in a graph

[paulvdh]

To me it seems that this idea would be a quite silly exercise, and that is probably the most important reason it has not been done before.

1024 devices on a 7 bit I2C address bus?
There are some extensions to I2C, but still the bandwith would be too small for such numbers of devices and you will violate the capacitance limit of the I2C bus.

STM32 does have quite a lot of higher bandwidth busses available. From USB, I2S, SPI, to the humble UsART.
As a "fast computation box" the exercise would be quite pointless, but as a distributed I/O network with per-node computation capabilities it does make sense. And the combination of UART & RS-485 drivers is an quite effective combination for that.
Have a look at the big LED installations that Mike Harrison makes:
https://www.youtube.com/user/mikeselectricstuff/videos
Some of the big distributed LED installations he designed have 100.000 LED's and a distributed network of processors.
Recently I saw a video of a splitter box with Ethernet input, because he ran out of bandwidth with RS-485.