Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
There was nothing facetious about it. Grand Central taking advantage of multicore communication on Intel processor and chipsets does not mean that single-core systems will not work. That would be analogous to saying that ALL software would have to be multithreaded in order to run. There's no humor in that.

Likewise, optimizing code for Intel does not make PPC not work... Based on "the big technologies introduced are Intel only, therefore 10.6 is Intel only" almost gives as much evidence as Grand central takes advantage of multicore communication as evidence they are eliminating single core support.

That right there sets you down one specific path. Poor machine code is not the only source of a speed issue.

This is where I disagree vehemently. Machine code is at the heart of every speed issue and is the root cause of all OS speed issues. Since the machine code (or user readable version Assembly code) is explicitly telling the processor what to do on every clock cycle it is functioning. Machine code that is inefficiently written, does not take advantage of pipelining or processor features is the root cause of every speed issue you run into. Sure you can change the higher level code to yield better results but you're just changing the machine code via a different means at that point.

You can do all of the high level code optimization you want but if it results in poorly utilized assembly you're going to have speed issues. That's why assembly coding is the last step in optimization of high performance applications. When you truly need speed you write it in assembly (unless you can train/fix the compiler to implement the higher level code more efficiently). Every instruction you give your processor takes a set number of clock cycles to complete and efficiently managing the pipeline and various functional units so that as much as possible is happening on every clock cycle will yield the most bang for your buck on speed. Once the machine code is as efficient as possible the only methods left for increasing speed are to get faster busses and processors.

In certain specific situations, it's an option. Suggesting, as you did, that it is one of two equal paths to an end in the scope of rewriting the OS generally was the problem.

For many problems it is two equal paths. I never meant that it was always the case.

They specifically covered this at WWDC. You can even tell just on the name: Snow Leopard does not obviate Leopard. It's not a feature release.

So now Apple will be maintaining and updating 10.5 for Intel and PPC, and 10.6 for Intel? as long as 10.6 is around? We've seen the end of 10.4.x updates shortly after 10.5 shipped and this is completely understandable. But now they are going to have to keep up 10.5.x and 10.6.x updates when they could stop 10.5 shortly after 10.6 and maintain the 10.6.x updates. The PPC users might not see as much of a performance boost as Intel but it would simplify Apple's development. As has been stated many times, if the 10.6 update supports PPC and offers little to PPC users then it's not like they'd be forced to upgrade, however even slightly faster and more stable will be enough for many.

It's not like dropping PPC support means they can eliminate their entire PPC coding staff or move them all to Intel development. There's still PPC support that they will need, and if they need to keep 10.5 up to date for PPC they need to do the same for Intel unless 10.6 is free, which would be a strange move, since if it were going to be free why a 10.x update and not a 10.5.x update?

No, it's not. Adobe has already previewed CS4 and discussed a number of new Photoshop tools.

OK, then CS5.

The bottom line is that any amount of foaming-at-the-mouth rage at the likely prospect of an Intel-only release isn't a death sentence to PowerPC right away. It's the next step of a long goodbye that started 3 years ago. 10.6 will not implement anything that PowerPC users will want--Apple has already said as much. I'm not talking about abstract objectives here, like speed, efficiency, and footprint requirements, that everyone wants; I'm talking about actual implemented code. It's clear from the presentations so far that even if Snow Leopard ran on PowerPC, which it does not, it's not providing any added value to PPC Macs. The code in the developer preview won't speed up or reduce resource consumption on PPC Macs.

I'm not foaming at the mouth, I'm just pointing out that you or I don't know for sure what Apple is planning to do with Snow Leopard. And where did they announce that there's no value added to PPC macs? The only evidence you've given are the developer preview specs and two big technologies that are going to be implemented in 10.6 that happen to be Intel only. I'm not saying that it's not enough evidence for many of us to come to a 100% conclusion. I won't necessarily be that surprised if 10.6 is Intel only, but it just seems to be like it should be a much bigger announcement than how it was handled.
 
Is it just me or is there a slight irony that the people who slated MS for letting Vista be put on woefully underpowered computers are complaining that Apple won't design 10.6 for old hardware?

At least Apple are telling you in advance here.

I wasn't aware Apple has told us anything yet in that regard. We have Matticus for that, after all. He knows more than Apple does about Snow Leopard. ;)
 
Likewise, optimizing code for Intel does not make PPC not work... Based on "the big technologies introduced are Intel only, therefore 10.6 is Intel only" almost gives as much evidence as Grand central takes advantage of multicore communication as evidence they are eliminating single core support.
If the only changes are Intel-only, it has the necessary and obvious effect of providing nothing of benefit to PowerPC users.

The important detail about Grand Central isn't its multicore implementation, it's that it's Intel-specific in nature, like the other announced feature. If the new code is Intel-only, the new technologies are Intel-only, and the development process remains Intel-only, it leaves nothing for PowerPC users to want or benefit from.

It seems as though some people just want the 10.6 name on their machine--regardless of whether it offers anything of utility. They can just renumber the 10.5 code to 10.6, making no changes, and that seems to be what some people are asking for. It does not make sense, but that may be what Apple does just to pacify these people.
This is where I disagree vehemently. Machine code is at the heart of every speed issue and is the root cause of all OS speed issues.
That's quite clearly not the case. If you have poorly written high-level code, improving the machine code implemented upon compiling isn't a magical fix.
Sure you can change the higher level code to yield better results but you're just changing the machine code via a different means at that point.
With any kind of programming change, the end result is in the machine code. Anything you do is changing the machine code somehow, whether it's tweaking the compiler, the API-level code, or high-level source.
You can do all of the high level code optimization you want but if it results in poorly utilized assembly you're going to have speed issues.
That simply proceeds from a faulty premise that there's a major defect in the compiler. Efficiency problems in execution come from a variety of sources, and each must be particularly addressed. No matter how good you make your compiler, you can't eliminate the results of lazy/rushed programmers or erroneous code.
For many problems it is two equal paths. I never meant that it was always the case.
Then that issue is resolved, because that's exactly what it sounded like and what I objected to.
So now Apple will be maintaining and updating 10.5 for Intel and PPC, and 10.6 for Intel? as long as 10.6 is around?
No. 10.5 would be maintained as long as they choose to do so (historically, a few maintenance updates).
The PPC users might not see as much of a performance boost as Intel but it would simplify Apple's development.
Not nearly as much simplification as just letting it go.
It's not like dropping PPC support means they can eliminate their entire PPC coding staff or move them all to Intel development. There's still PPC support that they will need, and if they need to keep 10.5 up to date for PPC
Where are you seeing this ongoing 10.5 development? The PowerPC staff will be transitioned to other projects based on their skills and interests (many of them already have been). At this point, there aren't that many of them left anyway.
which would be a strange move, since if it were going to be free why a 10.x update and not a 10.5.x update?
Because it's a substantially different codebase and not a bugfix update, which would break their numbering protocols.
I'm not foaming at the mouth, I'm just pointing out that you or I don't know for sure what Apple is planning to do with Snow Leopard. And where did they announce that there's no value added to PPC macs? The only evidence you've given are the developer preview specs and two big technologies that are going to be implemented in 10.6 that happen to be Intel only. I'm not saying that it's not enough evidence for many of us to come to a 100% conclusion. I won't necessarily be that surprised if 10.6 is Intel only, but it just seems to be like it should be a much bigger announcement than how it was handled.
I don't disagree with any of these points (nor do I consider you to be mouth-foamy), except that "handling" of the "announcement" isn't the case yet. As I've said, a definitive announcement is premature at this point. 10.6 isn't even at a true beta milestone yet, nor have the majority of its distinguishing features been developed. The actual announcement, either way, is still several months in the future (the release of further details at Macworld would be a prime candidate). Apple makes its announcements on a careful schedule, and will regularly refuse to comment or downright lie in order to keep that schedule (recall the iPhone denials, as one of the latest examples)--the whole thing is carefully orchestrated theater.
 
The change over

Well, I guess that leaves me in a catch 22 then.

On one hand it's a well known fact that Apple has a long track record of bold moves and cutting off legacy support for this and that at regular intervals. There was the floppy drive that went out the window. There was the dropping of various connectivity (SCSI, parallel, mouse port, serial, VGA... none of this was announced loudly, most users discovered it when they unboxed their new Macs).

Mac never had a "parallel" or "serial" port as the terms are generally used in the PC world. The separate mouse port was put out of its misery way back in 1986. The ADB was put out to pasture in 1998 the same year USB was introduced. There were plans for three SCSI-3 interfaces: FireWire; SSA (Serial Storage Architecture) and FC-AL (Fibre Channel - Arbitrated Loop). Only FireWire really went anywhere.

Apple found that USB was on par with the very old SCSI-1 interface speedwise and had Macs able to use both around for a couple of years. The demise of SCSI was a given--even on the Mac the interface was a headache once you got over three devices. In the PC world SCSI was an unmitigated train wreck.

VGA wasn't a big deal as most macs cam with adapters.

Things are enver as cut and dried as they appear.
 
If the only changes are Intel-only, it has the necessary and obvious effect of providing nothing of benefit to PowerPC users.

The important detail about Grand Central isn't its multicore implementation, it's that it's Intel-specific in nature, like the other announced feature. If the new code is Intel-only, the new technologies are Intel-only, and the development process remains Intel-only, it leaves nothing for PowerPC users to want or benefit from.

It seems as though some people just want the 10.6 name on their machine--regardless of whether it offers anything of utility. They can just renumber the 10.5 code to 10.6, making no changes, and that seems to be what some people are asking for. It does not make sense, but that may be what Apple does just to pacify these people.

What people want is knowing they'll be able to run applications developed for 10.6 or later and will have more support than just a couple maintenance updates beyond.


That's quite clearly not the case. If you have poorly written high-level code, improving the machine code implemented upon compiling isn't a magical fix.

With any kind of programming change, the end result is in the machine code. Anything you do is changing the machine code somehow, whether it's tweaking the compiler, the API-level code, or high-level source.

That simply proceeds from a faulty premise that there's a major defect in the compiler. Efficiency problems in execution come from a variety of sources, and each must be particularly addressed. No matter how good you make your compiler, you can't eliminate the results of lazy/rushed programmers or erroneous code.

Erroneous code cannot be fixed by the compiler, however rushed or lazy code, provided that it is functionally correct can be fixed by modifying the compiler so that it recognizes and implements the code efficiently in machine code. Whether or not it's worth it to do it in the compiler or to just fix the source is up to the programmers to decide, although fixing the compiler will affect all developers especially if the non-optimal source is seen as a common method for handling that sort of function.

No. 10.5 would be maintained as long as they choose to do so (historically, a few maintenance updates).

Not nearly as much simplification as just letting it go.

Where are you seeing this ongoing 10.5 development? The PowerPC staff will be transitioned to other projects based on their skills and interests (many of them already have been). At this point, there aren't that many of them left anyway.

Well they're going to have to deal with the masses of unsatisfied PPC users at some point, if they roll out 10.6 for PPC that maybe doesn't do as much as it does for Intel performance gains, and roll the 10.5.x updates into 10.6.x updates they can probably get off ending 10.5.x updates sooner and just roll them into the 10.6.x updates. No one is forcing PPC users to buy it and Apple can explicitly tell PPC users that they won't see much of a boost. PPC users will buy it and Apple makes money while doing very little different other than moving 10.5.x+1 into 10.6.y and making the PPC users feel all warm and fuzzy inside.

Because it's a substantially different codebase and not a bugfix update, which would break their numbering protocols.

If it's such a major fix then why does everyone seem to think that it's going to be so trivial for developers to be sure that their code works on 10.5 or earlier and PPC? If it's big enough to warrant a 10.x update then there's a slew of re-testing to be done in order to make sure compatibility is still there. A strong official announcement would allow savings by giving them a chance to decide to freeze their 10.5 and newer versions and start working on 10.6 only code to take the most advantage of the new speed/stability and not have to worry about back compatibility.

I don't disagree with any of these points (nor do I consider you to be mouth-foamy), except that "handling" of the "announcement" isn't the case yet. As I've said, a definitive announcement is premature at this point. 10.6 isn't even at a true beta milestone yet, nor have the majority of its distinguishing features been developed. The actual announcement, either way, is still several months in the future (the release of further details at Macworld would be a prime candidate). Apple makes its announcements on a careful schedule, and will regularly refuse to comment or downright lie in order to keep that schedule (recall the iPhone denials, as one of the latest examples)--the whole thing is carefully orchestrated theater.

Well, we've seen Arn's official comment, they haven't confirmed. This actually leads me to believe that they will probably at least support G5s and might be deciding whether or not G4s (for the last rounds of PowerBooks and iBooks) might be on the chopping block. What would the harm be in letting us know that it's Intel only through the spokesperson? No one expects any Intel machines to be dropped so not knowing means that there is some pursuit of PPC going on.

Just like Clinton's campaign, the sooner they announce the more time it gives PPC users to accept it and not be too bitter when the 10.6 update ships (maybe even rework their budgets to buy newer hardware). The longer they wait or give hope the more disappointed/bitter PPC users will be when the announcement does hit.

So, none of us know, we just have varying levels of confidence based on the evidence.
 
I'm pretty confident that Apple will keep a PPC G5 build, I'm not so sure they'll seed it or debug it for release as Snow Leopard. I think most PPC systems devs will move to work on PA Semi stuff ... On my pet platform (Java), the transition to Intel 64 bits (whatever the x-64-name) was done a few months ago ...

The correct name would be EM64T :)
 
What people want is knowing they'll be able to run applications developed for 10.6 or later
It's not a feature release! Developing for 10.5 will still work for 10.6. The way it's currently structured, you can develop to take advantage of 10.6 features without breaking compatibility with 10.5--the basic APIs are unchanged (unlike 10.2 - 10.5). Grand Central and OpenCL gracefully fall back if the system can't take advantage of those technologies.
if the non-optimal source is seen as a common method for handling that sort of function.
Then it's a problem with the API or programming language that needs to be addressed. The compiler should not be rewriting code and correcting what it views as "mistakes". That's the function of a higher-level checking feature that might be available in the IDE, but a compiler compiles code exactly as it is instructed, whether it's suboptimal or not--failure to do so makes bugfixing almost impossible. XCode helps you out in a big way, but if you tell it to do something and ignore its objections, it does not override you--just as any good tool should.
No one is forcing PPC users to buy it and Apple can explicitly tell PPC users that they won't see much of a boost. PPC users will buy it and Apple makes money while doing very little different other than moving 10.5.x+1 into 10.6.y and making the PPC users feel all warm and fuzzy inside.
That's absolutely ridiculous. You're actually okay with just changing the numbering to shut people up. That, more than anything, shows the massive infirmity of the PPC complaint. Moreover, there's no statement as to price or whether Apple will be making any money from 10.6.

Doing as you suggest would break the version number protocols. 10.6, as 10.5.x renumbered, would lack the 10.6 codebase. It has no business being numbered as such to pacify insecure users.
If it's such a major fix then why does everyone seem to think that it's going to be so trivial for developers to be sure that their code works on 10.5 or earlier and PPC?
Because it's not a feature release. The reshuffling is behind the scenes. Nothing changes in terms of API calls. You write using the same functions as 10.5, and they are carried out differently. In the case of new technologies you might target, the last 10.5 updates will probably be, as historically done, compatibility updates to allow Leopard to understand and safely ignore Snow-Leopard specific bits.

It won't be easy for Apple, but that doesn't mean it won't be trivial for application-level developers.
Well, we've seen Arn's official comment, they haven't confirmed. This actually leads me to believe that they will probably at least support G5s and might be deciding whether or not G4s (for the last rounds of PowerBooks and iBooks) might be on the chopping block.
If that were the case, why wouldn't they have confirmed that at least some PowerPC systems definitely would be covered? The comment fell conspicuously short of that.

This seems an intense form of denial. If "developer assurance" is what you're after, as you've said, the "no decision" comment should be rather unsettling for you. If there were no chance of them dropping PPC entirely, then there would be no reason to leave that question unanswered. Instead, that comment reinforces the possibility of no PowerPC support.
What would the harm be in letting us know that it's Intel only through the spokesperson? No one expects any Intel machines to be dropped so not knowing means that there is some pursuit of PPC going on.
Not necessarily. It just means they're not ready to announce it yet. At this stage, as evidenced by many of the commenters here, announcing no PowerPC support before being able to show people what Snow Leopard is would do more harm than good. Even with an above-average amount of knowledge, you habitually treat 10.6 like any other 10.x release in your comments, when it expressly is not. That indicates that the general public needs to see more of Snow Leopard before they understand that there's no point in having it if they won't benefit from its changes, and that Snow Leopard does not mean being left behind like Panther users when Tiger came out.
The longer they wait or give hope the more disappointed/bitter PPC users will be when the announcement does hit.
They're not giving any hope at all. It's all created in the minds of people hearing that announcement. Nothing they've done suggests that PowerPC will be kept. They didn't instill any hope by refusing to confirm the rumors--hope would have been them denying any element of it.

I'm not foreclosing the possibility, but that's false hope. They've given you zero evidence of PowerPC support and nothing but evidence against it. Some people are holding out, looking for any possible path to it. It's better all around if they simply start preparing for the inevitable. If it stalls and through some stroke of sheer luck, 10.6 support some PowerPC Macs, it'll be a pleasant surprise that way. Seeing hope when all signs point the other way is just setting yourself up for disappointment.
 
Then it's a problem with the API or programming language that needs to be addressed. The compiler should not be rewriting code and correcting what it views as "mistakes". That's the function of a higher-level checking feature that might be available in the IDE, but a compiler compiles code exactly as it is instructed, whether it's suboptimal or not--failure to do so makes bugfixing almost impossible. XCode helps you out in a big way, but if you tell it to do something and ignore its objections, it does not override you--just as any good tool should.

I'm not saying it does anything differently than what it was told just that there are a million different ways to do the exact same thing. Some are sloppy and lazy some are elegant and some are just plain stupid. The better a compiler is the more it will recognize that different code will yield the same results and implement the exact same optimized code. There is nothing that is corrected. I write HDL for my living along with software and a few classes writing assembly. I have often seen the compiler optimize my code to much simpler logic that has improved my coding over the years. I realize that HDL is different than higher level programming languages but the general principal is the same.

That's absolutely ridiculous. You're actually okay with just changing the numbering to shut people up. That, more than anything, shows the massive infirmity of the PPC complaint. Moreover, there's no statement as to price or whether Apple will be making any money from 10.6.

I never said that they were just changing the numbering, just that PPC would not see as great of a gain as Intel users.

Because it's not a feature release. The reshuffling is behind the scenes. Nothing changes in terms of API calls. You write using the same functions as 10.5, and they are carried out differently. In the case of new technologies you might target, the last 10.5 updates will probably be, as historically done, compatibility updates to allow Leopard to understand and safely ignore Snow-Leopard specific bits.

You are very trusting if you believe that it will be completely compatible after such a major rework. If it's enough of an update to require a 10.x number, it's enough to make me wary of applications functioning exactly the same on it.

If that were the case, why wouldn't they have confirmed that at least some PowerPC systems definitely would be covered? The comment fell conspicuously short of that.

This seems an intense form of denial. If "developer assurance" is what you're after, as you've said, the "no decision" comment should be rather unsettling for you. If there were no chance of them dropping PPC entirely, then there would be no reason to leave that question unanswered. Instead, that comment reinforces the possibility of no PowerPC support.

They've already released a version that's Intel only. To say that they don't know which architectures will be supported would indicate that there's at least some work going into the PPC codebase, maybe it won't be used, maybe it'll all get rolled into a 10.5.x update and they'll keep 10.6 Intel only. But since they won't confirm something that's supposed to be so obvious that I'm in "denial" then I'd say there's a decent chance of it supporting PPC.

Not necessarily. It just means they're not ready to announce it yet. At this stage, as evidenced by many of the commenters here, announcing no PowerPC support before being able to show people what Snow Leopard is would do more harm than good. Even with an above-average amount of knowledge, you habitually treat 10.6 like any other 10.x release in your comments, when it expressly is not. That indicates that the general public needs to see more of Snow Leopard before they understand that there's no point in having it if they won't benefit from its changes, and that Snow Leopard does not mean being left behind like Panther users when Tiger came out.

How does preparing users of an unsupported architecture do more harm than good? Providing any sort of hope will only make the announcement that much more crushing, and if the computers are part of a business it gives more time for the business to start on an upgrade path if they want the new speed/stability that 10.6 is supposed to supply. A short notice might entice a business to look strongly at alternatives on the next upgrade. Time would be on Apple's side.

They're not giving any hope at all. It's all created in the minds of people hearing that announcement. Nothing they've done suggests that PowerPC will be kept. They didn't instill any hope by refusing to confirm the rumors--hope would have been them denying any element of it.

I'm not foreclosing the possibility, but that's false hope. They've given you zero evidence of PowerPC support and nothing but evidence against it. Some people are holding out, looking for any possible path to it. It's better all around if they simply start preparing for the inevitable. If it stalls and through some stroke of sheer luck, 10.6 support some PowerPC Macs, it'll be a pleasant surprise that way. Seeing hope when all signs point the other way is just setting yourself up for disappointment.

Until they confirm all we have is rumors. If the developer release and new features are enough for everyone to be so sure PPC isn't there, why not admit it. If the rest of us are being completely illogical in our idea that it might be there then there's no point in denying something so completely obvious to the rest of the world.
 
The better a compiler is the more it will recognize that different code will yield the same results and implement the exact same optimized code.
Again, this is something that depends on the specific nature of the optimization, and it is impossible to generalize so broadly. For your statement to be true, it requires an assumption that a given compiler procedure is not optimized to begin with, which simply is not true for many, if not most, operations.

Optimizing the compiler is ongoing process done by GCC developers. Unless and until a new version of GCC is announced for 10.6, the compiler is not the source of code optimizations. Rather, as indicated, it is the actual source of the OS being tweaked.
I never said that they were just changing the numbering, just that PPC would not see as great of a gain as Intel users.
I don't see any evidence of any code change having any impact on PowerPC. So far, Snow Leopard offers exactly zero for PowerPC users to take advantage of. Not a single new line of code is something they could use. If they're not getting the new code, then calling it 10.6 is just slapping a different number on the same, old code. That's pointless.
You are very trusting if you believe that it will be completely compatible after such a major rework. If it's enough of an update to require a 10.x number, it's enough to make me wary of applications functioning exactly the same on it.
This just keeps going around and around in circles. It's not about being trusting; it's about being out of the application developer's hands. The changes are occurring behind the developer interface, not at or after it. Rewrites to take advantage of Grand Central/OpenCL will have the necessary ability to be ignored and treated essentially as code comments where GC is unavailable.
To say that they don't know which architectures will be supported would indicate that there's at least some work going into the PPC codebase,
Why? All it indicates is that they are not confirming the rumor at this time. It may mean that there is ongoing PPC support being worked on, but it is not a necessary condition of that statement.
How does preparing users of an unsupported architecture do more harm than good?
Because without a demonstration of the OS and a showing that it doesn't cut them off from their applications, it causes the type of melodramatic, misguided, wailing rants that have plagued this thread. PowerPC users should have started "preparing" 3 years ago. I was personally upset about the decision to ditch RISC processors, but like I've said, it's not a platform war anymore. It's just reality.
If the developer release and new features are enough for everyone to be so sure PPC isn't there, why not admit it.
We've been here already, several times now. It's premature for that sort of announcement, because it distracts from other things going on at Apple at a point before the 10.6 has even entered beta. Letting people stew in their outrage without showing them that they're not missing out on any "killer" apps is bad PR.
 
I do agree that leaner code should mean faster machines, so I don't mind the drop of PPC support, even though 2/3 of my Macs are G4s (and still run Tiger anyway).
Surely there is no real overhead in the PPC support though? Apps are compiled as universal binaries, meaning they have Intel code bundled with PPC code, the OS just has to select the one it wants and load that, ignoring the other one.

I personally think it's still too soon to drop support for PPC, the G5 powermacs are still fairly competitive machines.
 



131105-6846_400.jpg


Image from LogicielMac
LogicielMac publishes a screenshot for the system requirements for Mac OS X Snow Leopard which was seeded to developers this week. The requirements list the following:

- An Intel Processor
- An internal, external, or shared DVD drive
- At least 512 MB of RAM
- Display connected to an Apple-supplied video card
- 9GB of disk space, or 12GB for developer tools

Developers received an early copy of Snow Leopard at WWDC this week. As this is an early version, requirements could change in the future, but the dropping of PowerPC support has been long rumored. MacRumors can independently verify that these are the current requirements for Snow Leopard.


Article Link

An intel Processor ...
It's not bad, but also not good.
Before I acquired an Apple computer,
I had heard one news about Apple was that
its processors would be intel.
But when I bought and used a secondhand one,
I felt firstly that the sort of old professor was very good,
especially when it showed pictures.
 
Again, this is something that depends on the specific nature of the optimization, and it is impossible to generalize so broadly. For your statement to be true, it requires an assumption that a given compiler procedure is not optimized to begin with, which simply is not true for many, if not most, operations.

And once again show me where I said that this was the case for many or most operations? I've only been arguing that optimization can be done if a properly functional piece of code is found to be the source of inefficient machine code. If the compiler were perfect or even close, there would be no reason to have to rework everything behind the API calls for speed and stability since it would already be the most optimized machine code it could be. However this does not rule out functions, steps, processes, that do not need to be there in the first place which to me would count as erroneous code.

I don't see any evidence of any code change having any impact on PowerPC. So far, Snow Leopard offers exactly zero for PowerPC users to take advantage of. Not a single new line of code is something they could use. If they're not getting the new code, then calling it 10.6 is just slapping a different number on the same, old code. That's pointless.

You do not know this for sure, only Apple and it's workers do. Just because you don't see any evidence does not mean that Apple isn't touching PPC code. If they're removing extraneous steps and fixing erroneous functions a fairly high programming level, it's very likely that the PPC will see benefit from that as well since more of that code will be processor agnostic.

This just keeps going around and around in circles. It's not about being trusting; it's about being out of the application developer's hands. The changes are occurring behind the developer interface, not at or after it. Rewrites to take advantage of Grand Central/OpenCL will have the necessary ability to be ignored and treated essentially as code comments where GC is unavailable.

Even if the function calls and interface for developers remains the same, tweaking the API functions for speed and stability is enough of a rework that it would still require quite a bit of testing. Until I run my code on 10.6 and fully test it I have no guarantee that one of their fixes or tweaks won't break my code. It may be unlikely but when that much code is "fixed" there are bound to be unintended consequences.

Why? All it indicates is that they are not confirming the rumor at this time. It may mean that there is ongoing PPC support being worked on, but it is not a necessary condition of that statement.

Because without a demonstration of the OS and a showing that it doesn't cut them off from their applications, it causes the type of melodramatic, misguided, wailing rants that have plagued this thread. PowerPC users should have started "preparing" 3 years ago. I was personally upset about the decision to ditch RISC processors, but like I've said, it's not a platform war anymore. It's just reality.

Many did start preparing 3 years ago but applications like Photoshop finally went universal as late as April of last year. It made a lot of sense to stick with PPC until that point to maintain maximum speed and compatibility. Many companies will have only started looking at upgrading to Intel from then. Apple dropping PPC support in the OS this soon may hurt them by giving the (false) impression that they don't support their hardware for very long, and for the premium they charge it may have some companies looking at alternatives in the next purchase cycle.

We've been here already, several times now. It's premature for that sort of announcement, because it distracts from other things going on at Apple at a point before the 10.6 has even entered beta. Letting people stew in their outrage without showing them that they're not missing out on any "killer" apps is bad PR.

If the evidence is so obvious there would be nothing to confirm or deny. It would simply be the truth despite what me and the other "melodramatic, misguided, wailing" people seem to believe. But they've already told us that there wouldn't be any "killer apps" why not just admit that 10.6 is a speed and stability upgrade for Intel users and let the wounds start to heal. The longer they allow PPC users to cling to hope the less time they will have for the official announcement to blow over.
 
As long as the party does not explicitly claim to confirm or deny the leaked material, it can be discussed in the context of speculation.
Suppose under NDA, you learn the iPhone 3G comes in white. Various people speculate about the colors; white inevitably comes up. In your blog you say, "I'm not explicitly confirming it, but I can see why white is a good idea." Do you really think that fig leaf would satisfy Apple? Or are you never going to be offered info under NDA again, by them or anyone else that knows of that incident, regardless of specific legal consequences?

Part of the burden of agreeing to sign NDA is to keep quiet.
 
In your blog you say, "I'm not explicitly confirming it, but I can see why white is a good idea." Do you really think that fig leaf would satisfy Apple?
Yes, but "I'm explicitly not confirming it" is a contrived statement. You'd probably just say, "white's a good idea for a color and would probably sell well."
Part of the burden of agreeing to sign NDA is to keep quiet.
To keep quiet about trade secrets and confidential information. Once that information is no longer (a) secret or (b) confidential between parties, it is no longer covered by the NDA. Any further information is your responsibility to keep quiet. A trade secret is only legally protectable as long as it is a secret.
And once again show me where I said that this was the case for many or most operations?
"I'm not saying it does anything differently than what it was told just that there are a million different ways to do the exact same thing. Some are sloppy and lazy some are elegant and some are just plain stupid. The better a compiler is the more it will recognize that different code will yield the same results and implement the exact same optimized code."

There are not a million different ways to do the exact same thing. For any given "exact thing", there may not be a practical way to improve the compiler, but there are almost always ways to improve the source code. None of your statement was prefaced by "in some limited circumstances" or anything else--it's presented as a commonplace occurrence. It's not. Developers shouldn't say, "My code sucks. Let the compiler guys find a way to fix it." They should just fix it.
I've only been arguing that optimization can be done if a properly functional piece of code is found to be the source of inefficient machine code.
And that was never a disputed issue, nor has it been a factor in this discussion, but it keeps taking up space all the same. Had Apple referred to GCC optimizations and improvements, you'd have an important point. As it stands, the focus is on the actual codebase of OS X.
If the compiler were perfect or even close, there would be no reason to have to rework everything behind the API calls for speed and stability since it would already be the most optimized machine code it could be.
False. The machine code compiler and the developer-accessible APIs are not on the same level. Improvements to the API can be done without a single change to the machine compiler. Just think of all the Core technologies rapidly developed for Tiger. At some point, they have to be tightened. Not the compiler, but the API itself. Doing so is not architecture agnostic.
Until I run my code on 10.6 and fully test it I have no guarantee that one of their fixes or tweaks won't break my code.
Absolutely, but if it breaks your code, it breaks someone else's, and it's a fix Apple needs to make. You can decline to support 10.6 until that is done, or
Apple dropping PPC support in the OS this soon may hurt them by giving the (false) impression that they don't support their hardware for very long, and for the premium they charge it may have some companies looking at alternatives in the next purchase cycle.
Well, for starters, they support their hardware exactly as long as their service agreement states. Future software updates are not guaranteed for any length of time from any major vendor--the only guarantees are bugfix updates to the current software. From there, no business is going to jump on the 10.6 bandwagon immediately at release. It's usually about a year before businesses will transition to a new OS--by that time, every PPC Mac will be long out of warranty. Moreover, if the "premium" charged for the hardware is causing them to hesitate, that means they're already looking at alternatives, so you've loaded the question.

An Apple shop is an Apple shop for a reason, and it's not how they support four year old Macs with the latest system software.
If the evidence is so obvious there would be nothing to confirm or deny.
Of course there is. They have to make an explicit statement at some point.
But they've already told us that there wouldn't be any "killer apps" why not just admit that 10.6 is a speed and stability upgrade for Intel users and let the wounds start to heal.
Asking the question repeatedly and forcing me to answer it repeatedly isn't going to change the result. It's premature.
The longer they allow PPC users to cling to hope the less time they will have for the official announcement to blow over.
That's a good thing. PPC users can't update anyway, so why overshadow Apple's important progress and interesting new technologies with a bunch of whining for longer than they have to? If there's no PPC support, they're going to get some amount of bad press at launch. Why give two bad press cycles--one a year before it's released, and another rehashing the whining at release?
 
...

I haven't bothered to read through all 33 pages of this, so I'm sure that what I'm about to say has already been said... hence my apologies for being redundant.

Apple has already stated that SL's main mission will be more focused towards optimizing and streamlining the OS, opposed to adding a whole bunch of new "whiz-bang" features.

If that's the case, then why on earth would Apple spend any time, effort, or money optimizing the OS that's been put out to pasture for a few years now? The reality is that PPC user received all the optimizations they're ever going to get from OS 10.0-10.4... and we should all be happy with those performance increases. The future is Intel... Frankly, I'd question Apple's motives for spending any more resources on the PPC architecture.

Further still... if SL is to primarily have the same feature set as Leopard, then what exactly are PPC users going to be missing out on other than the optimizations for Intel that they won't be able to use in the first place?

So it seems that PPC users won't really but shut out in the cold until 10.7 rolls around... and by that point it will have been around 5 years or so since the last one was sold.

In all honesty... I think this is a brilliant move on Apple's part towards completing their transition over to the Intel architecture - I really don't see how there would/could be any better way of doing so.

Basically, all PPC users will be suffering from is a hit to their egos in that they won't be able to say that they're running the latest and greatest. Perhaps the only way Apple could have lessened the blow would have been to label the next release as OS 10.5.5 as they had done with OS 8... but the only reason for them to have done such would have been to coddle PPC users and nothing more.

So for all of those asking why there isn't going to be a slew of new features in 10.6... all they have to do is look at it's correlation with the dropping of PPC support.

10.6 is the final chapter of PPC Macs.... if you haven't bought an Intel machine yet, you have around 2-3 years or so until you start missing out on new features.

Again... as far as I'm concerned, it's a brilliant move.
 
"I'm not saying it does anything differently than what it was told just that there are a million different ways to do the exact same thing. Some are sloppy and lazy some are elegant and some are just plain stupid. The better a compiler is the more it will recognize that different code will yield the same results and implement the exact same optimized code."

There are not a million different ways to do the exact same thing. For any given "exact thing", there may not be a practical way to improve the compiler, but there are almost always ways to improve the source code. None of your statement was prefaced by "in some limited circumstances" or anything else--it's presented as a commonplace occurrence. It's not. Developers shouldn't say, "My code sucks. Let the compiler guys find a way to fix it." They should just fix it.

Give a programming assignment to 400 different programmers and you'll end up with 400 different implementations that do the same thing. They may use similar methods and formats but they will use different paths, and the end result of their programs are the same. Some results will be more optimal and in different ways, there's memory optimal, speed optimal, and many varying balances to be struck in between.

If there were only one, or very few, correct way(s) to code something then Apple wouldn't have to release 10.6 since the optimal solution is already there or it's darn close. Improved compilers can figure out that two very different, yet functionally identical pieces of code should result in the same machine instructions and can implement the most optimal low level code for both styles where a different compiler might have very different results based on the two input streams.

At any rate where to do the fixes is not up to you or I, the entire point of this off topic discussion was that compiler "fixes" can also result in more optimal machine language and in some instances yield the same results as a higher level code fix and result in a better optimizing compiler. I never meant to imply that this was the way to provide all optimizations to OSX nor would I advocate that as the only path but it is another path that can be utilized if the gain outweighs the cost.

False. The machine code compiler and the developer-accessible APIs are not on the same level. Improvements to the API can be done without a single change to the machine compiler. Just think of all the Core technologies rapidly developed for Tiger. At some point, they have to be tightened. Not the compiler, but the API itself. Doing so is not architecture agnostic.

I never said that. The higher level of language or abstraction you go into in the MacOSX APIs the more likely you are to be in architecture agnostic code. Any fixes made at the levels that are architecture agnostic will also benefit the PPC users as long as it's not using the new technologies.

Absolutely, but if it breaks your code, it breaks someone else's, and it's a fix Apple needs to make.

Assuming that what broke your code was not something that Apple had found to be erroneous and "fixed" in 10.6. I've seen instances where a little known bug has been used as a "feature" and applications break when the bug is fixed. Not that it's good coding practice but in today's world rushed code is becoming less of an exception and more of the norm.

Moreover, if the "premium" charged for the hardware is causing them to hesitate, that means they're already looking at alternatives, so you've loaded the question.

Only if the reason the premium seemed worth it was that Apple has a record of machines that tend to last longer and hold their value better than other PCs.

Of course there is. They have to make an explicit statement at some point.

Asking the question repeatedly and forcing me to answer it repeatedly isn't going to change the result. It's premature.

If it's so obvious and many here are 100% sure that PPC is being dropped and the rest of us are clinging to false hope then it's already been announced and we're being dense. If there hasn't been an official announcement and they aren't confirming that it's Intel only. Then we're all just speculating and our thresholds for evidence vary.

And my wife thanks you... Due to this debate I get most of this stuff out of my system and don't have to confront her to satisfy my urge to debate completely meaningless stuff while at home.
 
Further still... if SL is to primarily have the same feature set as Leopard, then what exactly are PPC users going to be missing out on other than the optimizations for Intel that they won't be able to use in the first place?
Precisely.
Basically, all PPC users will be suffering from is a hit to their egos in that they won't be able to say that they're running the latest and greatest.
That's largely what it comes down to, it seems. Especially among those threatening legal action and opposing the suggestion that the end is near with such intense vitriol.

They're not complaining that OpenCL won't work--their GPUs are too old anyway. They're not complaining that Grand Central won't work--it's a multicore-oriented technology, not a multi-CPU one (i.e. Dual G4 and G5 systems don't see much of an improvement because Leopard already handles multithreaded applications and does CPU load-balancing). They're not complaining about Exchange integration, because there's no reason to expect it won't be offered in a 10.5 update (at least along the lines of iChat AV for Panther). That's all 10.6 is right now, and it offers nothing for them.

But it must not be about reason. Outbursts like this rarely are.


Give a programming assignment to 400 different programmers and you'll end up with 400 different implementations that do the same thing.
Yes, absolutely. And all 400 are built on the same compiler. Correcting and improving those 400 different approaches involves tweaking the code itself and carefully managing it. Saying that someone else can come along and rewrite the compiler to fix what was inefficient source code is a colossally bad practice, and rarely, if ever, works. Even if the compiler is improved, other code will benefit from that as well, and yours will still be just as slow relative to the alternatives. If someone can write source code, using the same compiler, that gets substantially better performance, you have to fix your source code.
the entire point of this off topic discussion was that compiler "fixes" can also result in more optimal machine language and in some instances yield the same results as
Then end it. The compiler is not the issue. OS X optimization, not GCC, is the topic. Stop using compiler improvements as a defense in every single post; it's irrelevant. Bring your ideas to a GCC thread; I'm sure they'll be valuable there.
I never said that.
"If the compiler were perfect or even close, there would be no reason to have to rework everything behind the API calls for speed and stability since it would already be the most optimized machine code it could be."

There is no causation in that statement--whether or not the API needs work has nothing to do with whether or not the compiler needs work.
Any fixes made at the levels that are architecture agnostic will also benefit the PPC users as long as it's not using the new technologies.
Yes, but changes at the post-platform level would be new features. Accordingly, 10.6 does not have extensive fixes at that level.
I've seen instances where a little known bug has been used as a "feature" and applications break when the bug is fixed. Not that it's good coding practice but in today's world rushed code is becoming less of an exception and more of the norm.
That's too bad for the developer. He shouldn't have done that, whether other programmers are equally lazy or not, and any attempt to blame a company for fixing a bug like that based on developer inconvenience is ludicrous.
Only if the reason the premium seemed worth it was that Apple has a record of machines that tend to last longer and hold their value better than other PCs.
Not being able to run Snow Leopard has no impact on the functional life or retained value of the machine.
If it's so obvious and many here are 100% sure that PPC is being dropped and the rest of us are clinging to false hope then it's already been announced and we're being dense.
On the contrary, if it had been announced, you'd be insane. False hope and being thick-headed are only relevant prior to an announcement.
 
I haven't bothered to read through all 33 pages of this, so I'm sure that what I'm about to say has already been said... hence my apologies for being redundant.

Apple has already stated that SL's main mission will be more focused towards optimizing and streamlining the OS, opposed to adding a whole bunch of new "whiz-bang" features.

If that's the case, then why on earth would Apple spend any time, effort, or money optimizing the OS that's been put out to pasture for a few years now? The reality is that PPC user received all the optimizations they're ever going to get from OS 10.0-10.4... and we should all be happy with those performance increases. The future is Intel... Frankly, I'd question Apple's motives for spending any more resources on the PPC architecture.

<snip>

10.6 is the final chapter of PPC Macs.... if you haven't bought an Intel machine yet, you have around 2-3 years or so until you start missing out on new features.

Again... as far as I'm concerned, it's a brilliant move.


You're right. . . . It's been said. Like 500 times.
 
Not to change the subject here, but has anyone read the article on Gizmodo? Its pretty interesting, pertains to the Parallel Processing, [ie. Dual Core] and GPU processing.

A good read, for those with Intels. Link.
 
And all this begins with a screenshot of the so called "specs" for "Snow Leopard".

Well guess what:
-iPhone SDK beta's are also Intel only.
-But hey, they just run great on PPC. You know why it's a so called Intel beta?
-Because the SDK runs already perfect on PPC.

iPhone SDK beta's are a good example why a spec says "Intel only".

Guess what:
Snow Leopard already runs on PPC. Snow Leopard is already optimized for PPC. That's why the beta's are Intel only.
It's so easy for Apple to code and optimize al that stuff for PPC G5.

Bottom line: Apple needs to build Intel Beta's. Not PPC beta's. They play with PPC code ;).

Just wait and see when the iPhone SDK will be out of beta ;). I'm sure this will be released as the new Xcode package ;). Oh yes, this so called new Xcode package will be Universal.

If Apple would drop PPC G5 support in Snow Leopard, they would also drop it in the iPhone SDK beta's. But in the end, all this will run on the "faster" PPC Mac. Or do you Intel geeks realy think that Apple will strip all the PPC code when the so called iPhone SDK comes out of beta? If this would be the case the SDK would not run on PPC since SDK1. This is too stupid for words! :D Realy too stupid... No PPC G5 support :rolleyes: in the iPhone SDK or Snow Leopard.... Hahahahaha...

BTW: I'm running the iPhone SDK on my G5 since beta 1. It all works fine & "bug free". New SDK beta's just add some extra features and new application builds. I love the iPhone simulator on my G5. I wonder why they just don't release it for PPC :rolleyes:. Oh yes, it's still buggy on Intel and they need to sell Intel developer machines ;).

Seems that I'm right hey ;)
xCode 3.1 includes the iPhone SDK and is PPC/Intel compatible.

You will see the same with Snow Leopard. Beta's are Intel, release will be both PPC/Intel...

Greetz :D
 
One year pases

and, snow leopard doesn't support PPC, doesn't surprise me, if i buy an iMac today, probably'll be outdated in 2 years
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.