...well, not precisely.
there was something about the script component of the render management system (done in perl) that seemed somewhat lacking. this would turn out to be the final link in the chain to getting the whole shebang up and running.
...but not before i almost completely lost my cool (such as it is). the prez of the company showed up and i gave him the results of the render test that i had started last saturday, which showed (again, as i had already forgotten by this point) that the mac dual proc 2GHz g5's were performing at about the same level as a single p4 3GHz. he asked why, and i began that there were differing architectures... of course the prez could not believe this and wanted me to go to apple's site where all the claims are made, etc...
...it was a little too much for the barely begun day. i blurted that the tests were photoshop and that highlighted integer performance whereas we needed floating point for 3-D rendering -- and that macs are not precisely known for floating point performance.
now, this discussion has been going on for a while now -- but all the other times i've been pretty calm about it; but this time my frustration may have shown -- and this time the argument seems to have sunk in.
i can understand the disbelief -- after all, the macs do cost quite a bit compared to a clone p4 even with the bells and whistles. and with the rather lackluster render results i was obtaining, that meant the mac could no longer be considered as a competitive product for future render farm expansion.
the only remaining possible alternative to the intel inside experience (read: costly) to consider, then, was amd's opteron. which, given my generally positive experience with its athlon brethren, could be a good thing. especially if the price/performance slope is similar to the athlon versus p4.
i will admit the possibility that maybe there are yet undiscovered optimizations for the g5 processor and os x combo -- but the fact that nothing is obvious -- and even the web is shy of pages on optimization (not hard disk optimization) -- is definitely not a plus factor. one doesn't need to fight the os to get the maximum performance a platform has to offer.
afterwards, i went googling and a plethora of sites came up in the results that showed that the g5 was superior to the pc in what seemed to be a whole trainload of synthetic benchmarks. i say synthetic because while they do exercise the machine in predictable ways, the data they work with maybe does not reflect a real-world environment. and what's more real world that a project for a paying client?
in my tests, using a scene from the client's earlier data shipment to us, the mac steadfastly remained at a comparable level to the pc workstations. however that may be, i think i'll still hunt around for ways to get the mac up to it's supposed speed. must be the geek in me. (",)
anyways, back to the render script component. the render script would fail, noting that the 3-D software was not at the location the system environment variable said it would be. ...naturally, neither os x or the software installer for the 3-D software had any documentation where this environment variable could be located, much less modified.
at essentially wits' end, i decided to email the programmer of the render management system with the issues that i'd encountered. i asked if there was a way to add a third clause to the os check routine (which, in a nutshell checked if not NT, then Linux) such that the check would now be if not NT, check if OS X; if not that either, then Linux.
now, this is something i could have done myself, had i the documentation -- but, as i mentioned in a paragraph back, i had none.
...amazingly, the programmer emailed back, with a little piece of perl code that i spliced into the render script. there was a little snag, though, as he actually gave two options. suffice to say the simpler option only worked on the mac, making the linux render inoperable. with code spliced in, one render script could now be called to manage renders across three different os platforms. is good.
so, then. now we can set up the entire floor (pc's and macs) to augment the linux render farm. render nirvana. sort of.
hoarding and the skyway patrol
good thing that the building's guard noticed, and even better, warned us that the right rear wheel of rani's car was underinflated. so we spent some time changing the tire. jose took the lead in the process, but at a certain point, the guard got involved and helped expedite the wheel change. that done, rani zoomed us all to the drop off point where ferdz, louie and jose disembarked for their mrt transfer. i accompanied rani to her shop and thence made my way to a nearby supermarket.
that was the skyway patrol part: just writing it down; makes this post marginally longer, is all. hehehe
the hoarding bit has to do with 3-in-1 coffee. now, i could safely be considered a coffee addict -- if i have a mantra, it would be "coffee is good". i used to get 12-pack boxes of maxwell house sachets, but i'd go through a box in about a day or two, so it behooves me to get the 24-pack plastics. rani calls it hoarding (since i buy three plastics at a time), but i prefer the term "stocking up"...
oddly, though, haven't been able to find purefoods' cooked salami at either the 7-eleven near where i live, or the supermarket near rani's coffee shop. just thought it worth noting. a processed food item shortage?
Tuesday, November 02, 2004
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment