Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Low Power G5 Coming Soon?
- Thread starter MacRumors
- Start date
- Sort by reaction score
jouster said:
No, let him do it. It saves me the effort of pulling out my "64-bit myth" soapbox!
thatwendigo said:
OK 1st question "There is no inherent performance increase from 64-bit processors, unless you are doing one of a tiny handful of very specialized tasks"
--->please explain to us little people why the computer & database industry years ago went onto 64-bit chips? I doubt it was for more memory alone; I believe that ALL data base apps (from SAP, Oracle, PeopleSoft, M$, MySQL) benefit immensely when hosting databases and serving up dynamic intranets/internets for thousands or millions of hits during a day or even hundreds of requests simultaneously. Am I wrong on this??
2nd question, what chip is the "8461D" that you mentioned above?? I have no idea what that is. Is it Freescales future solution or the PPC unions solution via IBM? Or is it even a cpu for Apple at all??
Eliminating the Northbridge to memory card controller being external sounds promising.
I side question >> I've tried to research on ArsTechnica.com whether or not the Opteron64bit/Athlon64 cpu's if they TRUELY are 64 bits or just EMULATE 64-bit processing via code extensions.???
thanks for the knowledge and insight but a good thread or even clarity in lamens terms with real-world examples of applications current & setups in use would be helpful for us , well you know cpu hoodlums.
cheers.
PS: carbon-based Powerbook (sweeet rumor there, bring us back to the sweet design of the Pismo)
OK 1st question "There is no inherent performance increase from 64-bit processors, unless you are doing one of a tiny handful of very specialized tasks"
--->please explain to us little people why the computer & database industry years ago went onto 64-bit chips? I doubt it was for more memory alone; I believe that ALL data base apps (from SAP, Oracle, PeopleSoft, M$, MySQL) benefit immensely when hosting databases and serving up dynamic intranets/internets for thousands or millions of hits during a day or even hundreds of requests simultaneously. Am I wrong on this??
You answered it yourself ... they went 64 because thousands of millions of hits require 64! how many keyboard hits do you expect on a day on your PC or mac?
2nd question, what chip is the "8461D" that you mentioned above?? I have no idea what that is. Is it Freescales future solution or the PPC unions solution via IBM? Or is it even a cpu for Apple at all??
It is a dual core G4 with freescale is developing. Frescale and IBM have nothing to do with one another. IBM developed G5 on their way to POWER5 which is will be their main server processor (now power4). Freescale and IBM make chips for a lot of stuff! take gamecube/ps2, embedded systems etc. Apple used few solutions modified. but a Dual core G4 is primarily for apple or power hungry hdware like gamestations that use PPC. G4 is one of the most widely used embedded processor.
I side question >> I've tried to research on ArsTechnica.com whether or not the Opteron64bit/Athlon64 cpu's if they TRUELY are 64 bits or just EMULATE 64-bit processing via code extensions.???
I think (read as: i read some where!!) Opteron is a 64 bit processor which can emulate or transcode at a much native hardware level a 32 bit instruction!
--->please explain to us little people why the computer & database industry years ago went onto 64-bit chips? I doubt it was for more memory alone; I believe that ALL data base apps (from SAP, Oracle, PeopleSoft, M$, MySQL) benefit immensely when hosting databases and serving up dynamic intranets/internets for thousands or millions of hits during a day or even hundreds of requests simultaneously. Am I wrong on this??
You answered it yourself ... they went 64 because thousands of millions of hits require 64! how many keyboard hits do you expect on a day on your PC or mac?
2nd question, what chip is the "8461D" that you mentioned above?? I have no idea what that is. Is it Freescales future solution or the PPC unions solution via IBM? Or is it even a cpu for Apple at all??
It is a dual core G4 with freescale is developing. Frescale and IBM have nothing to do with one another. IBM developed G5 on their way to POWER5 which is will be their main server processor (now power4). Freescale and IBM make chips for a lot of stuff! take gamecube/ps2, embedded systems etc. Apple used few solutions modified. but a Dual core G4 is primarily for apple or power hungry hdware like gamestations that use PPC. G4 is one of the most widely used embedded processor.
I side question >> I've tried to research on ArsTechnica.com whether or not the Opteron64bit/Athlon64 cpu's if they TRUELY are 64 bits or just EMULATE 64-bit processing via code extensions.???
I think (read as: i read some where!!) Opteron is a 64 bit processor which can emulate or transcode at a much native hardware level a 32 bit instruction!
To further clarify from tomshardware.com
"Opteron is the first ever x86, 64-bit processor that can also run 32-bit programs."
MORE OVER
The advent of 64-bit computing only means that the transistors can manipulate binary numbers that are 64-bits wide, compared to 32-bits wide, or even 16-bits using IBM's PC and AT machines with Intel's 8088 processors that were sold in the 1980s.
Using binary notation, transistors create binary information depending on whether a transistor receives electrical current or not. A `1' designates that the transistor has received current, a `0' means that it has not. In binary notation, a 10 represents a 2, 100 represents a 4, 1010 represents a 10, and so on. Devices based on 16-bit processing, thus, involve binary numbers with 16 places, compared with 64 places for 64-bit devices.
64-bit computing, in fact, has been pervasive in the server community for years, such as with RISC processors by Sun. It has just taken that long for the x86 environment community to agree that the timing was right. The technology largely involves no more than adding more transistors to accommodate the additional bits -- a 64-bit processor represents over 2,000 additional registers and 25,000 additional transistors.
"Opteron is the first ever x86, 64-bit processor that can also run 32-bit programs."
MORE OVER
The advent of 64-bit computing only means that the transistors can manipulate binary numbers that are 64-bits wide, compared to 32-bits wide, or even 16-bits using IBM's PC and AT machines with Intel's 8088 processors that were sold in the 1980s.
Using binary notation, transistors create binary information depending on whether a transistor receives electrical current or not. A `1' designates that the transistor has received current, a `0' means that it has not. In binary notation, a 10 represents a 2, 100 represents a 4, 1010 represents a 10, and so on. Devices based on 16-bit processing, thus, involve binary numbers with 16 places, compared with 64 places for 64-bit devices.
64-bit computing, in fact, has been pervasive in the server community for years, such as with RISC processors by Sun. It has just taken that long for the x86 environment community to agree that the timing was right. The technology largely involves no more than adding more transistors to accommodate the additional bits -- a 64-bit processor represents over 2,000 additional registers and 25,000 additional transistors.
Don't know if this has been discussed, but if its low power 3GHz - that mean they're going to get rid of the water cooling?
D
D
SiliconAddict said:
Actually, you are quite wrong. You see, before I got a Mac I was a diehard PC geek. Used to read all the hardware sites every day. Could rattle off the differences between Athlon, P3, P4, K6, etc. And I still follow them quite much as I make my living fixing them, building and reccomending systems, etc.
I know quite a lot about system architecture. Problem is, little of it matters for day to day operations of most people. The Quad-pumped 133-Mhz P4 bus benefits little when all you're doing is surfing the net, writing in Word, and listening to an MP3 in iTunes. Same with HyperThreading. These things help with memory and CPU intensive operations (Games, hardcore math operations, 3d modelling, etc.), but have little to no effect on day to day operations. I remember when the P4 came out with it's 400 Mhz (Quad 100 Mhz) bus, it was supposed to kill the Athlon on it's dual 100 Mhz bus (or was it dual 133).... It didn't even come close.
I've had many systems in my day, and all from the 500 Mhz P3 I had to the present 2Ghz P4 have seemed about the same on day to day tasks. Just load 'em up with RAM and a fast disk and I'm happy.
Where did I throw out specs? Just pointing out my observations with 5 different computers over the weekend. On a fairly standard operation using the exact same software across platforms. I'm sure my test would cook on a G5 or an AMD64 machine, but none were available to me.
The iMac/800 was never really a top of the line G4, and the iBook G3 was, well, a budget machine. I found it interesting that they kept pace with a P4 @ 2Ghz and even Intel's newest and latest Centrino. I was really expecting them to tank, especially given the lack of FSB speed on the G3/G4....
Again, on most real world tasks you'd be hard pressed to tell the difference. I know I can't - each feels about the same for me. Now, if you're doing 3d modelling or gaming, a laptop really isn't for you (on either platform)
If you're a sampling of the "adults", I'll stay in kindergarden. Or with the real adults, thank you.
jj2003 said:He he, let's do a CPU benchmark and not remove the biggest bottleneck, CD reader..
That would have been great, but it was interesting to see the results, nontheless. I was thinking that the Mac would not be much faster than the Duron (the Mac had a 100Mhz speed advantage, but a bus speed disadvantage (Duron is duble-pumped 100Mhz). The actual shocker was that the Duron was so slow - they were awesome CPU's in their day and I was ripping on a decent CD burner (16x10x40x) and CD-ROM (52x LG), neither of which made a difference.
The fact that both G3 and G4 Macs at 800 Mhz kept pace with a 2Ghz P4 was a huge shock to me, especially given the fact that both IBM laptops had relatively recent CD drives.
But a raw CPU test would be of little value to the general population, whose computer work is mainly I/O limited (hard drive, Internet, CD, etc.)...
facts straight, conclusions wrong
Your observations are correct, but your conclusion is wrong.
Databases are the big "killer app" for 64-bit because large databases benefit tremendously from keeping more than 4 GiB of the database cached in RAM.
It's for memory alone.
The 32-way IBM Power4+ system that did over a million transactions per minute on TPC-C had 1 TiB of RAM (http://www.tpc.org/tpcc/results/tpcc_result_detail.asp?id=104021701).
You don't even need 64-bit for big memory on a system - many 32-bit Xeon systems support more than 4 GiB, in fact up to 64 GiB on a single Intel 32-bit server. The problem is, however, that no single task can easily use more than 4 GiB.
32-bit systems can easily handle 64-bit integer arithmetic - they're just a little bit slower at it than a 64-bit CPU, since the compilers use pairs of 32-bit operations to synthesize 64-bit integer operations. Almost all of the time, this is good enough, since few programs *depend* on 64-bit integers in their main algorithms.
Prom1 said:
Your observations are correct, but your conclusion is wrong.
Databases are the big "killer app" for 64-bit because large databases benefit tremendously from keeping more than 4 GiB of the database cached in RAM.
It's for memory alone.
The 32-way IBM Power4+ system that did over a million transactions per minute on TPC-C had 1 TiB of RAM (http://www.tpc.org/tpcc/results/tpcc_result_detail.asp?id=104021701).
You don't even need 64-bit for big memory on a system - many 32-bit Xeon systems support more than 4 GiB, in fact up to 64 GiB on a single Intel 32-bit server. The problem is, however, that no single task can easily use more than 4 GiB.
32-bit systems can easily handle 64-bit integer arithmetic - they're just a little bit slower at it than a 64-bit CPU, since the compilers use pairs of 32-bit operations to synthesize 64-bit integer operations. Almost all of the time, this is good enough, since few programs *depend* on 64-bit integers in their main algorithms.
Acer revs new Ferrari 64-bit notebook
Quite a few of them already, even a new one that hit the news today:
Acer revs new Ferrari notebook (http://news.com.com/Acer+revs+new+Ferrari+notebook/2100-1044_3-5453161.html)
http://global.acer.com/products/notebook/fr3400.htm
Hmmm, and it's lighter than a 17" PB....
Unfortunately, since it tops out at 2 GiB of RAM the "64-bit myth" is what they're marketing!! (Although, unlike the PPC970, an Opteron or Nocoma is faster when compiled for 64-bit vs. 32-bit - so they are selling the speed of the 64-bit instruction set, even though they aren't using 64-bit memory.)
visualanté said:
Quite a few of them already, even a new one that hit the news today:
Acer revs new Ferrari notebook (http://news.com.com/Acer+revs+new+Ferrari+notebook/2100-1044_3-5453161.html)
http://global.acer.com/products/notebook/fr3400.htm
Hmmm, and it's lighter than a 17" PB....
Unfortunately, since it tops out at 2 GiB of RAM the "64-bit myth" is what they're marketing!! (Although, unlike the PPC970, an Opteron or Nocoma is faster when compiled for 64-bit vs. 32-bit - so they are selling the speed of the 64-bit instruction set, even though they aren't using 64-bit memory.)
I still think the 3 GHz chip and the low power chip are 2 different chips (the low power being 1.6-1.8 GHz for PowerBooks). With the extra L2 cache, the 3 GHz 970 GX will probably still put out as much heat as the 2.5 GHz 970 FX.Mr. Anderson said:
AidenShaw said:
And here's a bit more detail on that. Your base x86 CPU (going back to the days of the 8086 and 8088) is a 16 bit CISC (complex instruction set computing) CPU. In comparison, the Motorola 68000 is a RISC CPU (I think it's 16 bit, but I could be wrong; my memory on that CPU's a bit hazy.) Modern day CPUs combine the "best" features of both CISC and RISC, but it's safe to call x86 a CISC descendant, and PowerPC a RISC descendant.
For various reasons (handwave, handwave), RISC CPUs had a lot more registers than CISC CPUs. x86 has four general data registers, four segment registers, and four addressing registers -- all 16 bits in size. The four general data registers could be split into eight 8 bit registers if you were so inclined. The move to the 386 introduced two more segment registers, and extended the twelve original registers to thirty two bits; since then, it's remained pretty much unchanged. Net result: your typical compiler has four registers it can rely on; maybe up to eleven if it's really careful about the way it does things, but that's really pushing things, and I doubt that gcc (for example) would play around like that.
In comparison, PowerPC has thirty-two general purpose registers, not counting a bunch of registers that are only accessible in supervisor (roughly equal to kernel) mode. More handwaving ensues (I haven't looked at IBM's PDF in depth.
)Now, a brief digression. There are a bunch of places from whence data can be sourced. In order, from slowest to fastest, you have your hard drive (or floppy, or CD-ROM); main memory; level three cache (if present); level two cache; and level one cache. If a CPU needs data, it will load it from one of those sources, and into a spare register. If it doesn't have a spare register, it will push a register's data out to level one cache (and from there to main memory) to free it up. (Well, the compiler will; again, handwaving ensues.) In other words: if you need data, and it's already in the register, you save a lot of time, because you don't need to pull it from cache, or, heaven forbid, main (SLOW! at least relative to the CPU) memory.
So let's suppose you have a function that does something. In the course of doing this something, it needs to manipulate some dozen pieces of data. On x86, it'll be constantly swapping data in and out of memory so it can play around with the registers -- kinda like if you're trying to correlate several documents, but only have room for two on your desk at once. On PowerPC, on the other hand, it can load the bits of data into the general purpose registers once, play around with them to its heart's content, and flush the end result out to memory at the end. Net result: you lose a bunch of memory accesses, and everything's a lot faster.
How does this tie in with x86-64? Well, AMD took the basic registers -- all fourteen of them -- and extended them to 64 bit. They also introduced another eight compiler-accessible registers. All of a sudden, provided you target the opcodes that provide those registers, you've got a lot less data shuffling going on, and you don't need so many memory accesses. (Compiler-accessible refers to the fact that what the compiler can see and manipulate is a very different beast to what's actually on the CPU. Again, more handwaving.)
So. If you compile x86 code, you can compile it in 32 bit mode (presumably to be compatible with the P3, P4, etc.), and have four data registers; or you can compile in a mode that's only compatible with the 64 bit CPUs, and have twelve. (I don't know if the 32 bit mode has been extended to include the new registers, or not. I'm guessing not, but I won't swear to it. IMO, it should have been, but I wasn't involved in the design.
) Therein lies the reason (or a very large part of it) for the speed boost when you compile code for x86-64 over x86-32: the extra registers. Yes, you lose out on the amount of data you're shuffling around -- 64 bits vs 32 bits, you've got a lot more data coming over the memory bus -- but you gain because you cut the amount of data shuffling you need to get the work done. The latter outweighs the former in the vast majority of cases.
WoW, this is good news all this means is that maybe just maybe the PM will not need a liquid cooled CPU at 2.5 GHz ---> onwards since it consumes less power and delivers the same performance. This is also good news for the iMac G5 since it soon advance to in the REV B version to:
G5 1.8GHz 20 inch
G5 2.0GHz 20 inch
G5 2.0GHz 23 inch
Why do I believe the iMac G5 will have a 23 inch lcd screen since with the iMac G4 there was *added* dead weight to the base and with this new design they can accommodate a 23 inch lcd at no added dead weight.
Since the 17 inch has been dropped from the Pro Cinema Display line and the iMac is considered as a Prosumer PPC with the eMac as the Consumer PPC Mac.
I am still very happy with my iMac G5 1.8 Ghz
Still wondering when will they release a 2Gig PC3200 DIMM unbuffered for the iMac G5 since Samsung already has developed it and would really benefit "Tiger OS" 64-bit to a minimal amount <-- maybe, maybe not.
-----------
Even though the iMac G5 1.8 Ghz runs at 2/3 the processor speed it is quite fast load it with ram since the SATA drive is great as well.
G5 1.8GHz 20 inch
G5 2.0GHz 20 inch
G5 2.0GHz 23 inch
Why do I believe the iMac G5 will have a 23 inch lcd screen since with the iMac G4 there was *added* dead weight to the base and with this new design they can accommodate a 23 inch lcd at no added dead weight.
Since the 17 inch has been dropped from the Pro Cinema Display line and the iMac is considered as a Prosumer PPC with the eMac as the Consumer PPC Mac.
I am still very happy with my iMac G5 1.8 Ghz
Still wondering when will they release a 2Gig PC3200 DIMM unbuffered for the iMac G5 since Samsung already has developed it and would really benefit "Tiger OS" 64-bit to a minimal amount <-- maybe, maybe not.
-----------
Even though the iMac G5 1.8 Ghz runs at 2/3 the processor speed it is quite fast load it with ram since the SATA drive is great as well.
Little Endian said:
I could not agree more. You summarized it very well. Apple is making a ton of money on everything but PowerMacs. There is no need for an update for another 10 months. That is how long it might take IBM to jump to a 2.8. Powerbooks have been selling well without upgrades as well. The dual core rumors might become reality giving the PowerBook another full year before we see a G5.
Don't get too excited folks.
4GB in a PB G5?
If Apple decides to release a new G5 PB in January (IF) would they possibly support 4GB of DDR2 and also have PCI Express graphics. It would seem to be a logical step as while they have rejig the architecture they may as well intergrate the latest and greatest. The reason for this is i don't see Apple releasing a Rev(B) G5 PB with such a substatial change or Rev(C) for that matter. I don't know, but it would seem that the first G5 PB whether we see it in Jan '05 or June '05 is going to have to incorporate such technologies.
(Just a thought from downunder)
If Apple decides to release a new G5 PB in January (IF) would they possibly support 4GB of DDR2 and also have PCI Express graphics. It would seem to be a logical step as while they have rejig the architecture they may as well intergrate the latest and greatest. The reason for this is i don't see Apple releasing a Rev(B) G5 PB with such a substatial change or Rev(C) for that matter. I don't know, but it would seem that the first G5 PB whether we see it in Jan '05 or June '05 is going to have to incorporate such technologies.
(Just a thought from downunder)
What about support for the 30" Display in a PB?
Does anyone believe we will see graphics support for a 30" Display in the next PB whether they be G4 or G5's. Does anyone know of portable DDL card? I know Alienware have a 256mb 6800 in one of their laptops but i don't think that it is DDL compliant. Or will apple leave the 30" Displays to the high high end desktop users?
Does anyone believe we will see graphics support for a 30" Display in the next PB whether they be G4 or G5's. Does anyone know of portable DDL card? I know Alienware have a 256mb 6800 in one of their laptops but i don't think that it is DDL compliant. Or will apple leave the 30" Displays to the high high end desktop users?
macuser05 said:
Sorry to say, but your test is meaningless because you were ripping from different CD/DVD drives. Your test is not only about the CPU power.
What you should do is test the same machines again, directly from an already-dumped WAV/AIFF file. Even then it wouldn't really be a good test because iTunes on Windows could be running on some kind of emulated platform (is it *really* a native Windows application? I find the page scrolling in iTMS incredibly slow)
Of course, it would be a good iTunes test, just remove the CD ripping part of the test.
the card needed for the 30" is way thicker than the powerbook itself... theres no way. 256mb chip isnt enough.. they are special cards.JRM said:Does anyone believe we will see graphics support for a 30" Display in the next PB whether they be G4 or G5's. Does anyone know of portable DDL card? I know Alienware have a 256mb 6800 in one of their laptops but i don't think that it is DDL compliant. Or will apple leave the 30" Displays to the high high end desktop users?
Rincewind42 said:
The problem is ultimately latency. If you take the total bandwidth available and divide it by the number of cache fills possible per second given the latency constraints, you would have to fetch atypically large memory chunks to actually come anywhere close to actually using the bandwidth available. By "atypical" I mean substantially larger than what your average C/C++ program will require when it needs to fill a cache line in practice (I vaguely remember calculating it being on the order of 1-kB for the G5 to use all the bandwidth), and there are other restrictions in the cache that make this a non-starter. The much higher number of cache fills possible on the Opteron architecture in a given second means that it can fetch larger quantities of smaller objects, which in real-world code means that it actually is able to use more of its memory bandwidth -- the PPC memory objects are about the same size as Opteron objects for the same software, but the Opteron can fetch a lot more per second. Looking at my own C/C++ codes, most memory references are 40-200 bytes in size, which puts it just a bit under the edge of the sweet spot for the Opteron and an integer factor off for PPC970.
The bus speed is only loosely related to latency. IMO, latencies need to get down into the 50ns range before we'll really be able to use the bandwidth we already have. The Opterons get close, which is why their memory bandwidth is reasonably close to theoretical in practice. Giving the the PPC970 more bandwidth without improving the latency performance won't help much because all that will allow us to do is fetch the same number of even bigger objects per second, which most codes really can't use as it is. My supercomputing codes are actually bound by memory latency performance (as are most actually), and while we use the PPC for workstations, it really falls on its face performance-wise next to Opterons (which do the heavy lifting) on these codes. It takes as long for a PPC970 to access its local memory as it takes for an Opteron to fetch remote memory across the NUMA fabric. That's gotta hurt when you are trying to keep the pipelines full. Of course, if your codes are mostly CPU bound (e.g. LINPACK), memory performance matters a lot less.
I've stated before and still maintain that IBM has not put a high-end memory system into the PPC970 to differentiate it from their Power line, which looks a lot more like the Opteron system architecture.
ObTrivia: GCC 2.9x gives the best memory performance on the G5 in most benchmarks. Substantially better than both IBM XLC and GCC 3.x (which is the worst by a fair margin).
