GPUL 64bits GigaProcessor for Mac (FOR SURE)

MacFreak

Chic Not Geek
Apple Computer is looking toward a 64-bit future for the Mac -- courtesy of PowerPC partner IBM.
http://www.eweek.com/article2/0,3959,543317,00.asp

According to sources, IBM Microelectronics, a division of IBM, is working with Apple on a 64-bit PowerPC processor for use in the latter's high-end desktops and servers.

Sources said Apple is testing the CPU, dubbed the GigaProcessor Ultralite (GPUL) on Mac OS X-based hardware at its Cupertino, Calif., headquarters, and making sure that the processor complies with a new bus architecture on tap for future Macs.

In addition, IBM plans to offer the processor as the centerpiece of future Linux-based systems, the sources said. As reported this week by eWEEK, IBM recently announced that it would soon introduce new versions of its high-end p690 and p670 servers designed to run Linux native, in place of IBM's own AIX operating system.

Some GPUL details are expected to be disclosed at Microprocessor Forum in San Jose, Calif., in mid-October. IBM will hold a session at the conference on Oct. 15 entitled "Breaking Through Compute Intensive Barriers -- IBM's New 64-bit PowerPC Microprocessor."

Peter Glaskowsky, editor in chief of forum sponsor Microprocessor Report, said that while he doubted GPUL's role in the Mac's future will be on the public agenda, "We expect this chip to form the basis of Apple's 64-bit future strategy."

Some observers say GPUL—which shares technology with IBM's server-focused Power4 chip—will double Mac performance. However, they caution that the chip probably won't reach Apple's consumer systems for more than a year at the earliest.

While the bulky, power-hungry Power4 is designed for servers, GPUL is reportedly cooler and more compact; sources said it compares in size to Intel's Celeron.

However, sources said, GPUL will inherit many Power4 performance advantages, such as being able to perform more instructions per clock cycle than current PowerPC chips. It is likely to also use the 0.13- (later 0.10-) µm lithography copper and silicon-on-insulator (SOI) technology seen in the Power4, making for smaller and thinner chips.

In addition, GPUL will be a multi-core chip, with two or four processors in one package. Having the processors closer together and sharing the same cache will make for faster multiprocessing environments, sources said. However, sources did not say if applications would need to be rewritten to be optimized for multi-core processors.

Sources said that benchmarks and applications tests demonstrate that a 1GHz GPUL processor doubles the performance of the 1GHz Motorola PowerPC G4 processor in current Macs. Even so, they said, the first run on GPUL processors should range from 1.4 to 2GHz, depending on yield.

GPUL will also support Vector/SIMD Multimedia Extensions (VMX), a group of 162 instructions that speed data processing and algorithmic-intensive tasks, such as multimedia creation and display.

Sources note that internal documents and publicly released information make no explicit mention of Motorola's Altivec multimedia extensions currently used in the PowerPC G4 and marketed under the name Velocity Engine by Apple. However, they said that VMX and Altivec are highly compatible, if not identical

ADVERTISEMENT

While GPUL is also designed to support eight-processor systems running the AIX OS, sources said Apple is focusing on testing the chip on dual-processor, Mac OS X-based systems. Apple and IBM are also tailoring the chip for a new high-frequency, point-to-point Mac bus dubbed ApplePI, short for Apple Processor Interconnect. According to sources, the companies describe ApplePI as "a replacement for the MaxBus used on current Apple systems. ApplePI is used to connect high-performance PowerPC processors to memory and high-speed I/O devices."

GPUL will also apparently play a role in IBM's desktop-Linux efforts. The Mac-focused Architosh site recently reported that Linux developer Red Hat, for one, may be working with IBM on a 64-bit, Altivec-compatible distribution. eWEEK's sources confirmed that GPUL is intended for Linux systems as well as the Mac.

Perhaps the most disappointing news for Mac fans, sources said, is that IBM does not expect to be finished with GPUL project until late summer 2003. Apple's recent confirmation that new Macs released after January 2003 will boot in Mac OS X only had sparked speculation that the company was planning to unveil 64-bit Mac systems at Macworld Expo/San Francisco that month.

Like AMD's 64-bit Clawhammer (the release of which was recently delayed), GPUL processor is backward-compatible with 32-bit OSes and applications. One source said 32-bit Mac applications could run on GPUL with "a very small performance difference," although recompiled programs, as well as a recompiled OS, would be able to take advantage of new addressing modes as well as other 64-bit features.

Sources said this transition should be less complicated than Apple's early-'90s move from 68000-series Motorola processors to the PowerPC family founded by Apple, IBM and Motorola.

Development of a new processor line has become increasingly urgent for Apple. Even as its desktop offerings, powered by Motorola PowerPC G4 chips, have stalled near the 1GHz mark, Windows-based PCs sport CPUs from Intel and AMD that approach 3GHz.

Although many metrics minimize the link between simple clock speeds and real-world performance between radically different CPU architectures and OSes, the slow advance of Motorola's chips has apparently depressed Apple's Mac sales.

However, sources said, Motorola probably will continue to play a role in Mac hardware. One observer familiar with Apple's processor strategy said that even if Apple wanted to abandon Motorola chips, it wouldn't happen in less than three or four years -- at least when it comes to laptop-friendly chips such as the PowerPC G4 and the IBM-developed PowerPC G3, which still powers Apple's consumer-level iBook notebook.

Meanwhile, sources said, Motorola's long-awaited PowerPC G5 CPU from Motorola is likely to break cover perhaps as soon as early 2003. The G5, according to published product road maps from Motorola, should be available as 32- and 64-bit products with backward compatibility, though Motorola has provided few additional details.

Official at Apple and IBM declined to comment.
 
If you read the last phrase, you know that it's pure speculation.

I wonder whether IBM will ever use the term GPUL. Even internally.

I'm all for the Son of Power4 processor in our Macs, but like everyone else (and eWeek) we just don't know whether it will really be better than Motorola's alternatives at the time when SoP4 actually hits the market.

Always remember what Steve Jobs said about leaving the G4: "[After the transition to Mac OS X is complete (January 2003)] Then we'll have options. And we like to have options."

A transition to 64bit is something that eventually *will* happen to the Mac platform, but the last thing *I* would want would be all-new 64bit PowerMacs with an operating system (and all of its applications) running in some 32bit compatibility mode. Sure, the processor would get great benchmarks, and I'm also sure that compiling a kernel would be really, really fast on that beast - once GCC is adapted to it. But we're really living in transitions on the Mac platform. And somehow I hate it.

1993 - You could buy the first generation of PowerMacs. They were really great. But actually slower than the Quadras (68040 processors), because most of the operating system was emulated in the PowerPC's 68020-emulator.

1994 - We were waiting for a project called Copland. This would bring us a PowerPC native operating system. We also got new PowerMacs. They still didn't match a Quadra 840av, because of a lack of PowerPC native software. The operating system, for example, had a SCSI driver (and all PowerMacs had SCSI, no IDE) that ran emulated.

1995-1997 - While we were waiting for Copland, which more and more seemed like vapour-ware, we got smaller and bigger system updates that slowly improved the PPC vs. 68K code ratio. Four years of transition - and still the operating system wasn't PowerPC native.

1997-1998 - Apple buy NeXT. Or the other way round. Whatever. A new 'plan' comes up, Copland is killed. (Clones are killed, too, so is the Newton.) The 'Rhapsody' plan sounds great. Also, Steve is back. Oh, the iMac is new also.

1998-2003 - We're in a transition. We now have a PowerPC native operating system. It's not the answer to the 1993 question of when we'll have a PowerPC native OS, because now the Classic OS actually feels faster and is almost 99% PowerPC native, too.

2003-2008 - Transition to 64bit? No, thanks.
 
Being on a 64bit processor won't help the speed of kernel compiles, on the virtue of being 64bit alone. The GPUL (too close to GPL for my taste), is said to be quite a bit faster than what we have now even at the same clock speeds; so even with most applications being run in the processors 32bit compatablity mode, they should perform better.

As for the OS, one would hope that Apple has been good about keeping as much of the OS 64bit clean as they can. Carbon might be a sticking point, but again I would hope that they thought ahead enough to keep the carbon librarys 64bit clean. If these assumptions are true, it should be a simple matter of a OS update to make the OS take full advantage of the GPUL, the applications would have to be recompiled as well, but that would be up to their developers, and while waiting for an update, most (if not all) current applications should just keep on chugging.

I see this being a much more painless transition than our previous ones. The 68k->PPC transition was relativly painless, and in this case it would be basically a 32bit PPC -> 64bit PPC transition, which should be almost pain free one would think. This assumes quite a bit about how good a job Apple has done in designing OS X, and everything at this point is speculation, so I wouldn't put money on it yet, but I would say this proc gives us (and Apple) a very nice road out of the pit Motorola has gotten us into.
 
How can you call the 68K>PPC transition painless? Read my post again... It was as painless (more or less) as 9>X and took years until we actually saw the performance we were promised. (Not that Apple could avoid it, the 68K line of processors had really hit the roof of its development.)

I've written an editorial about the Son of Power4 at http://macnews.net.tc for your reading pleasure.
 
Originally posted by LordOphidian

I see this being a much more painless transition than our previous ones. The 68k->PPC transition was relativly painless, and in this case it would be basically a 32bit PPC -> 64bit PPC transition, which should be almost pain free one would think. This assumes quite a bit about how good a job Apple has done in designing OS X, and everything at this point is speculation, so I wouldn't put money on it yet, but I would say this proc gives us (and Apple) a very nice road out of the pit Motorola has gotten us into.

Yes they will perform better. And the 32-bit versions of the applications will be transparent as IBM has previously indicated with SUSE Linux compiled for the 64-bit PowerPC. All 32-bit apps run normally in the 64-bit SUSE PPCLinux version as noted in their Linux site.
 
Originally posted by fryke
How can you call the 68K>PPC transition painless? Read my post again... It was as painless (more or less) as 9>X and took years until we actually saw the performance we were promised. (Not that Apple could avoid it, the 68K line of processors had really hit the roof of its development.)

I've written an editorial about the Son of Power4 at http://macnews.net.tc for your reading pleasure.

It was painless in the way that apps didn't break, they didn't get noticably slower (for me atleast, but my first PPC was the 7200/75) and except for all my new shareware apps having "FAT" in the name, it didn't cause me any pain. I know it caused problems for developers and some applications didn't like the emulation all that well, but in my experiance, and the experiance of others that I know, it was a very smooth transition, especially considering the whole arch was changing.

And needless to say this transition (assuming it happens) will be even more painless, infact it should be transparent.
 
Originally posted by MacFreak
GPUL will also support Vector/SIMD Multimedia Extensions (VMX), a group of 162 instructions that speed data processing and algorithmic-intensive tasks, such as multimedia creation and display.

Sources note that internal documents and publicly released information make no explicit mention of Motorola's Altivec multimedia extensions currently used in the PowerPC G4 and marketed under the name Velocity Engine by Apple. However, they said that VMX and Altivec are highly compatible, if not identical

FYI, for Apple/IBM/Motorola, the original, internal codename for AltiVec was VMX.
 
Oh, however 'painless' you call the transition from 68K to PowerPC, we had to wait about 5 years for a native operating system. All I'm saying is that we've been constantly 'in a transition' with Apple always promising that things would get better in the future instead of delivering in the present. At least where those transitions are concerned. (I'm not saying they did nothing right, of course they did, I'm still a big Mac fan and user since 1987!).

Sahara G3 (PowerPC 750FX) has a VMX SIMD engine. Does it work in Mac OS X? No, it's not supported.

Else the iBook would be too fast for the PowerBooks. :)
 
Originally posted by mattmoss


FYI, for Apple/IBM/Motorola, the original, internal codename for AltiVec was VMX.

Programmatically, if you recompile the SUSE LinuxPPC kernel for the PowerPC64 you can set the flag for AltiVec and 64-bits. The Altivec flag comes up with an error if your CPU is a Power4. All the 32-bit Linux apps run just fine even if the Power4 is used (must be binary compatible :D ). BTW, if you try to set the flag for Altivec on a 750FX it also comes up with an error.
 
Well, the thing about the PPC arch is that it was DESIGNED to be able to take on 64-bit additions without compromising 32-bit apps. Not only this, but a jump from 32-bit to 64-bit means NOTHING when dealing with speed boosts. Sure you get better precision with certain apps, and a humungoid integer value limit, but no actual performance boost by itself.

VMX was a shell for PPC SIMD instruction design. Two VMX-compliant SIMD units (Altivec being one) may not actually be binary compatible.

Actually this 'speed drop' people keep thinking of when jumping to 64 bit WON'T HAPPEN. A 64-bit PPC chip would still contain the complete instruction set for 32-bit, 16-bit and 8-bit (like it does now), in a binary compatible manner. The instructions aren't emulated, but just executed. Hell, the PPC already sits on a 64-bit bus, so it isn't like an 8 bit, 16, 32, or 64 bit load will take any different amount of time to complete from each other.

People need to get out of the mindset of "completely different arch" and start seeing that this is an addition to the arch, not a replacement of it. This addition had room made for it YEARS ago without many consumers ever noticing it.

Another thing is... the PC world is always in transition as well. How can Apple keep up if they aren't? Sure they can switch chips over to an IBM PPC, but it won't mean you will notice this state of transition ;)
 
If you don't want to be in transition, you need to get out of the computer industry. Also, the 680x0 to PPC transition was incredibly smooth all things considered. And pretty darned smooth with none of those things considered. Apple has mastered the transition.

The big reason that 680x0 instructions were so slow on the PPC is that there was no 680x0 emulator in hardware. Ever. It was all software and ROM. Truly incredible. If you want to see code break with each new OS iteration, look back to the BeOS. They were good people doing good stuff, but they were doing a lot to their OS that broke apps.

This is a completion of transition, not a new transition. The PPC was the child of 64 bit computing, and there has been a 64 bit PPC chip running at each generation. 32-64 bit compatibility is already done, and will likely remain important for notebooks. The biggest losers in 64 bit computing are the ones who care about the electricity lost when processing twice as much data to accomplish the same amount of work. Expect laptops to stay 32 bit for a while.

I think this GPUL will probably be the way to go. Apple has done all of this work to remain abstracted from the HW, this will be the opportunity to cash in. It all makes sense to me. All the same, don't get excited about timelines that don't exist.
 
Back
Top