MOTUnation.com

With the rumors that Apple may be releasing dual core G5's at MacExpo Paris later this month, I have a question for the more techy of you out there.

If the dual core's are released will DP have to be rewritten to make use of the dual cores? Or is like a processor upgrade, where the program will just run faster?

PS. I don't want to get into a are the rumors true debate. Let's just say hypothetically the dual cores are released ....

Multi threaded apps are multi threaded regardless if it is two physical CPU's or virtual CPU's.

OSX is very good at using and disperssing threads among CPU's so the OS takes care of a lot of the work but on the other hand DP has been dual CPU aware and working from something like version 3.x in OS9

All the best,

Wayne

With the rumors that Apple may be releasing dual core G5's at MacExpo Paris later this month, I have a question for the more techy of you out there.

This is what I'm hoping for. With any luck we'll see dual dual-core 3ghz machines in the near future. That will be the computer I buy to get me through what will no doubt be a long hairy transition to Intel.


btw what would we call them? 2x2x3s? ...4x3s? quad 3s?

bigwayne56 wrote:
OSX is very good at using and disperssing threads among CPU's so the OS takes care of a lot of the work but on the other hand DP has been dual CPU aware and working from something like version 3.x in OS9

Maybe I misunderstood your post, but I'm not talking about dual processors, I'm talking about dual core processors, which is an entirely new technology.

That being said would DP take advantage of the dual core processors, or would the program need a rewrite?

Since the OSX release, the handling of multiple processors and the way tasks get distrubuted to them has been handled by the operating system itself, not the individual programs (which is unlike Dp in OS9). So...as long as the operating system can handle and knows what to do with dual core processors, the programs running in OSX should too.

Dual Core vs. Dual Processors:

The two technologies are similar, but with important differences. Dual processors share nothing but the bus (and all outside modules connected by that bus, like RAM). Dual Core processors share the same die (one socket in the motherboard), the same memory controller, but they each have their own pipelines and cache. Pipelines are where things are queued up for processing, and the cache is where bits of code (think of a carpenter's toolbelt full of hammers, screwdrivers, and nails) are kept handy. If these two processors have to go back out and get more stuff for the cache or pipelines, then they have to compete for the memory controller, the system bus, and the RAM, so they try to keep their caches as orderly as possible.

To further our carpenter analogy, let's say you're building a house. Dual processors would be like sending two companies out to work on the house. Each company is capable of doing its own thing--a roofer and a plumber, for instance. Dual core processors is a little like each company sending out two carpenters, complete with their own toolbelts. Chances are, they're going to be working on the same part of the project, but sharing the load. So, dual core, dual processors would be like having two carpenters from each of two companies. The work progresses much faster. But only if the contractor has laid out instructions for everyone. If he only said "build a kitchen sink and a roof" then some of your carpenters may be sitting around smoking cigarettes. But if he says "you two build the kitchen sink; Joe you get on one end, and Moe, you get on the other." Then he tells the other "processor" company's workers "Ted, you and Ned build a roof. Ted, get on one end, and Ned you build from the other." Hopefully they can make it meet in the middle, but the point is that with specific instructions they can make the work go a lot faster. They all still share the same supply truck (RAM) so that still has the potential to slow things down if the truck isn't run well.

Software that is not threaded for dual-core or dual processors utilizes only one processor, but if it outsources any of its work, then OSX may send that to the other processor. OSX is pretty smart about dividing things up, but to take advantage of dual-core technology, the software itself needs to be smart. If you don't want one of your workers sitting around on break, then at least you've got to recompile your software so that it has built-in instructions for what to do when one processor suddenly has time on its hands. Because this is happening in the space of one physical processor, OSX may not be able to help out with that. It can convey the messages, but it can't intervene and say, "whoa... take that instruction and send it over to the other core on that board."

So which software will be ready for that? Any that recompiles with the compilers that Apple provides developers. Otherwise, they won't be as efficient as they could be. How can we know? Only if the developers tell us.

Here is a simplified explanation much like mine, but a lot longer.
A slightly more technical explanation, but mostly useful in the Win-Tel discussion.

I haven't found anything specifically about Apple's dual-core plans, other than they're planning on it. But I'm sure it's out there for those who seek.

Shooshie

That's the best reply to a question I've seen in a while Sooshie.

If I may add, I have read on the MAC blogs in the recent past that the dual cores are not expected to be ground-shaking in terms of speed advances. I remember reading that it may me a wash on the first machines even though CPU MF increases. We should look to things like throughput and cooling techniques to assess the real deal.

I currently have one of those 2' vertical fans sitting on the floor in front of my 2.5ghz mac. I run it on low just to force better cooling and it really keeps it kachunking nicely when room temps would cause throttling with big sessions. IMHO throttling is our biggest enemy and this fan was like buying a new machine for about 35 bucks.

Good luck

Yeah, great answer Shooshie,

I've also read of no great speed advance, but it's said that the dual core will have a 50-80% performce increase over a single core. So if they have the cooling worked out (and it dosen't sound like the MDD G4's) it should be a cool machine.

I'm mostly interested in the (minute?) chance of a dual dual core machine (4 cores)... Now *that* would make me buy a new Powermac before intel

Here's what Rumors wrote abut it:
"The PowerMac G5 will soon be updated with dual-core IBM PowerPC 970MP processors at up to 2.8 or possibly even 3.0GHz. Despite recent optimism regarding the 3GHz "barrier," we are taking a conservative stance and predicting a 2.8GHz high-end system as the most likely outcome.



However, that leap from 2.7 to 2.8GHz in the high-end is larger than mere clock rates might suggest. Dual-core technology is significantly more efficient than two separate CPUs, allowing data and bus bandwidth to be shared directly between the two cores. It also, most importantly, paves the way for quad-processor G5's! In addition, dual-core tech is far from the only improvement due in the new PowerMacs; faster memory, PCI Express graphics support (still unclear whether or not SLI twin-GPU support will be enabled or not) and a long list of minor feature additions are also in the offing.

Notably, sources report that Apple will bundle a Mighty Mouse with all new PMG5's.

We are currently conferring with our most reliable contacts at Apple and hope to have a detailed specification list for all three new PowerMac models sometime this week; meanwhile, continue on to the next page for more dirt on Powerbooks, video iPods, and more...

blackcrayon wrote:I'm mostly interested in the (minute?) chance of a dual dual core machine (4 cores)... Now *that* would make me buy a new Powermac before intel

Yes, that's what we're talking about: dual dual-core Powermacs. ...and maybe single dual-core's in January for Powerbooks.

One thing for sure: in a few years, when we all have dual-core, dual Intel processor Macintoshes, those are going to be some smokin' machines for VI applications. At that point, we're going to have to have the whole Native vs. Pro-Tools debate once more. And assuming we're stable and well supplied with software (meaning, MOTU is still in business), and assuming Apple doesn't screw up the bus architecture, guess who I think will come out on top of that one!

Shooshie

Hey; from your lips...

Some ramblings:

1. Not all Mac Intel P4 machines will be dual core on arrival. The mix of machines is anyone's guess at best. The single cores will likely target low-end portables and desktops. Probably a good Apple strategy aimed at Wintel fence-sitters looking for price-performance breaks.

2. Code Portability: Could be a trip for developers without adequate unix training or code portability discipline -- who take for granted that their PowerPC code will run accross platforms without consideration for architectural issues like machine byte order (so-called "little endian" versus "big endian").

3. Altivec-wired code -- like ones used by Altiverb and their ilk will require special hand coding..to a form of highly portable C so they can take advantage of Apple's new Accelerate Framework -- This is because Altivec code cannot readily be converted to Intel' s SMID (single instruction, multiple data) mathematical functions.

4. Also, not all of the Intel chips are 64-bit compliant -- yet another unknown performance issue. I doubt most Mac-centric developers are cognizant of all the specifics of Intel's EM64T 64-bit extensions. Apple boasted at the Developers Conference this year that Xcode 2.1 is ready for the task...will see...I recently downloaded Xcode 2.2 preview..sweet sweet lies..

5. Agree with the previous posts about multi-threading. Tiger supports Intel••™s Hyper-Threading hardware..so it should be able to support the transition from G4/5 to P4...to support intel's SMP (Symmetric Multi-Processing) -- be it dual or single core...

Looks like DP portability from PowerPC to P4 dual core is in good shape overall with a few caveats -- I am more worried about the third party software vendors that code to machine or architectural specifics...

Kris..