IBM to Release 64-Bit, 1.8GHz Processor in 2003

Professor_Quail writes "A Forbes article supposed to be released tomorrow gives some details about the new PowerPC processor that IBM and Apple have been working together on; the chip is slated to be introduced at the end of next year. The introduction of this chip should put to rest any speculation that Apple is moving to an Intel platform."

Comments

No Certainties..

[Choco-man]

All it really says is that they plan to go into production of the 64 bit chips toward the second half of next year. "Industry" experts say that it would be used in the Mac. This is certainly a far cry from Jobs saying it - if anything, I think it makes the race between the two competing chip manufacturers all the more interesting. Apple, I should think, will select the company which will allow it to compete most effectively in the marketplace - not the first one who says in a press release that they plan to release bigger, faster, more powerful chips sometime next year..

Re:No Certainties..

[infornogr]

I will strangle anyone who says "4) ???, 5) Profit."

Re:No Certainties..

[Murdock037]

Apple, I should think, will select the company which will allow it to compete most effectively in the marketplace.

Which marketplace did you mean? It seems to me that the only marketplace of which Apple is a part is the Apple marketplace.

You're right, there aren't really any certainties until it comes out of Steve Jobs' mouth-- and even then, take it with a grain of salt. But he does get excited about shiny new things, and this sounds like it would be up his alley. Unless Motorola's keeping some secrets, I wouldn't be surprised if this is what's coming next.

Re:No Certainties..

[Daniel Dvorkin]

Which marketplace did you mean? It seems to me that the only marketplace of which Apple is a part is the Apple marketplace.

GMAFB. Apple is part of the PC marketplace; its products compete directly against those of Dell, HPaq, Gateway, er, IBM ... etc.

Re:No Certainties..

[ZigMonty]

Exactly! To the media we're probably considered industry experts and they will probably believe whatever rumor we tell them.

Re:No Certainties..

[shaper]

Which marketplace did you mean? It seems to me that the only marketplace of which Apple is a part is the Apple marketplace.

Hmmm, Gateway seems to disagree.

Re:No Certainties..

[GMontag451]

You want to try to emulate PPC on x86?! Good luck. PPC has tons more general purpose registers than x86 does. There is a reason why the only Macintosh emulators for x86 only do 68K emulation.

Re:No Certainties..

[Performer Guy]

Apple made that mistake in the past. They've learned their lesson. They know they need to keep pace with i86 processor developments.

Re:No Certainties..

[GMontag451]

The 68K family has 16 semi-general purpose registers while the x86 has half that, and there have been 68k emulators for x86 for a long time. In fact, the number of registers to be emulated is not that important when you can't map to the registers of the host machine because there are not enougth.

68K architecture may have 16 registers, but they are 16-bit, while x86 are 32-bit. On top of that, you can get away with only mapping 7 or 8 (D0, D1, D2, A0, A1, A5, A6, A7), because the rest aren't often used. In PPC assembly, use most or all 32 registers at the same time is quite common, because with a RISC instruction set, you *have* to do everything in registers.

The number of registers is *very* important, because each significantly used register that you can't map is one that will have to be fetched from cache or from main memory very often. That adds up to a very significant performance drop.

But in any case going from 16 to 32 registers doesn't add any complexity.

Of course it doesn't add complexity. Writing an emulator is in fact quite simple. I could write a PPC emulator in Perl and have it run anywhere Perl does. That doesn't mean it will be fast. In fact, it will probably be so slow that it would literally take a month just to boot up MacOS.

I guess the complexity lies in the instruction set and the MMU.

The PPC memory manager may be somewhat trickier to implement than the 68K memory manager but not that much, and in many ways the PPC instruction set should be easier to implement than the 68K one. It has much fewer addressing modes and only one way to load to and store from memory.

Re:No Certainties..

[Shanep]

I strongly get the impression IBM has some other ideas in mind for these chips other than simply being a supplier for Apple.

Interesting. Perhaps they are going to release a 64-bit IBM workstation with their own custom Linux to go head to head with 64-bit offerings from Sun and HP.

I rather like the thought of putting them in Apples, though. : )

Re:No Certainties..

[Caktus]

68K architecture may have 16 registers, but they are 16-bit

68K registers have always been 32 bits wide.

On top of that, you can get away with only mapping 7 or 8 (D0, D1, D2, A0, A1, A5, A6, A7), because the rest aren't often used.

If the 68K family has 16 registers is for a reason: speed. Accessing memory is slow. Compilers take full advantadge of the registers to avoid accessing memory, so the argument that only a small set of the registers are often used does not hold. If you need further proof, just search for some m68k assembly generated by a C compiler.

The number of registers is *very* important, because each significantly used register that you can't map is one that will have to be fetched from cache or from main memory very often. That adds up to a very significant performance drop.

Remember that we are talking about the x86 architecture, so you have 8 semi-GPR. From those 8 registers you need two for stack management, so you just have 6 left. You'll need at least another register to use as a base to access to data, for example the status word stored in a struct with other important data. So you might just get 5 registers left to map to emulated registers. The point is that you'll end up effectively mapping 4 from 16 registers, so you'll be basically accessing memory all the time. This is no different from emulating a PPC.

The PPC memory manager may be somewhat trickier to implement than the 68K memory manager but not that much, and in many ways the PPC instruction set should be easier to implement than the 68K one. It has much fewer addressing modes and only one way to load to and store from memory.

In theory a RISC architecture is much more simple to emulate than a CISC architecture, specially memory access, and I fully agree with you in that aspect. In the other hand the PPC is not an extremely RISC architecture as an Alpha could be. Just take a look at the different variants for each basic instruction. There are several opcodes for the move from register to register, each with subtle differences. And this situation repeats for every basic (purely RISC) instructuction. In fact the PPC is not that RISCy (REDUCED Instruction Set Chip).

The old Mac OS for the m68k architecture didn't make use of the MMU. Then, it doesn't make much sense to write suport for it. In the PPC case the situations is very different. Mac OS X uses the MMU. I think that the MMU must be the complex aspect of coding a PPC emulator which might slow down the emulation so much that it can render it useles for any practical purpose.

I originally replied to your post because I found it misleading. Again I'm replying to a post that's not just misleading but has big factual mistakes (e.g. 16 bit registers). I don't belive that that post deserves a +3, I think it deserves a -1 Misleading. Please, moderate posts properly.

missleading

Re:No Certainties..

[stripes]

68K architecture may have 16 registers, but they are 16-bit, while x86 are 32-bit.

No, the 68000 had 32bit wide registers a 32bit ALU, a 16bit data bus, and a 24 bit address space (25 bits if you count the supervisor pin). I have the databooks. I have owned computers using these. I have programed them (in C mostly, but the debugging was in assembly). The Palm's CPU32 is I think based on this, which means I even still use one :-)

The 68010 was I think the same. The CPU32 might be based on this, if so I have one.

The 68020 had 32 bit data buses and a 32 bit address space, but was otherwise the same. I've used these but not owned them.

The 030 and 040 are the same but have a built in MMU, and sometimes FPU. I have used and programmed the 040 a lot, but not owned them. I have data books for both somewhere.

The 060 was super scaler but otherwise much like the 040. Never used one. Didn't have a data book for it.

If you don't beleve me, call Moto and get a free data book. Enjoy.

On top of that, you can get away with only mapping 7 or 8 (D0, D1, D2, A0, A1, A5, A6, A7), because the rest aren't often used. In PPC assembly, use most or all 32 registers at the same time is quite common, because with a RISC instruction set, you *have* to do everything in registers.

Hmmm, I sort of disagree with this. Almost every 68000 instruction uses one or two registers, most can use far more (what with the complex non-RISC addressing modes). Almost every RISC instruction uses 3 registers (sometimes one register is used twice though). Registers are extremely important in both RISC and CISC code. Not so much on stack based machines though.

I think the real reason the 68k emulators are easier then PPC emulators is 68k CPUs are not very fast. If you ignore the almost-68K CPUs like the ColdFires I think the 68k family didn't go faster then 60Mhz. Also prior to the 68030 most instructions took more then one cycle to execute. So a 600Mhz Intel/AMD/PPC can afford to spend 10 cycles doing the work of one 68k cycle and you are still as fast as the original.

On the other hand PPCs are far far faster. I have I think a 50Mhz one in my set top box, emulating that on a 600Mhz Intel/AMD would only give you 5 or so cycles to get the work done. Worse yet the one I have in my old laptop is 500Mhz, the 600Mhz Intel/AMD gets barely more then a cycle! A brand new top o the line Intel might get 4 cycles to do the work in, but that really isn't much time!

At least not for anything that does the translation on the fly. For something that does the work ahead of time and caches it like the TranMeta Crouse, or (I think!) some 68K emulators, you can do much better, if there are loops at least.

Re:No Certainties..

[Ctrl-Z]

Repeat after me: Apple is a hardware company.

Re:No Certainties..

[stilwebm]

You also missed another important fact that helps speed up emulation of most 68K CPUs. Excluding the 68060, the 68K CPUs are not superscalar (Well, ColdFire uses "instruction folding" which uses less silicon to get a few more instructions in at once, but this is not truly superscaler). So your recent Intel/AMD and PPC can acheive an IPC greater than 1. The PPC is superscaler, so emulating it with a superscaler processor is helpful, but the performance gap is even more narrow.

If memory serves me correctly, the 68040 was the also first piplined 68K. PPC and the latesest offerings from AMD and Intel are pipelined, of course.

Re:No Certainties..

[stripes]

So your recent Intel/AMD and PPC can acheive an IPC greater than 1

Hey, what's a factor of two between friends, right? :-)

If memory serves me correctly, the 68040 was the also first piplined 68K. PPC and the latesest offerings from AMD and Intel are pipelined, of course.

I seem to recall the 68000 having a small pipeline. The 68010 definitly did which is part of how "loop mode" worked (an ALU instruction followed by a "decrment and check cc and branck back one insn" is "loop mode" and you can execute one per cycle, because it stops the first 3 stages of the pipeline).

I'm not sure what was first on the 040, maybe built in ALU? No, that was the 030, or was that an option on the 030? (the 040 I used was the 68LC040 at 25Mhz)

Everyone will still see it as slow

[SexyKellyOsbourne]

Though we all know by now that cycles per second alone does not determine performance, the average consumer does not.

Though it is a revolutionary advance, they're more apt to see "64-bit" as a useless gimmick or even see it as inferior to "128-bit" Gamecube processors, while thinking that 1.8ghz is dirt slow, especially in 2003 when Intel will be in the 3's and AMD in the 2's, even if the chips still are 32-bit.

All you need to do is make a chip oscillate fast, and Joe Customer will think it's the greatest thing since sliced bread.

Re:Everyone will still see it as slow

[Jucius Maximus]

If IBM makes some whack-ass server software that actually takes advantage of the 64 bit architecture, it could provide a better performance/price, performance/power useage, performance/space, etc ratios than current server solutions.

But that's a big *IF* . But it would be cool to have another option out there.

Re:Everyone will still see it as slow

[BitGeek]

All you need to do is make a chip oscillate fast, and Joe Customer will think it's the greatest thing since sliced bread.

Not to mention most of the geek wannabes who post on slashdot.

I think its time Apple start calling anything based on the power PC architecture twice its clock speed, and anyhting thats both powerPC and 64 bits at 4 times its clock speed. After all, the processor does twice as much as a 32 bit processor in a given clock.

So calling this new PowerPC that runs at "1.8GHz" a "7.4GHz PowerPC" is just as legitimate as Intel calling their pentiums 2.8GHz, etc. (Cause they don't really actually run at 2.8GHz. That's just one clock rate that exists at some point on the processor. Processor clocking is far more complicated than that.)

These published clock rates are a marketing fiction to begin with, so tis time for apple to release their 3GHz processors in January and that 7GHz 64 bit one the following january.

Re:Everyone will still see it as slow

[vlad_petric]

Cause they don't really actually run at 2.8GHz.

Actually they do. What you're missing is the other component of the speed equation, namely the IPC (instructions per cycle). Intel design favors clockspeed to IPC, for obvious marketing reasons, while AMDs designs are more balanced. That's why they get similar performance with considerably slower (in terms of clockspeed) CPUs

The Raven

Re:Everyone will still see it as slow

[Hrothgar The Great]

I've taken computer architecture before, thanks, and I've also USED many computers AND I've read benchmarks and listened to the comments of many people with much more knowledge than I on the subject and NO one expert has EVER made the claim, to me at least, that any (non-theoretical) RISC processor will operate 4x more efficiently in regard to clock speed.

While I do agree that a processor running several parallel instructions could average 4 IPC and run instructions really, really fast, if said processor is based on a reduced instruction set, doesn't that mean that each instruction actually accomplishes a smaller amount? (And that the speeds therefore may be closer to balancing than the RISC one actually being 4x as efficient?) Perhaps I simply misunderstand the nature of RISC, but that's the impression I have.

Re:Everyone will still see it as slow

[LinuxHam]

If IBM makes some whack-ass server software that actually takes advantage of the 64 bit architecture

They/we already do. It's called zSeries. Like the z800. That's one whack-ass server. Imagine doing self-service web hosting that takes users from first click to a fixed IP dedicated host up and running in 5 to 10 minutes with no additional hardware. Now imagine that kind of service for up to 10,000 or more fully independent hosts in a 19" rack. If I had a some bucks and gumption to start a business, that's exactly what I would do. A z800, the fattest pipes I could buy, and some disk.

Re:Everyone will still see it as slow

[GigsVT]

You are correct, and also, executables will be larger in RAM in a truely RISC environment, since more instructions are required to accomplish the same thing.

Re:Everyone will still see it as slow

[rampant mac]

Talk about superior OS stuff, I'm all ears, but "MHZ Myth" "MHZ Myth" just gets stupider every time you say it.

...just gets stupider every time you say it... Maybe we should talk about our superior grammar software?

Re:Everyone will still see it as slow

[dbrutus]

According to Apple the only performa 640 was one of those hybrid dos machines. The spec is still on the Apple site. This was the era of selling crippled chips without math coprocessors. The 486DX66 that came in the box was paired with a 68LC040, thus we have an x86 chip with math coprocessor compared with a 68k Motorola chip without one. Oh yess, a *very* fair comparison.

Since no major PC computing platform uses the 68k line anymore for their CPUs why should we care about this anyway?

Re:Everyone will still see it as slow

[NanoGator]

"If I had a some bucks and gumption to start a business, that's exactly what I would do. A z800, the fattest pipes I could buy, and some disk. "

I must be tired, I thought you said "dicks" and not "disk". Given the lack of context, that made for an amusing sentence. Heh.

Re:Everyone will still see it as slow

[NanoGator]

"This "megahertz myth" crap was around when I had a 33 MHz 68040 Performa 640, and my 486/DX2 66 blew the shit out of it.
"... "I wish you Mac people would quit making a bunch of shit up instead of talking about the strong points of the Mac like you should be."

Heh. It's a funny thing, really. It's even more complex than the IPC/MHZ debate.

At home I had a 486 33 mhz with 8 meg of RAM. At school I had access to a Mac that was running at 75mhz with 16 meg of RAM. In theory, that thing should have mopped the floor with my 486, right?

Nope.

I was far more productive on my 486. I think I was running Windows 3.1 (it might have been 95, but I'm not 100% sure of that) with PhotoStyler. The Mac was running whatever OS was popular at the time and Photoshop. It took like half an hour to print to the printer on that thing. At home, I'd hit print and moments later it was going.

So wtf, why was the Mac so slow compared to my piddly 486? Well, I'm not 100% certain, but I think it had to do with the apps more than the hardware. Whatever OS I was running, the Mac OS was significantly more sophisticated. Photoshop was multi-layered, vs. Photostyler was more like "Paint and forget about undoing it". On top of that, I think one of the students overloaded the Mac with Fonts. (sadly, Apple had the philosophy of "we'll load everything at once instead of only loading what we need right now".) My PC was tuned specifically for what I wanted to do, and it ran circles around the Mac. I definitely did not have a very high opinion of Mac back then.

Today, Mac OSX is a little processor heavy with its UI. A friend of mine bought one of their notebooks about a year ago. It was pretty and all, but it got a little lagged while drawing the fancy flashy stuff on the bottom. I have no idea what that does to overall system performance, but it makes me wonder if it'd eat into rendering times in Lightwave, for example. Maybe it's all FUD, I dunno.

Frankly, I don't give a rat's ass how many IPCs it does or how fast it is. I want benchmarks. I'm sure that processors can have all kinds of advantages and disadvantages to each other, but real world conditions always change everything. In the case of the Mac and 486 I mentioned earlier, technical superiority meant nothing. Whatever speed advantage the Mac had was lost with the apps it was running.

Re:Everyone will still see it as slow

[Shanep]

This "megahertz myth" crap was around when I had a 33 MHz 68040 Performa 640, and my 486/DX2 66 blew the shit out of it.

Therefore, with my minimum sample size of 2 machines, I can deduce that all processors can be compared with MHz alone. Further, all architectures perform exactly the same, MHz for MHz across the board for similar instructions and they all scale in a linear fashion regardless of the ratio of core speed to main memory speed or other similar limitations. There is also no such thing as this "bottleneck" crap. Bottlenecks r what yer get when your old Chev brakes down on tha intastate and bloks a lane.

PS, this is sarcasm.

NASA did a study to find the best cost/performance for their Fortran number crunching.

AltiVec is a beast. A 500MHz G4 using AltiVec ran 6.9 times faster than a P3 800 and 3.7 times faster than a 500MHz Alpha 21264. The G4 worked out to be 5.3 times cheaper per FLOP than the P3 and 8.4 times cheaper than the Alpha. Although there is no mention of Intels SIMD within this documents and the FORTRAN compilers at the time of the documents writing were very limited in their abilities to vectorize FORTRAN code to make better use of the AltiVec.

Here is a 1GHz G4 performing up to 10 times faster than a 2GHz P4 while querying a DNA database and 2 times faster at their fastest measured rates.

Saying that the MHz Myth is a Myth, based on a single experience is really idiotic. Anyone who has at least failed the first semester of a CS course would know that different architectures cannot be judged on MHz alone. Hell, even comparing different revisions of the same architecture family cannot be judged on MHz alone (a 33MHz 486DX is much faster than a 33MHz 386 for example, ignoring floating point of course). Wanna talk about CISC vs RISC vs CISC-wrapped-around-RISC?

Here are some G3's (as low as 333MHz) and a 450MHz G4 running faster than a P3 500MHz. There are plenty of graphs and numbers here which might put a fright into you Hrothgar.

Re:Everyone will still see it as slow

[Shanep]

That guy at barefeats would appear to be a little biased.

In his section comparing games performance, the G4 machines come last in 3 out of 4 tests and he then proclaims the G4 to be the overall fastest.

Fact is, (and I love PPC) that the memory architecture is a severe bottleneck that must be smashed. AltiVec is a beast, but is wasted for anything non cache bound.

Re:Everyone will still see it as slow

[Hrothgar The Great]

Anyone who has at least failed the first semester of a CS course would know that different architectures cannot be judged on MHz alone.

Hold on there, speedy. I never said any of that. You just read what you wanted to read from my comment. What I and many people continue to claim, is that MHz is a FACTOR. See if you can get that through your head. The MHz myth people on here, for the most part, are acting as if clock speed is entirely insignificant. The guy I was responding to actually claimed not only that a PowerPC processor would operate at double the efficiency (and consequently that a 64 bit PPC would operate at 4x efficiency ??) of an equivalent clock speed Intel processor, but that clock speed itself is "marketing fiction". I think that that is in fact quite ridiculous, even looking at these benchmarks.

Incidentally, the benchmark in which apple modified the NCBI Blast (which I admittedly know nothing at all about) to run much faster on their own architecture seems a bit of an unfair comparison to the standard blast procedure (which only used gcc's optimizations) running on an Intel chip. Looking at the first graph, the A/G blast obviously runs much, much faster than the standard one on Apple's own architecture! The difference between this and a completely non-apple system SHOULD be very dramatic, right? Or am I missing something? (The NASA study, on the other hand, does demonstrate some interesting differences, as you stated)

I'm not basing my opinions of performance on one example either, so throwing words like "idiotic" at me aren't going to get you anywhere either. I simply provided one example from memory. I'm not going to spill out my whole life to you in a flame post, so you can stop drawing one thousand conclusions about my intelligence from one paragraph any time now. Thanks. I won't do you a similar disservice.

Re:Everyone will still see it as slow

[Shanep]

2.8 GHz? Who needs that?

Well, of course it is great for some things. Obvously the top of the list would be 3D rendering and manipulation, 2D graphics rendering and manipulation, scientific computing and typical 3D gaming.

But, if you're getting frame rates in your games that are in the hundreds at the maximum practical resolution of your monitor in true colour (I would'nt run a 17" over 1024x768) or not ever doing anything that pegs your CPU at 100% for an appreciable amount of time, then if these people shell out big bucks to go from a 1GHz P4 to a 2GHz P4, they are either ignorant and/or stupid.

Upgrading (CPU) a machine that spends 95% of it's life at 5% processor occupancy is nuts. Seeing people pay big bucks for number smashers so that they can surf the web and run winword.exe just cracks me up.

However, I love it when people do it! Because I pick up PC's off the street, thrown out, which have always been in perfect working order. I've always found Windows OS to get slower and slower with registry rot as time goes on, meaning that a fresh Windows install makes a huge difference. But the average Joe perhaps is not aware of this and ends up throwing out his "awfully slow" PC, which I then pick up and use for OpenBSD, Linux or W2K.

My current server is a Pentium 200MMX with 128MB SDRAM which someone just threw out! Running OpenBSD 3.1 with two 40GB UDMA drives, it saturates fast ethernet easily. I actually install all my apps to it and even run Diablo II LOD off it over the ethernet with good speed. I'd love to see how it performs with some GigE cards, but that will have to wait...

Re:Everyone will still see it as slow

[be-fan]

The frame-rate faster than refresh rate arguement is entirely stupid. If you're getting 150 fps in a game, you're not turning the detail high enough. The truth is that even a brand spanking new P4 2.8 GHz with a Radeon 9700 isn't going to run Doom III at 1600x1200 at more than ~30fps. And I Doom III still doesn't come anything close to the quality of the FMV in games even from the PS-1 days. Also, if you do stuff like DivX encoding, Ogg encoding, etc, you need those gigahertz. Don't get me started on GCC. Compiling templated code in g++ takes several times longer than the equivilent C code, and it's irritating when even a simple templated program takes minutes to compile. Lastly, GNOME and KDE eat up those processor cycles. I don't care if my CPU is only running 5% load on average, but if it can't move the GUI along fast enough, I need an upgrade. Even my P4 2GHz is only barely satisfactory running KDE 3.x (two seconds just to launch Konqueror from cache!).

Re:Everyone will still see it as slow

[be-fan]

On top of this, when comparing the machine side-by-side with a 2.8 Ghz Pentium running XP, I highly doubt you'd notice any perceived speed deficiencies at all on the PowerMac...
>>>>>
Heh heh. In our library, we've got some 2.26 GHz P4s running XP right next to one of those fancy wide-screen iMacs (800MHz G4). Both machines have 512MB of RAM. While OS X is definately "prettier" (though not as pretty IHO as Keramik, but I digress) the Mac was definately slower. A lot slower. "Feels like a 500 MHz Celeron" slower. And I was just surfing the web and printing some stuff out. It was mostly a snappiness thing. While the WinXP machine did everything immediately, the Mac was more "dignified" about things. I really hate using those things, but I try them every time I get the chance just so I can write stuff like this :)

Re:Everyone will still see it as slow

[Shanep]

If you're getting 150 fps in a game, you're not turning the detail high enough.

Not always the case. If someone has their game set to max details, colour depth and practical resolution and they're getting multiple frames per refresh, then they hardly need an upgrade. If they're running a game that becomes perceivably choppy, then it's time to upgrade. Kinda proves my point.

Also, if you do stuff like DivX encoding, Ogg encoding, etc, you need those gigahertz.

I don't disagree. However, my old PII-300 encodes MP3's using LAME faster than realtime (single speed CD audio extraction). For me this was adequate, but the offer of a P3-500 CPU for $40 .au was too good to pass. : )

Don't get me started on GCC.

Obviously the domain of the CPU power hungry user.

Lastly, GNOME and KDE eat up those processor cycles.

My nice WindowMaker desktop flies.

Even my P4 2GHz is only barely satisfactory running KDE 3.x

Why run KDE3 if it requires greater than a 2GHz P4?!?

I run OSX 10.1 on an old 300MHz G3 with ATI Rage, I find it quick. So what is wrong with KDE3 if it can't deal with a 2GHz P4?

(two seconds just to launch Konqueror from cache!).

2 whole seconds?! Bloody hell!

Seeing people pay big bucks for number smashers so that they can surf the web and run winword.exe just cracks me up.

Is it not obvious that I'm trying to say that not everyone needs these ultra powerful machines? I didn't say nobody needs them.

Re:Everyone will still see it as slow

[Shanep]

Hold on there, speedy. I never said any of that.

You said, "a complete lie", "megahertz myth" and then go on with a single example which has already been pointed out by others to be quite unfair for more than one reason.

Don't say the "MHz Myth" is a lie when you actually mean the "MHz Myth" groupies are a bunch of exagerating liars. I've pointed out somewhere here one of the guys making benchmarks finds the G4 comes last 3 times out of 4 times and then proclaims it the overall fastest. Blame people like him, not the MHz Myth.

The "MHz Myth" is for example, the belief amongst plebs, that a 1GHz Intel will have the same computing power as a 1GHz PPC. It is a myth.

I agree that Apple has and will continue to fall behind until the next CPU revision. The current memory speeds are really crap, comparatively speaking.

Incidentally, the benchmark in which apple modified the NCBI Blast (which I admittedly know nothing at all about) to run much faster on their own architecture seems a bit of an unfair comparison to the standard blast procedure (which only used gcc's optimizations) running on an Intel chip.

I know little about BLAST also. Apple would be stupid if they didn't try to use AltiVec for this "embarassingly parallel" task though. If Intel is worried, they can alter the standard to get better performance on x86. If anyone can find MMX/SSE BLAST benchmarks, I'd like to see them.

so you can stop drawing one thousand conclusions about my intelligence from one paragraph

Let me assure you, I'm not drawing any conclusion about your intelligence based on your paragraph. I've mouthed off here plenty of times in the past without being verbose enough to keep me out of flames.

However, make short, agressive posts that appear to proclaim obvious untruths without fully explaining yourself, and you have to expect loads of moderation and replies.

Re:Everyone will still see it as slow

[Shanep]

However, the guy I was responding to, I guess I just found myself not caring quite as much.

Completely understandable. I'll *try* not to jump the gun next time. ; )

Re:Everyone will still see it as slow

[be-fan]

To respond to the two whole seconds thing: I'm an impatient person. The human response time is about 1/3 of a second. The computer may spend most of its time waiting for me, but unless every time *I* wait for it is less than this 1/3 of a second, it's still too slow. As for your 300MHz G3 running OS X, I feel sorry for you. I've used OS X on a 800MHz G4 (512MB) and it's unusably slow. Thus you can see why KDE 3.x on a 2GHz P4 is only barely usable to me.

Re:Everyone will still see it as slow

[be-fan]

I've using a dual 1.25 at Microcenter, and though it was snappier than the iMac, it still was nowhere near as responsive as WinXP on anything faster than a 2Ghz P4.

Re:Everyone will still see it as slow

[Shanep]

As for your 300MHz G3 running OS X, I feel sorry for you.

I'm an impatient person.

I feel sorry for you. Sounds to me, that you will always be unhappy with performance.

I've used OS X on a 800MHz G4 (512MB) and it's unusably slow.

How ridiculous. When OSX was at 10.1.4 on my 300MHz G3 (128MB) it was annoyingly slow. But the upgrade to 10.1.5 was a MASSIVE improvement, making it a joy to use. Jaguar is even faster, even though Quartz Extreme does not support my video controller.

Thus you can see why KDE 3.x on a 2GHz P4 is only barely usable to me.

If KDE3 is "barely" usable for you on your 2GHz P4, why the hell are you using it? Go WindowMaker, AfterStep, etc if you want lightning fast.

To think I used to use Linux on a 486DX33 with a badly supported Diamond SpeedStar 24X.

Re:Everyone will still see it as slow

[BitGeek]

Yes. And this new 64 bit chip will issue 8 instructions per a clock cycle, while intels chips (I'm not conversant on AMD's details) generally take multiple clock cycles per single instruction. While many of them have been optimized to execute in a single clock cycle, and multiple instruction paths can occur under the intel design, on average, the amount of WORK DONE (not instructions executed) on an intel design is much less than that on a PowerPC design.

Which means that all those people who think that a 2.8GHz pentium is necessarily faster than a 1GHz powerPC are ignorant or idiots.

Unfortunately, there are no benchmarks that have not been cooked by one faction or another.

Re:Everyone will still see it as slow

[BitGeek]

This post has been moderated thusly:

Flamebait=2, Insightful=3, Interesting=2, Overrated=3, Total=10.

At the risk of being modded down, I think the moderation system is broken-- clearly moderators are fighting over the position, rather than the quality of the post.

Re:Everyone will still see it as slow

[BitGeek]

his "megahertz myth" crap was around when I had a 33 MHz 68040 Performa 640, and my 486/DX2 66 blew the shit out of it.


The ironic thing is that BOTH of those processors ran at 66MHz!

Back in those days, motorola labled the speed of the chip based on the speed of the external buss, not the internal clock rate, while Intel used the higher of the two- the internal clock rate.

So, even on clock there is no way the 486 was faster-- and when you look at the architectures, it was absolutely a lot slower.

So for this guy to claim that the 486 blew it away, we know he's just saying what he wants to be true-- any fair comparison would show quite the opposite.

AND revealing his ignorance of the fact that both of those parts had the same internal clock rate!

Clock rates are all about marketing, and nothing about performance.

Re:Everyone will still see it as slow

[BitGeek]

And of course you're wrong-- your own comparison compared two chips with the SAME CLOCK RATE.

They were labeled differently because the companies labeled them based on different clocks.

But both ran internally at 66MHz.

That pretty much proves my case, idiot.

PS- I love how you think compiling with altivec performance optimization on is "cheating". so, in your view, the only fair comparison is one where the floating point unit is never used? Uh Huh.

Re:Everyone will still see it as slow

[BitGeek]

If you're happy with your 1GHz processor, fine. But don't pretend that current x86 processors at 2+GHz don't wipe the floor with the slower ppc offerings.

Yet another idiot who thinks that the clock rate determines the processor speed.

Yes, idiot is not too strong of a word.

BY the way, the x86 compared to was fully optimized for the pentium FPU. The powerPC was as well, and it "wiped the floor" with the pentium, as you say.

To claim that the only fair comparison is one where the powerpc FPU is not used is absurd.

And to then claim that because this "Fair" comparison wasn't done the faster clock speed of the pentium makes it faster just shows how ignorant you are of processor architecture and performance.

Given that all this stuff has been explained to you time and again, your continued refusal to accept reality earns you this title: bleeding idiot

Re:Everyone will still see it as slow

[BitGeek]

This is just wrong.

What do you use Altivec for? Ripping MP3s? Encoding MP4 video?

The memory architectuer doesn't get in the way of these at all. Think about it-- what is the uncompressed bitrate of DV video or CD data?

Do the math and you'll see that the memory architecture is more than sufficient to keep the altivec processor fed.

What you just repeated is one of the many myths that people spread about the powerpc, but it simply isn't true.

Unfortunately, most people don't do the math.

Re:Everyone will still see it as slow

[be-fan]

I feel sorry for you. Sounds to me, that you will always be unhappy with performance.
>>>>>>>>>>
Actually, I was perfectly happy with the performance of BeOS on my old PII-300, and with the performance of Win2k (just the UI, not overall). Both those OSs offered instant or near instant response, which is all I'm asking for. 1/4 of a second is about 250ms. You can do a couple of dozen hard drive accesses in that time. Needing more than that for the relatively simple processing required for UIs is just criminal.

How ridiculous. When OSX was at 10.1.4 on my 300MHz G3 (128MB) it was annoyingly slow. But the upgrade to 10.1.5 was a MASSIVE improvement, making it a joy to use. Jaguar is even faster, even though Quartz Extreme does not support my video controller.
>>>>>>>>>>
This was with X.2 by the way.

If KDE3 is "barely" usable for you on your 2GHz P4, why the hell are you using it? Go WindowMaker, AfterStep, etc if you want lightning fast.
>>>>>>>>>>..
Barely usable for me == lightning fast. Just south of instant. I can't go WindowMaker or AfterStep because I end up using KDE apps anyway (Konqueror, Kopete). I've got some complaints, such as even the simplest apps taking over a second to start up, but overall I'm quite happy with it. If I wasn't (and before, on my PII I wasn't) I wouldn't use it.

To think I used to use Linux on a 486DX33 with a badly supported Diamond SpeedStar 24X.

Re:Everyone will still see it as slow

[Shanep]

I can't go WindowMaker or AfterStep because I end up using KDE apps anyway

Last time I was running KDE, you didn't need to run the KDE GUI to use KDE apps, just have the KDE libraries installed.

This was with X.2 by the way.

Why must things happen instantly for you? You ought to re-write yourself as a QNX app.

Re:Everyone will still see it as slow

[Shanep]

Unfortunately, most people don't do the math.

Actually, with HP48GX in hand, I do.

These things you have described are processor intensive. Encoding MP3's and video will easily make the CPU the bottleneck.

Every situation does not fall into one category you know.

Think about it-- what is the uncompressed bitrate of DV video or CD data?

CD data, I assume you mean CD audio, since CDROM could be using any compression, proprietary or open. Well CD audio data is uncompressed to begin with. You want math, so 16bit samples * 2 channels * 44100 samples per second = 176,400 bytes/second. Of course, who does DAE at 1x? So what is your point?

more than sufficient to keep the altivec processor fed.

AltiVec is not always used and when it is, it tends to be with apps that are obviously CPU intensive and thus not memory bound. One will be a limiting factor, though this can be vice versa depending on the application at hand. Hell, in databases disk is usually the limited factor, unless your db is small enought to fully sit in RAM.

What you just repeated is one of the many myths that people spread about the powerpc, but it simply isn't true.

So you think the performance people see with DDR in memory bound apps are figments of their imagination? You think these new memory technologies are worthless? The quicker the main memory can burst the required data into the CPU registers, the quicker the CPU will operate on that data and burst it back. Even in CPU bound applications, faster memory can enable small performance improvements through reduced propagation delays. There is more to data transmission performance in CS than bandwidth considerations.

Re:Everyone will still see it as slow

[BitGeek]

I was responding specifically to the claim that altivec is wasted because its starved for data. Since you (or whoever it was that made that claim) didn't specify what usage altivec was being put to where it was starved for data, I provided examples of the scenarios I know of where altivec is used.

With them memory busses in question, the altivec unit is not starved for data when ripping a CD or encoding DV into MP4 video.

In fact, in these cases the bottleneck is actually the device the raw data is being read off of.

So the claim that the altivec unit is wasted because of memory bottlenecks is silly-- the limiting factor when encoding DV video to MP4 is the hard drive, not the altivec unit.

Re:Everyone will still see it as slow

[Shanep]

In fact, in these cases the bottleneck is actually the device the raw data is being read off of.

Absolutely.

So the claim that the altivec unit is wasted because of memory bottlenecks is silly-- the limiting factor when encoding DV video to MP4 is the hard drive, not the altivec unit.

Wouldn't argue with that.

Slimming?!

[T-Kir]

IBM server chip seen slimmed down for Apple Macs

So the IBM version still stuffs itself with pizzas, whereas the Apple version is on Slim-Fast shakes wearing a lycra outfit and eating mostly fruit (well eating Apples would be cannabalistic, unless they bring out the PowerHannibal chip variant)... ;)

Re:Slimming?!

[sinserve]

Dell already supports Longhorn.

thank you than you, I will be here all week.

Apple actually seems tempting?

[Anonymous Coward]

hmm.. OSX and a 1.8 GHz 64-bit proc? if only they would release one that didn't look like a desklamp, or a giant pastel egg, i'd be tempted to use one.

Re:Apple actually seems tempting?

[rampant mac]

Biege box?

That's like stuffing a Picasso into a Pinto.

Re:Apple actually seems tempting?

[Mononoke]

if only they would release one that didn't look like a desklamp, or a giant pastel egg, i'd be tempted to use one.

Ok, here ya go:

XServe

Re:Apple actually seems tempting?

[Pengo]

geezus.. the powerbook is one of the sexiest laptops on the market. Doesnt't look like a lamp or an egg.

Re:Apple actually seems tempting?

[Some Dumbass...]

if only they would release one that didn't look like a desklamp, or a giant pastel egg, i'd be tempted to use one.

Try leaving the computer in the box. ;)

If that's still too gaudy for you, turn the box inside-out, so the plain cardboard side is showing.

Clawhammer for me.

[WittyName]

I will take price/performance any day.

Getting the volume up is going to be difficult for IBM..

Re:Clawhammer for me.

[Chemical]

How can a Mac possibly have a lower TCO for the home user? First things first, they cost twice as much as a comperable PC. Second, if the logic board or one of the other pieces of proprietary hardware breaks you have to replace it with Apple parts from an Apple authorized vendor, and that will cost a fortune. I cannot possibly see how an Apple can end up with a lower TCO than a PC. I'm very curious. Please explain the logic behind that statement to me.

Re:Clawhammer for me.

[fault0]

> Good for you! I'll take "ease of use" and "lower total cost of ownership" any day.

And so will the other two mac users in the world.

Ease of use has become quite similiar between Macs and PC's.

If Apple had more open hardware again (clones), I'd use it (again). I loved my PowerComputing box, shame on Apple for killing clones.

Re:Clawhammer for me.

[bnenning]

I've never seen a single ANYTHING to show that what you claim about TCO is true.

I've seen several. Try here for starters.

Re:Clawhammer for me.

[davidstrauss]

Volume won't be a problem at all for IBM. They run more PowerPC chip fabs than Motorola. The only reason IBM isn't making G4s is Apple's contract with Motorola, which seems to be icy at the moment. IBM could create G3s that run faster than G4s and flood the market tomorrow if there weren't legal issues. IBM and Apple seem to have a serious future together.

Re:Clawhammer for me.

[rampant mac]

If Apple had more open hardware... [snip].

Hmm, plugs in my USB mouse. Damn, that works.

Plugs in a firewire hard drive. Shit, that works too.

Plugs in a USB scanner. Dammit, that also works!

Plugs in a Mac PCI Radeon video card, son of a... It works!

Tries a Belkin USB hub, holy moly, that works too!

But wait, my PS/2 mouse won't work! Or my parallel printer! Or my ADB tablet!

Time to move forward, eh?

Re:Clawhammer for me.

[bnenning]

First things first, they cost twice as much as a comperable PC.

Where can you get a PC comparable to the iMac for $650? Or comparable to the iBook for $600? The price difference is not as much as you think, and can easily be made up for by ease of maintenance, lack of viruses and spyware, and better security.

Re:Clawhammer for me.

[Otter]

Like the other guy said, there have been a fair number of studies claiming a lower TCO, even in a mixed environment.

Everything - from software, to software support, to hardware services, to hardware upgrades, to peripherals is either priced at or above what the "commodity" white box-PC equivalent is.

1) The big savings is on support. You need far fewer techs per Mac than per PC, and you can pay them less. For that matter, in Windows-heavy businesses, they'll frequently tell users (individuals or a group of graphic artists or web designers), "OK, you can have a Mac but we won't support it all."

2) Almost all hardware upgrades and peripherals are the same as the ones you'd put on a PC. Just don't buy the hard drive or USB mouse from a Mac-specific catalog and it won't cost you any extra.

3) Sure, you can buy white-box garbage that's cheaper than anything in the Mac world. But that comes with plenty of extra costs in the long run. Most of the time, you'd be better off with Dells.

Re:Clawhammer for me.

[Svenne]

Cool.. Care to mention where one would turn to pick up an iBook for $600?

Re:Clawhammer for me.

[Dun Malg]

To quote from the site to which you link:

"The average Wintel home user spends around 50 hours per year troubleshooting their computer, while the average Mac user spends less than 5."

This "conclusion" at which they arrive is in itself inconclusive. Just because group A spends more time troubleshooting than group B does not mean that group A's computers require more troubleshooting. I know that if I were included in the survey that produced the above statistic I would definitely skew the PC side towards "more time troubleshooting" because I'm a compulsive tinkerer. I can't leave my settings, drivers, and services alone so I end up spending hours balancing it all. I have a Win 98 PC I use at work that NEVER needs troubleshooting. A friend of mine has a Mac that requires reinstallation of the OS every 3 months. It's all about how you use 'em. Besides, the TCO they're talking about also includes the cost of retraining, repurchase of software, and downtime due to switching over. Hardly the "from scratch" sort of TCO you're talking about. Find me a TCO analysis that doesn't rely on nebulous calculations involving "retraining" and "man-hours spent troubleshooting Uncle Bob's PC vs Aunt Eunice's I-Mac" and I'll take notice.

Re:Clawhammer for me.

[Twirlip of the Mists]

First things first, they cost twice as much as a comperable PC.

Yes, but you only have to buy them half as often. ;-)

And, incidentally, no they don't. You can find cheaper PCs, but most often a prebuilt system with the same features as the Mac-- like a widescreen LCD, or a Superdrive, or Gigabit Ethernet, whatever-- will be within 15% of the Mac's price.

Second, if the logic board or one of the other pieces of proprietary hardware breaks....

Speaking as a long-time Mac owner... doesn't happen. I have seen a couple of systems fail while under warranty, but those of course get repaired for free. If you're really worried about it, buy a five-year AppleCare plan. By the time your warranty runs out, you'll be ready to buy a new computer.

Please explain the logic behind that statement to me.

In order to fully understand the math, you have to assign a dollar value to your time. I find that about $250 an hour is a good number for me during the week; since I value my weekends more, I arbitrarily assign a value of $500 an hour to Saturdays and Sundays. Since Macs require essentially no farting around to make them work or keep them working, while PCs-- no matter what OS they run-- require considerable set-up and maintenance time, the Mac comes out as a big winner.

Re:Clawhammer for me.

[Twirlip of the Mists]

Or, you could run Linux, and you'd have the cheapness + performance + lack of all that you mentioned.

"Lack of all" is right. If I were running a web server or a database server or a file server or something, I'd consider Linux for it. But as a home computer? Pfeh. I prefer to run an operating system that can run programs I actually want to use, thank you very much.

Ah, Linux. Depending on your distribution, you get one or more CDs positively full of software... none of which is worth a tinker's dam.

Re:Clawhammer for me.

[dbrutus]

Congratulations, you are not in the Apple demographic. Nothing they will do will ever please you. Please stop paying attention to Apple now because unless you are in charge of IT purchasing at a company in Apple's target market you won't ever get a machine from them that you'll like.

You are also probably not in the Lambourghini, GAP, butler, and countless other market demographics but chances are you aren't compelled to rant about how they are irrelevant to you. Try extending that to Macintoshes, would you?

Re:Clawhammer for me.

[dbrutus]

Try taking a look at this PC spec page. Notice what's not there? Parallel ports are on the way out. Do you insist on 5.25 floppy drives on your machines as well?

Re:Clawhammer for me.

[dbrutus]

OK, create a workgroup server running Windows, web serving, file and print, and a database for 100 people. Now do the same using a mac.

The mac is hands down cheaper because the software on Windows is so much more expensive.

Apple makes the whole widget.

OK, now Linux beats mac out on price, no doubt. But can it even come close on ease of use?

Re:Clawhammer for me.

[dbrutus]

Mac people have been sticking PC memory into their computers for years. Ditto with hard drives, etc. If you don't want to pay extra, you don't have to get 'genuine GM parts' for a GM car either. You save money there too even when both parts are turned out by the same factory.

Re:Clawhammer for me.

[fault0]

No, but perhaps when a replaceable motherboard? heh.

Re:Clawhammer for me.

[Hast]

OK, now Linux beats mac out on price, no doubt. But can it even come close on ease of use?

Depends if you know how to use it or not. The first time you setup a Linux system like you mentioned is most likely going to take longer than a Win/Mac. (Assuming you didn't get the server preinstalled from one of the companies that does that.) However after running that server for a while you'll get so used to it that when it's time to upgrade or add new servers it will be up in very little time.

That's the benefit of working with a systemed geared towards experienced users. While new users are likely to make mistakes and take longer (I know I did the first time I installed Linux.) the more accustomed you get the faster and easier it gets.

Re:Clawhammer for me.

[maraist]

What the poster was trying to say (though it wasn't fully representative of the population) is that since building a PC can be an enjoyment, and sometimes even a communal thing, it's economic costs are reduced, since in some instances we would pay to have a "put-together" toy, such a puzzles, models, etc. So on a case-by-case situation, the lower purchasing price and the negative opportunity cost (due to enjoying putting it together) and having the thrill of running a machine that you know you've built, leads to lower total [economic] cost.

Further, the viral reduction and reduced administrative overhead of MACs do contribute to it's value (or rather, reduce the associated economic costs relative to a PC), but the lack of utility from having PC-centric applications offsets much of this. Further, sophisticated administrators can dramatically reduce viral instances (e.g. NEVER run email attachments, avoid using MS office, or at least restrict it' usage, have external fire-walls, etc). Unfortunately we can't all be savy admins, but I've been viral free running virtually every OS I've ever heard of for most my life. Yes it factors in, but again, on a case-by-case basis, this isn't as much a cost as you're suggesting.

Further, the "accounting" cost of having a lan party with MAC's is significantly higher than one of nicely configured PCs. So much so that it's often impractical for the average user. PC's allow downgrading parts (e.g. upgrading piecemeal, then when a new machine is purcahsed, the old parts can be re-instated), further reducing "accounting" costs, and facilitating greater utility from existing purchases. Most notably, I've NEVER paid more than $500 for a PC (thanks to component reuse), and consequently I have over a dozen machines at my house (switch boxed, networked, what-have-you). At any given time, I have 2 state-of-the-art machines. This could never happen with MAC's (especially the iMAC).

That being said, the original poster and myself don't constitute the majority of the population. For such cases, your arguments are much stronger. There IS an opportunity cost involved with building a machine for a friend or for a company. The responsibility alone adds to the economic cost. In such instances, I recommend Dells, Compaqs, etc, simply because support issues are too critical. Though often I'll point them to something like mwave.com or comp-fairs with pre-fabbed OEM systems with 3 year system warranties (and lifetime warrenties on parts). In general though, I'm NEVER as satisfied with a name-brand product as with a grass-roots product.. Grass roots OEM's provide linear expansion cost increases where-as name-brands make their bread-and butter off upgrades. Further, name-brands tend to produce proprietary parts with little 3'rd party support. (Packard Bell / Gateway use to be SUCH a pain in the ass). MAC's fall into this category, plus the loss of compatibility with the main-stream.

Re:Clawhammer for me.

[dbrutus]

http://www.bb-elec.com/convert_serial_port/usb.asp

From what these people are saying you should be able to attach this to a USB computer(mac or pc) and get a parallel port out the other end.

Cheers.

Re:Clawhammer for me.

[dbrutus]

Of course I meant the hardware/software combination of x86/Linux v. PPC/Mac OS X. Since it is very hard to find a Mac OS X capable system without an included license for some Mac OS, it's actually not very fair to compare PPC/Linux to PPC/Mac OS X.

But then again, you knew that.

Re:Clawhammer for me.

[MoneyT]

He was talking about the fact that the parent post had said you can get a PC for half as much as a mac. Since the iBooks cost $1,200 it logicaly follows that if the parent statement was true, a comparable PC laptop would cost $600. He was asking where he could get one.

unix time bug

[jacquesm]

with a little luck this will save us from that dreaded 2^32 time bug !

Re:unix time bug

[Trusty Penfold]

Switch to Windows. Windows had a bug with Year 2000, and that is passed.

Anyway, it is still a long to to 2032.

Re:unix time bug

[YU Nicks NE Way]

I realize that you're being funny, but Windows actually uses a 64 bit date/time structure, and has since NT 3.1. We're going to need to deal with the Y5G bug before the Windows clock rolls over.

news

[sstory]

I frequently see articles like this on tech sites. Articles about 64-bit chips, 64-bit linux, 64-bit Windows. None of the articles explains how 64-bit equipment will benefit the user. Perhaps techies assume it's obvious; to them it might be. To the rest of us it isn't. And I don't think I'm speaking from a particularly uninformed position. So can someone please point me to info explaining not the availability of 64-bit processing, but the advantages, capabilities, tradeoffs, etc?

Re:news

[bogie]

32-bit proessors can only use 32 Megabits of ram huh?

They actually support 4GB of ram, unless of course you were just trying to be funny.

Also for your future reference

http://www.crucial.com/library/mb_vs_mb.asp

Re:news

[bogie]

HAHAHA

Yes I too would like to know who modded that Insightful. They should be exposed before all of Slashdot and have their mod privilages taken away. They should also not be allowed to use computer agin until they take a remedial "Introduction to computers" class.

Re:news

[fliplap]

64-bit means you can handle these huge wacky long integers. Which is important for the home user because *tud* *beeeeeeeeeeeeeeeeeeeeeeeeeeep.....*

Re:news

[jhines]

For Apple, I'd say large image processing, and video editing.

The key is going to be HUGE memory support when Apple comes out with it, 16Gb or more.

Re:news

[dmayle]

It's quite simple, really. It's all about getting easy access to memory. We're getting awfully close to physical limits of 32-bit addressing of RAM (4 Gb, though x86 gets around this slightly with segments in server chips). It's not uncommon for a graphic designer (and soon, maybe Joe America with home movies and video editing software) to drop 2GB into a desktop/workstation machine. We'll be hitting that memory limit awfully soon, and with 4GB of ram under a grand, 64-bit addressing starts to look necessary.

Re:news

[selectspec]

The first advantage is the ability to have a 64-bit address space for pointers. This allows for extensibility to address considerably more physical memory (over 16,000,000,000 GBytes). Of course, no system requires that much memory, but the added virtual space is very handy, and systems do currently buck into the 32-bit limit of 4GB. The additional virtual memory space is handy in kernel development where everything shares the same memory mapping. The spectrum of the 64-bit address space is large enough to give everyone plenty of room to play with. Makes code much simpler.

Having 64-bit pointers actually has a draw back in that the amount of memory required to store a pointer is now 8 bytes instead of 4. For some code this increases memory utilization considerably and equally increases memory bandwidth requirements. Because of this, most (except alpha) 64-bit cpus will allow you to use 32-bit addressing if you are using less than 4 MB of memory.

Memory is only one feature of 64-bit processing. 64-bit arithmetic is very useful, especially when processing lots of data. However, software must be written generally to take advantage of this feature. When working with large numbers which require more than 32-bits to express, 64-bit CPU's have a huge advantage over their 32-bit cousins. Cryptographic, compression, multi-media and parity generation applications bennifit greatly from 64-bit operations.

Re:news

[leonbev]

You can rest assured that Apple will promote the benefits of 64-bit processors if they really use this technology in their next-generation PowerMac.

Unfortunately, this IS Apple that we're talking about, so you can't expect a fair comparsion. Instead, you'll probably see Steve shouting "The G5, THE FIRST 64-bit home SUPER-computer"! He'll make sure to include some misleading benchmarks showing their new system completing some obscure Photoshop benchmark twice as fast as the latest Intel PC. How else is he going to justify charging $4,000 for it? :)

Re:news

[Twirlip of the Mists]

Having 64-bit pointers actually has a draw back in that the amount of memory required to store a pointer is now 8 bytes instead of 4.

You're right about this, but for the wrong reason. The real impact of 64-bit addressing isn't in code size, but rather in cache performance. If your memory addresses are 64-bit ints, you can only fit half as many of them into cache as you could if they were 32-bit ints. Programs compiled for 64-bit addressing result in considerably more cache misses than their 32-bit counterparts. I've tested this myself using various toy programs on an IRIX box with 64-bit R12000 processors. On that system, you can compile to either a 32-bit ABI that uses 32-bit pointers (but that supports long long) or a 64-bit ABI that uses 64-bit pointers. Tests reveal more P- and S-cache misses when running the 64-bit binary than when running the 32-bit binary.

Re:news

[GMontag451]

Even though it is possible that in some far off distant future, 16 Exabytes will be required for some application, it is highly doubtful. To put it in perspective, 1 Exabyte (2^60 bytes) is estimated to be enough to store every single word ever spoken (in text, not in sound) by any human since the dawn of history.

Re:news

[gerardrj]

But Apple's target market and marketing ideas aren't geared toward the user who wants to store lots of text. The market to people who want to store and manipulate lots of digital data, pictures, sound, video, 3D scientific data.
True 64bit memory address space is ludicrous to store text/words, but it becomes constraining when you're trying to perform fluid dynamic simulations of major weather systems, or other "real world" events.
And it's not just scientific people performing these computations. It's also the new generation of 3D animators, and game creators that need to store, move and calculate on these large data sets.

Re:news

[maraist]

I've seen several responses, and few were well informed.
The number of bits is exactly equal to the number of digits the computer can work with.. Think of this as having a hand-held calculator with 10 digits. You can only do meaningful work up to those 10 digits. It's possible to represent larger numbers using floating point (exponential notation), but then you lose precision, since you can only display 10 digits worth of decimal (thus if you added 1 to a centillion, it would be rounded off).

Computers happen to use base-2 instead of base-10, so it needs more digits to do the same work as a 10-decimal-place hand-held. In fact, it takes roughly 32 bits to approximately represent those 10 decimal digits. 2 ^ 32 = 4 billion. (The 9'th decimal place).

Thus more bits, means you can represent a larger number (just like more positions on your calculator means you can represent the bigger salary of an enron executive). However, if all the numbers you're working with are small, then there's no benifit to having more digits. It just means more work for the poor machine.. PLUS there's a subtle slow-down associated with larger bit-counts.

Now there are several reasons why you'd want larger counts, and the most important is the memory size. 32bits gets us roughly 4 billion, or 4 Gig of memory, or even 4 billion clusters on a hard-disk (e.g. max of 4 billion inodes, etc). Going to 64bits gives us an unimaginably large number, but takes up twice as much over-head. 64bits / 8 bits/ byte = 8 bytes for a single number, as opposed to 4 bytes for a number. So the DOS FAT64 table would take up twice as much space, and so on with other File-Systems. Likewise all pointers and integers in memory would be 8 bytes instead of 4, increasing code size, and wasting precious cach-space.

Note, however, that it's entirely possible to work with larger number than your core can represent. Think of the calculator again.. If you know that the US budget is on the order of 2 trillion dollars, than you can just assume the extra left most digits and do all your work in the < 4 billion region, externally keeping track of all the carry's (just like in elementary math). Likewise it's relatively easy to combine multiple 32 bit registers to act as a 64bit register, though it takes some effort on the programmers part. Plus this isn't as fast as if it were simply a 64bit number to begin with.

Thus computer engineers have not arbitrarily increased bit-size from archetecture to archetecture. The original 8-bit machines worked fine for their embedded controller realms. 90% of all work was 8-bit, and so they could justfiy the expense of manually working out 16, 24 or 32bit arithmetic. Plus for certain important operations, the CPU would automaticaly combine multiple 8 bit registers to form a 16 bit address.

The beloved 8086 from which all PC's have derived used two 16 bit registers combined in an awkward way. Normally you'd think 2 concatenated 16 bit registers would equal 32 bits (and thus allow 4Gig of memory), but what they actually did was overlap most of the bits so that you really only had a 20bit number (which maxes out at 1 million). Thus The original IBM PC's could have up to 1 Meg of memory. The advantage was that you exclusively worked with 16 bit numbers which were REALLY small (2 bytes each) and REALLY fast (hardly any delay since you could optimize much of it's operation). However, the CPU had to perform an ADD for every memory access (since it had to produce the overlayed 20 bit number). Another problem is that while you could access 1 meg of memory, you could only do it 64K at a time. All arrays had to be <= 64k which is a REALLY big problem.

When Intel went 32bit, they kept the same crappy memory scheme of overlaying 16 bit registers atop a pointer-register. The only difference was that the pointers became 32bits. For most purposes this was sufficient, so only a single overlay was used. However, DOS compatibility required using one of the 16bit registers to provide an offset into a DOS memory frame. Theoretically it's possible to achieve higher than 4 gig of system memory on IA-32 machines through the use of these 64 thousand base-registers, maxing out at 48 bits. In fact, the CPU's actually allow something near this address space on their pin-outs, but very few motherboards accomodate this.. PLUS, a single application would have to be written in order to internally segment itself having arrays no bigger than 4 gig each (the exact same problem with 8086 16-bit register overlaying). Plus I'm not aware of OS-support for this capability (though it's theoretically possible). I'm pretty sure Linux doesn't support it at least.

Even though the IA-32's 16bit segment selectors are generally not used (except for 16bit mode DOS support), they're still an impediment, since they involve adding a base to a pointer on every operation. I'm not 100% sure, but I think this mode can be deactivated for performance enhancement, but other aspects of the IA-32 memory model involve such slow-downs.

RISC architecture, on the other hand uses bit-concatenation techniques to avoid having to perform additions for every memory access, and thus can provide clean memory access efficiently, though with no possibility for extension beyond it's physical register size (e.g. <= 4 gig).

An important thing to consider is that programs are designed to operate within it's address space. The larger the address space, the more advanced a solution can be programmed. In the 16-bit constrained world, for example, you'd have to artificially break a problem down into 64/32k chunks. In the 4 gig world, you can't treat arbitrarily large data sets; you have to worry about overflow for things like file generation, compressors.. pkzip can't backup your whole hard drive because it integer overflows after 4 gig, etc. More and more, we're hitting the 4 gig limit, and program designers say that's the user's problem; they don't bother breaking up their application into nice and neat 4 gig chunks because 99% of the time their applications won't hit that boundry.

By going to a 64bit space, developers can once again safely ignore the possibility of their application being used on ever larger data sets. No disk drives currently exist that would require >64 bit address spaces within a backup tool. It opens up a whole new avenue of uses for simpler programs.

-----------

In summation, bit-size does not strictly limit the largest number a CPU can natively achieve, nor does it limit the max memory size. However, it does facilitate efficient access of larger number-spaces. That larger number-space comes at a cost of CPU complexity/cost/ and even performance when 99% of operations don't warrent the extra size.. Still, as more and more common tasks cause us to run into the 4 gig limit, we have a choice.. Either program like we did on the 8086 and other 8/16/20/24 bit archetectures, manually segmenting the data-space into discontiguous chunks, or we move to platforms that natively give us headroom.

Re:news

[maraist]

Shouldn't 16-bit chips be enough because as we all know 64k should be enough for everybody.

Cute, but just fyi, it was 640K, and that wasn't the limit of the CPU, it was a choice of where to end the user-memory space and where to begin the driver memory space.

See posting for details of why the 16bit x86 bit chip could do more than 64K.

Re:news

[maraist]

Well said, but it's more than just memory spaces, it's the more abstract concept of address spaces. For example, hard-disk sector numbering, or any resource enumeration. It dramatically simplies coding for such resources. Think of the number of penneys in the stock market. This number is in the trillions, so a nice 64bit int would be very nice (though not required as you suggest).

Good lord...

[Prince_Ali]

A full GHz behind Intel? Do you judge cars based solely on peak RPM?

Re:1Ghz.

[Suppafly]

I'm sure they'll spin the 64-bit thing as being 'better' just like they've convinced their loyal followers that the mhz-myth makes an 800mhz G4 perform like a 2+ Mhz Athlon or Intel processor. By the time they even finish developing this 1.8ghz chip, those of us using 32bit chips will be chuggling along at 4ghz or so and waiting for the 5ghz on the horizon.

Benefits? Depends what you do with your computer.

[WittyName]

Many people doing CAD, circuit simulation, or editing large images need more than 4 gigs of ram now. 4 gigs is all you can get with 32 bits. On intel, using evil segments, you can use 36 bit. Win2k Enterprise does this...

Also, do not forget about Moore's Law. CPU's keep getting faster. Problem is hard disks are not. So more RAM for caching will be the solution.

Checking pricewatch I see that 2 gig pc100 dimms are less than $500 each.

Damn fine

[kitzilla]

Good to see Apple back out on the cutting edge, where it belongs. 64-bit PPC architecture with marketable clock speed and OS X 10.2: holy smokes! Get to the back of the bus, Microsoft. Take your Crayola XP desktop with you.

I assume one of the Linux PPC distros will be on board with the new chip, once it's on the street. Fun for the whole family.

I can see the mac commercial now...

[Prince_Ali]

I was like... you know... posting a flame on slashdot while logged in... and then beep... and I was modded to -1... so nobody could see my post. So now I log in as an AC... because mods don't want to waste their points on me. AC Swith.

1.8ghz in 2003?

[autopr0n]

Hrm, intel/AMD will be at what then, 4ghz? :P

64 bit is nice, but I doubt the chip will be more powerful then an x86 chip at twice speed.

Keep in mind that 64 bit chips do not simply work at twice the speed that 32 bit chips do, unless they are working on 64 bit integer numbers (in which case, they will actually work faster then 2x the speed of a 32 bit chip). Unlike the move from 16 bit to 32 bit, where 16 bit integers (either -32k to 32k or 0 64k values) were to small for lots of work, especially work with memory addresses on machines with >64k of ram :P

Nowadays, most CPUs (including x86) have 64bit floating point coprocessors to handle most mathematical code, so 64bit CPUs won't give you much of an improvement there either.

on machines with >4gb of ram, it will be a big improvement, but with advances in virtual memory it won't be as much of an advance, since programs can work in their own 4gig memory space on systems with more then 4 gigs of ram, and the virtual memory hardware can use more then 32 bits for mapping addresses.

Anyone, one only has to look at the difference between a Nintendo 64 (64 bit CPU) and a PC (32bit CPU) to see that CPU speed (and graphics accelerators!) has a much greater impact on performance then the bit width of the CPU.

Re:1.8ghz in 2003?

[Anonymous Coward]

64 bit is nice, but I doubt the chip will be more powerful then an x86 chip at twice speed.

Err... get your facts straight.

For floating point, IBM's Power4 chips are currently faster than Intel x86 chips running at more than 2.5 times the clock speed.
Case in point: SPECfp2000.

Removing duplicates, here's the list:

1. Alpha 21264C at 1250MHz
2. Itanium2 at 1000MHz
3. POWER4 at 1300MHz
4. SPARC64 V at 1350MHz
5. POWER4 at 1100MHz
6. Alpha 21264C at 1224MHz
7. Alpha 21264C at 1000MHz
8. Pentium 4 at 2.8 GHz
9. Pentium 4 at 2.66 GHz
10. Pentium 4 at 2.53 GHz

Re:1.8ghz in 2003?

[styrotech]

Yeah, but for this new desktop chip IBM is stripping out the dual cores and huge caches that make the Power4 such a powerful beast. The standard Power4 is too large, power hungry and expensive to be a desktop chip.

I'm pretty sure it will be a fast chip don't get me wrong, and I'm really looking forward to new Apples and IBM Linux workstations using this chip. But at the same clockspeed, I'm pretty sure the Power4 would kick the ass of this new chip at SPEC benchmarks.

I (like the poster you replied to) would be pleasantly surprised if the new chip was more than 2x as fast as similarly clocked x86 chip (ie an Athlon 2200+ at 1.8GHz). I don't expect it would be though.

Re:1.8ghz in 2003?

[Best_Username_Ever]

1. Alpha 21264C at 1250MHz
2. Itanium2 at 1000MHz
3. POWER4 at 1300MHz
4. SPARC64 V at 1350MHz
5. POWER4 at 1100MHz
6. Alpha 21264C at 1224MHz
7. Alpha 21264C at 1000MHz
8. Pentium 4 at 2.8 GHz
9. Pentium 4 at 2.66 GHz
10. Pentium 4 at 2.53 GHz

IBM's Power4 chips are currently faster than Intel x86 chips...

You seem to have deliberately ignored the superiority of the Alpha chip in your assessment. Hmm that sounds familiar ... you don't work for Compaq/hp do you?

Re:1.8ghz in 2003?

[karlm]

64 bit is nice, but I doubt the chip will be more powerful then an x86 chip at twice speed.

As others have pointed out, the POWER4 1.1 GHz and 1.3 GHz beat 2.8 GHz P4s in floating point. You may not know that in some integer tests, G4s spank Athlons. For instance, from the distibuted.net rc5-64 finishing announcement:

Our peak rate of 270,147,024 kkeys/sec is equivalent to 32,504 800MHz Apple PowerBook G4 laptops or 45,998 2GHz AMD Athlon XP machines or (to use some rc5-56 numbers) nearly a half million Pentium Pro 200s.

If those numbers are accurate, a mobile G4 at 800 MHz is 1.42 times as fast as a 2 GHz Athlon XP at rc5-56 encryption. Clock-for-clock the mobile G4 would then be 3.54 times as fast as an Athlon XP when doing rc5-56 encryption. The workin set is very small, so caches didn't come into play. However, you can get a G4 box with 2 MB L3 cache per CPU.

Don't get me wrong, I'm glad I have my trusty Intell box. However, give credit where credit is due. IBM/Apple/Motorolla designed one heck of a CPU family. The POWER4 chip performs almost as well as the Alpha, but doesn't double as a space heater and is very easily virtualizable (which is important for os390).

Re:1.8ghz in 2003?

[Perdo]

Exactly...

In other news, AMD is expected to release a 2.5 Ghz, x86-64 bit processor.

My other thought on this:

If you want something done right, do it yourself. Apple has not done that since Steve Wozniak left.

Btw, next time you need a monitor, or even a full on computer, let me know. There is no sense in letting your site drop when you have fans that are gearheads.

Re:1.8ghz in 2003?

[Artifex]

For floating point, IBM's Power4 chips are currently faster than Intel x86 chips running at more than 2.5 times the clock speed.
Case in point: SPECfp2000.

And what would the list look like if Athlon XPs/MPs were added to the list? This is a very biased list; it seems to be full of just commercial servers.

Re:1.8ghz in 2003?

[Toraz Chryx]

" But at the same clockspeed, I'm pretty sure the Power4 would kick the ass of this new chip at SPEC benchmarks."

Think is, the GPUL will be simpler (no second core), and manufactured on a smaller process, so it's clockspeed heatroom will likely be a fair bit higher than the POWER4s by my reckoning (whatever that's worth... probably not much :))

Re:1.8ghz in 2003?

[be-fan]

Actually, the RC5 test is a famous example of a misleading benchmark. The AltiVec unit in the G4 has a vector permute unit that is very handy for stuff like crypto but little else. The RC5 benchmark is specifically coded to use this unit. It's not a very good indicator of overall performance. As for PPC (discounting the POWER series), I've never liked it very much at all. It never had the insane multi-proc system architecture of a SPARC or MIPS machine or the pure CPU power of an Alpha. In the end, it was just fairly low-end RISC with good power consumption. Even an individual POWER-4 does't look too shiny next to an Alpha or Itanium2, especially given the insane amount of cache (128MB!) that they were using in the SPEC benchmarks.

PS> A Power4 puts out about 125 watts, essentially the same as the 130 watts put out by the most power-hungry Alphas.

Re:1.8ghz in 2003?

[be-fan]

Where do you get twice the speed? Do you mean twice the _clock speed_? Clock speeds really, really, absolutley, do not determine speed or performance.
>>>>>
CPU Performance = IPC * Clocks_Per_Sec.
Clock speed is fully one half of the performance equation, no matter what Apple tells you. It's a simple multiplication. If you can get twice the IPC running the same code, then you can beat a 2x clock speed disadvantage. If you can't (and a G4 can't) you can't. (Note, this is CPU performance only. It's the system designer's responsibility to surround a fast CPU with good memory subsystems, which AMD and Intel do, and so far Apple does not).

Did you know that a P4 takes 20 clock cycles to perform a multiply?
>>>>
Did you know that the G4+ takes 7 clock cycles to do the same? Actually, both are simplifications. Actual instruction latency charts are published on both Motorola's and Intel's website, I suggest you read them. Yes, it takes a P4 around 20 clocks to do one multiply. If you're doing one multiply per program, then a P4 will be a lot slower. But thanks to something called pipelining (read about it, try ArsTechnica) a P4 can have 20 multiply instructions "in the pipe" at once while a G4 can have 7 "in the pipe" at once.

You can chop up your instructions as much as you want, and increase the clock to hell, but not change performance at all.
>>>>>>>>
Um, a P4 at 100 GHz, even if it took 20 clocks per multiply would get about 5 billion multiplies per second. A G4 at 1 GHz, even if it took 1 clock per multiply, could only get 1 billion per second. Clock speed does matter. In fact, it's a linear factor!

The chip IBM is making is a mips based chip, and takes fewer cycles to perform all its instructions.
>>>>>>>
I think you mean "RISC" chip.

It also has a _ton_ more registers, which means you can perform significant operations without going to or from memory.
>>>>>>
Actually, a G4 has 32 general purpose integer registers, and 16 rename registers (48 total) while the P4 has 8 general purpose integer registers mapped to 128 entry internal register file (128 total). The G4 has the advantage of more registers directly visible to the compiler, but that's a code optimization issue, not so much a data storage issue.

Reading or writing a number to memory is about 100 times slower than an arithmatic instruction.
>>>>>>
Not quite that much. Again, I suggest you read some actual timings :)

But to use those coprocessors,
>>>>
x86 FPUs have been integrated since the 486. The MMX and SSE/SSE2 units have always been integrated. They are just another execution unit, like the integer or AGR units.

you have to go into modes like mmx. And bolted on extra instructions like mmx have restrictions on them, like not being to do mmx and floating point math at the same time.
>>>>>
Nobody uses MMX anymore :) The FPU instruction set isn't "bolted-on" an is fully independent of the integer unit. The SSE/SSE2 units are also fully independent. Of course, that's the external appearence. The internal execution units of the processor look different, even in a G4. The Altivec unit is actually 5 totally different units, while the P4 FPU and SSE units are actually one integrated unit. Of course, these are implementation details that don't really make a difference unless you're doing multiple types of floating point operations at once. In the common case of doing a bunch of the same operation on a bunch of data, they're equivilent.

For the future, 64-bit is the way to go, and x86 is not.
>>>>
But what if you have a 64-bit x86? What'll happen then? Ah, my reality is being distorted! My puny mind... my puny mind!

Re:1.8ghz in 2003?

[be-fan]

Um, that doesn't make any sense. The SSE2 unit is also good (usually better than Altivec since the P4 has 3x the memory bandwidth of the G4) at audio, video, and Photoshop. It's just not as good at RC5 because it lacks a permute unit. Quoting RC5 scores showing the G4 beating a P4 or Athlon are thus meaningless unless you're doing a lot of RC5 crunching.

Apple has never changed their mind before

[strictnein]

"The introduction of this chip should put to rest any speculation that Apple is moving to an Intel platform."

Especially since Apple has never changed their mind before, about anything major.

Intel Platform

[vlad_petric]

The introduction of this chip should put to rest any speculation that Apple is moving to an Intel platform.

C'mon ... Mac OS/X for x86 doesn't really have much to do with Intel, but with Microsoft. A Mac OS/X running on Intel hardware is nothing but Microsoft's worst nightmare in terms of what it can do to its market. So it's just a trumpcard in negotiations with Microsoft (i.e. "If you stop Office/Mac, we drop the atomi^M^M^M^M^M Mac OS/X for x86").

The Raven

Re:Intel Platform

[TheAncientHacker]

Guess people have forgotten ASCII. Or did you really mean:

"If you stop Office/Mac, we drop the atomi

Mac OS/X for x86").

(Just guessing you meant ^H instead of ^M)

All over Mac websites.

[mikedaisey]

This is just confirmation of threads folks on appleinsider.com and other mac websites have been following for quite some time.

Based on all the rumor and innuendo that is swirling around for the last 3 months, it is highly likely that this is indeed the chip Apple will be migrating to, and that it will be out at some point in 2003...probably the fall, though opinions on that vary.

At the Microprocessor Forum on the 15th (Tuesday) IBM will be giving a long talk on the nature of this chip, and that's the talk Mac enthusiasts have been waiting for to see what's what with the particulars...so stay tund for that to receive more information than the Forbes article had.

Re:Already are 64 bit

[damiam]

There are NO 64bit consumer processors currently available. I'm typing this on a dual Athlon MP 2200+, and it is most definately 32bit. The Itanium is 64bit, and the Claw/Sledgehammer processors will be, but neither is currently available for consumer use.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Why not?

[autopr0n]

Can you give us an example of any car that is faster then a car with an engine where the peak RPM is more then 2.2 times as high?

Re:Why not?

[Vader82]

The Didge Viper revs to less than 6krpm.
What can beat it? Normal street cars cant. Take your 1.8L super-big-exhaust-turbo civic/integra/prelude/whatever and see what happens.

YOU GET SMOKED!

Why? Because the viper has mad displacement. More displacement means more energy per revolution, aka more computation per clock, ala AMD or the P3. P4 is more like the rice burner, revving to insane RPM but generally not doing much per revoltion. It only gets "fast" because it revs so high.

Re:Why not?

[Alan Partridge]

a Caterham Superlight R will destroyyou're bloated Viper. Engine displacement? 2litres.

U R A fool.

Re:Why not?

[JimBobJoe]

Let's talk about faster in the normal two ways...0 to 60mph performance, and the quarter mile (in what time and at what max speed will a car, from a stop, travel one quarter of a mile.)

When we talk about engine power, we usually talk about horsepower, and you'll see many engines that have lots of horsepower--Honda, an oustanding engine maker, makes some small displacement engines with lots of horsepower. Horsepower though is simply the energy capacity of the engine--the higher horsepower a car has, the more weight it can pull at higher speeds. Even with a car heavily laden, it would have to take a very high speed before you start seeing the advantages of an engine with 100 horses versus 150 horses.

The thing that makes a car fast is torque. Your small displacement Honda engines aren't so good with torque--in fact, the torque comes at a very high end of the rpm scale (like...in the 6000-8000 rpm range.) That means you have to rev them up really high in order to get the maximum torque--and it's torque that actually accelerates the weight of the car (as opposed to just moving it.)

People talk about the viper..but that engine is so different, it's hard to compare. How about Saab turbocharged engines...for instance, the 2.3 liter 4 cylinder used in the 9-5 Aero--a small engine, with a powerful turbocharger, it makes 250 lb-ft worth of torque, which is quite a lot, and is actually pretty close to what the Acura NSX makes torque wise...however, the torque curve for the Saab engine makes maximum torque all the way from 2000RPM-4500RPM which means that all that wonderful torque is available to you pretty much no matter what the engine is doing (whereas even with an NSX...the torque is not available until the 4000 range, meaning you are always spinning the engine faster--sure it's fun, but that doesn't make the car any faster.)

If anything, if you want the car to be quantifiably faster, and not just faster in the sense of feeling faster, you want your maximum torque to come out as low as possible on the rpms. Large displacement engines, turbocharged engines, and to a certain extent, diesel engines, all have this.

Crutchety sh*tty?

[yerricde]

Linux == GNU, which is not crutchety shitty UN*X.

I don't know about you, but some people define "crutchety shitty" in terms of a monolithic kernel design. (I don't; monolithic kernels have their uses.) Linux is based on the same sort of monolithic kernel design as BSD and UNIX® systems, and the GNU/Linux operating system is based on Linux. Thus, some consider GNU/Linux "crutchety shitty" in that sense. HURD, on the other hand, runs on top of the Mach microkernel (though it'll be ported to the faster L4 microkernel before 1.0). Darwin (the open-source core on which the proprietary Mac OS X GUI runs) is essentially FreeBSD ported to Mac hardware, running on top of Mach.

Re:1Ghz.

[autopr0n]

I'm sure they'll spin the 64-bit thing as being 'better' just like they've convinced their loyal followers that the mhz-myth makes an 800mhz G4 perform like a 2+ Mhz Athlon or Intel processor.

Well, I would hope so, that's almost 400 times as fast :P

haha

[autopr0n]

Actualy the limits are 4 gigabytes, and 16 exabytes (2^32, and 2^64) respectively. However, there are ways to get around this limit (after all, there were 16 bit machines with more then 64k of ram, and machines today with more then 4 gigs running on 32 bits)

Oooh 64 bits!

[khuber]

Welcome to 1992 (SGI/MIPS) or 1994 (Sun).

I'd rather have a Power4 (which is available now of course) than wait a year for a crappy stripped Power4.

-Kevin

Re:Oooh 64 bits!

[Toraz Chryx]

The problem with that is, a .18 POWER4 is totally unfeasible for a desktop machine.

in addition, this stripped down POWER4 should clock a LOT higher due to the smaller process, and being a less complex chip. (and it'll use one hell of a lot less power)

It's just like the 604e verses G3 all over again, except the PPC7455's replacement might will be the brute force implementation :)

Re:Oooh 64 bits!

[caveat]

here's the cheapest POWER4 system i can find - $12,495. everybody bitches about how much macs cost, but i doubt it's going to be more than $4000-4500 for one with the new PowerPC. do i even have to make a point?

Re:Oooh 64 bits!

[caveat]

ultimately, yes it is vastly superior to the mac. but for anything i'm going to realistically need to do with my computer, the mac is going to do just fine.
of course if apple gets their shit together and builds a halfway decent system around these chips, the ibm might not be /that/ much better than the macs. but that's a pretty big if.

less then $500?

[autopr0n]

Checking pricewatch I see that 2 gig pc100 dimms are less than $500 each.

Or you could get four 512 meg sims for $25 each :P

Re:less then $500?

[WittyName]

This is true, but show me a motherboard for less than $500 with more than 4 DIMM slots. Probably going to need another memory controller, or a bridge chip (with some latency).

Even the 1 giggers are much cheaper, but 4 of them does not present an addressing issue.

Of course the 2 giggers are probably double sided, and you probably can not run three of them anyway..

Re:less then $500?

[TheGreek]

No. He's speaking about motherboards with more than four slots.

Anyone planning on telling the developers?

[hayden]

If Apple is planning on moving to a 64-bit architecture then they'll need to start educating their developers real soon now. If everything is coded properly then there's no problem. In the real world pointers get assumed to be int size or int is assumed to be 32-bits. Also word alignment becomes an issue.

This is not something they should just spring on their developers.

Re:Anyone planning on telling the developers?

[jimbolaya]

Most of that burden will be handled by the compiler. A few developers will need to be concerned, but not the majority. Apple maintains a version of gcc, and I am certain if there is any truth to this rumor, that they are also working with Metrowerks to make sure their compilers will support the new chip (which raises all sorts of interesting prospects, since Motorola owns Metrowerks).

Re:Anyone planning on telling the developers?

[Wesley Felter]

I'm going to disagree with all the other replies and say that virtually all apps will remain 32-bit, so developers won't need to do anything. After all, that's how things work on Solaris, AIX, and Linux, so why should OS X be different?

Re:Already are 64 bit

[athlon02]

well technically x86 processors since the PPro have 36bit addressing.

Re:Already are 64 bit

[Sivar]

36 != 64, but just because CPUs with Intel's PAE can address 64GB of RAM (2^36 = 64GB) does not make them 36-bit processors. They can only actually address 4GB at any one time, which is why any single process can use no more than 4GB of RAM (actually, 3.5GB with Linux and 3GB with Windows)

Re:lol

[khuber]

No, the PPC has been 32 bits for its lifespan.

The G5 vaporchip is supposed to be essentially a 64 bit G4.

-Kevin

What's an instruction?

[yerricde]

It's the efficiency of the processor that matters, which is measured in IPC, the "instructions per cycle" that it can execute.

Be careful. Some architectures require more instructions to do the same thing. For instance, on 6502 or x86, you can load an integer from memory and add it to a register in one instruction, whereas on ppc, arm, or mips, this takes two.

Re:What's an instruction?

[the_2nd_coming]

yes, however, that one instruction might take 2 cycles :-)

old cisc procs worked like that....sure your assembly was fewer instructions than a risc, however, the cisc proc had to run more cycles per Instruction because at the machine level, it still could only move so many bits in and out of registers so many times in one cycle.

that is why risc was invented, having one or 2 operations per instruction gave the programmer much better ability to squeeze as much out of a cycle as he or she could....think of a cisc instruction as a brawd sword and a risc instruction as a scalple.

now, Intel has realised that a mixture of cisc and risc is good. some situations, it takes you just as many cycles to execute a desired outcome in cisc and risc, so it would be easier on the programmer to use a cisc instruction rather than a group of risc instruction, hence you get the fine tuneability of risc, but the lower impact on the programmer of cisc.

64-bit != speed

[Sivar]

At least, not necessarily.
Just because these new chips will be 64-bit does not mean they will be fast. 64-bit processors require more cache and main memory (because all of the memory pointers are 64-bits rather than 32) and cannot necessarily do most common computations faster.

Say you are doing a multiply operation. Very common. The numbers are, say, 500,000 and 42. Both of those numbers are occupying a full 64-bit register, even though they could be stored in 32-bit registers easily. The multiply operation still takes the same amound of time to complete, because the register size doesn't matter unless the numbers cannot fit.

Now, software doing math with numbers greater than ~4.3 billion (what will fit in a 32-bit register) will be able to perform those calculations more quickly, but rarely are such large numbers used. Certain operations, such as encryption and advanced mathematics, will be able to calculate up to 4 times faster, but again, this will not matter much for most applications (though perhaps folding@home and SETI@home will see a speed up).

Additionally, the increased code size caused by the larger memory pointers (about 5%) can actually slow code, because the cache hit rate will drop by that same 5%.

The Opteron processor's early benchmarks (which show that it simply kicks ass) are misleading because the Opteron has other tweaks to improve speed: Twice as many registers, an integrated low-latency memory controller, probably a better branch prediction unit, and a few other minor tweaks. The speed increase is not caused by the larger registers.

That said, IBM makes some very nice processors, and if they incorporate many of their ideas into this new CPU, Apple will hopefully be very competitive. (though those 1.8GHz better have a great IPC to compete with the Clawhammer and 3+GHz P4!)

64-bits is very nice in that Apples can now address >4GB RAM per process, but few people are finding the 4GB memory barrier to be all that restrictive, less professionals working on very high-end tasks such as gargantuan 3D models with staggeringly huge textures.
I'm all for Apple every since OSX was released, but let's not succumb to the 64-bit myth anymore than we should the MHz myth.

Re:64-bit != speed

[Sivar]

This is a feature of very few processors, and is considered "bad"(tm) and "Not a Good Thing"(tm) by many microprocessor designers. Why that is, I have never heard a satisfactory answer for. Now, the x86 architecture allows access to partial registers by addressing, say, "ah" rather "ax" or "eax" (which are 8, 16, and 32 bits respectively). AFAIK, the PowerPC architecture does not directly support the use of segmented registers, so you would have to use dirty hacks like verious bitwise operations (clearing part of a register with AND, using the remaining part in math, putting the result (after a bitshift) into the other half of the register, etc. Nasty. No particular advantage, either.
Of course, I have never programmed the PowerPC in assembler so what do I know?

Re:64-bit?

[jared_earle]

"Further proof that OS-X is NOT an unix OS is the fact that you can't backup HFS+ files using standard GNU tar."

GNU is not UNIX.

"Also, OS-X doesn't include simple items such as /etc/fstab and so forth."

fstab does not a UNIX make. Besides, fstab is there and useable if you want. NetInfo is used as first choice only.

OSX is as much a UNIX as Linux is, if you wish to be pedantic. Both use GNU/BSD tools on top of a kernel.

Why bother bickering over which is the most UNIX-like or UNIX-based? This isn't a pissing contest.

Uh already 64bits, it's the 1.8Ghz that is new

[gelfling]

Sorry but PPC is already 64b. The 1.8Ghz is the new part.

Re:Uh already 64bits, it's the 1.8Ghz that is new

[Alex_Ionescu]

As far as I know, read, and seen, the PPC is a 32-bit CPU. I know it has some "Velocity Engine" in the G3 or G4 Macs that's supposedly "128-bit", but the PPC chip itself is 32-bit.
If anyone would like to correct me, please go ahead.

Re:Uh already 64bits, it's the 1.8Ghz that is new

[JohnG]

I can't find reference to it on their site now, but I could have sworn there was a 64-bit implementation of the PowerPC already also. Not the ones used in the Macs mind you. (Those are Motorola anyway).

Re:Uh already 64bits, it's the 1.8Ghz that is new

[gerardrj]

Yes, PARTS of the PPC are 64bit. Parts of it (AltiVec) are 128bit. But the connections going out of to the machine are not 64 bit yet. This change will allow the entire chip to operate at 64bitness, and also to remain completely compatible with 32bit code (according to the PPC design plans)

Re:lol

[scrod]

All current PowerPC processors have been 32-bit, but the PowerPC ISA has always been 64-bit. That's why a 64-bit PowerPC processor will be able to run all 32-bit PPC binaries at native speed.

Re:64-bit?

[mrjohnson]

Uh... the Mac's powerpc chips are 32 bit, but you could run Linux on it. :-)

You clearly flunked physics

[Rui del-Negro]

The melting point of steel is about 1500C.

The Athlon XP uses 12% more power than the P4, and hence produces 12% more heat. The problem with Athlons is that (unlike the P4) they don't include an integrated head spreader, so all heat is concentrated on a much smaller area. The Hammer / Opteron does have an IHS, and will probably dissipate between 60 and 80 Watts of heat. That is quite good for a 2.5 GHz, 64-bit chip (compare with 135 Watts for Intel's Itanium 2).

Re:You clearly flunked physics

[pmz]

(compare with 135 Watts for Intel's Itanium 2)

Sun's 1.2GHz UltraSPARC III Cu runs at 50 watts. Their 650MHz UltraSPARC IIi runs at less than 18 watts.

For the same power consumption, a person can run two to six times as many non-Itanium 64-bit processors. Thus, any performance benefits of the Itanium for highly-parallel computation diminish in importance. It seems Intel can compete only on up-front cost, but the competition can surely respond to this, too.

Re:Thank God!

[khuber]

The stupid "Megahertz Myth" has one year to live.

Of course Pentium 4s totally smoke G4s. A Pentium 4 2.53 is three times faster than a G4 867 according to specint2000/specfp2000. Amazingly, that three times performance difference is paired with a three times megahertz difference.

System specint2000/specfp2000
AMD Athlon XP 2100+ 1733
720/613
Intel Pentium III 1133
461/320
Intel Pentium 4 2533
882/861
Intel Itanium 800
314/645
Intel Itanium 2 1000
~700/~1350
IBM POWER4 1300
804/1202
Sun UltraSPARC III 1050
537/701

Apple G4 867
257/154

What were you saying about the megahertz myth? It doesn't apply to the slow G4?

-Kevin

Re:Opteron will be 64 bit and over 2 GHz

[Rui del-Negro]

The Opteron is probably still a long way off. The first chips based on the Hammer will be called Athlon Something and will have a single core (even the Opteron is likely to have a single core, although there is talk of a dual-core design). The "rating" of the first 64-bit Athlons will probably be around 3400+, running at a little over 2 GHz.

Seeing the number of times the Hammer (and the Itanic) were delayed, I wonder when this new IBM chip will actually see the light of day...

RMN
~~~

Problems with the Itanium

[computerchris]

I work at the University of Colorado and we have a research lab of Itanium machines that are used to study "Compilation Issues on Itanium Architecture". They are currently doing research on how to get different programs to compile under the new architecture. The current problem is they can't even get the gcc compiler to work correctly, so don't hold your breath waiting for an Intel 64 bit solution.

Re:Problems with the Itanium

[mpsmps]

The gcc compiler is quite horrible on Itanium as the Itanium architecture does not map well onto the gcc internal abstractions. However, the Intel compiler has very good performance on Itanium. We found as much as 10 times better performance for the Intel compiler on our in-house benchmarks. This demonstrates at least that it is possible to produce good compilers for Itanium. God knows when gcc will be one of them, though.

Re:Already are 64 bit

[Nutello]

The Linux Agenda VR3, to name just one example, is a PDA that uses a "64bit consumer processor", NEC's VR41xx. That's a MIPS64 CPU, although the firmware
runs it in 32bit mode. The same processor is used in many MIPS-based WindowsCE PDAs, like the Casio Cassiopeia. Other 64bit consumer processors are Toshiba's TX-49 (another MIPS64) and SuperH's new
SH-5, which has yet to ship.

Re:64-bit?

[ahknight]

Lastly, why would you want to buy your hardware and software from a specific vendor? Sure it might work better, but is that level of integration really worth the money (for most of us at least.)

Well, let's see, pay more and it works or pay less and babysit it ... gee, what's my time worth again? More than about $3,000 once every five years or so, for sure. (Yes, I said five years. I'm on a three-year-old machine now any my previous two Macs held up for five years each before they were just plain obsolete.)

Isn't this the same reason most of us are moving away from Sun to begin with?

No, it's because they cost $40k each just for the right to win the pissing contest with the ISP next door. EVERY situation I've seen a large Sun used it could have been handled with Linux on a couple of Xeons or on an Xserve and MOSXS. There's no compelling reason to use a Sun anymore other than to win the pissing contest with the sysadmins of the competitor (what competitors are left, at least).

They dont make geeks like they used to...

[Rui del-Negro]

I think its time Apple start calling anything based on the power PC architecture twice its clock speed, and anyhting thats both powerPC and 64 bits at 4 times its clock speed. After all, the processor does twice as much as a 32 bit processor in a given clock.

No it does not. Do you think bits are some sort of speed measurement? Like, "bits per second"? 64-bit means the chip has 64-bit registers. Basically what that means is it can work with larger numbers and - more importantly - larger memory addresses. It will take exactly the same time as a 32-bit chip to do a specific operation (ex., add two bytes, jump to a new address in a program, etc.). The speed at which operations are done depends on the chip's design and clock speed.

So calling this new PowerPC that runs at "1.8GHz" a "7.4GHz PowerPC" is just as legitimate as Intel calling their pentiums 2.8GHz, etc. (Cause they don't really actually run at 2.8GHz. That's just one clock rate that exists at some point on the processor. Processor clocking is far more complicated than that.)

What? Of course they run at 2.8 GHz. That's the clock speed; they can't help but run at 2.8 GHz. Even if they have absolutely nothing to do, they still go through 2.8 billion cycles each second. There are clockless chips (that work at a variable speed), but the P4 is not one of them.

RMN
~~~

Re:They dont make geeks like they used to...

[Rui del-Negro]

Yes, they did that to be able to do the operations in 1 clock cycle.

I've heard some people speculate that the Hammer will use a similar trick on the instruction decoder: run it at twice the clock speed so that it keeps the execution units fed. Don't know if there's any truth in it, though. Basically that's what Intel is trying to do with hyperthreading (although the approaches are different).

One thing AMD has already confirmed they've improved is the prefetch, which is much better on the XP than on the old Athlons, but is still not quite as good as the P4's. They can probably get a good 10-15% of performance there. Add the integrated memory controller, increase the FSB and cache, and you have something that'll probably be about 25% faster than current Athlons for the same clock speed (on 32-bit code). That would mean a 2 GHz Hammer would probably have a "rating" around 3200+.

By the time the Hammer is released, the P4 will probably be hitting 3.2 GHz, so I suspect AMD will not get a big lead over Intel (at least in the mainstream market, where 64-bit code won't be very important). But since neither AMD nor Intel are selling their top chips anyway, I don't think that will be very relevant. What AMD really wants is big corporate clients (like Intel has) for their low- and mid-range chips.

RMN
~~~

Re:They dont make geeks like they used to...

[Rui del-Negro]

No real reason why they shouldn't; 2 GHz is actually rather conservative. The new chip is very similar to the current Thoroughbred, and those can run at 2.2 GHz even without an IHS and with a regular (bad) cooler. They can be taken up to about 2.4 GHz with good air cooling. Add an integrated heat spreader and I suspect even an Athlon XP could be pushed to 2.7 GHz or so. The problem is, there's virtually no market for it; even the 2400+ (2 GHz) models are selling poorly.

AMD has been having some problems with SOI manufacturing but those will probably be solved by the end of the year.

RMN
~~~

Re:They dont make geeks like they used to...

[maraist]

Superscalar performance is improved by using the larger registers to execute more instructions in parallel.

You're assuming that the 64bit registers equates to 2 32bit or 4 16bit. These are independent concepts. The PowerPC's Altivec (sp?) and Intel's SSE (and AMD's 3DNow) do what you're talking about, and this was all done with 32bit Integer cores. They simply added new specialized registers, or remapped existing registers.

Let's be clear here, the 64bit refers to the integer core. 64bit floating point registers have been here for virtually forever. Intel even has 80bit, and other RISC platforms tout 128bit floating point, but these provide only precision, NOT performance enhancements. (float v.s. double v.s. long double).

The only thing benifit 64bit provides is faster 64bit arithemetic (long int), which is essential for >4Gig contiguous memory spaces, but also for other types of calculations. The reason I say faster is because 64bit int-arithematic is possible with smaller registers, but only via emulation (though it's not as bad as you'd suspect since there's hardware support such as add-with-carry).

Re:They dont make geeks like they used to...

[Rui del-Negro]

Not to be pedantic, but with certain applications, certain 64-bit architecutres actually provide shorter execution. Superscalar performance is improved by using the larger registers to execute more instructions in parallel.

The registers and the execution units are two separate things. A CPU's ability to execute instructions in parallel has nothing to do with the size of the registers or the memory addressing (which is what "64-bit CPU" means). It has to do with its internal design.

To benefit from 64-bit registers (or from new registers), software needs to be rewritten, and even then, not all software would benefit from it. A lot of operations only need 8 or 16 bits of data, and don't benefit the least bit from 64-bit registers.

This is because larger registers let you feed more data into the various processor components at a faster rate.

More data, yes (of course, if you have 64-bit registers, you must have 64-bit ALUs). Faster, no. The speed at which the data is fed depends on the clock cycle.

With some applications this makes little difference, but with things like signal processing or matrix operations that benefit from SIMD; speed boosts would certainly occur. This assumes that you have more ALUs or FPUs to feed in your 64-bit chip.

There's no reason to add more execution units since it's hard enough keeping the current ones fed.

SIMD can only be used in very special cases; it's not an answer to every problem, and again software needs to be rewritten to use it (and compiler support isn't exactly brilliant).

Besides, SIMD (Altivec / SSE2 / etc.) use separate registers, which are already 128-bit long in most architectures (ex., G4, P4). 64-bit CPUs are not going to change this; they're simply increasing the main register size (including memory addressing) and, in some cases (ex., x86-64), adding new general-purpose registers.

RMN
~~~

Re:They dont make geeks like they used to...

[Lars T.]

The double pumped ALU for easy instructions is running at twice clock-speed. The the complex integer instruction unit, which is infact also an ALU for mult/div/shift/etc. operations, doesn't (at least you wouldn't notice, because it takes up to three times as many cycles as the ALU in the P3). IOW doing multiplies (or shifts), the P4 still isn't as fast as the P3.

Re:They dont make geeks like they used to...

[BitGeek]

Of course they run at 2.8 GHz. That's the clock speed; they can't help but run at 2.8 GHz.

Its unfortunate that being a "geek" has become cool-- there are so many such as yourself who have taken on this label and use it to bash actual engineers.

A modern processor is not like the old days where they had a crystal that resonated at a given frequency to generate the clock. The modern processor uses a phased locked loop, and clocks various parts of the processor at DIFFERENT RATES.

It used to be the clock rate was the rate at which it accessed its internal buss. Well, are you really claiming that the buss for a pentium is 2.8GHz? Motorola continued to use this figure for a long while, after intel started listing the clock rate as the highest clock that exists anywhere on the chip.

Furthermore, the clock rate no longer measures the rate at which instructions are issued-- this varies as the chip executes code. Cach flushes and pipeline flushes, branch prediction failures, and the fact that cisc instructions take variable numbers of clock cycles to execute make the clock rate as a measurement of speed (on cisc architectures like the pentium) pretty pointless. Nevermind that the pentium architecture has an embedded 386 processors on board to handle the non-pentium instructions for backwards compatibility-- depending on whats happening between the two processors (all on the same chip) you never know whether the instruction that was just executed was really going to be used (due to out of order execution.)

The RISC architecture was designed to get around this by making every instruction execute in a single clock. so you can more easily parallelize your processing... thus its quite easy for a processor running at 1GHz to be 4 times as effective as one at 2GHz (because it issues 8 instructions per clock and each one is far more likely to execute in a single clock.)

Intel already played fast and loose by redefining what the clock rate of a chip meant once. And the modern chips are so complicated that there really is no single actual clock value-- the external bus is at one clock rate, the various instruction units run at some fraction of the "clock rate" and the internal memory buss has yet another clock.

Don't insult someone's "geekiness" when you don't understand the basics of processor design. The CISC/RISC split occurred over 10 years ago. And while both camps have learned from each other and adopted technology where they can, the architectures are still VASTLY different-- making your straight on clock rate comparison about as smart as a the guy who says "But you see, it goes to 11!"

Re:They dont make geeks like they used to...

[BitGeek]

a P4 2.8 GHz does it at 2.8 GHz (with some parts operating at twice that speed, as was pointed out).


Gee, os it really isn't 2.8GHz? Its twice that speed in some places?

I think you just conceded my point that this number is a totally fabricated marketing term-- even you admit that some places don't run at 2.8GHz.

So, since two ALUs equal "twice the clock rate" then the current PowerPC G4 is an 8GHz chip.

Even if they ARE running at twice the clock rate, the clock rate is STILL IRRELEVANT because how much WORK can be done has very little to do with clock rate.

Clock rate is only relevant when comparing processors of EXACTLY the same design.

When you compare two architectures- intel to AMD or intel to Motorola, and talk about clock rate and performance, you're speaking out of your ass.

Clearly you don't.

[Rui del-Negro]

In that case they should also include an 8-bit chip, because the vast majority of values processed by any CPU is 8 bits long.

RMN
~~~

Re:1Ghz.

[Anonymous Coward]

I'm sure they'll spin the 64-bit thing as being 'better' just like they've convinced their loyal followers that the mhz-myth makes an 800mhz G4 perform like a 2+ Mhz Athlon or Intel processor.

Well, I would hope so, that's almost 400 times as fast :P

Actually a 2 Mhz (Megahertz) processor is millions of times faster than an 800 mhz (millihertz) processor. Nice try though. :P

ah, the ignorant have spoken..

[autopr0n]

Did you know that a P4 takes 20 clock cycles to perform a multiply?

Did you know that you are an idiot? the p4 has a 20 stage pipeline, which means the process of excecuting instructions is seperated into 20 peices, and the hardware used to do each one of those pecies works on part of a diffrent instruction at the same time. So while a multiply might take 20 clock cycles to come out of the other side of the CPU, if all you have is a program with one multiply instruction followed by a hlt or something.

Most programs, of course, have more then one instruction. With a 20 stage pipline one instruction takes 20 cycles to run, but you can also perform 19 other instructions along with it... depending on how many excicution units you have along with it.

The p4 has two ALUs, each running at twice the clock speed of the rest of the CPU. (in contrast, the athlon has 4 regular speed ALUs). So in actualy, you'd be able to run 80 or so instructions in that 20 clock cycles.

Integer multiplies are actualy performed by the floating point system, IIRC, rather then by the ALU, so they won't be as fast as addition and subtraction.

The chip IBM is making is a mips based chip, and takes fewer cycles to perform all its instructions. It also has a _ton_ more registers, which means you can perform significant operations without going to or from memory.

IBM is not making a mips chip, moron. They are making a Power PC chip. the p4 has only 8 general purpose 32 bit registers, but in addition has 8 80 bit floating point registers, 8 64bit integer SIMD registers and 8 128 bit floating point/vector SMID registers.

MIPS only has 32 general purpose registers, and although they can be used however you want, several of them are 'reserved' for the stack, and things like that. Also the first register is always zero, and you can't store anything in it. So in actuality, MIPS chips have fewer registers then Intel chips. PPC chips on the other hand do actually have more registers then Intel chips though, with 32 general-purpose registers, 32 floating (64 bit?) point registers, and 32 128 bit vector SMID registers.

This doesn't really help your argument, though: Reading or writing a number to memory is about 100 times slower than an arithmatic instruction.

it's true that reading from memory takes a long time, and that's why modern CPUs don't do it very often. They use these things called "caches" you know? The vast, vast majority of memory access doesn't actually need to hit ram.

But to use those coprocessors, you have to go into modes like mmx. And bolted on extra instructions like mmx have restrictions on them, like not being to do mmx and floating point math at the same time.

No, I was talking about using floating point math for integers larger then 32 bits, rather then splitting 64 bit ints up into 32 bit chunks and adding them with carry (which takes more then two instructions). MMX doesn't allow 64bit int math, as far as I know, but rather allows you to sacrifice floating-point math for accelerated 8, 16, and 32 bit math. It's always interesting in that Mac fans seem to think that Intel chips suddenly lost the ability to do integer math and floating point math at the same time when they gained MMX.

Anyway, that's really beside the point due to the fact that, as you can see, MMX no longer uses the floating-point registers.

For the future, 64-bit is the way to go, and x86 is not. I think one of these IBM processors will be the ideal linux machine. (It'll be low power too, so I won't need a hairdrier-loud fan like I do with my athlon :) )

since when are those separate things?

Might not hurt to learn a thing or two about how computers work before opening your mouth.

Re:ah, the ignorant have spoken..

[cartman]

You shouldn't insult the poster for being an ignorant moron, when your own knowledge of these issues is not adequate.

The p4 20-stage pipeline has to be flushed _whenever_ there is a branch misprediction. Since there is a branch every 6 instructions (on average), misprediction is not an uncommon scenario. An FP instruction followed by a branch directly afterward could very easily take 20 cycles.

The MIPS architecture has 32 general purpose registers and 32 64-bit FP registers (MIPS r4000 user's manual, pp 154). They _cannot_ be used "any way you want." Mips therefore has 64 registers, which is far more than x86. Even this is misleading however, because x86 converts instructions into micro-ops which have 128 GPRs mapped to the traditional 8 regs, but I digress..

Although cache enhances memory access speed, it is still quite slow compared to registers (often >25 cycles).

You should be more polite when responding to posts.

Re:ah, the ignorant have spoken..

[maraist]

having a 20 cycle multiply kills you if you have even one instruction dependent upon the result of the multiply.

Not true. You're thinking of 20 stages being for the raw operation, when in fact, only a few stages are dependent on the actual operation, the rest are for setup (I-decode, mem/reg fetch, data-transfer) and write-back. Thus if i2 depends on i1, then both will go through the i-decode and register fetch, and only a handful of double-pumped clock-ticks will be wasted waiting for the output of i1; i2 will immediately proceed as soon as the data is available. (wasting possibly 2 to 4 [double pumped] clock-ticks).

Now I'm not completely sure about the P4 internal design, but I've studied the MIPs architecture and it's definately possible to have zero delays (except for branch mispredictions and non-register memory-loads). The only real limitations are if the added complexity of having look-ahead multiplexors on the data-input lines slows the rest of the system down too much to warrant doing so.

Further, having 20 stages means you can have a faster clock. Thus if only 25% of your instructions are data-dependent to a greater degree then there are a number of stages between instructions (e.g. if there would be any ACTUAL internal blocking), but you're clocked 50% faster, then you've you'll always have faster operation. If however, the faster clock speed means that 50% of your instructions run faster (saving 25% of operations to slow memory loads / complex FPU operations), then you'll have a total throughput which is signficantly higher.

These are indeed opposing forces. Having fewer stages with fewer gates in each doing more efficient work with higher clock-rates is an ideal. But all-things-being-equal, (materials/innovation/instructions/etc), deeper pipes tend to produce higher throughput (to a point for a given technology). Intel obviously must have simulated various numbers of stages to determine a given optimal point given the current technology. Though their minds were most likely clouded by the MHZ myth's marketing possibilities.

Why does everyone presume...

[PythonOrRuby]

... that it'll be one or the other?

Right now Apple uses processors from IBM and Motorola. It isn't that hard to see the relationship just reversed if Motorola can't deliver a higher performance processor than IBM. IBM supplying the power, and Motorola working on low power, low heat 64 and 32-bit processors for the PowerBooks and all of the consumer machines.

If IBM flawlessly integrates Altivec compatibility with VMX, and given that Motorola's got quite a bit of Altivec experience, Apple could get the technology into the whole line.

Re:Why does everyone presume...

[terrymr]

Isn't the PowerPC a joint IBM / Motorola development anyway ?

Re:Why does everyone presume...

[PythonOrRuby]

Yes. The PowerPC was the result of the so-called "AIM"(Apple, IBM, Motorola) alliance.

heh...

[autopr0n]

Everything about IBM's Power4 processor is amazing. Amazing technology, amazing size (680 million transistors), amazing power requirements, amazing performance. And it's amazing that anything so complex can work at all. This beast has 5,200 pins on the package and consumes 500 watts (that's right, half a kilowatt) of power. Actually, Power4 is more than a processor, it's an entire neighborhood of processors. It's sold as a module comprising two processor cores per die, and four die per module, making eight 64-bit processors and 680 million transistors in one unit. Each individual die contains 174 millions transistors and measures a sun-blocking 400 mm2 in IBM's 0.18-micron 7-layer copper process.

8 CPUs stuck together, 1.33 times faster then a p4. And with only 12.36 times as many transistors! (And just 10 times as many interface pins, and power use!)

If IBM's 'scalling down' is more then by more then 25%, it'll be slower then intel. If it's by less then 95%, it'll be more expensive :P

Re:heh...

[pmz]

8 CPUs stuck together, 1.33 times faster then a p4.

Actually, the IBM SpecFP numbers are from using only one core on the package giving the core all the cache that is normally shared. So, it is not a case of 8 Power 4 CPUs beating one P4 CPU; rather, it is a case of one Power 4 CPU with oodles of cache beating one P4 CPU.

no

[autopr0n]

2^16 = 65536 = 64k. Do the math yourself.

Re:no

[TheGreek]

4004 was 4-bit. 8008 was Intel's first 8-bit processor.

no

[autopr0n]

not direct 16 bit addressing.

2^16 = 65536 = 64*1024 (64k). The math is pretty simple.

Obviously most 16 bit systems use some scheme to store more then that. I don't know about most 8 bit systems, but the z80 used a pair of registers (h and l) to store addresses, giving them a total of 64k or ram they could access at once.

8 bit direct addressing only gives you 256 bytes of ram, or 1/4th of a k. I think intel's 4004 chip had this limit (the first integrated CPU ever made)

Re:i think

[rdean400]

Heh, some of IBM's work in PowerPC-related design already does this. The Power4 chip, which is used in the pSeries (RS/6000+) and iSeries (AS/400+) hosts 5 different architectures in the core, 2 of these are 32-bit (32-bit Power and PowerPC) and 3 of these are 64-bit (64-bit Power, PowerPC, and "Amazon"). If they put their mind to it (but I doubt they would), it wouldn't be hard.

--rdean

p.s.--"Amazon" was a codename for the chip architecture that was going to merge the AS/400 and RS/6000 lines in the early 90s. The project was scrapped, but the resulting instruction set was used in the AS/400 line during its migration from CISC to RISC architecture.

huh

[autopr0n]

Are you saying super-exhuast riceboy cars have engies that rev to 13.2k RPM? Even a civic SiR only goes up to 7.3k :P

Sure, clock on a computer dosn't mean everything, but it does mean something.

Clockspeed Doesn't Matter to Apple Users...

[Shuh]

... because they perceive M$ OS to be clunky, junky, and unsafe at any megahertz! ;c)

I can see the "Switch" add now...

[dameron]

Hi,

My name's Tony. I work at a law firm. My PC used to hiccup at me all the time, blue screens here, illegal operations there. I didn't know what to do. All I know is the macros for my legal documents used to take forever. I'd start a macro then answer the phone, and it wouldn't be done until nearly after I said "Hello, this is MacIntyre and Finch, how can I help you?" How annoying???

That's when I realized I needed to address more than 4 gigs of memory. I mean really, when you're sending out C&D letters to 180 million people you need real power!

Then I got this new 64 bit Apple machine and it's like "WOW", man do those macros fly!!!

Hi! My name's Tony and I work for the RIAA...

-dameron

Linux is available for 64 bit

[Anonymous Coward]

Uhm you know, Linux is available for 64-bit processors, at least for the pSeries boxes (PPC - PowerPC proc). http://www.penguinppc.org/ && (http://www.linuxppc.org/ || http://www.linuxppc.com/). SuSE has a distro for this, I believe. Not so sure about RedHat - although I think their 7.1 release did have a port for PPC.

Re:Linux is available for 64 bit

[Twirlip of the Mists]

I want a decent and relatively cheap desktop 64-bit computer to work with....

Why? You know the only difference between a 32-bit and a 64-bit processor is the memory address limit, right?

Do you really need to allocate more than 2 GB of RAM to a single process on your desktop?

Forgive me if I'm being pedantic, but it's frustrating to me that most people don't know what "64-bit" means, and that of those who do, most of them don't understand that a 64-bit processor will be slower than an otherwise equivalent 32-bit processor. To understand this, think cache lines.

Re:Linux is available for 64 bit

[eizan]

hey, just co clarify: 64 bit can mean more than just the address limit. from what I understand, typically it refers to the word size in the chip, i.e. number of bits usually associated with an integer datatype. it usually just so happens that memory is addressed with integer-sized numbers. I used to think that it referred to general-purpose register size, but now with all those SIMD instructions being added to modern processors nowadays, the labeling gets a little screwey.

64 bit chips tend to be faster than 32 bit chips when it comes to crunching large amounts of data even though the logic might be more complicated because if the chip is designed right, cycle for cycle, it can usually process twice the amount of data.

Re:Linux is available for 64 bit

[MaxVlast]

Most people think about Nintendos. My 16 bit console is better than my 8 bit console. I bet my 64 bit Linux box would be f0kk1ng gr00vy!

Re:Linux is available for 64 bit

[WetCat]

2GB of RAM for single process? Easy! Now!
- PDF reformatting and printing of large and rich text documents.
- Quick search
- Caching of 300GB hard disks
- Image and video processing
A lot more can be imagined...

Re:Linux is available for 64 bit

[Hast]

64-bit processors are only faster if the data is high precision. (Ie >32 bits.) If you only work with 32-bit data then you won't gain anything from a 64-bit CPU.

This since the added 32 bits will just be redundant. Typically you can't use them for another calculation.

Re:Linux is available for 64 bit

[sco08y]

An 'n-bit processor' refers to the size of an integer. This is *usually* the same size as a pointer, but not always.

Do you really need to allocate more than 2 GB of RAM to a single process on your desktop?

I just ordered a 512 MB chip for my 2 year old laptop.

I was doing a machine learning course just a few months ago. I had hacked together some code in Perl that did statistical analysis of language (much simpler than it sounds) which happened to build huge indexes. The fact that my laptop only had 256 megs of RAM was actually a real PITA.

More commonly, Photoshop users have always been the biggest consumers of RAM. Now they're going to be replaced with video editors and 3D modelers. Having 3 or 4 gigs of RAM would allow them to be productive on cheaper and cheaper machines.

To understand this, think cache lines.

You've got to think trade-offs. Remember:

It can be fast / good / cheap. Pick two.

64-bit pushes you towards "good". So the resulting chip could be slower, or it could be as fast but more expensive. It will take more wires to keep the cache as effective, but at the same time many operations (e.g. copies) will be sped up.

Re:Linux is available for 64 bit

[giberti]

I remember this same discussion about 32bit processors. What's important is once it is in production, we can start developing applications that take advantage of it. Remember the run on Memory in 1995 when Windows 95 hit the shelf. Everyone had to go and upgrade their 486's and Pentium's so that they had 4-8Mb ram... now look at us, a machine with less than 128Mb what a joke. (I run 1Gb myself (yes I have dual processors too)) Having a couple of Gig of RAM is not that far off, and software that can take advantage of it isn't either.

Re:Linux is available for 64 bit

[Twirlip of the Mists]

Now they're going to be replaced with video editors and 3D modelers. Having 3 or 4 gigs of RAM would allow them to be productive on cheaper and cheaper machines.

One of the best, and possibly most expensive, video effects systems in the world is called "Inferno." It's sold by a company called Discreet Logic, out of Montreal. An Inferno runs on an SGI Onyx2 or Onyx 3000 computer-- one of the ones with like 12 processors that stands 7 feet high and sounds like a hurricane. An Inferno costs around $750,000.

With an Inferno, you can do visual effects for film at 2K resolution (2048x1556, usually at 36 bits per pixel) in real time. There's no tool out there that's better.

An Inferno has, at most, 2.5 GB of RAM. Many systems run just fine with 1.5 GB of RAM. (Don't ask me why, but the vendor recommends either 1.5 or 2.5 GB, not 2.0 or 3.0. That's just the way it is.)

I think you're overestimating the real need for RAM. Having more would be all well and good, but in the real world it's just not necessary for those kinds of tasks.

Re:Linux is available for 64 bit

[vought]

Do you really need to allocate more than 2 GB of RAM to a single process on your desktop?

16-bit scans of 4X5 inch film at 2400 dpi are over 2GB in size.

Although the percieved quality increase is negligible to nonexistent in most cases, 16 bit files give digital artists and photographers a greater margins to adjust tonality, contrast and other variables without introducing muddines or banding. The only problem is that 16 bit files are four times the size of the 8 bit files that are straining 32 bit plattforms right now.

Yes, I'd like to have more addressable memory. When I no monger have to worry about Photoshop scratch disks, I'll be a happy man.

Re:Linux is available for 64 bit

[Twirlip of the Mists]

16-bit scans of 4X5 inch film at 2400 dpi are over 2GB in size.

No, they're not. Where did you get your numbers?

A 4x5" transparency scanned at 2,400 ppi would result in a raster image of 12,000 by 9,600 pixels. That's 115.2 million pixels. At three bytes per pixel (8 bits each for R, G, B) that results in a file that's about 330 MB. (115.2 million times 3 = 345.6 million, divided by 1024*1024 = 329.6)

Using two bytes per color per pixel-- or a total of six bytes per pixel-- that comes to 659.2 MB, or exactly twice as much as the 8-bit version. Which makes sense, because 16 bits per color pixel is twice-- not four times-- 8 bits per color pixel.

To test this, I created a 4x5", 2,400 ppi file in Photoshop, at 16 bits per channel, and saved it as a TIFF. The result? A file on disk of exactly 659.1 MB on my desktop. That's uncompressed, of course. I had no problem at all doing this-- in the background, no less-- on my dual gigahertz G4 with 1 GB of RAM.

How in the holy heck did you get from about 660 MB to over 2 GB? You're math is very, very wrong.

Leaked a little early?

[jimbolaya]

From the article:

"International Business Machines Corp. Monday announced a microchip for personal computers..."

and:

"(TRANSMISSION EMBARGO UNTIL 12:01 am EDT/0401 GMT)"

Note that it says "announced," past tense. They didn't announce it Monday, October 7, so my guess is they are about to announce it tomorrow (as I right this on Sunday). Looks like Forbes made a boo-boo.

Re:lol

[Wesley Felter]

There have been plenty of 64-bit PowerPCs, they just weren't used by Apple. 620, Power3, Power4, RS64, etc.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Apples and oranges...

[ktakki]

No surprise that the 486 was faster: the Performa 640 used a 68LC040 which lacked an FPU and had no L1/L2 cache, while the 486/DX2-66 had an integrated FPU and often came with 256K of L2 cache memory.

Oddly enough, the Performa 640/Quadra 630 was one of those Macs that came with a 80486 daughtercard that plugged into the 68040 motherboard.

System 7.x and Windows 3.x: the worst of both worlds.

k.

Instruction cache

[yerricde]

so it would be easier on the programmer to use a cisc instruction

Actually, it's "easier on the programmer" to use C. The true advantage of CISC "bytecode" style instruction sets is that they have a small binary code footprint, which improves the performance of instruction caches. Not that I'm implying x86 is good bytecode or anything...

Re:Instruction cache

[Wesley Felter]

The true advantage of CISC "bytecode" style instruction sets is that they have a small binary code footprint, which improves the performance of instruction caches.

And then Intel throws away that advantage by caching uops instead of instructions.

Re:Already are 64 bit

[AKnightCowboy]

There are NO 64bit consumer processors currently available.

Sure there are. Sun Ultrasparc IIe's are consumer priced and fully 64-bit. You can pick up a full system for just around $1k. They're not the speediest things on the planet, but you just said 64-bit consumer level processor.

Re:Benefits? Depends what you do with your compute

[vlad_petric]

Also, do not forget about Moore's Law. CPU's keep getting faster. Problem is hard disks are not. So more RAM for caching will be the solution.

Well, the problem is that CPUs are getting a lot faster than RAM, too ... That's why "newer" Alpha processors, for instance, support L3 cache as well.

The Raven.

64-bit x86 CPU at 5 Ghz in 2003

[eyefish]

Let's see, so we'll have a 1.8 Ghz PPC CPU by the end of 2003. By then Moore's law predicts we'll have a 5 ghz 64-bit x86 CPU. Now more than ever I see a reason for Apple to "make the switch" to a x86 architecture.

Re:64-bit x86 CPU at 5 Ghz in 2003

[eyefish]

You're missing an important point. First of all, I myself admit (as an example) that even a 500Mhz PPC beats hand down a Pentium 4 at 900Mhz in most real world situations. HOWEVER, I know this because I'm a techie. Most people, specially "average joe" has no clue as to why a 500Mhz CPU can be as fast as a 900Mhz CPU. He just sees the numbers and buys the "faster" one.

The same thing will happen next year when we see a 5Ghz x86 processor being compared to a 1.8Ghz PPC processor. In the consumer market space, it's not necessarily who has the best technology, but rather who can make the customer *think* that they have the best technology, and in the world of marketing, numbers speak.

Re:64-bit x86 CPU at 5 Ghz in 2003

[eyefish]

>> So you're saying then that Apple should migrate
>> to a slower processor because the public perceives
>> that chip to be faster! That's a pretty bizarre
>> statement to make.

Yes, that's *exactly* what I'm saying. And remember that x86 chips are way cheaper than PPC chips due to competition between Intel and AMD. You could actually build a dual-processor x86 system that is faster and cheaper than a single-processor PPC system.

On a side note, remember a history lesson: Back in 1985, when Apple had black and white displays, PCs had monocrome display, and both had "beep" sounds and no multitasking, the Commodore Amiga had a super-high resolution display (comparable to today's 800x600 SVGA), 4-channel stereo sound (or 16 in software), 4096 colors, super fast hardware-assisted video acceleration, true multitasking, a faster CPU (twice as fast as a PC's or Mac's), a video output (for simultaneous Monitor and TV output), true hardware plug-and-play (no software installation required, ever), it was *cheaper* than PCs or Mac, and god know what else it had, and it still failed in the market. Why? People were interested in running programs everyone else had, and plug in devices everyone else had.

Now, don't get me wrong, I don't like that "herd" mentality, and as a matter of fact I'd take a Mac, Amiga, BeOS, or Linux machine anyday over Windows, but the fact is that this is not how "average joe" thinks. "Average Joe" buys a machine, and if software and devices he can buy at the local store don't work on it, he simply returns it.

It's also one of the reasons I use PCs for work. I cannot find the tools I need on Macs or Linux systems (although, great advances in this area have been done recently), and thus I have to use Windows. I don't like it but I have to live with it. At home I then come back to my trusty "alternative" machines.

Botton line: marketing wins anyday over reality, it's just how (sadly) the world works most of the time.

Re:64-bit?

[MaxVlast]

They're jealous and insecure. They've spent ten years breathlessly screaming that Macs are toys and it's not an operating system if it doesn't have a CLI, then when Apple releases the coolest UNIX on the block, they don't know what to do with themselves.

Amusingly, these are many of the same people who used to spend hours trying to make their Linux installs look like NEXTSTEP. Now that NEXTSTEP is back in a kickass operating system, it's not UNIX anymore.

Sad, really.

Microsoft would love Apple to

[jpmorgan]

MS would love Apple to switch to a complete x86 architecture.

If Apple went toe-to-toe with the 1000lb Gorilla, they'd be dead within 18 months. Remember, Apple is fundamentally a hardware company. Moving into an ultra-low margin commodity hardware market from a high-margin monopolistic hardware market to compete with a software company would be moronic.

Re:Microsoft would love Apple to

[bnenning]

If Apple went toe-to-toe with the 1000lb Gorilla, they'd be dead within 18 months.

Probably yes, but maybe no. There is a small but significant chance that Mac OS X for x86 could crack open the Windows monopoly, and if I were Bill I wouldn't want to take that chance.

Moving into an ultra-low margin commodity hardware market from a high-margin monopolistic hardware market to compete with a software company would be moronic.

Which is why Apple won't do that unless they're compelled to, i.e. if Microsoft stops Mac development.

Re:64-bit?

[ahknight]

I would really like to know WHY some people are so adamant about burning OS X on the UNIX front.

The same reason Jehovah's Witnesses maintain that Christ came back when they preducted (circa 1917), albet invisibly and silently so that no one knew but them: people don't like to change their mental picture of the future they predicted. Linux zealots preducted Linux would make it to the desktop. BSD, somehow, did it instead. They're upset that they put their faith in the, well, wrong religion. ;)

Re:POWER4 != PowerPC

[Wesley Felter]

Did you even look at the article? It says that the PowerPC 970 is "a 'lite' version of [IBM's] Power4 chip".

Re:64-bit?

[Aqua OS X]

I agree. OS X is a unix OS. The CLI and the fact that it can run unix apps should, more or less, be a dead give away.

And by the way, you can actually turn on the old NeXT Step UI (for cocoa apps), via some easter egg commands that can be typed into the command line ;)

Citius Altius Fortius

[Kjella]

64 bit is no miracle cure, I'm surprised everybody has hyped it as much as they have. It does lift the 4gb RAM limit (which can be overcome by segments too, but is more of a ugly hack), hardly an issue for todays desktops but perhaps for tomorrows. It does provide much more accurate calculations for various scientific uses (which can actually be quite a few things that don't sound very "scientific", for instance I could probably use it running some more exotic economic theories (wave theory, chaos theory) or simulations, maybe things like voice recognition.

But from what I've read of theoretical papers, the biggest advantage is the increased number and size of registries. To keep it short, one can keep a lot more information inside the CPU simultaniously. I've looked a bit into assembly programming and today most of the registries have designated "tasks", while the new registers are all general-purpose (and twice as big). It's difficult to say how much of a difference it'll make, but I believe it'll lead to a decent performance boost for all applications.

Kjella

The real hardware performance for macs finally...

[JollyFinn]

a) peak 8 instructions/ cycle.
b) 10 times OO window.
c) 5 times as fast bus.
d) Large buffers for OO loads/stores!
e) Excellent branch predictors.
f) 3 L1 cache ports! [2 load 1 store].

I'd say 64bit is nice add on in apple sight for a great chip. Unfortunately describing these issues would puzzle average Joe so much that they wouln't understand.
But I think apple could reuse their old hype and multiply the values by great numbers!

BTW: Apps spend plenty off time in OS libraries so MAC may be faster, as apple has a LOT more intensive optimizing those than MS...
And we all know how important for performance is to optimize code.
Photoshop for instance is good example such app, under NT it spends 67% off time in OS provided libraries.
I think apple have optimized ALL functions called by photoshop HEAVILY...

Jouni Osmala
ps. Not a mac zealot. x86/linux @home.

If IBM offers that new chip based linux desktop cheap enough I may switch platform,
next fall.

Macros

[yerricde]

when there is no benifit to using a risc instruction over a cisc instruction, a cisc instruction would be prefered since it does more with less keyboard work.

Keyboard work doesn't matter much. The MIPS architecture specifies a full complement of macroinstructions. Heck, somebody on the gbadev list mentioned writing a macro assembler that took 68000 assembly language and emitted ARM machine code.

In effect, CISC now stands for "compressed instruction set coding".

Re:BSD on Mach

[ahknight]

Why not just fork BSD directly to their own liking and skip the Mach layer?

Because then it wouldn't be NeXT, silly!

Re:Already are 64 bit

[The AtomicPunk]

How about an Ultra 1 for $100 on ebay? :)

Re:64-bit? Here are a few reasons.

[spinlocked]

EVERY situation I've seen a large Sun used it could have been handled with Linux

You need to get out more.

I've worked on several large scale Sun projects within the finance industry - Each with more than 1 million pounds worth of hardware. In each case the choice of the hardware was influenced by the following factors:

1. Which platforms does the application run on - (You'd be surprised how often the answer is - SPARC/Solaris only - less so these days, but many small finance ISV's still only support SPARC/Solaris)

2. Which database platform is required. (More often than not it's Sybase, sometimes Oracle, hardly ever anything else - DB2 rarely) Sybase will normally recommend SPARC/Solaris as it's their development platform. Likewise Oracle - authough they tend to be a little more platform agnostic.

3. How much downtime is acceptable - or put another way how much will downtime cost the business in real terms. For a major commercial bank, loosing their general ledger for example, will not only make it impossible to settle but they could be closed down by the finacial regulators. For an exchange, if they loose the ability to process trades and have to suspend the market, they will loose money directly (their profit on each trade) and may also have to pay customers compensation for their loss of earnings.

4. What availability figures will a particular vendor be willing to gaurantee (technically and financially). All large hardware vendors are very conservative on this - all vendors have product reliability issues from time to time - many customers refuse to admit responsibility for their mistakes (patch management, environmental issues). Going to court is expensive for all concerned, so vendors normally try to placate an angry customer with a better discount or by free hardware. Customers in turn appeciate the relationship and continue to place large orders. Many vendors are only willing to gaurantee very high (more than 5 nines) availability figures on their highest end server and disk products.

5. Large systems are likely to be more reliable than small systems from the same stable. Fact. The systems vendor has spent more money in R&D to make it so. They typically have more redundant/better quality components, dynamic partitioning capabilities (seldom used dynamically, of course) better systems management capabilities, more data replication options. Most importantly, larger systems are administered better, during the implementation phase the sys admins are trained, their systems runbook is developed, patch management and backup strategies are developed and the systems are tested properly. Human error (or process) is almost always to blame when large systems incur significant downtime.

6. How credible is the vendor? What platform is your major competitor using? If a particular vendor (systems and software) it's likely to be for a good reason - they understand the market, have strong relationships with ISV's, produce strong products and have decent service people to fix things when they go wrong.

7. The principle of locality of data. Many (not all) finance systems will benefit from keeping data in memory. High end 64 bit chips have large (8 or more Megabyte) E-caches. High end SMP 64 bit machines can address hundreds of Gigabytes of memory with (mostly) uniform performance and good reliability. Data is more likely to be in memory when it's needed, therefore you can process more trades per second, run risk analysis faster and generally make money faster.

Finance is a risk averse industry, in order to maintain transactional integrity, with robust reliability, with decent disaster recovery and finally good performance. They are willing to spend the money on (and often require) high end 64 bitness. In fact the cost of the hardware often pales into insignificance in comparison to software costs, running a datacentre, employing decent architecture design, systems admin and programming people, not to mention hardware support contracts, leasing DR fibre pairs, etc. etc.

Re:64-bit != speed -my favourite Solaris fact-let.

[spinlocked]

Generating 64bit code from a compiler will often run slower than equivalent 32bit code. For example; all of the binaries in /usr/bin on Solaris9 are 32bit, both for backwards compatibility and for performance - there are nearly 600 files. There are separate sparcv7 (32bit) and sparcv9 (64bit) binaries for only very few commands. Of these, some are 64bit so that they understand the 64bit kernel structures (adb, mdb, truss, the 'p' commands (pmap, pcred, pstack etc.) and there's sort. sort is the only command compiled to 64bit for performance. It's the only command deemed likely to encounter a large enough dataset to benefit from being 64bit.

What happened to the G5?

[mbourgon]

According to The Register, late last year (http://www.theregus.com/content/archive/22328.htm l)

[supposedly accurate benchmark numbers]
GHz 1.2 1.4 1.6
SpecInt2000 987 1151 1340
SpecFP2000 1005 1173 1359
"By comparison, Intel's 2GHz Pentium 4 has recorded SpecInt2000 and SpecFP2000 scores of 656 and 714, respectively, according to www.specbench.org If accurate, the G5 figures are impressive indeed."

I am curious where the G5 is... I had hoped to have heard more about it by now.

Mod the parent down!

[Junks Jerzey]

With such flagrantly wrong statements as:

68K architecture may have 16 registers, but they are 16-bit, while x86 are 32-bit.

it makes you wonder if this guy has ever touched a 68000 in his life, or if he's just spouting incorrectly remembered facts from a college survey course.

Correct

[Hrothgar The Great]

Yes, I guess I had forgotten that the 68040 in my machine was a 68LC040. Of course, I eventually modified mine by swapping the processor with a real 68040 anyway (the rumor at the time was that Apple was soldering the processors to the motherboard - that certainly was NOT the case with mine). So, I think it IS a fair comparison, if you want to argue like the parent post did that anything Apple uses is twice as fast as anything anyone else uses.

Re:Correct

[dbrutus]

Nah, processor speed advantage ebbed and flowed across lines for years. It still does. I think that PPC is currently somewhat lagging and might get a nice lift in 2003 with the new IBM chip. I just thought your comparison was unfair and irrelevant since nobody's using 68k chips in desktop cpus and hasn't for several years.

Pot, kettle, black

[cat_jesus]

Did you know that you are an idiot? the p4 has a 20 stage pipeline, which means the process of excecuting instructions is seperated into 20 peices, and the hardware used to do each one of those pecies works on part of a diffrent ... Most programs, of course, have more then one instruction... No, I was talking about using floating point math for integers larger then 32 bits, rather then splitting 64 bit ints up into 32 bit chunks

You have some nerve calling someone else ignorant and stupid when you can't even tell the difference between then and than, my 8 year old son can do that.

Re:processor registers

[Lars T.]

There is no indication that Intel is working on x86 compatible 64-bit CPUs, while they already have existing 64-bit CPUs - which weren't stunningly fast in their first incarnation, despite having lots of registers.

Re:You sound like the RIAA.

[Twirlip of the Mists]

You on the other hand claim that you would be making $250 to $500 if you were doing something other than tinker with your PC, or that you are losing that much by tinkering rather than doing something else. On a weekend no less.

The RIAA needs to get realistic and so do you.

Sorry, dude. If you figure a 2,000-hour work year, I make an average of $250 an hour. (No, I don't work a 2,000-hour year. But that's how you do the math.) I know that's way up there, above average in extremis, but those are the facts, and I won't make excuses for them. So my time during the week is worth precisely $250 an hour to me.

I personally value my weekends more than my weekdays, so I-- as I said-- arbitrarily set the value at $500 per hour. I will happily pay $500 so I can spend an extra hour with my family, with whom I spend too little time as it is.

Arguing with me about how I account for my time isn't really going to win you any points in the persuasiveness category. And you can kiss "Miss Congeniality" goodbye.

Re:A little optimistic

[Twirlip of the Mists]

Heh. Okay, I guess you got me on that one. Slashdot is costing me a fortune! ;-)

The difference, of course, is that I like writing on Slashdot, at least most of the time. I don't like fighting with a PC, or changing my oil, or things like that. That's my story, and I'm stickin' to it.

Megahertz myth

[be-fan]

I've diatribed before on this topic, and would like to share an insight. AltiVec very well may show some good benchmarks in some cases, but there is a very good explanation for it. The G4 chip is extremely memory bandwidth limited. It's memory bus allows for something like 1.3 GB/sec of bandwidth, and on a dual processor Mac that bandwidth is shared. Altivec can chew through a whole lot more than that in a given second. On datasets that are memory bandwidth limited (anything greater than 2 MB), a P4 will whip a G4's ass due to the 3x memory bandwidth advantage (4.2 GB/sec). On datasets that fit entirely in the internal caches (anything less than 512 KB) the P4 will whip the G4 because it also has several times the internal cache bandwidth (more than 2x depending on clock speed). The only case in which he G4 will win is data sets between 512KB and 2MB. The G4 has a fast DDR-SRAM backwide cache which the P4 doesn't. While a 1.5 MB dataset will spill the P4's cache and hit main memory, the G4 will be able to satisfy it out of the backside cache. This could very well explain certain G4 benchmarks.

Re:Duh...

[Lars T.]

But since there are branches, pipeline-length and branch-prediction come into play. You were saying?

Re:you proved his point.

[back_pages]

Yeah, because 30 years ago, when Ford built the GT40, embarrased the gay right out of Europe, realized that there's no competition in that, and retired the GT40, Non-Americans wanted a feather to stick in their hat. So now they revert to bad mouthing Chevrolets, something Americans do in the first place. Go back to your island. Nobody cared, nobody cares, and nobody ever will care in the future.

P4 ALUs

[Rui del-Negro]

The double pumped ALU for easy instructions is running at twice clock-speed. The the complex integer instruction unit, which is infact also an ALU for mult/div/shift/etc. operations, doesn't

Actually, IIRC, there are two double-pumped ALUs in the P4. Are you sure they can't do shifts? I know they won't do muls or divs, but shifts look like a perfect operation to do in one "double-pumped" (ie, two) clock cycle(s).

IOW doing multiplies (or shifts), the P4 still isn't as fast as the P3.

If you mean per clock cycle, I'm sure you're right. From that point of view, there are very few CPUs that are as inefficient as the P4. But the point is, the P4 was designed to run at insanely high clock speeds to begin with. And I'm pretty sure a 3 GHz P4 can multiply integers as fast as any P3. I'm not so sure about FPU performance, though. The P4 really can't cut the mustard there (and eats Athlon dust).

RMN
~~~

Re:P4 ALUs

[Lars T.]

Yes, there are two DPed ALUs, and page 5 of The Microarchitecture of the Pentium® 4 Processor talks about the ALUs - and no, shifts are done in the CIIU, and for small shifts several adds are actually faster.

And I do mean that multiply and shift are absolute slower on the P4 than on the (fastest) P3. Multiplies/shifts take 4/1 clock cycles to complete on the Pentium 3, and 16/4 on the P4. That is a factor of 4, and the P4 is not yet at 4 GHz - let alone 4 x 1.4 GHz (the fastest the Tualtin core goes).

Yes, that is indeed intresting

[autopr0n]

fascinating in fact.

er...

[autopr0n]

Hrm, my Computer archetecture class never covered the MIPS FP... well... Actualy it probably did, I didn't really attend all that often :P

You are in correct.

[autopr0n]

I can tell the diffrence between then and than, when I am paying attention.

Thank you for making a relevant comment on the content of my post though.

for data, not code.

[autopr0n]

Another poster responded to you about your first point (instruction dependancy), so I won't cover that.

The vast, vast majority of CPU benchmarks are small enough (or have been hijacked enough by x86 companies) to not need to hit ram. If you want to do interesting things like video, you'll hit RAM.

Yeah, you'll need to hit RAM, but only for data, not code. Most CPUs (including x86s) have seperate caches for data and code. Hitting ram for each instruction would be absolute murder.

You clearly flunked physics too

[Rui del-Negro]

Yes, and heatsinks also make it much harder to cool the chip. I mean, how is the air from the fan expected to cool the core if there's that big block of metal in the way...?

RMN
~~~

Right...

[Rui del-Negro]

Yes, after all, IBM has a lot more experience making chips than Intel, right? And they've never had any manufacturing problems with any of their products, right? And they've just opened a new plant.... well, if it's brand new I'm sure it'll work flawlessly, right?

No worries, mate.

RMN
~~~

Intel should hire you to design the next Itanic

[Rui del-Negro]

Do you know anything about hardware architecture? Don't bother to answer; it was a rethorical question.

Let me try to explain this slowly and in large, pretty letters.

Two ALUs do not equal twice the clock rate. The P4 has seven execution units. That does not mean it runs at 7x 2.8 GHz. Two of those seven execution units (the "simple ALUs") are double-pumped (they move data twice for each clock cycle, sort of like DDR memory transfers data at twice the clock speed). Therefore, these simple ALUs work (internally) at 5.6 GHz, on a 2.8 GHz chip. The CPU clock (the frequency with which data is moved between the main parts of the CPU) is 2.8 GHz.

The P4 has a long pipeline, which means it needs more cycles than, say, a PIII or and Athlon or a G4 to do some (resonably simple) operations. However, instructions can enter the pipeline before the previous instruction has finished executing. Think of it as a corridor: people go in at one end, and they come out at the other end. It may take 5 seconds for one person to walk across the corridor, but it won't take 10 seconds for two people to cross it, because the second person doesn't need to wait for the first one to reach the end.

This means there's a big penalty if the pipeline needs to be flushed, but as long as instructions are processed continuously (and the P4 has pretty good branch prediction / prefetch), it is quite fast indeed.

The actual time it takes to do something useful (such as multiply two numbers, compress a file, or render a 3D scene), depends on a lot of things. And it is important (a lot more important than the clock speed). But a P4 2.8 GHz does run at 2.8 GHz, contrary to what you said. If you want to discuss CPU architecture you need to understand the basic concepts, such as what clock speed means.

I am not talking out of my ass but even if I did, I suspect I'd still sound smarter than you.

RMN
~~~

Re:Intel should hire you to design the next Itanic

[BitGeek]

You contradict yourself, and then are patronizing about it!

You are a complete and total idiot.

As I have proven, clock speed means different things and different times.

And you keep repeating your stupid little myth that theres one clock on a CPU.

You're just an ignorant fuck who thinks he knows what he's talking about and that gives you the right to be insulting and patronizing.

Repeating the same falsehoods in bold letters doesn't make you look brilliant, fuckwad.

Go learn something, I'm done schooling you.

You had me at hello.

[Rui del-Negro]

If you're a hardware engineer, I hope you don't design anything that people's lives depend on! Let me just quote a couple of sentences from your first post on this thread:

"its time Apple start calling anything based on the power PC architecture twice its clock speed, and anyhting thats both powerPC and 64 bits at 4 times its clock speed. After all, the processor does twice as much as a 32 bit processor in a given clock."

And:

"calling this new PowerPC that runs at "1.8GHz" a "7.4GHz PowerPC" is just as legitimate as Intel calling their pentiums 2.8GHz, etc. (Cause they don't really actually run at 2.8GHz. [...] These published clock rates are a marketing fiction."

I really don't think anything you say (including mixing memory bus speed with CPU core speed, or references to Spinal Tap) can possibly beat those two ideas (that bigger registers make the processors faster and that clock speeds are made-up numbers).

Feel free to keep trying, though.

RMN
~~~

Re:You had me at hello.

[BitGeek]

Nice Dodge. Are you going to back up your assertion that the ALUs run at twice the clock speed, or not?

And are you going to reconcile this with your claim that there is only one clock on a CPU?

Naw, I figure you're ignore what you made obvious to all of us: You're an idiot.

But feel free to keep being patronizing. ITs amusing in a pathetic sort of way.

Re:He has a point.

[BitGeek]

because there's no way the CPU (Altivec or no Altivec) is going to crunch through the data fast enough.

Ha! That's funny. I'd like to see an example of a x86 encoding a DV stream to MP4 in real time.

This is commonplace on PowerPC machines, but I don't think its possible with any x86 on the market.