G5's and optimized software
In the many G5 threads, I keep running across the assertion that current software needs to be "optimized" for the G5 to run at maximum efficiency. Does this optimization entail the release of entirely new (to be purchased) versions of current software (Photoshop, Final Cut, etc.), or will there simply be updates, patches, etc.?
Can somebody please explain how this will work?
Can somebody please explain how this will work?
Comments
I guess bigger programs might take more work than just a recompile!
Most third party software makers will move to 64 bit apps with a major rev. So you're going to pay anyway.
As for optimizations, there are two kinds of optimizations: CPU optimizations and system optimizations.
CPU optimizations would mean making the program aware of the fact that certain numbers can be larger than 4 billion and that you can address more than 4GB of RAM. This would require a rewrite of the program and in most cases isn't trivial. It is possible to make a program 64 bit aware very quickly, but there is no real guarantee that it woull effectively use the capabilities of the G5 unless the software was written with 64 bits in mind (quite a bit of rendering/video/scientific software was written with 64 bits in mind, so these programs would be very easy to make 64 bit aware).
System optimizations come from the actual binary version of the software being optimized for the G5's better memory bandwidth or for the fact that the CPU likes instructions in a certain order more than the G4's order. These optimizations usually do not require a programmer to sit down in front of his program to write new code, and these optimizaitons can usually be done fairly easily because they are automated.
As for how long it takes for a vendor to release G5 optimized software, it depends on the particular piece of software and the particular software vendor. For example, some programs support plug-ins. Photoshop would be one such program. Photoshop plugins do very computationally intensive work and it is possible (and common) for end users to upgrade their plugins apart from a full Photoshop upgrade. So for Photoshop, you could get some new G5 plugins (indeed, Adobe has one already) and well, just plug them in.
My guess is that most software vendors will "silently" add G5 support. In other words when you pick up the next version of your software (as long as it is out in about half a year or so), there will be a version that supports the G5. As users upgrade their software, they will get the G5 version of their code. Perhaps you will have a smart installer that installs a version of the code for the G4 or for the G5 depending on which machine you have.
Hope this helps. Remember that the G5 is faster than the G4 here and now, and that it will only get faster as time goes on and more software is released with the G5 in mind (including the OS).
Originally posted by Scott
Think about this. Where do you think that little stop watch comes from when QuickTime puts up the "wait" cursor? That aint coming from no Cocoa application. So if the Quicktime layer is stuck in Carbon then Apple has a lot of work to do to update it to G5/64 bit optimizations. And if third party apps are using the QT layer and QT is stuck in Carbon ...
What are Cocoa and Carbon?
Originally posted by C-Bear
What are Cocoa and Carbon?
Two programming toolsets the end user really doesn't need to know.
It's like asking, "was this program written in fortran or c?" It doesn't matter to the end user. The developer chose that programming language because it was best suited for the job.
There is a debate among some people about one being vastly superior to or faster than the other. The simple truth, though, is that applications developed in one can be just as fast or just as slow as applications developed in the other. One is targeted at procedural programmers and the other at object-oriented programmers. Previously, there were technologies that were only available to one of these development solutions, but since 10.2 was released, the two are nearly complete peers. They are growing to be more alike with each major version of Mac OS X.
The comment Scott made is completely unrelated to making something optimized for the G5. Cocoa code needs to be optimized/rewritten/recompiled. Carbon code needs to be optimized/rewritten/recompiled. The case of the stopwatch in QuickTime Player he gave is just a sample of bad, single-threaded programming overall, nothing else. I could list off several Cocoa apps that give the colored spinning wait cursor. They too are just examples of bad code that needs to be optimized in a more general sense.
You can write shoddy, slow code in both Cocoa and Carbon.
You can write fast, elegant code in both Cocoa and Carbon.
What are Cocoa and Carbon?
Remember OS 9 (and 8 and 7 etc)??
Carbon is like a spiffed up 9. Carbon applictions runs "native" in both OS 9 and OS X. So to carbonize old OS 9 applications is a neat way of enabling them to run in both 9 and X without rewriting the appliction from ground up. However the price to pay is that not all services in X is aviable in Carbon. So while carbon is neat way of getting legacy stuff into X it is not perfect
Cocoa can use all the trimmings of X, but does not run in 9 and also require a total rewrite of a OS 9 application. So Cocoa is the elegant way of doing a X application it is starting all over.
A google on "Cocoa and Carbon" will bring up a large amount of articles about debunking the myth about this and that.
Much off the legacy stuff ported from 8 and 9 is actually Apples and that is why if things like printing or QuickTime is carbon things get complicated...
With more and more stuff becoming OS X only, the Carbon stuff will taper of, I assume.
Carbon and Cocoa are pretty much equivalent in feature-set. There is really no difference from the user's perspective. The developer may choose one or the other to meet his/her needs though.
Carbon is a lower-level than Cocoa, and so can be used to write very optimized code for a particular CPU, for example (like for distributed computing code).
Barto
I'll just leave it at that for now so this thread doesn't stray too far off topic.
Being 64 bit does not mean the same thing as obtimized. 64 bit just means that the barrier of 4 gigs of memory is no longer a problem. (In 32 bit you could get by it, but it's an ugly hack.) For almost every program out there, except high memory consumers, 32 bit will be more than enough. When was the last time ANY of your programs swollowed more than 4 gigs of RAM? I'm not talking about Photoshop or Premier, I'm talking Word or Mail, maybe even AIM. Come on now.
A bonus is the fact that the G5 can fit 2x32 bit instructions in the same space as a 64 bit instruction, 32 bit compiled apps will actually run faster.
Carbon and Cocoa are actually toolsets, believe it or not. They are not the languages you program in. Cocoa is designed for objective C. When rewriting an app for cocoa, you can use Obj-C to talk to the API, but still have a C++ or C backend to save time of just rewriting to obj-c.
So, let's review
Adam - Debunking myths and legends of whoever will listen.
Being 64 bit does not mean the same thing as obtimized. 64 bit just means that the barrier of 4 gigs of memory is no longer a problem. (In 32 bit you could get by it, but it's an ugly hack.) For almost every program out there, except high memory consumers, 32 bit will be more than enough. When was the last time ANY of your programs swollowed more than 4 gigs of RAM? I'm not talking about Photoshop or Premier, I'm talking Word or Mail, maybe even AIM. Come on now.
A bonus is the fact that the G5 can fit 2x32 bit instructions in the same space as a 64 bit instruction, 32 bit compiled apps will actually run faster.
Ahem. There is a difference between 64-bit memory addressing (which the G5 doesn't even have) and 64-bit INT precision, and 64-bit my ass. There is another bonus of extra precision at much reduced performance cost when dealing with raw numbers up to 2^64 billion (unsigned).
So, let's review
64-bits can be an optimization in specific circumstances, and I don't think anyone was saying Carbon or Cocoa were languages
Barto
Originally posted by Barto
Ahem. There is a difference between 64-bit memory addressing (which the G5 doesn't even have) and 64-bit INT precision, and 64-bit my ass. There is another bonus of extra precision at much reduced performance cost when dealing with raw numbers up to 2^64 billion (unsigned).
Very true, but memory is the only one people seem to keep pushing, like:
Originally posted by Yevgeny
CPU optimizations would mean making the program aware of the fact that certain numbers can be larger than 4 billion and that you can address more than 4GB of RAM.
64 bit will definitely help in general for apps that need it.
64-bits can be an optimization in specific circumstances, and I don't think anyone was saying Carbon or Cocoa were languages
And my bad on that one, I read one of the posts wrong.
Adam
Originally posted by R_Peach
Very true, but memory is the only one people seem to keep pushing, like:
...
64 bit will definitely help in general for apps that need it.
The reason why people push memory as the primary bonus to 64 bit computing is because it is the number one bonus to 64 bit computing. There aren't that many things in the world that need a 64 bit integer to address them (this is coming from someone who does 64bit integer programming). Bear in mind that I am talking about 64 bit integers, not 64 bit reals (numbers with a decimal point) which are commonplace and quite necessary.
People want and need to address more RAM. This is a fact of life, and programmers like myself wish that we had more than 4GB of virtual memory on a modern OS. Serious video editing people need more RAM. Serious DTP people need more RAM. The proliferation of data (video, picture, audio, etc) begs for more RAM on the user's machine to deal with it all. My company has users with terrabytes of digital images that they need to keep track of (preferably lots of it in memory).