Slashdot Mirror
Xgrid Agent for Unix
mac-diddy writes "Someone on Apple's mailing list for Xgrid, Apple's clustering software, just announced an 'Xgrid agent for Linux and other Unix platforms' available for download. There are still some issues being worked on like large file support, but it does allow you to simply add a Unix node to your existing Xgrid cluster. Just goes to show that when companies embrace open standards and code, the world doesn't fall apart."
Somewhat silly, but wouldn't you incur a bit of overhead mixing machines of different endian-ness? I suppose for non-communication intense algorithms this wouldn't be a big deal.
Not really. Everyone uses network byte order for communication, so you won't have more overhead in a mixed system than you would in a homogenous system.
"They redundantly repeated themselves over and over again incessantly without end ad infinitum" -- ibid.
In the past, as I have moved between jobs, I've written a number of Object->relational mapping tools.
After a while they cease to become fun to write, and you'd rather just get on with writing code that does something instead of infrastructure. By using and contributing to OSS projects, you can use the same code no matter what company you end up at. Because the code is portable it can become part of the package you can offer to a potential employer - they not only get an employee but potentially one that can producive almost right away because they are familiar with the tools they'll be using, with no cost to the company for said tools.
So it makes life easier for you, less re-work. And it makes life easier for employers, as they get richer products sooner. And if the employee becomes really proficient at a widely used OSS project they can write their own way through consulting or training.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
You don't need XGrid for faster compilation - Developer Tools already includes distcc
"[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz
Well firstly, since Windows is more then just a kernel, just because the Dev kit has it does not mean Windows as a whole does. Secondly, Athalons, P4, Celerons and Xeons are all the same architecture, ia32. If you had used the P4 and say, Itanium or Opteron/A64 you would have a point, which is why I qualified the statement in the beginning with 'to a large extent.'
"I use a Mac because I'm just better than you are."
Actually, no it is quite feasible if you do it on a large scale and depending on what you use the cluster for. Big Mac and the Army cluster are two examples of where a mac cluster can be cheaper.
Jesus was a compassionate social conservative who called individuals to sin no more.
This troll is getting old. MS does not and never did own 40% of Apple. They bought a large chunk of non voting shares in exchange for making IE Apple's default browser. As soon as the 3 year contractual agreement was up, MS sold the shares, and for a decent profit.
I wouldn't say that - I find it pretty amusing you've been registered at ./ for so long and are still so wrong.
p.s. I know I should reference - how about 'MS owns fuck all anymore' - will this do?
The Mothership
Not quite. "Network byte order" is big endian. So on big endian ppc's, which macs are, all those "ntos" macros, etc., expand to NOPs. Once you introduce little endian machines into the mix, they start doing real work to transform internal representations for the wire.
The real tragedy is when you have homogenously little endian machines; e.g., a network that only has PCs on it. An integer gets byteswapped twice to end up in exactly the same byte order it was all along.
Can anybody confirm if the linux and unix ports are smp aware?
(I wrote the xgridagent).
As the other poster said, XGrid does not care what the binary does (so it can be smp aware, multi-threaded, whatever). However, the xgridagent itself is not explicitly smp aware, but it is multi-threaded. Each task is started in its own thread and depending on the OS(?) I guess they could spread to other CPUs. The other aspect of the question is "Does the Unix XGrid agent support MPI like Apple's GridAgent for OS X?". It does not and I can't say for sure how difficult it would be to support it. However, since all communication is done via the XGrid protocol, I don't see what would prevent it from being implemented. BUt other things need to be done first.
The most pressing issue is to fix the annoying "large message" issue which makes the agent hang (while it waits forever for the controller to accept more frames). I am convinced it is trivial, I just don't know enough about BEEP to fix it. I am hoping somebody who knows BEEP will take a look at xgridagent-profile.c and fix the xgridagent_SengMSG() function and send me the patch.
Daniel Côté
To utilize Xgrid, the application has to be written for it
Not so, not so.
If your problem is embarrassingly parallel, chances are you can use Xgrid to run it right now.
For example, let's say you're rendering a 3D animation. (I haven't done real 3D work since the PowerAnimator days, so pardon me of some of my jargon is antiquated.) You've got a scene file on which you can run a render command. A command-line argument tells the renderer which frame to render.
No problem. Just use use Xgrid's Xfeed plugin. Xfeed lets you set up a job that runs a single command with a variety of command-line arguments. You tell Xfeed that you want to run the "render" command with "-f" and the numbers 1 through 720.
Xgrid goes to the first available machine on the grid and says, "Run render -f 1." Then it goes to the second machine and says, "Run render -f 2." And so on, until there are no available machines. Then it waits until a machine becomes available and says, "Run render -f n."
As each output file (a frame, in this case) becomes available, Xgrid (the client application itself, I mean) collects them in whatever directory you specified when you submitted the job.
The cool part comes when you realize that this isn't a cluster. It's a grid. That means machines can come and go as they please. If this job is running overnight, when I come in the next morning and sit down at my workstation, the agent on my computer stops the job and de-registers itself. The job goes back in the controller's queue for processing on whatever the next available machine is.
And you don't have to have any special software for this. It can be done right now with the tools that already exist in Preview 2.
I write in my journal
The other packages require a bit of planning, whereas Xgrid excels at locating nearby resources for pawning off processing tasks. Rendezvous (ZeroConf) is exactly about the need for ad hoc networking. Xgrid extends that to the cluster...
There exists no way of exchanging information without making judgments. --Bene Gesserit Axiom
Here are three gotchas that can make this sort of thing less appealing than it may seem at first:
Problem type: The problem may not be well suited to running on a bunch of PCs (especially when the agent app isn't allowed to take 100% of the machine's resources to accimplish the task) over typical office networks. Basically if the app needs to communicate frequently with other nodes, or if a huge data set is involved (or both), latency or bandwidth issues might outweigh the possible advantage of putting more CPUs to work.
Security: The data may be highly sensitive, in which case you might not want to put it on ordinary desktop PCs that might have untrustworthy users, spyware, etc.
Configuration: The configuration of your office's PCs may vary enough to make the cost of getting a companywide desktop cluster working unacceptably high. You'd have to pick a few target configurations and settle for that. Hopefully drivers and such wouldn't matter as much as CPU, RAM, disk, and OS version, but there are still companies that are just now getting their desktops updated to Win2K. There's also the headache of installing yet another required application on a large number of heterogeneous machines, which is virtually guaranteed to result in confusing installation problems. Oops, our app crashes if the user has this or that service pack installed. Oops, our app requires strong encryption. You could build your app on top of some sort of moderately portable framework or VM or whatever but that will have system requirements too, and probably will have some surprising gotchas when deployed in a real-world environment.
If Apple breaks this intentionally (meaning not for adding significant, enhanced functionality) in their next release, I will stand with you as an anti-Apple nay-saying zealot and deride them all up and down /.
-Potentially recovering Mac zealot (it's so hard with WWDC right around the corner :-( )
sigs are for fools and trolls. no signature is *always* appropriate. you should turn them off in your preferences.