Out of curiosity, I disagree with John Nack's premise as well, but what were his inaccuracies?
Well, let's ignore such unfortunate admissions as this one:
Quote:
Here's the reality: Apple's migration to Intel chips means that it's easier to develop for both Mac and Windows, because instead of splitting development resources optimizing for two different chip architectures, you can focus on just one. [..] In the case of Soundbooth, the team could leverage Adobe's expertise in building great audio tools for Intel chips (namely Audition) to bring the app to market faster and with a richer feature set.
(Read: "We can't be bothered to actually, gasp, port code!")
Here's a completely false statement:
Quote:
Yes: Apple requires the use of Xcode to build Mactel apps. If you're using CodeWarrior, you have to convert your whole project.
It's true that you can't compile a Universal Binary with CodeWarrior. Anyone can figure that out. After all, CodeWarrior does not ship with a suitable Intel Mach-O compiler, so, um, duh?
What's not true is the assertion that you have to use Xcode. There's quite a few projects out there that don't. Xcode just happens to be an okay IDE (not a particularly great one, but certainly good for its price tag).
But you could use any compiler and linker, then use lipo to merge the two Mach-O binaries together. So what he's saying here, "Apple requires the use of Xcode to build Mactel apps", is simply false. They neither require so for purely Intel apps, nor for Universal ones. It's nonsense. I don't have to use an IDE at all, nor much of anything from the Xcode Tools.
The guy is either incompetent, or lying to defend his company's pathetic decision. If it's an honest mistake, fair enough, but if he doesn't know such details, then he should really reconsider making blog posts about whether dropping PowerPC support is the right decision.
Even from my own benchmarks, a dual-core Intel iMac is just under half the speed of a quad where the iMac is clocked slightly lower at 2.16GHz than the 2.5GHz G5.
It's just that the clock speeds on the Intels can go higher, the chips run cooler and they are cheaper.
I honestly don't know what persuaded the big console makers to go PPC what with the low processor yield, bad compilers and difficulty porting code.
Perhaps, but in addition to being a better renderer, EI is much faster than C4D. It makes a lot of use of Altivec. My unofficial comparisions are for EI. I don't have anything against the Intel chips, but I'm not going to really be impressed until SSE gets seriously overhauled and multicored.
Perhaps, but in addition to being a better renderer, EI is much faster than C4D. It makes a lot of use of Altivec. My unofficial comparisions are for EI. I don't have anything against the Intel chips, but I'm not going to really be impressed until SSE gets seriously overhauled and multicored.
SSE was overhauled for Core 2, and I don't remember anything suggesting that SSE was only on one core. It may well be that your program hasn't been optimized enough for Core.
SSE was overhauled for Core 2, and I don't remember anything suggesting that SSE was only on one core. It may well be that your program hasn't been optimized enough for Core.
No, I mean multiple SSE cores per CPU core, a la Altivec. Alternatively, it could just up the single-core vector size to, say, 256 or 512 bits. The SSE update for Core was a baby-step. To spell it out, SSE needs to ditch backward compatibility with SSE1/2/3 and become a full-blown SIMD juggernaut. It doesn't even need to have many instructions the way Altivec does. It's not utilitized much by generic software anyway, and it irritates me immensely how Intel continues to straddle-the-fence with new technology.
So what if it doesn't cater to generic needs? This is the Xeon we're talking about.
I'm not sure why Apple has their current G5s still at a premium price though, the refurbished G5 Quad is still $2700.
There are a number of disciplines that are screaming out for fast PPC kit at the moment. It's not a question of which hardware is better, but a question of which hardware runs their key apps better.
A Mac Pro might be the best machine in the world ever, but if it doesn't run the software properly, then it's about as much use as a cock-flavoured-lollipop.
I don't know anybody that would trade their Quad for a Mac Pro right now. Anybody with any sense is holding on to their PPC kit until the clusterfuck that is CS3 settles down. Once the waters have cleared, then the PPC kit will lose its value and it'll be time to buy a Mac Pro. But not before, and def. not today.
I suspect the Quads will be flying off the shelves right now ? and if you don't understand why, you've no business buying kit for the design business.
No, I mean multiple SSE cores per CPU core, a la Altivec.
They are called execution units, not cores. The PPC970 had two, it looks like Core 2 has three per CPU core. That's a bit of a misnomer because in both systems, the execution units are not duplicated, each execution unit performs a different type of task.
Quote:
So what if it doesn't cater to generic needs? This is the Xeon we're talking about.
Both the Core and Xeon use the same processor designs, possibly the same mask in some cases, just a more exhaustive binning and qualification procedure. Most features that are introduced for Xeon do trickle down to the consumer chip.
Perhaps, but in addition to being a better renderer, EI is much faster than C4D. It makes a lot of use of Altivec. My unofficial comparisions are for EI.
Electric Image better than C4D? I don't know, I haven't tried them but I'm sure C4D has a pretty good reputation - you also have to weigh up image quality. I also like that C4D was one of the first 3D packages to be a universal binary.
I think the big issue is that although Altivec seems to be geared more for high end computation and beats SSE in floating point calculation, benchmarks time and time again showed that the PPC Macs were not significantly outperforming their PC counterparts in most software packages. I can't recall any that did. Whether you use mainly one package, I can't think of any specific app that looked much better on PPC.
Since the majority of people use PCs, all I can think of is that developers put in more time learning how to optimize with SSE code. Given that Altivec and SSE require optimizing in different ways, it makes sense that they would just go with the popular one and forget the other.
The major studios that use renderfarms use Intels - Pixar use Dell hardware. That would lead me to thinking that X86 is better. The word 'better' is of course quite a loose term and is not limited to theoretical performance.
Quote:
Originally Posted by Messiah
I suspect the Quads will be flying off the shelves right now ? and if you don't understand why, you've no business buying kit for the design business.
The only reason I could see them doing that is because Adobe and Autodesk haven't updated their software. But I don't see that increasing quad sales. If the people who use that software needed the power, they'd have bought the quads ages ago. Otherwise, they can hold out with what they are using for a good long time to come. I don't think there's much point in spending so much money on a machine that will have little to no resale value.
My brother did that on a car. Sure MG Rover are going bust so why not get a 'cheap' MG? The reason is because when he comes to selling it, he's going to get next to nothing back.
So although PPC is not a lame duck in that it still has some life in it, it has no future. By the time CS3 or whatever comes out, who's to say that the high end Macs won't be packing 8 or 16 cores for the same price as the current Mac Pros? A quad PPC G5 won't ever be able to compete with that.
You're missing my point. Xeon is, above all else, a marketing term. Xeon itself has no ties to any architecture or anything in particluar aside for an intended market of high-performance users.
Either way, Altivec still delivers the goods. SSE doesn't quite. Hopefully this won't matter for too much longer, as long as I can get a Cell-based computer to do my rendering. Four PS3's and an iMac is quite possibly the best bang for the buck in 3D product visualization.
Quote:
Originally Posted by Marvin
Electric Image better than C4D? I don't know, I haven't tried them but I'm sure C4D has a pretty good reputation - you also have to weigh up image quality.
"Better" is a subjective term. "Faster" and "More accurate raytracing" are not. C4D is a fine program. It has a nice interface and I like it too. But it doesn't render like EI. I'm not sure anything does. Probably the only thing in the same universe is Renderman. It runs x86 because the PPC970 was too fast a blip on the radar screen. Within two years everything will be rendering on Cells.
There are a number of disciplines that are screaming out for fast PPC kit at the moment. It's not a question of which hardware is better, but a question of which hardware runs their key apps better.
Yes indeed. That is why the eBay resale prices on G5s are high. The designers using PS need a PPC.
Quote:
A Mac Pro might be the best machine in the world ever, but if it doesn't run the software properly, then it's about as much use as a cock-flavoured-lollipop.
LOL
Quote:
I don't know anybody that would trade their Quad for a Mac Pro right now. Anybody with any sense is holding on to their PPC kit until the clusterfuck that is CS3 settles down. Once the waters have cleared, then the PPC kit will lose its value and it'll be time to buy a Mac Pro. But not before, and def. not today.
I have to time the sale of my G5 just right - let the refurbs die out and the demand increase.
Quote:
I suspect the Quads will be flying off the shelves right now ? and if you don't understand why, you've no business buying kit for the design business.
I told 'em in the post above - but you need to actually check eBay to see it for yourself.
You're missing my point. Xeon is, above all else, a marketing term. Xeon itself has no ties to any architecture or anything in particluar aside for an intended market of high-performance users.
While it is true that it is a marketing term, they have not deviated from what I described in the ten years they've been using the trademark.
Since the majority of people use PCs, all I can think of is that developers put in more time learning how to optimize with SSE code. Given that Altivec and SSE require optimizing in different ways, it makes sense that they would just go with the popular one and forget the other.
Apple takes care of all that for you - all you have to do is write to the Accelerate.framework and it magically generates Altivec or SSE depending on what the binary is going to be. If Adobe did their usual productivity-sapping custom frameworks, or worse, hard-coded Intel assembler for portions of PS, then they painted themselves into a corner and no wonder they are so slow to get out.
There is so much new stuff under the hood in Leopard that I hope Apple engineers drove over to Adobe to get them on board with the 2x faster CoreText framework, the speed gain from letting gcc 4 produce an Intel 64-bit
"Better" is a subjective term. "Faster" and "More accurate raytracing" are not. C4D is a fine program. It has a nice interface and I like it too. But it doesn't render like EI. I'm not sure anything does. Probably the only thing in the same universe is Renderman. It runs x86 because the PPC970 was too fast a blip on the radar screen. Within two years everything will be rendering on Cells.
I checked out the EI software but it has the same problem as Lightwave having different programs for modelling and animation. I'm looking into Renderman at the moment and it seems pretty fast on the Intels but I can't get complex scenes yet because it doesn't have a nice interface. I love programmable shaders though.
As for rendering on the PS3, it would be nice. Even the 256MB Ram shouldn't be a problem if you use a decent renderer. It's just a question of whether it will run generic software and if that software can take advantage of the cores. I read that the PS3 doesn't have 7 actual cores but 1 generic core and 6 floating point cores. The Xbox 360 has 3 full cores and shares 512MB Ram with the GPU so if the GPU is unused, I reckon you get 512MB Ram. Given that you can buy 2 XBox's for the price of 1 PS3, I'd say you're better with them.
Quote:
Originally Posted by lundy
Apple takes care of all that for you - all you have to do is write to the Accelerate.framework and it magically generates Altivec or SSE depending on what the binary is going to be. If Adobe did their usual productivity-sapping custom frameworks, or worse, hard-coded Intel assembler for portions of PS, then they painted themselves into a corner and no wonder they are so slow to get out.
There is so much new stuff under the hood in Leopard that I hope Apple engineers drove over to Adobe to get them on board with the 2x faster CoreText framework, the speed gain from letting gcc 4 produce an Intel 64-bit
binary, and using some of their GPU frameworks.
But is that automated vectorization? For example on the Altivec side, auto-vectorization is quite bad so hand-coding is the only way to get an advantage. If it translates hand-coded Altivec or SSE then it might be better. The Leopard devtools do look nice but I wish they would focus more on useful things than marketing gimmicks. I was so glad when they said they would introduce Python and Perl scripting for Cocoa apps. I just wonder why they didn't do it from the beginning because now we have the Applescript baggage. If it was for the OS 9 transition then they should've made Applescript a Python module. They should also delete Automator and forget they ever made it. I'm still reeling from the 16MB new file bloat.
I was so glad when they said they would introduce Python and Perl scripting for Cocoa apps. I just wonder why they didn't do it from the beginning because now we have the Applescript baggage. If it was for the OS 9 transition then they should've made Applescript a Python module. They should also delete Automator and forget they ever made it. I'm still reeling from the 16MB new file bloat.
Thankfully, they don't listen to you, and people like Avie don't have a say any more.
No, this has nothing to do with autovectorization. You write your vector operations as API calls to the Accelerate framework.
Automator is a big part of the new Xray performance tool - for recording and playing back your application's user operations while you have Xray observe the object allocation and many other parameters.
I'm not making unreasonable suggestions by saying that Apple should use the technology they have. People all over the place complain about certain aspects of the Mac OS, notably the Finder, when there is a massive amount of tried and tested tools there for them to use and most people who venture into the command-line will see how much better they work.
To make something like Automator, which has 16MB files for something as simple as making a new document (the majority of which is the interface nib files) is ludicrous. We have Python that makes a new file with one line of code. All Automator is doing is wasting nearly quarter of a gig of space. Y'know someone on a forum was going to phone Apple because his default installation was 17GB. It's getting ridiculous. Windows XP even comes on a CD, not a DVD. We don't need this bloat.
What Apple have tried to do with Applescript and Automator is bring scripting power to the masses and in my experience, people have just as hard a time with Applescript as other programming languages because at the end of the day, you still need to think like a programmer.
Quote:
Originally Posted by lundy
No, this has nothing to do with autovectorization. You write your vector operations as API calls to the Accelerate framework.
Does that mean learning new vectorization code or is it pretty universal? What about programs that are already highly optimized for SSE? I can't see a program that has been developed for a long time on PCs using lots of SSE code firstly undoing the optimization and then using the accelerate framework, which presumably only works for OS X.
Even for new applications like the Adobe program, I don't see how the Accelerate framework would fit in if you had to optimize for Windows x86, Mac x86 and Mac PPC. It seems to me you can only ever target two out of the three with ease.
Hand-coding SSE lets you get better optimization for Windows and Mac x86. Accelerate will give you some but not great optimization for Mac PPC and x86. Naturally, Apple don't care so much about Windows but Adobe does.
Quote:
Originally Posted by lundy
Automator is a big part of the new Xray performance tool - for recording and playing back your application's user operations while you have Xray observe the object allocation and many other parameters.
Ok, it sounds pretty useful but I reckon it could probably still have been done using the tools already available. I'm just really neurotic about redundancy. Hence why I want a new alphabetic keyboard without doubled up numbers and one all-encompassing programming language. We have so many tools available, hundreds of languages and thousands of scripts and modules, Apple don't need to make their own proprietary stuff. If anything that drives people away from Mac development.
To make something like Automator, which has 16MB files for something as simple as making a new document (the majority of which is the interface nib files) is ludicrous. We have Python that makes a new file with one line of code. All Automator is doing is wasting nearly quarter of a gig of space.
On my computer, Automator is 14MB total. I'm not sure where you get quarter gig from.
I do agree that it's close to useless. I couldn't find any reasonable means of looping or conditional operation, and what it can do is somewhat inefficient at best, a snail at worst. It's just a way to make linear processes. The processes I did manage to make turned out to duplicate what iPhoto had but I didn't notice. There is a nifty command to merge multiple PDFs into one large PDF, but there was no command to tell it where to save it, so all that did was made a derelict PDF with some weird random file name in the /tmp/ directory.
Quote:
Hence why I want a new alphabetic keyboard without doubled up numbers and one all-encompassing programming language. We have so many tools available, hundreds of languages and thousands of scripts and modules, Apple don't need to make their own proprietary stuff. If anything that drives people away from Mac development.
I really don't think it is possible to have a single programming language to do everything for everyone. The adage "jack of all trades, master of none" fits. Many of Apple's APIs are really only meant to help Mac developers quickly turn out a good program for the Mac platform. Heck, I don't think one can even approach an all-encompassing programing language without either being proprietary or crap, usually it is proprietary and crap.
I checked out the EI software but it has the same problem as Lightwave having different programs for modelling and animation.
EI currently doesn't have a modeler. But I know what you're talking about. It takes some time to get used to the workflow, but after you get used to it, it ends up being very nice. It's particularly nice if you want to maintain a database of model revisions but only a single animation/render project.
The vector code - if they painted themselves into a corner by coding raw assembler, then they are screwed for the PPC end. On the other hand if they used the gcc macros they might be OK.
Automator is not a programming language - it is a workflow generator. I don't have hardly any things for which it is appropriate. The one thing that it is good for is making a wrapper for an Applescript so that you can stash it in the contextual menu. This only works for Finder though.
Is Python the one that uses indentation to determine scope? If so, no thanks.
Comments
Out of curiosity, I disagree with John Nack's premise as well, but what were his inaccuracies?
Well, let's ignore such unfortunate admissions as this one:
Here's the reality: Apple's migration to Intel chips means that it's easier to develop for both Mac and Windows, because instead of splitting development resources optimizing for two different chip architectures, you can focus on just one. [..] In the case of Soundbooth, the team could leverage Adobe's expertise in building great audio tools for Intel chips (namely Audition) to bring the app to market faster and with a richer feature set.
(Read: "We can't be bothered to actually, gasp, port code!")
Here's a completely false statement:
Yes: Apple requires the use of Xcode to build Mactel apps. If you're using CodeWarrior, you have to convert your whole project.
It's true that you can't compile a Universal Binary with CodeWarrior. Anyone can figure that out. After all, CodeWarrior does not ship with a suitable Intel Mach-O compiler, so, um, duh?
What's not true is the assertion that you have to use Xcode. There's quite a few projects out there that don't. Xcode just happens to be an okay IDE (not a particularly great one, but certainly good for its price tag).
But you could use any compiler and linker, then use lipo to merge the two Mach-O binaries together. So what he's saying here, "Apple requires the use of Xcode to build Mactel apps", is simply false. They neither require so for purely Intel apps, nor for Universal ones. It's nonsense. I don't have to use an IDE at all, nor much of anything from the Xcode Tools.
The guy is either incompetent, or lying to defend his company's pathetic decision. If it's an honest mistake, fair enough, but if he doesn't know such details, then he should really reconsider making blog posts about whether dropping PowerPC support is the right decision.
The G5 still renders 3D scenes a lot faster than any x86.
I think they are about the same (check the UB Cinema4d benchmark):
http://www.macworld.com/2006/08/firs...ench/index.php
Even from my own benchmarks, a dual-core Intel iMac is just under half the speed of a quad where the iMac is clocked slightly lower at 2.16GHz than the 2.5GHz G5.
It's just that the clock speeds on the Intels can go higher, the chips run cooler and they are cheaper.
I honestly don't know what persuaded the big console makers to go PPC what with the low processor yield, bad compilers and difficulty porting code.
I think they are about the same (check the UB Cinema4d benchmark):
http://www.macworld.com/2006/08/firs...ench/index.php
Perhaps, but in addition to being a better renderer, EI is much faster than C4D. It makes a lot of use of Altivec. My unofficial comparisions are for EI. I don't have anything against the Intel chips, but I'm not going to really be impressed until SSE gets seriously overhauled and multicored.
Perhaps, but in addition to being a better renderer, EI is much faster than C4D. It makes a lot of use of Altivec. My unofficial comparisions are for EI. I don't have anything against the Intel chips, but I'm not going to really be impressed until SSE gets seriously overhauled and multicored.
SSE was overhauled for Core 2, and I don't remember anything suggesting that SSE was only on one core. It may well be that your program hasn't been optimized enough for Core.
SSE was overhauled for Core 2, and I don't remember anything suggesting that SSE was only on one core. It may well be that your program hasn't been optimized enough for Core.
No, I mean multiple SSE cores per CPU core, a la Altivec. Alternatively, it could just up the single-core vector size to, say, 256 or 512 bits. The SSE update for Core was a baby-step. To spell it out, SSE needs to ditch backward compatibility with SSE1/2/3 and become a full-blown SIMD juggernaut. It doesn't even need to have many instructions the way Altivec does. It's not utilitized much by generic software anyway, and it irritates me immensely how Intel continues to straddle-the-fence with new technology.
So what if it doesn't cater to generic needs? This is the Xeon we're talking about.
I'm not sure why Apple has their current G5s still at a premium price though, the refurbished G5 Quad is still $2700.
There are a number of disciplines that are screaming out for fast PPC kit at the moment. It's not a question of which hardware is better, but a question of which hardware runs their key apps better.
A Mac Pro might be the best machine in the world ever, but if it doesn't run the software properly, then it's about as much use as a cock-flavoured-lollipop.
I don't know anybody that would trade their Quad for a Mac Pro right now. Anybody with any sense is holding on to their PPC kit until the clusterfuck that is CS3 settles down. Once the waters have cleared, then the PPC kit will lose its value and it'll be time to buy a Mac Pro. But not before, and def. not today.
I suspect the Quads will be flying off the shelves right now ? and if you don't understand why, you've no business buying kit for the design business.
No, I mean multiple SSE cores per CPU core, a la Altivec.
They are called execution units, not cores. The PPC970 had two, it looks like Core 2 has three per CPU core. That's a bit of a misnomer because in both systems, the execution units are not duplicated, each execution unit performs a different type of task.
So what if it doesn't cater to generic needs? This is the Xeon we're talking about.
Both the Core and Xeon use the same processor designs, possibly the same mask in some cases, just a more exhaustive binning and qualification procedure. Most features that are introduced for Xeon do trickle down to the consumer chip.
Perhaps, but in addition to being a better renderer, EI is much faster than C4D. It makes a lot of use of Altivec. My unofficial comparisions are for EI.
Electric Image better than C4D? I don't know, I haven't tried them but I'm sure C4D has a pretty good reputation - you also have to weigh up image quality. I also like that C4D was one of the first 3D packages to be a universal binary.
I think the big issue is that although Altivec seems to be geared more for high end computation and beats SSE in floating point calculation, benchmarks time and time again showed that the PPC Macs were not significantly outperforming their PC counterparts in most software packages. I can't recall any that did. Whether you use mainly one package, I can't think of any specific app that looked much better on PPC.
Since the majority of people use PCs, all I can think of is that developers put in more time learning how to optimize with SSE code. Given that Altivec and SSE require optimizing in different ways, it makes sense that they would just go with the popular one and forget the other.
The major studios that use renderfarms use Intels - Pixar use Dell hardware. That would lead me to thinking that X86 is better. The word 'better' is of course quite a loose term and is not limited to theoretical performance.
I suspect the Quads will be flying off the shelves right now ? and if you don't understand why, you've no business buying kit for the design business.
The only reason I could see them doing that is because Adobe and Autodesk haven't updated their software. But I don't see that increasing quad sales. If the people who use that software needed the power, they'd have bought the quads ages ago. Otherwise, they can hold out with what they are using for a good long time to come. I don't think there's much point in spending so much money on a machine that will have little to no resale value.
My brother did that on a car. Sure MG Rover are going bust so why not get a 'cheap' MG? The reason is because when he comes to selling it, he's going to get next to nothing back.
So although PPC is not a lame duck in that it still has some life in it, it has no future. By the time CS3 or whatever comes out, who's to say that the high end Macs won't be packing 8 or 16 cores for the same price as the current Mac Pros? A quad PPC G5 won't ever be able to compete with that.
Either way, Altivec still delivers the goods. SSE doesn't quite. Hopefully this won't matter for too much longer, as long as I can get a Cell-based computer to do my rendering. Four PS3's and an iMac is quite possibly the best bang for the buck in 3D product visualization.
Electric Image better than C4D? I don't know, I haven't tried them but I'm sure C4D has a pretty good reputation - you also have to weigh up image quality.
"Better" is a subjective term. "Faster" and "More accurate raytracing" are not. C4D is a fine program. It has a nice interface and I like it too. But it doesn't render like EI. I'm not sure anything does. Probably the only thing in the same universe is Renderman. It runs x86 because the PPC970 was too fast a blip on the radar screen. Within two years everything will be rendering on Cells.
There are a number of disciplines that are screaming out for fast PPC kit at the moment. It's not a question of which hardware is better, but a question of which hardware runs their key apps better.
Yes indeed. That is why the eBay resale prices on G5s are high. The designers using PS need a PPC.
A Mac Pro might be the best machine in the world ever, but if it doesn't run the software properly, then it's about as much use as a cock-flavoured-lollipop.
LOL
I don't know anybody that would trade their Quad for a Mac Pro right now. Anybody with any sense is holding on to their PPC kit until the clusterfuck that is CS3 settles down. Once the waters have cleared, then the PPC kit will lose its value and it'll be time to buy a Mac Pro. But not before, and def. not today.
I have to time the sale of my G5 just right - let the refurbs die out and the demand increase.
I suspect the Quads will be flying off the shelves right now ? and if you don't understand why, you've no business buying kit for the design business.
I told 'em in the post above - but you need to actually check eBay to see it for yourself.
You're missing my point. Xeon is, above all else, a marketing term. Xeon itself has no ties to any architecture or anything in particluar aside for an intended market of high-performance users.
While it is true that it is a marketing term, they have not deviated from what I described in the ten years they've been using the trademark.
Since the majority of people use PCs, all I can think of is that developers put in more time learning how to optimize with SSE code. Given that Altivec and SSE require optimizing in different ways, it makes sense that they would just go with the popular one and forget the other.
Apple takes care of all that for you - all you have to do is write to the Accelerate.framework and it magically generates Altivec or SSE depending on what the binary is going to be. If Adobe did their usual productivity-sapping custom frameworks, or worse, hard-coded Intel assembler for portions of PS, then they painted themselves into a corner and no wonder they are so slow to get out.
There is so much new stuff under the hood in Leopard that I hope Apple engineers drove over to Adobe to get them on board with the 2x faster CoreText framework, the speed gain from letting gcc 4 produce an Intel 64-bit
binary, and using some of their GPU frameworks.
"Better" is a subjective term. "Faster" and "More accurate raytracing" are not. C4D is a fine program. It has a nice interface and I like it too. But it doesn't render like EI. I'm not sure anything does. Probably the only thing in the same universe is Renderman. It runs x86 because the PPC970 was too fast a blip on the radar screen. Within two years everything will be rendering on Cells.
I checked out the EI software but it has the same problem as Lightwave having different programs for modelling and animation. I'm looking into Renderman at the moment and it seems pretty fast on the Intels but I can't get complex scenes yet because it doesn't have a nice interface. I love programmable shaders though.
As for rendering on the PS3, it would be nice. Even the 256MB Ram shouldn't be a problem if you use a decent renderer. It's just a question of whether it will run generic software and if that software can take advantage of the cores. I read that the PS3 doesn't have 7 actual cores but 1 generic core and 6 floating point cores. The Xbox 360 has 3 full cores and shares 512MB Ram with the GPU so if the GPU is unused, I reckon you get 512MB Ram. Given that you can buy 2 XBox's for the price of 1 PS3, I'd say you're better with them.
Apple takes care of all that for you - all you have to do is write to the Accelerate.framework and it magically generates Altivec or SSE depending on what the binary is going to be. If Adobe did their usual productivity-sapping custom frameworks, or worse, hard-coded Intel assembler for portions of PS, then they painted themselves into a corner and no wonder they are so slow to get out.
There is so much new stuff under the hood in Leopard that I hope Apple engineers drove over to Adobe to get them on board with the 2x faster CoreText framework, the speed gain from letting gcc 4 produce an Intel 64-bit
binary, and using some of their GPU frameworks.
But is that automated vectorization? For example on the Altivec side, auto-vectorization is quite bad so hand-coding is the only way to get an advantage. If it translates hand-coded Altivec or SSE then it might be better. The Leopard devtools do look nice but I wish they would focus more on useful things than marketing gimmicks. I was so glad when they said they would introduce Python and Perl scripting for Cocoa apps. I just wonder why they didn't do it from the beginning because now we have the Applescript baggage. If it was for the OS 9 transition then they should've made Applescript a Python module. They should also delete Automator and forget they ever made it. I'm still reeling from the 16MB new file bloat.
I was so glad when they said they would introduce Python and Perl scripting for Cocoa apps. I just wonder why they didn't do it from the beginning because now we have the Applescript baggage. If it was for the OS 9 transition then they should've made Applescript a Python module. They should also delete Automator and forget they ever made it. I'm still reeling from the 16MB new file bloat.
Thankfully, they don't listen to you, and people like Avie don't have a say any more.
Automator is a big part of the new Xray performance tool - for recording and playing back your application's user operations while you have Xray observe the object allocation and many other parameters.
Thankfully, they don't listen to you, and people like Avie don't have a say any more.
Avie Tevanian it seems made some decisions which turned out bad:
http://daringfireball.net/2003/07/th...d_and_the_avie
However, he was still very responsible for the quick transition to OS X:
http://www.appleinsider.com/article.php?id=1627
I'm not making unreasonable suggestions by saying that Apple should use the technology they have. People all over the place complain about certain aspects of the Mac OS, notably the Finder, when there is a massive amount of tried and tested tools there for them to use and most people who venture into the command-line will see how much better they work.
To make something like Automator, which has 16MB files for something as simple as making a new document (the majority of which is the interface nib files) is ludicrous. We have Python that makes a new file with one line of code. All Automator is doing is wasting nearly quarter of a gig of space. Y'know someone on a forum was going to phone Apple because his default installation was 17GB. It's getting ridiculous. Windows XP even comes on a CD, not a DVD. We don't need this bloat.
What Apple have tried to do with Applescript and Automator is bring scripting power to the masses and in my experience, people have just as hard a time with Applescript as other programming languages because at the end of the day, you still need to think like a programmer.
No, this has nothing to do with autovectorization. You write your vector operations as API calls to the Accelerate framework.
Does that mean learning new vectorization code or is it pretty universal? What about programs that are already highly optimized for SSE? I can't see a program that has been developed for a long time on PCs using lots of SSE code firstly undoing the optimization and then using the accelerate framework, which presumably only works for OS X.
Even for new applications like the Adobe program, I don't see how the Accelerate framework would fit in if you had to optimize for Windows x86, Mac x86 and Mac PPC. It seems to me you can only ever target two out of the three with ease.
Hand-coding SSE lets you get better optimization for Windows and Mac x86. Accelerate will give you some but not great optimization for Mac PPC and x86. Naturally, Apple don't care so much about Windows but Adobe does.
Automator is a big part of the new Xray performance tool - for recording and playing back your application's user operations while you have Xray observe the object allocation and many other parameters.
Ok, it sounds pretty useful but I reckon it could probably still have been done using the tools already available. I'm just really neurotic about redundancy. Hence why I want a new alphabetic keyboard without doubled up numbers and one all-encompassing programming language. We have so many tools available, hundreds of languages and thousands of scripts and modules, Apple don't need to make their own proprietary stuff. If anything that drives people away from Mac development.
To make something like Automator, which has 16MB files for something as simple as making a new document (the majority of which is the interface nib files) is ludicrous. We have Python that makes a new file with one line of code. All Automator is doing is wasting nearly quarter of a gig of space.
On my computer, Automator is 14MB total. I'm not sure where you get quarter gig from.
I do agree that it's close to useless. I couldn't find any reasonable means of looping or conditional operation, and what it can do is somewhat inefficient at best, a snail at worst. It's just a way to make linear processes. The processes I did manage to make turned out to duplicate what iPhoto had but I didn't notice. There is a nifty command to merge multiple PDFs into one large PDF, but there was no command to tell it where to save it, so all that did was made a derelict PDF with some weird random file name in the /tmp/ directory.
Hence why I want a new alphabetic keyboard without doubled up numbers and one all-encompassing programming language. We have so many tools available, hundreds of languages and thousands of scripts and modules, Apple don't need to make their own proprietary stuff. If anything that drives people away from Mac development.
I really don't think it is possible to have a single programming language to do everything for everyone. The adage "jack of all trades, master of none" fits. Many of Apple's APIs are really only meant to help Mac developers quickly turn out a good program for the Mac platform. Heck, I don't think one can even approach an all-encompassing programing language without either being proprietary or crap, usually it is proprietary and crap.
I checked out the EI software but it has the same problem as Lightwave having different programs for modelling and animation.
EI currently doesn't have a modeler. But I know what you're talking about. It takes some time to get used to the workflow, but after you get used to it, it ends up being very nice. It's particularly nice if you want to maintain a database of model revisions but only a single animation/render project.
Automator is not a programming language - it is a workflow generator. I don't have hardly any things for which it is appropriate. The one thing that it is good for is making a wrapper for an Applescript so that you can stash it in the contextual menu. This only works for Finder though.
Is Python the one that uses indentation to determine scope? If so, no thanks.