http://qs1969.pair.com?node_id=230500

JPaul has asked for the wisdom of the Perl Monks concerning the following question:

Greetings all;
I have a new project that I'm going to attempt to have a go at - I don't know about success, but then, it wouldn't be as fun would it?

At any rate, I've got a line on a Total Impact 'Total mPower 2' processor card. The long and skinny is that its a PCI based card with four 233mHz 604e PPC processors on it, sharing 128M of local SDRAM.
The system works by having you compile ELF binaries for the PPC processors, and using kernel modules to upload these binaries to the processors, which then execute them accordingly. No OS to get in the way, so to speak.
What I would _like_ to do is run a threaded perl application across the processors, which may or may not even be possible without an OS. I was thinking along the lines of perlcc'ing my source to C, and then using a cross-compiling gcc to generate the ELF binaries for the processors.

This is likely much more complex than I'm making it out to be. I'm sure I can make this application run on a single processor, but making it run on multiple processors while sharing the same data structures in local memory may not be be something achievable in perl.
The Total Impact website has more about the TPMP cards (Although the site is right now offline. Go figure.)
Anything anyone can throw into the void would be helpful, I'd also be interested in any involvement with these cards, perl related or otherwise, to get an idea how people have dealt with them in the past.

My thanks to all,
JP,
-- Alexander Widdlemouse undid his bellybutton and his bum dropped off --

  • Comment on Perl code to a multi-processor slave card: Total mPower 2

Replies are listed 'Best First'.
Re: Perl code to a multi-processor slave card: Total mPower 2
by robartes (Priest) on Jan 28, 2003 at 08:42 UTC
    Hi JP,

    ...pause while robartes attempts to stop drooling...

    OK. Fine now. Have you thought about getting the Perl interpreter compiled for these monsters? If you have a cross-compiling gcc set up, that should be doable (although possibly not easy).

    It then comes down to getting your scripts executed by the interpreter on the card, which I, not knowing the cards and with the website you quoted still unresponsive, have no idea on how to do :). It could involve everything from writing a wrapper around the Perl interpreter to do your I/O, modifying the kernel modules (if you have the source) or writing your own upload utilities.

    Sounds like a really interesting and fun project!

    CU
    Robartes-

[reply]
Re: Perl code to a multi-processor slave card: Total mPower 2
by JPaul (Hermit) on Jan 28, 2003 at 05:23 UTC
    For anyone wanting to salivate over a picture of one (Like I would):
    Pictures of a pair here.

    JP,
    -- Alexander Widdlemouse undid his bellybutton and his bum dropped off --

[reply]
Re: Perl code to a multi-processor slave card: Total mPower 2
by pg (Canon) on Jan 28, 2003 at 15:53 UTC
    I worked on the core network system for GPRS (2.5G wireless system) before. We used a similar environment, not the same type of card, but the binary is also compiled and loaded on to card.

    I don't really like your idea of directly sharing data among processes, this way of multi-processing has been proved wrong from a structural point of view, and largely reduce the maintainability of your application.

    For that GPRS system I worked on, we used both TCP and UDP to communicate between processes, it has been proved that performance was not a problem with TCP and UDP. Also we used stream at any tightly-coupled point (have to check whether your card support any thing similar to Unix stream.)

    (I think you made some typo, by saying multi-thread across multi-processors, any way).

    As for language, c is usually the best choice for this kind of project.

    Writing perl script and then compile into c might shorten the development cycle, but will definitely hurt performance. I would assume anything that runs on card, requires high performance and throughput.

    Also I would imagine that all the libraries, if any, you can find are in c.

[reply]
      The software that I'd like to run spits out data manipulations on a single very large data set (Well, alright, in the scale of things 70M isn't that large - but having to use multiple instances of a 70M structure?). Right now it runs in a single process (on a single processor), but I'm hoping to speed the whole mess up by splitting the component parts over processes (and thusly processors, by loading individual process binaries to a processor), but for it to work it would need to act on the same data set in memory.
      Having multiple sets would require they some how stay consistent, and a hell of a lot more memory than that card has on it.

      Communicating via processes using TCP/UDP would work, certainly, and is a good idea. I will investigate this further.
      I'm not sure what you mean by 'We used stream'. Details?

      As for speed; Keep in mind, this is a personal project - something I'm doing for "fun". I'm not so fussed about raw blazing speed, but rather to get it working on a platform somewhat faster than the one it runs on currently (A 200mHz Indy)

      JP,
      -- Alexander Widdlemouse undid his bellybutton and his bum dropped off --

[reply]
Re: Perl code to a multi-processor slave card: Total mPower 2
by mattr (Curate) on Jan 29, 2003 at 07:50 UTC
    Neat looking card! Sounds like you will be compiling perl to run on G3 or G4 (!) after reading this |page but it seems the thing is mainly designed to offload tasks from a program running on the computer's main CPU to run independently on the card's CPUs, as in rendering.

    But I am guessing you want to put all of Perl, not just some C program with a Perl interface, into the card because it is cool, etc. A Perl Accelerator (like this or as FPGA) would be insanely great!

    Caveat, I have absolutely no experience with this kind of thing. But I want to kibbutz anyway! And I feel encouraged by the TPMP2 manual section (pg. 14 of the linux manual) entitled, "There is no spoon". (!)

    Since they say the board doesn't actually run linux itself, some modules maybe just won't work, unless you could run maybe SMP linux on the card too. But assuming everything works as you need it, you're talking about running a different perl on each one.. so then how to tell each perl where the memory cache is? Maybe if you have one central perl program running on the motherboard you can have that spawn separate processes for the card's CPU's that way the children know where the memory is. Only problem is that the manual says the children won't be able to always see main memory pages so you might have to have one child set up the cache (in high shared memory) and report to the others where it is.. sorry I can't theorize more. If it works it'll be great..

[reply]
OT: S@H on Total mPower 2
by Mr. Muskrat (Canon) on Jan 28, 2003 at 15:46 UTC

    Any one know how long they take to process a Seti@home work unit?

    8^D

[reply]

Back to Seekers of Perl Wisdom