wow, that's hilarious, thanks for that luke On 29 December 2016 at 08:19, Luke Kenneth Casson Leighton <[email protected]> wrote: > --- > crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 > > > On Thu, Dec 29, 2016 at 8:03 AM, Lauri Kasanen <[email protected]> wrote: >> On Thu, 29 Dec 2016 00:44:33 +0000 >> Luke Kenneth Casson Leighton <[email protected]> wrote: >> >>> thats interesting. i worked for aspex semi in 2003 and they had the exact >>> same problem, programming ultra parallel devices is limited to a few >>> hundred competent people in the entire world. >>> >>> interesting to me because ericsson bought aspex. >> >> Surely that's changed now, with the ubiquity of modern GPUs? It's >> entirely normal there to handle hundreds or thousands of threads at >> once, at massively parallel workloads. > > for the ASP: no. not a chance. it was a massively-parallel (deep > SIMD) *two bit* string-array processor with (in some variations) 256 > bits of content-addressable memory, that used "tagging" to make the > decision as to whether any one SIMD instruction was to be executed or > not. > > it was so far outside of mainstream processing "norms" that they > actually had to use gcc -E pre-processing "macros" to substitute > pre-defined pipeline-stuffing c code loaded with hexadecimal > representations of assembly-code instructions to be sent to the SIMD > unit. > > a similar trick was deployed by ingenic for their X-Burst VPU: their > pre-processing mechanism is a dog's dinner mess of awk and perl that > would look for appropriate patterns in pre-existing c-code, whereas > Aspex's technique was to just put capitalised macros directly > interspersed in c code and let the pre-processing phase explicitly > take care of it. > > it was utterly horrible and insane, and it was only tolerated on the > *promise* that, at the time each architecture was announced, it could > do *CERTAIN* tasks at a hundred times faster than the AVAILABLE > silicon of the time. > > of course... by the time each architecture revision actually came out > (18 months + later) the speed of pentium processors had of course > increased so greatly that the gap was only 20, 10 or even 5 times > greater.... > > to write code for the ASP you measured the number of lines of code in > DAYS per line of (assembly-style) code. you actually had to write a > spreadsheet to work out whether it was more efficient to map the > operands into single-bit linear per processor or to use the "string" > feature to process operands spread out in parallel across mulitple > neighbouring APUs. > > the factor which made this analysis so insanely complex was that the > "load and unload" time had to be done linearly using a standard memory > bus, and was a looong time relative to the clock rate of the APUs. > thus, if you only needed to do a small amount of computation it was > best to use the single-bit technique (4,000 answers in a slower time, > to match the "load and unload" time), but if you had a lot of > computation to perform it was better to use the parallel technique, in > order to keep the little buggers busy whilst waiting for load or > unload. > > ... or... anything in between. 2,4, 5, 6, 8, 12, 24, 32, 64, 96, 128 > or 256 bit parallel computation, it was all the same to an > array-string massively-parallel deep SIMD *bit-level* processor. > > but it made programming it absolutely flat-out totally impractical and > even undesirable, except for those very very rare cases, usually > related to the ultra-fast content-addressable-memory capability. > > i.e. extremely, extremely rare. > > putting a "normal" c compiler on top of the ASP, or porting OpenCL to > it, would be an estimated 50-man-year research and programming effort > all on its own. just... not worth the effort, sadly. > > l. > > _______________________________________________ > arm-netbook mailing list [email protected] > http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook > Send large attachments to [email protected]
_______________________________________________ arm-netbook mailing list [email protected] http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to [email protected]
