Because a dualcore processor is about the same as a dual CPU system.
In theory, but a mac w/2x single core processors would still be faster than a powermac with one dual core processor. It's slower than an actual dual processor machine. I think they would equal out at close to 1x 2.3 GHz dual-core processor would be same as 2x single core 2.0. or 1.8 GHz machines. (I think it's closer to the 1.8's myself.) I read a while back that comparatively a real dual processor machine can still handle a better workload in highly stressful CPU load situations. Rendering, and video stuff would fair better with a Dual sockets with single core processors in it; than a single socket machine with one dual core processor. That is where I think 2x 1.8GHz would probably score better than one dual core 2.3GHz G5.
If, and when they put these in PowerMacs they still need to have 2x dual core processors to stay competitive vs. current intel, and AMD driven PC's anyway IMO.
In theory, but a mac w/2x single core processors would still be faster than a powermac with one dual core processor.
I would say the opposite is true. In a dual core chip, the two cores communicate faster than in a two single-core configuration. You can expect at least the same performance, if not better in some cases.
I would say the opposite is true. In a dual core chip, the two cores communicate faster than in a two single-core configuration. You can expect at least the same performance, if not better in some cases.
Not according to the dual core tests that were posted in here, and elsewhere for IBM, Intel, and AMD a while back.
I would say the opposite is true. In a dual core chip, the two cores communicate faster than in a two single-core configuration. You can expect at least the same performance, if not better in some cases.
I don't have any technical info to offer but it would seem that dual core and dual processor would have strong points in differing areas. It seems to me that tasks that require a lot of FSB bandwidth would favor the dual processors where a task that requires chip to chip communications would favor dual core processors. I don't know which tasks would fall into each of the categories but I would think that overall the performance should be fairly close with each one having an edge on the other in certain tasks.
In the light of all these speculations, it maybe possible that Apple brings REAL Dual, Dual-Core and Dual Dual-Core to the line-up of PowerMacs and Single and/or Dual-Cores to the iMacs. All we know is that Dual PowerMacs won't go faster in the months to come, FXs are limited to 2.7GHz and the only G5 alternative is Dual-Core up to 2.5GHz.
Can iMacs be equipped with (up to 2.7GHz) FXs?
Will they be better off with slower (1.4-2.0GHz) dual-core MPs?
Considering the heat, power consumption and noise factor...
Will PowerMacs get a significant boost with DUAL (2.0-2.5GHz) dual-core MPs?
It seems to me that tasks that require a lot of FSB bandwidth would favor the dual processors where a task that requires chip to chip communications would favor dual core processors.
Considering memory intensive applications, the bottleneck of Power Mac G5 architecture exists between U3 system controller and DIMMs. The independent FSB does not offer much advantage.
Quote:
Originally posted by jherrling
In the light of all these speculations, it maybe possible that Apple brings REAL Dual, Dual-Core and Dual Dual-Core to the line-up of PowerMacs and Single and/or Dual-Cores to the iMacs.
Current Apple's system controller does not have enough memory bandwidth for 4 cores, and Apple won't develop new system controller for PowerPC.
Considering memory intensive applications, the bottleneck of Power Mac G5 architecture exists between U3 system controller and DIMMs. The independent FSB does not offer much advantage.
Current Apple's system controller does not have enough memory bandwidth for 4 cores, and Apple won't develop new system controller for PowerPC.
I'd wondered about this myself. I'd thought about it in terms of bus contention of 4 cores along the Elastic bus. But you're right...if the U3 has enough trouble with latency between two chips and memory, how effective will it be to have 4 cores squabbling over memory through a narrow U3-based channel?
From what you seem to be alluding to, Apple looked at the problem, asked IBM if it had any suggestions, got told it was 'an existing issue'that was 'being worked on', looked at all the work it had already done and slowly backed away...
So. Is it safe to say that a 1.4GHz MP in a future iMac will outrun the current 2.0GHz iMac?
Just want to pound it to the ground even more, here. The answer is not only no, it should be emphatically no.
For 95% of what a consumer does - web browsing, office apps, and perhaps even the iLife apps - a 2 GHz iMac will be 20 to 50% faster than a prospective 1.4 GHz 970mp system.
Most applications can't use more than one processor. Many that do, don't do it efficiently. Even with Photoshop, a 2 GHz iMac is probably better than a 1.4 GHz 970mp.
Where a 1.4 GHz 970mp may feel smoother is in "throughput." Running applications in parallel, where each application is taking up a nontrivial chunk of CPU time. But most usage patterns for consumers, and even pros, is one app at a time. Even so, that's a "may." A 2 GHz iMac could do that sort of thing better than a 1.4 GHz 970mp.
If you start talking a 1.6 GHz or 1.8 GHz 970mp, that's when we can start thinking it may be worth it.
Quote:
And that a Dual 2.0GHz MP in a future PowerMac will outrun the current Dual 2.7GHz model?
This is more of a "perhaps". When you start talking about 4 processors, the more specialize the software. So you always have to ask what is it faster at.
If Apple sells a quad machine, it will be a specialist machine that costs more than $3k. Why, very few apps can take advantage of 4 CPUs that well. People whose usage patterns make a quad machine better than a dual will be few and far between.
Will a dual 2 GHz 970mp machine be faster than a dual 2.7 GHz 970fx machine in Photoshop? Perhaps. I'm thinking no right now.
Faster at CFD and the like? Yes.
Faster at games? For now, no. Hardly any games take advantage of more than one CPU.
Faster at Internet stuff (browsing, IM, email)? No.
Any quad machine will be for a specialist market for a specific piece of software, especially a machine that is at 0.7 GHz disadvantage. If it was a dual 2.5 GHz 970mp, that'll be a different story. I can Apple selling it for $3.5k too.
For 95% of what a consumer does - web browsing, office apps, and perhaps even the iLife apps - a 2 GHz iMac will be 20 to 50% faster than a prospective 1.4 GHz 970mp system.
yeah, true, but that is OS X 'farming out' the threads, not the individual software in some cases. so OS X for the most part takes a best guess approach for multi-threading and multi-CPUs / cores etc.
specialised software written for multiCPU multicores would give OS X more 'direction' on how to best farm out those threads across multiple processors etc, and coordinate what each thread is doing and how each thread processors information from other threads, etc.
i think that is what THT is trying to say, sounds like.
Yeah, but most of the time, those threads take barely any CPU time. So you won't notice anyway. The multiprocessor systems show their muscles when you run in parallel two or more CPU intensive tasks (be it two separate tasks or two separate threads of the same well threaded task). Note the emphasis: you will see the difference if these tasks stress both CPUs at 100% for a long time, not for a couple of seconds. Even then and for the same architecture, there is the clock speed factor: what are you comparing, a 2.0 GHz single-core G5 against a 1.2 GHz dual-core or against a 1.8 GHz dual-core?
yeah, true, but that is OS X 'farming out' the threads, not the individual software in some cases. so OS X for the most part takes a best guess approach for multi-threading and multi-CPUs / cores etc.
specialised software written for multiCPU multicores would give OS X more 'direction' on how to best farm out those threads across multiple processors etc, and coordinate what each thread is doing and how each thread processors information from other threads, etc.
i think that is what THT is trying to say, sounds like.
Incorrect. An application cannot under any circumatances be forcibly miltithreadded by the OS. Every application that reports more than one thread has explicitly spawned those threads within it's own code.
What THT is saying is most general user apps have several threads, but not all of them are actively running at the same time. At any particular time most of the work is being done by one thread and that will run faster on a faster single processor than on a slower multi-processor box. But if you try to do many things simultaneously, you would finish the collective tasks faster on a multi-CPU box, than a faster singler CPU box.
Incorrect. An application cannot under any circumatances be forcibly miltithreadded by the OS. Every application that reports more than one thread has explicitly spawned those threads within it's own code...
okay. i understand now. for some reason i was under the impression that OS X force-multithreads...
Maybe you are confusing that with the ability of the OS to use a service-process thread to answer some client application thread calls. That's a lot slower (because of the communications requirements) than the OS just executing a system lib call in the user-space thread, but it does allow you to distribute work across more than one processor. OS X uses both models dependent on which is the more efficient implementation, but any particular API call is only implemented one way or the other.
Maybe you are confusing that with the ability of the OS to use a service-process thread to answer some client application thread calls. That's a lot slower (because of the communications requirements) than the OS just executing a system lib call in the user-space thread, but it does allow you to distribute work across more than one processor. OS X uses both models dependent on which is the more efficient implementation, but any particular API call is only implemented one way or the other.
okay, yeah that was probably what i was thinking more of. so i think it may be relevant to our discussion if you or someone else can give an indication of which API calls would be these "service-process threads" that OS X might distribute across more than one processor...
it's probably tricky question but i think rather than abstractly saying so and so app will be faster on dual-core, not so and so app.... it may be better if we non-OSX-coders could get a grasp on which libraries/APIs etc might be more likely to make good use of multicore or multiCPU...
i think that's the thing that is tripping up the more 'educated' Mac users, particularly going to Macintel -- performance right now seems to be very/too dependent on how an application is written for Mac Os X. We all know that a lot of major publishers predominantly write for Windows, so we can't always 'trust' that they have the resources/desire to do their best work for Mac Os X Universal Binary for Multicore/MultiCPU....
Decision to go with Intel is an old one. SJ said the option was intentionally developed and maintained from the start of OSX. That takes a certain effort, and I don't think they would have made that effort if the intent to switch wasn't there.
I notice a lot of debate over what recent setback in dev led to the decision to switch, but I don't think any recent problems at IBM were involved. The decision is an old one. Talk of poor roadmaps is a diversion. You have to look back and wonder what was going on then, when OSX was first being created.
Decision to go with Intel is an old one. SJ said the option was intentionally developed and maintained from the start of OSX. That takes a certain effort, and I don't think they would have made that effort if the intent to switch wasn't there.
I notice a lot of debate over what recent setback in dev led to the decision to switch, but I don't think any recent problems at IBM were involved. The decision is an old one. Talk of poor roadmaps is a diversion. You have to look back and wonder what was going on then, when OSX was first being created.
What is the real reason then? Contracts with Freescale and IBM? Negative perception of Mac OS X? Deal not closed yet with Intel? hmmm intriguing
Decision to go with Intel is an old one. SJ said the option was intentionally developed and maintained from the start of OSX. That takes a certain effort, and I don't think they would have made that effort if the intent to switch wasn't there.
Actually.. The first swith for OSX was _to_ PowerPC. NeXTStep had in its later years x86 as its primary platform. There wasn't an intent to switch back to x86, as much as there was a will to keep the original platform up to date and keep all doors open. Keeping them open was probably no big deal and I wouldn't be surprised if they also kept (are keeping?) the doors open for Sparc and PA-RISC too, sine NeXTStep also ran on those platforms.
Decision to go with Intel is an old one. SJ said the option was intentionally developed and maintained from the start of OSX. That takes a certain effort, and I don't think they would have made that effort if the intent to switch wasn't there.
The AIM alliance was founded in early 90's. Later during G4 development, IBM disagreed with Motorola "VMX" (Altivec) SIMD approach ; they preferred to go toward a higher-frequency design of G3 chip, which the G4 couldn't achieve. And in some way IBM was a little later proven to be so right, remembrer the one-year 500 MHz G4 debacle... So the divorce happened between IBM and Moto between 1998 and 1999, and they developed their own PowerPC projects separately.
In 1997, Apple was starting its new OS program with OpenSTEP-Rhapsody-Mac OS X. They could then clearly imagine that the PowerPC in a whole could never destroy Intel, whereas it was originally aimed to be the next computing era leader, replacing x86. The CHRP clones were even made to win a war they never began, because AIM alliance failed to grow. Even Microsoft, also committed to CHRP before, disengaged from it.
Comments
Originally posted by Cosmos 1999
Because a dualcore processor is about the same as a dual CPU system.
In theory, but a mac w/2x single core processors would still be faster than a powermac with one dual core processor. It's slower than an actual dual processor machine. I think they would equal out at close to 1x 2.3 GHz dual-core processor would be same as 2x single core 2.0. or 1.8 GHz machines. (I think it's closer to the 1.8's myself.) I read a while back that comparatively a real dual processor machine can still handle a better workload in highly stressful CPU load situations. Rendering, and video stuff would fair better with a Dual sockets with single core processors in it; than a single socket machine with one dual core processor. That is where I think 2x 1.8GHz would probably score better than one dual core 2.3GHz G5.
If, and when they put these in PowerMacs they still need to have 2x dual core processors to stay competitive vs. current intel, and AMD driven PC's anyway IMO.
Originally posted by onlooker
In theory, but a mac w/2x single core processors would still be faster than a powermac with one dual core processor.
I would say the opposite is true. In a dual core chip, the two cores communicate faster than in a two single-core configuration. You can expect at least the same performance, if not better in some cases.
Originally posted by PB
I would say the opposite is true. In a dual core chip, the two cores communicate faster than in a two single-core configuration. You can expect at least the same performance, if not better in some cases.
Not according to the dual core tests that were posted in here, and elsewhere for IBM, Intel, and AMD a while back.
Originally posted by onlooker
Not according to the dual core tests that were posted in here, and elsewhere for IBM, Intel, and AMD a while back.
Link?
Originally posted by PB
I would say the opposite is true. In a dual core chip, the two cores communicate faster than in a two single-core configuration. You can expect at least the same performance, if not better in some cases.
I don't have any technical info to offer but it would seem that dual core and dual processor would have strong points in differing areas. It seems to me that tasks that require a lot of FSB bandwidth would favor the dual processors where a task that requires chip to chip communications would favor dual core processors. I don't know which tasks would fall into each of the categories but I would think that overall the performance should be fairly close with each one having an edge on the other in certain tasks.
Can iMacs be equipped with (up to 2.7GHz) FXs?
Will they be better off with slower (1.4-2.0GHz) dual-core MPs?
Considering the heat, power consumption and noise factor...
Will PowerMacs get a significant boost with DUAL (2.0-2.5GHz) dual-core MPs?
And, finally when will those chips be available?
Originally posted by mjteix
It seems to me that tasks that require a lot of FSB bandwidth would favor the dual processors where a task that requires chip to chip communications would favor dual core processors.
Considering memory intensive applications, the bottleneck of Power Mac G5 architecture exists between U3 system controller and DIMMs. The independent FSB does not offer much advantage.
Originally posted by jherrling
In the light of all these speculations, it maybe possible that Apple brings REAL Dual, Dual-Core and Dual Dual-Core to the line-up of PowerMacs and Single and/or Dual-Cores to the iMacs.
Current Apple's system controller does not have enough memory bandwidth for 4 cores, and Apple won't develop new system controller for PowerPC.
Originally posted by mi0im
Considering memory intensive applications, the bottleneck of Power Mac G5 architecture exists between U3 system controller and DIMMs. The independent FSB does not offer much advantage.
Current Apple's system controller does not have enough memory bandwidth for 4 cores, and Apple won't develop new system controller for PowerPC.
I'd wondered about this myself. I'd thought about it in terms of bus contention of 4 cores along the Elastic bus. But you're right...if the U3 has enough trouble with latency between two chips and memory, how effective will it be to have 4 cores squabbling over memory through a narrow U3-based channel?
From what you seem to be alluding to, Apple looked at the problem, asked IBM if it had any suggestions, got told it was 'an existing issue'that was 'being worked on', looked at all the work it had already done and slowly backed away...
Correct?
Originally posted by mjteix
So. Is it safe to say that a 1.4GHz MP in a future iMac will outrun the current 2.0GHz iMac?
Just want to pound it to the ground even more, here. The answer is not only no, it should be emphatically no.
For 95% of what a consumer does - web browsing, office apps, and perhaps even the iLife apps - a 2 GHz iMac will be 20 to 50% faster than a prospective 1.4 GHz 970mp system.
Most applications can't use more than one processor. Many that do, don't do it efficiently. Even with Photoshop, a 2 GHz iMac is probably better than a 1.4 GHz 970mp.
Where a 1.4 GHz 970mp may feel smoother is in "throughput." Running applications in parallel, where each application is taking up a nontrivial chunk of CPU time. But most usage patterns for consumers, and even pros, is one app at a time. Even so, that's a "may." A 2 GHz iMac could do that sort of thing better than a 1.4 GHz 970mp.
If you start talking a 1.6 GHz or 1.8 GHz 970mp, that's when we can start thinking it may be worth it.
And that a Dual 2.0GHz MP in a future PowerMac will outrun the current Dual 2.7GHz model?
This is more of a "perhaps". When you start talking about 4 processors, the more specialize the software. So you always have to ask what is it faster at.
If Apple sells a quad machine, it will be a specialist machine that costs more than $3k. Why, very few apps can take advantage of 4 CPUs that well. People whose usage patterns make a quad machine better than a dual will be few and far between.
Will a dual 2 GHz 970mp machine be faster than a dual 2.7 GHz 970fx machine in Photoshop? Perhaps. I'm thinking no right now.
Faster at CFD and the like? Yes.
Faster at games? For now, no. Hardly any games take advantage of more than one CPU.
Faster at Internet stuff (browsing, IM, email)? No.
Any quad machine will be for a specialist market for a specific piece of software, especially a machine that is at 0.7 GHz disadvantage. If it was a dual 2.5 GHz 970mp, that'll be a different story. I can Apple selling it for $3.5k too.
Originally posted by THT
For 95% of what a consumer does - web browsing, office apps, and perhaps even the iLife apps - a 2 GHz iMac will be 20 to 50% faster than a prospective 1.4 GHz 970mp system.
From my Activity Monitor;
- Safari: 7 threads,
- MS Word: 6 threads,
- Excel: 5 threads,
- Mail: 9 threads.
Originally posted by mi0im
From my Activity Monitor;
- Safari: 7 threads,
- MS Word: 6 threads,
- Excel: 5 threads,
- Mail: 9 threads.
yeah, true, but that is OS X 'farming out' the threads, not the individual software in some cases. so OS X for the most part takes a best guess approach for multi-threading and multi-CPUs / cores etc.
specialised software written for multiCPU multicores would give OS X more 'direction' on how to best farm out those threads across multiple processors etc, and coordinate what each thread is doing and how each thread processors information from other threads, etc.
i think that is what THT is trying to say, sounds like.
Originally posted by mi0im
From my Activity Monitor;
- Safari: 7 threads,
- MS Word: 6 threads,
- Excel: 5 threads,
- Mail: 9 threads.
Yeah, but most of the time, those threads take barely any CPU time. So you won't notice anyway. The multiprocessor systems show their muscles when you run in parallel two or more CPU intensive tasks (be it two separate tasks or two separate threads of the same well threaded task). Note the emphasis: you will see the difference if these tasks stress both CPUs at 100% for a long time, not for a couple of seconds. Even then and for the same architecture, there is the clock speed factor: what are you comparing, a 2.0 GHz single-core G5 against a 1.2 GHz dual-core or against a 1.8 GHz dual-core?
Originally posted by sunilraman
yeah, true, but that is OS X 'farming out' the threads, not the individual software in some cases. so OS X for the most part takes a best guess approach for multi-threading and multi-CPUs / cores etc.
specialised software written for multiCPU multicores would give OS X more 'direction' on how to best farm out those threads across multiple processors etc, and coordinate what each thread is doing and how each thread processors information from other threads, etc.
i think that is what THT is trying to say, sounds like.
Incorrect. An application cannot under any circumatances be forcibly miltithreadded by the OS. Every application that reports more than one thread has explicitly spawned those threads within it's own code.
What THT is saying is most general user apps have several threads, but not all of them are actively running at the same time. At any particular time most of the work is being done by one thread and that will run faster on a faster single processor than on a slower multi-processor box. But if you try to do many things simultaneously, you would finish the collective tasks faster on a multi-CPU box, than a faster singler CPU box.
Originally posted by Hiro
Incorrect. An application cannot under any circumatances be forcibly miltithreadded by the OS. Every application that reports more than one thread has explicitly spawned those threads within it's own code...
okay. i understand now. for some reason i was under the impression that OS X force-multithreads...
Originally posted by Hiro
Maybe you are confusing that with the ability of the OS to use a service-process thread to answer some client application thread calls. That's a lot slower (because of the communications requirements) than the OS just executing a system lib call in the user-space thread, but it does allow you to distribute work across more than one processor. OS X uses both models dependent on which is the more efficient implementation, but any particular API call is only implemented one way or the other.
okay, yeah that was probably what i was thinking more of. so i think it may be relevant to our discussion if you or someone else can give an indication of which API calls would be these "service-process threads" that OS X might distribute across more than one processor...
it's probably tricky question but i think rather than abstractly saying so and so app will be faster on dual-core, not so and so app.... it may be better if we non-OSX-coders could get a grasp on which libraries/APIs etc might be more likely to make good use of multicore or multiCPU...
i think that's the thing that is tripping up the more 'educated' Mac users, particularly going to Macintel -- performance right now seems to be very/too dependent on how an application is written for Mac Os X. We all know that a lot of major publishers predominantly write for Windows, so we can't always 'trust' that they have the resources/desire to do their best work for Mac Os X Universal Binary for Multicore/MultiCPU....
I notice a lot of debate over what recent setback in dev led to the decision to switch, but I don't think any recent problems at IBM were involved. The decision is an old one. Talk of poor roadmaps is a diversion. You have to look back and wonder what was going on then, when OSX was first being created.
Originally posted by tfernsle
Decision to go with Intel is an old one. SJ said the option was intentionally developed and maintained from the start of OSX. That takes a certain effort, and I don't think they would have made that effort if the intent to switch wasn't there.
I notice a lot of debate over what recent setback in dev led to the decision to switch, but I don't think any recent problems at IBM were involved. The decision is an old one. Talk of poor roadmaps is a diversion. You have to look back and wonder what was going on then, when OSX was first being created.
What is the real reason then? Contracts with Freescale and IBM? Negative perception of Mac OS X? Deal not closed yet with Intel? hmmm intriguing
Originally posted by tfernsle
Decision to go with Intel is an old one. SJ said the option was intentionally developed and maintained from the start of OSX. That takes a certain effort, and I don't think they would have made that effort if the intent to switch wasn't there.
Actually.. The first swith for OSX was _to_ PowerPC. NeXTStep had in its later years x86 as its primary platform. There wasn't an intent to switch back to x86, as much as there was a will to keep the original platform up to date and keep all doors open. Keeping them open was probably no big deal and I wouldn't be surprised if they also kept (are keeping?) the doors open for Sparc and PA-RISC too, sine NeXTStep also ran on those platforms.
Originally posted by tfernsle
Decision to go with Intel is an old one. SJ said the option was intentionally developed and maintained from the start of OSX. That takes a certain effort, and I don't think they would have made that effort if the intent to switch wasn't there.
The AIM alliance was founded in early 90's. Later during G4 development, IBM disagreed with Motorola "VMX" (Altivec) SIMD approach ; they preferred to go toward a higher-frequency design of G3 chip, which the G4 couldn't achieve. And in some way IBM was a little later proven to be so right, remembrer the one-year 500 MHz G4 debacle... So the divorce happened between IBM and Moto between 1998 and 1999, and they developed their own PowerPC projects separately.
In 1997, Apple was starting its new OS program with OpenSTEP-Rhapsody-Mac OS X. They could then clearly imagine that the PowerPC in a whole could never destroy Intel, whereas it was originally aimed to be the next computing era leader, replacing x86. The CHRP clones were even made to win a war they never began, because AIM alliance failed to grow. Even Microsoft, also committed to CHRP before, disengaged from it.