What is the reason Parallella isn't blazing a trail ?

[piotr5]

if you really are in favour of a simd epiphany then you haven't understood what I meant when I said it's cheating. the point of adapteva is that simd can never be used to full extent, mimd can. it's true that the size saved could be turned into memory, but I doubt there will ever be more than 64Kb per core. on x86 it is rare to find any in-core-cache bigger than 64k, 64k is happy with some 16-bit addressing, and instructions coping with 17 bit but not 32bit are rare -- so I guess in terms of hardware it is awkward to implement. what could happen though is adapteva adds some of amd's hbm-chips on top of epiphany to provide some sort of 2nd level cache. if then the connection between arm and epiphany could be increased to appropriate speed then this actually could become the main memory instead -- the only problem is to do this in open-source hardware...

so, I said I'd like them to go simd just because it would attract all those idiots who believe simd to be the future, of which there are many. as was said in the tokyo-talk, for server-people to notice you the processor either needs x86 compatibility or it must be simd with compatibility to the graphics-cards. with risc-processor the latter truely is a possibility. sadly the most attractive solution isn't always the solution that will survive in future, peers can err, the hievemind isn't infallible. take for example vhs and whatever other tape-format: it's cd which survived, at least its aspect of having some digital data-format! it simply is the most pragmatic solution. now, how long did it take from invention of cd to actually fully substituting tapes? at least in theory it always takes a new generation to introduce new technologies to the leading players. so be patient with adapteva...

as for architectual limitations, also here you shouldn't confuse limitations in hardware with limitations in software. epiphany programs are not in elf-format therefore there is no relocation-table. therefore you need to compile each program to be stored on a particular core. same with the setup I suggested: you'd need to write the administrative code on your own since this hasn't been done before. is that really a limitation in hardware? is a risc-architecture limited just because you're supposed to emulate in software or fpga what cisc processors do in hardware? epiphany is a risc processor with 32k cache per core but without actual cache-management on-chip! and if you choose to implement such cache-management in fpga, you'd end up wasting much more energy than if it's done in software. that's the whole point of risc in various aspects of its simplicity!

[mhonman]

[piotr5]

thanks for the history lesson on risc, didn't know. always thought risc was just some nostalgia project by people who dislike the growing complexity of the assembler language. as for current use of risc-command-set, as I understood that's for energy-efficiency. better let multiple risc commands execute one after the other than to have hardware specialized in the task.

speaking of hardware, what's the point of simd? I believe everything that can be done in simd could also be done in hardware, but much more efficiently. you want to find out what colours some light has? put it through a prism! as I understood this is the actual purpose of fpga, to give access to some plugged in hardware doing your calculations more efficiently than simd ever could...

you advocate simd and mention sse, are you working for amd intel? if you love simd, then use amd's apu, ingenious invention. my bet is on mimd though. I agree that hardware solutions can save on complexity, but fact is that by implementing some hardware specialized to do some work in parallell to the main processor you buy a speed-up at the cost of doubling the power-consumption. you effectively have 2 processors occupied with your programs and one always is either doing what it's been hardcoded to do or is idle when nothing needs to be done. so on epiphany it means you'd have an 8-core processor with 8 additional cores occupied only with cache-management. I personally prefer to program those 8 additional cores to do other stuff in their spare time. this way maybe the burden of complexity is put on the software-developers instead of the hardware companies. however, times have changed, modern tools are ready for that task. and if that isn't enough, create an open-source project. if you see limitations in hardware, other developers might see the same, so they too will contribute to the open-source projects you create. don't you think? why keep re-inventing the wheel on your own and then keep that invention secret?

[mhonman]

The point of "massive" SIMD (GPGPU, Connection Machine, etc.) is that it works very well for problems where there is an underlying multi-dimensional structure to the data, with "almost" the same computations being carried out at each cell in the computational mesh. A lot of HPC is like this, and aims to solve truly massive problems that scale acceptably on GPGPUs. Although I've never programmed a SIMD system, I understand that certain nodes can be made to skip instructions via "condition codes". A conditional operation only generates results if the condition code is right - this approach is also used in VLIW architectures and some RISCs (ARM for example).

As for me, I'm a parallel/distributed applications guy and will write code for whatever architecture the customer fancies. So I like to learn the strengths and weaknesses of each architecture, so as to get the best performance. I work for a high-end embedded hardware manufacturer specialising in heterogenous DSP and FPGA systems. We are always on the lookout for new processors that will make our customers' lives easier (to sell hardware, we need to offer something that is better value than what presently exists).

I feel that we are now quite far off the original topic; clearly we disagree about why Parallella hasn't been a trail-blazer but I hope that the discussion will have give Adapteva some food for thought.

Since I don't have any other feedback that I think would be helpful to Adapteva, I'll be signing off now...
Mark