"Here is an email I sent to an alias we have at work which discusses everything I accomplished in using it
I've just spent a Saturday afternoon learning about Xgrid, and I
thought I would share the results. Part of my objective was just to
debunk the myth that you can just turn Xgrid on and suddenly it's
like you have more CPU's in your mac. The other part of my objective
was to figure out exactly what it takes to make use of Xgrid. Apple's
marketing talks a lot about how easy it is to set up Xgrid, and very
little about what you have to do to then use it.
Myths debunked:
So, the myth is certainly debunked. If you know anything about
parallel computing, then you know that a multi-cpu computer can't
figure out how to parallelize a task. It can only be given tasks that
are known to be independant, and then run them in parallel. What I
had hoped was that Xgrid uses the same logic that is in a multi-CPU
OS X box to distribute processes to multiple computers. I figured
even this was too much to hope for, and it was.
In short, all Xgrid does is take discrete tasks that you give it, and
farm them out to multiple machines. The onus is completely on the
user to break up a bunch of work (a "job") into separate tasks that
can be accomplished in parallel. You can also simply give it totally
unrelated jobs, and they will be distributed. Xgrid has no ability to
break up a single piece of work you give it into parallel tasks on
it's own, and it certainly doesn't sit in the background and farm out
processes over the network without your input.
Another important detail: the tasks that you give Xgrid are command
line tasks. For example, you can not use Xgrid to get iDVD to render
a DVD faster - not even if there are multiple separate video assets
that need to be encoded. It is possible for a GUI app to take
advantage of Xgrid natively. There is an API. I do not know in that
case if the tasks you give it have to still be command line, but my
guess is they probably do; since there is no interaction between the
controller and the agent until the task is complete, there would
hardly be any value to the task having a GUI. iDVD could
theoretically be written to break up it's work into multiple tasks
and submit them to Xgrid to be farmed out, but of course it has not
been so written.
Making use of Xgrid:
This simplest thing you can do with Xgrid is just give it a command
line to execute. If there are files and directories involved though,
this will not work b/c Xgrid needs to know what they are to
distribute them to the agent that gets the task.
The second simplest thing you can do is give it a command and specify files or directories to go with it, so they will be copied to the
agent for the work.
In both of the above cases, you get a single job with a single task
in it. If you submit multiple jobs, they will be distributed in
parallel, but a single job with a single task can't be broken up.
The more interesting way to use Xgrid is with a batch file. These
are .plist filex (XML underneath) which you can edit with Property
List Editor. A single batch file can specify many jobs, and each job
can specify many tasks. Each task can specify a command, arguments,
input files, output files, and lots of other things. You can also
specify a task "template" with a lot of parameters, and then refer to
that template in several tasks. In this case, each task need only
specify additional or different parameters from what is specified in
the template. Incidentally, you can also describe dependancies in a
batch file, such as if a certain task can't be executed until another
one completes.
I made a little batch file with 8 tasks in it, all of which were
"sleep" with varying numbers of seconds. In other words, I was able
to get a grid comprised of my mini and my PB to do nothing
approximately twice as fast as either of them can do that on their
own. It was pretty fun to watch the Xgrid Admin application heat up
both processors, farm out the tasks to them, and then watch the
progress bar move forward as each agent completed one of the tasks.
Basically what it boils down to is that if you have work to do that
is in a state where you could manually go to a bunch of different
macs and use the CLI to do parts of it in parallel, then Xgrid is a
great way to make that really easy to do, although building the batch
file for a new user would probably take as much time as farming out
the tasks manually. But if you have to do similar work repeatedly,
and the specs only vary slightly, then your batch file might be quite
re-usable.
My primary resources for this research were:
The xgrid cli command man page - man xgrid, or http://tinyurl.com/9r2qb
The Xgrid administrator manual
The macosxhints hint on using Xgrid w/out OS X Sever
Apple's Xgrid Technology Brief
-Avram
"
