[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]
On 25/10/12 12:51, Gordon Henderson wrote: > On Thu, 25 Oct 2012, paul sutton wrote: > >> sure sticking 4/8/16 pis in a cluster may not be of much use, BUT its a >> good opportunity for a group of us to get together, maybe with a few >> beers (or other drinks) play, learn and have fun at the same time. >> >> clearly at the end we would need to find some sort of app that would run >> to prove its using multiple processors. >> >> even if this is a simple programme to calculate PI. > > And there's the issue - just how to you break up a problem like > calculating Pi into something that will run on more than one processor? > > And that's the thing that's been the biggest issue all along. > > Some applications can parallise fantastically well - take mandelbrots > for example - you can divide the whole into squares and then get each > processor to calculate it's own little square of the whole by simply > giving it the x/y coordinates of the start and the size, then finaly > stitch the little squares together. This is how we generated > fantastically fast mandelbrots in the early days on transputers. > > Similarly for ray-tracing - you get each processor to generate a tiny > part of the whole scene. Each processor has the same data, the same > program, just a different x/y/z/limit starting point... > > Then things get complex - e.g. matrix multiply - where one result > depends on another result... > > Back to things like Pi - is there an algorithm that says: generate N > digits starting from digit Y? If there is, then throw it at X > processors and off you go... But if not, then it's diving deep into > the world of mathematics/comp sci. to work out a solution that will > parallelise effectively. > > Sometimes you take a different approach - one image construction > system I built had a pipeline of about 64 x i860 processors - each one > doing a small part to the whole image, then it would pass the data to > the next processor in the chain - which would do another tiny bit of > image analysis/enhancement, and so on - (the application here was > airport X-Ray scanners and synthetic aperature radar image > enhancement) the end result was that we got real-time results, but > with a bit of latency... For cases like that you then need ultra high > speed comms between the processors - something the early transputers > were good at (for the time). The Meiko CS2 box (no transputers, custom > comms chips) could xfer data at 75MB/sec any node to any other node - > slower than Gb ethernet today, but this was 20 years ago.. > > So it's not always easy. > > Other tasks you might want to look at might be parallel compilation - > e.g. my BASIC interpreter currently have 42 .c files - get 42 CPUs to > do the compile and it'll be 42 times faster (ish!) than a single > processor - of-course then other things start to be the bottleneck - > the underlying filesystem for example, and the final link stage can > still only be done on single processer for the most part... > > So throwing more processors at a problem isn't a magic bullet solution > - it needs thought and analysis of the problem - and that's why the > nerds cuddling their 30 year old FORTRAN programs wanted someone else > to do the hard work for them... And why companies the the Portland > Group are still going strong today... > > Gordon > Well the Pi thing was just an idea, maybe as a lug we can do something one day at a meet, that is pretty cool, like this, of course it will require serveral people to have Pis and of those people willing to actually bring them along. and I guess a specific linux build on sd card beforehand to make it work as a cluster, If the project mentioned before is anything to go by each Pi had the same software just configured slightly differently so everything would work together. Paul -- -- http://drupal.zleap.net skype : psutton111 http://www.linkedin.com/pub/paul-sutton/36/595/911 http://www.raspberrypi.org http://www.ubuntu.com -- The Mailing List for the Devon & Cornwall LUG http://mailman.dclug.org.uk/listinfo/list FAQ: http://www.dcglug.org.uk/listfaq