Xgrid and the Tiger Client?

s6275s6275
Posted:
in macOS edited January 2014
When Xgrid originally saw the light of day, I decided to upgrade to Tiger for that feature alone, since it seemed to allow any Tiger-equipped Mac to share its processor with any other Tiger-equipped Mac for any app that supports Xgrid.



Then, and I don't remember where, I read that only Tiger Server-equipped machines could send jobs to Client machines, and that Clients could not directly connect to other Clients in an Xgrid without the presence of a local Tiger Server in the mix somewhere.



Can anyone shed some light on this? Apple hasn't been clear on this matter, either accidentally, or purposely. However, it wouldn't be the first time that they drastically underestimated the importance of one of their features to the public...

Comments

  • Reply 1 of 7
    karl kuehnkarl kuehn Posts: 756member
    I think there might be a bit of confusion here. Unless Apple is massively changing the way XGrid works there is no requirement for MacOS X Server, but there is the concept of "master" computers that start and control jobs and "worker" computers that execute those jobs. The "worker" computers don't really talk to eachother, and there are a lot of settings about who in a grid can take the roll of "master" (along with who can join an existing grid in the first place).



    All of this is using the BEEP standard... so unless Apple goes away from that (and makes themselves proprietary... well more proprietary) none of this is a worry.



    And just to clear up a possible misconception: XGrid enabled apps are going to be few and far between. They are almost always going to be custom-built apps for people in scientific research or engineering development. This is not for games. There is a chance that the technology behind XGrid will make it into video processing (and 3D rendering), but that will probably be an adaption of the technology and not visibly XGrid. The reason behind that is in XGrid the processing software needs to be automatically downloadable from "master" computer by the XGrid "worker", and video codecs normally have licensing requirements that that just doesn't work with.
  • Reply 2 of 7
    s6275s6275 Posts: 19member
    Crap. Sounds kinda like AltiVec, which, if I am not mistaken, wasn't as widely adopted as Apple would've liked.



    Too bad Apple can't figure out a way for the OS itself to notice things that would benefit from AltiVec, or Xgrid, processing, rather than making developers write code into their apps to support it.



    Oh well. I knew my interpretation of Xgrid sounded too good to be true. Although, I still have one question: if Apple didn't intend for it to be usable by the masses, why build it in to the next OS? I could understand if it came with an OS X Server license, or was separately downloadable, but built in to every version of Tiger sold? Maybe they have something in mind that hasn't been revealed yet..?
  • Reply 3 of 7
    karl kuehnkarl kuehn Posts: 756member
    AltiVec and XGrid are on opposites side of the spectrum when it comes to the sort of data they are good for. AltiVec is best at tasks which involve a wide data set that needs relatively simple transformations applied to it. XGrid is much better at smaller data sets that require a lot more work on every atom of data. The similarity is that both work on data sets that have some "parallelism" in them (you are not working on events that have to depends on each other, so you can do them side-by-side conceptually).



    And both of them do require that you specifically program with them in mind. There is a lot of work going on right now experimenting with auto-vectorising compilers that will automatically use vector operations (like AltiVec) when they can be applied. That will simplify the process somewhat (and allow for cross-compiling for both AltiVec and the MMX inheritors without someone hand tweaking everything), but it is not going to change the requirements that the process be parallelized, that is still going to require a programmer to know how to arrange the structure. And then there is the fact that most programs just are not going to benefit.



    Oh.. and AltiVec is used exactly were it should be: PhotoShop filters, and a number of video codecs used by Apples video suite. It would be nice if more programs used it, but that is where it counts.



    The same is true for XGrid: this is a complicated idea and requires that the programmer do the work of setting up the structures. Once those are in place XGrid can do all of the heavy lifting of coordinating the job.



    As to why build it into the OS? Well, it is not so much built in as included. And at that point, why not. It will probably be include the same way as MacintoshManager/Apple Remote Desktop has been since MacOS 8.6: it is on the install CD.
  • Reply 4 of 7
    mpmoriartympmoriarty Posts: 289member
    So just so I can get it clear in my head, Xgrid won't allow me to simply turn my few Macs at home into a processing cluster automatically. Even if I assign what roles each machine have, I have to be running an application that supports Xgrid or I won't be able to take advantage of any free CPU cycles on another Mac on my home network.
  • Reply 5 of 7
    karl kuehnkarl kuehn Posts: 756member
    MPMoriarty: I don't know what would give you the idea that most applications could even benefit from being run in a cluster. Programs have to be very carefully designed so that running them like that does not slow them down. even the schedulers that allow for symmetric multiprocessing (think dual processors) with any real efficiency are nasty beasts, and that has a ton of hardware thrown at it on processors that support it (for example you cannot run two Pentium 4's together for that reason). The task of trying to generalize that sort of thing so that it works across a network will probably take the next 10 years to properly sort out (there are a number of research projects out there, look for "non uniform memory architectures" or NUMA, that is the part of the problem that people are tackling right now...).



    XGrid has always been about the scientific research community that needs to build massive clusters to get insanely large computations done (we are talking about things that take days or weeks to run even on 1,000 node clusters). It requires someone with a fair bit of knowledge in a specialized form of programming to get any use out of it at all. There are lots of people with that sort of knowledge in academia, and XGrid provides them a simple-to-use framework to mange those jobs once the program is completed.



    An XGrid-like system is useless for things like: games, image processing (except in insanely extreme cases... we are talking terabytes here), word processing (or anything else that has a user interface). The only possibilities for this to make it into a home computer are: things like SETI@HOME (this uses a self-rolled system that works like a limited XGrid... it is unlikely that any project like this would do anything different), theoretically it could be used for rendering video for burning on a DVD (but this would probably take the ideas and build a proprietary version into the product), 3D scene rendering (there are already several product that do this, including Pixar's Renderman... another case where it would be built into the app).



    Executive summary: XGrid is for specialty scientific applications and is very valuable in that field, but will not impact most people's lives directly (notice the word 'directly').



    Oh... I almost forgot, XCode also uses something like this for distributed builds, but you really do have to have fast computers and a fast network for it to actually be helpful... Or you have to be compiling really large codebases... Like PhotoShop for instance... or MacOS X 10.4... (hint, hint).
  • Reply 6 of 7
    kickahakickaha Posts: 8,760member
    Agreed. I use it in my research, and love it, but even then I had to be extremely careful to tune it for specific instances of data sets, and revert to single host use under a certain threshold.
  • Reply 7 of 7
    mpmoriartympmoriarty Posts: 289member
    Quote:

    Originally posted by Karl Kuehn

    MPMoriarty: I don't know what would give you the idea that most applications could even benefit from being run in a cluster. Programs have to be very carefully designed so that running them like that does not slow them down. even the schedulers that allow for symmetric multiprocessing (think dual processors) with any real efficiency are nasty beasts, and that has a ton of hardware thrown at it on processors that support it (for example you cannot run two Pentium 4's together for that reason). The task of trying to generalize that sort of thing so that it works across a network will probably take the next 10 years to properly sort out (there are a number of research projects out there, look for "non uniform memory architectures" or NUMA, that is the part of the problem that people are tackling right now...).



    XGrid has always been about the scientific research community that needs to build massive clusters to get insanely large computations done (we are talking about things that take days or weeks to run even on 1,000 node clusters). It requires someone with a fair bit of knowledge in a specialized form of programming to get any use out of it at all. There are lots of people with that sort of knowledge in academia, and XGrid provides them a simple-to-use framework to mange those jobs once the program is completed.



    An XGrid-like system is useless for things like: games, image processing (except in insanely extreme cases... we are talking terabytes here), word processing (or anything else that has a user interface). The only possibilities for this to make it into a home computer are: things like SETI@HOME (this uses a self-rolled system that works like a limited XGrid... it is unlikely that any project like this would do anything different), theoretically it could be used for rendering video for burning on a DVD (but this would probably take the ideas and build a proprietary version into the product), 3D scene rendering (there are already several product that do this, including Pixar's Renderman... another case where it would be built into the app).



    Executive summary: XGrid is for specialty scientific applications and is very valuable in that field, but will not impact most people's lives directly (notice the word 'directly').



    Oh... I almost forgot, XCode also uses something like this for distributed builds, but you really do have to have fast computers and a fast network for it to actually be helpful... Or you have to be compiling really large codebases... Like PhotoShop for instance... or MacOS X 10.4... (hint, hint).



    I'm sorry. I was just asking a general question.



    I was just curious is someone could use this to speed up video rendering and such. I didn't realize that Xgrid was only for the scientific communities.



    Mike
Sign In or Register to comment.