G5 in Jan - new info - Page 2

Go to yahoo and type motorola mpc 8500 and scroll down to <a href="http://www.pugglewump" target="_blank">www.pugglewump</a> etc. it wont go the way I listed..sorry about that.

Go to yahoo and type motorola mpc 8500 and scroll down to <a href="http://www.pugglewump" target="_blank">www.pugglewump</a> etc. it wont go the way I listed..sorry about that.

[quote]Originally posted by Renan:
<strong>Go to yahoo and type motorola mpc 8500 and scroll down to <a href="http://www.pugglewump" target="_blank">www.pugglewump</a> etc. it wont go the way I listed..sorry about that.</strong><hr></blockquote>

Are you retarded, or just plain stupid?

The following is from the page you gave a link to:
[quote]3) G5 happies: To quote MOSR (http://www.macosrumors.com/)...

On Wednesday, MPC 8500 revision 0.6 was received. This revision fixes a cache bug, and has improved altivec peformance to 85% of the 7460 G4's at e...<hr></blockquote>

Read the bold. Now, let the bold text sink in. This is nothing more than some Mac fan's online diary. He's quoting MOSR in his diary.

Wow.
Amazing.
Holy fscking sh*t!
I can hardly contain my joy.

SYN said --
"6-8x performance increase when compared to a MP800 with a simple recompile is not possible with any chip that is even remotely close to being ready for mass production... Has this ever happened? even the 604e to G3 did not provide such an increase.

The only case in which this could in fact be true is if the App was heavily reliant on AltiVec... or completely starved of memory bandwidth on current machines...

6-8x is quite a speed jump."

On the contrary, I think this jump would be (barely) possible, even leaving AltiVec out of it, with what I expect to be the next machines. Assume that the app fahre451 is talking about runs without MP tasks on a dual-800, and that the sealed-up machine that his new tests were run on was one of the 2.4-GHz G5 models that Architosh.com and other sites mention, then we have SPEC2000 (G4 DP-800) == 480 and SPEC2000 (G5 SP-2400) == 2046, so that the speedup would be 2046/480, or 4.3 x, quite consonant with the subjective "6 to 8 times" reported. See my CPU-characteristics chart at:
\t<a href="http://www.bayarea.net/~kins/AboutMe/CPUs.html" target="_blank">http://www.bayarea.net/~kins/AboutMe/CPUs.html</a>

On the other hand, the sites and figures that I am relying on are not universally accepted (to say the least). Witness these responses to the Register/MacOSRumors/Geek.com/Architosh.com numbers (Oct - Nov 2001):


obvious fakes (Oct 20 2001).
Those numbers are obviously fake. I predict that the G5 will actually score closer to 50% of those faked scores. The Register got its numbers from MacOSRumors, a site notorious for bogus and wildly over-optimistic performance claims (a site that makes Apple's bogus performance claims actually look conservative).

These SPECS are bullshit. Not because I can't have the G5 to be that fast but because such a score would rely on a groundbreaking design. The G5 isn't. It's a nice design, very nice, but it's still human -)

The specs are greatly inflated (Nov 07 2001).
I'm telling you people that the specs are way too good. There is no way the integer and floating point performance is 3X as good as a P4 at the same clock speed. You're all going to be in for a big disappointment when the G5 is finally released and tested. - by Mark


But I believe that, based on the public information from Motorola and the "moles" used by the rumor sites, which over the last three years, as far as the G5 goes, have all shown an astonishing degree of consistency and plausibility, the referred-to specs are not fakes.

To the other issue -- re-compiles or re-writes being necessary for a new chip -- Apple and Motorola have assured us that no recompile will be necessary to run G4 binaries on the G5 (when it comes), though a simple re-compile can greatly speed up 64-bit operations. (Does fahre451's code do 64-bit arithmetic?)

Kins Collins

A 2.4 ghz G5???


That is insane.

I doubt the fact that any such chip exists, even in very small quantities.

[quote]Originally posted by Kins C:
<strong>But I believe that, based on the public information from Motorola and the "moles" used by the rumor sites, which over the last three years, as far as the G5 goes, have all shown an astonishing degree of consistency and plausibility, the referred-to specs are not fakes. Kins Collins</strong><hr></blockquote>

You forget one thing... It's not 'moles' it's 'mole' MOSR and The Register are both being fed 'insider info' from the exact same source... I even remember MOSR saying as much in one of their reports... We also know MOSR and The Register are not being run by the same kinda folks as say 60 Minutes... 2nd source / independant verfication?!?! What-chew-talkin-bout Willis!

Give em something cool to report on and make it sound even half-way possible (not even sure that's needed any more) and fake some email headers and you too could be the next 'inside source' at MOSR or The Register.

It's a game the whole family can play! <img src="graemlins/smokin.gif" border="0" alt="[Chilling]" />

Dave

P.S. Oh I couldn't let this one pass me by either...

[quote]"To the other issue -- re-compiles or re-writes being necessary for a new chip -- Apple and Motorola have assured us that no recompile will be necessary to run G4 binaries on the G5 (when it comes), though a simple re-compile can greatly speed up 64-bit operations." <hr></blockquote>

Oh really now... care to provide a link where Apple has stated this? I'm sure quite a few people would love to see it!

[ 12-28-2001: Message edited by: DaveGee ]</p>

[quote]Originally posted by Strangelove:
<strong>let's face it: do you guys really think maya was coded for this peanut dual-800? c'mon...</strong><hr></blockquote>

actually maya only uses one processor (for rendering, the most time consuming part of 3d work) -- and god it bothers me!!!

Mike

Why bother compiling or writing Maya for a system that will be out of date in 6 months. Think about it for a minute... if you are writing an app that puts the most stress on any CPU you are running it on, why write it to a dated CPU design? Maya is also run by shops who absoutely need to have and buy the latest and greatest hardware. Every ounce of profit is irked out by faster CPU's. Apple has been touting Maya like sliced bread. Doesnt 1 + 1 + 1 add up to something here?

I skimmed this pretty fast so I may have missed it, but I did not see a mention of the speed boost by going from a 32 to a 64 bit processor. Why else would a recompile be needed except to put it in optimized 64 bit code? On top of that, it may have a new 256 bit AltiVec unit. On top of that too, it may be a dual G5, running at 1.6 GHz or above. I think it is quite possible to achieve that kind of performance increase. Though possible, I don't count on seeing it at MWSF.

DaveGee, posted 12-28-2001 06:46 PM, QUOTE
\tquote:

\tOriginally posted by fahre451:
\tApple System Profiler was not installed. I \tdid not bother installing it.


This one line tells me this whole post is BS...

First comes human nature... Don't open that box Johnny... What do you think the first thing little Johnny does..

Next comes the geek factor... What self respecting computer geek wouldn't do his or her level headed best to find out what some Apple branded hermetically sealed box had ticking inside it.

Finally comes the SUPER geek factor... A gaggle of code hackers recompile a company app and get a 6x to 8x performance pop and NOBODY was tempted to use all of the software tools they could get their hands on to see what may or may not be inside?

Sorry, but nobody could ever convince me this report was for real...
END OF QUOTE.

DaveGee convinces me here that fahre451's report is bogus. But my own argument and that of "Steve's office cleaner" have also convinced me that the figure of "6 to 8 x" is at least POSSIBLE.

Kins Collins

A 6-8x speed improvement isn't outside the realm of possibility for non-AltiVec code -- in fact it is probably more likely for non-AltiVec code than for AltiVec code. The AltiVec unit is "only" 2 years old now, and the one in the 7450 is less than 1 year old. The scalar core of the G4/G4+, however, is largely unchanged from the G3 -- which is something like 4-5 years old.

A processor clock rate boost from 800 to 1600 MHz, and a memory bus rate increase from 133 to 266, would account for a doubling of performance. Core architectural improvements, greater superscalar execution, wider internal busses, etc could reasonably deliver another 2x improvement -- that gets us to 4x. Depending on the exact nature of the code being executed and the new hardware optimizations built into both the chip and processor, a further 50-100% improvement is not unheard of between processor generations. Alternatively they could just have a quad processor prototype instead of a dual (this assumes that the application in question is multi-threaded, but that is likely considering the benchmarking machine of choice was a dual 800 and not the 867).

Does this mean the original quote is true? No.
Does this mean that such a machine will be introduced on Jan 7th? I'll tell you on the 7th.
Does this bold claim automatically mean that the poster is full of it? No.

[quote]Originally posted by snoopy:
<strong>I skimmed this pretty fast so I may have missed it, but I did not see a mention of the speed boost by going from a 32 to a 64 bit processor. Why else would a recompile be needed except to put it in optimized 64 bit code? On top of that, it may have a new 256 bit AltiVec unit. On top of that too, it may be a dual G5, running at 1.6 GHz or above. I think it is quite possible to achieve that kind of performance increase. Though possible, I don't count on seeing it at MWSF.</strong><hr></blockquote>

It is a common but incorrect assumption that switching to 64-bit code is somehow faster than running 32-bit code. This is
false! All other things being equal (i.e. there is no performance hit for the 32-bit mode operation), if an application does not need to manipulate 64-bit integers (and most do not), then it will be faster as a 32-bit application. Why? If you are running in 64-bit mode then all of your integers and pointers are twice as big, and your register set is larger and thus you end up hauling more data in and out of memory.

64-bit processors are typically faster than their 32-bit predecessors because they are newer, not because they are 64-bit. A 32-bit processor can be built (and usually are) with much wider busses, and often with larger-than-32-bit data types (i.e. double precision floating point and vector types). Exceptions are if the application needs &gt;32-bit address space (rare), or if it needs to do &gt;32-bit integer arithmetic (also relatively rare).

Recompiling for a new (compatible) processor typically shows performance benefits because the compiler can schedule instructions better by using knowledge of pipeline lengths, execution units, the cost of particular instructions, and resource stalls. How much of a benefit depends on how different the processors are -- for the Pentium4 it makes an enormous difference for a whole bunch of reasons.

The PowerPC spec defined how a 64-bit processor would work back in '94 when it was introduced. The 620 shipped in '95-96 and was a 64-bit processor. The move to 64-bit will be much easier for the PPC world than the x86 world, especially since Intel is off messing around with Merced.

Lastly, I think it unlikely that we'll see a "256-bit AltiVec unit". There could be enhancements to the spec (I'd like to see a new vector double type, that being a paired double), but I'm not sure that going to larger registers would be a win. A better use of those transistors would be to have more execution units and rename registers.

[quote]Originally posted by The Mactivist:
<strong>
And why would Apple send out a protoype box without telling people what is inside - what's the point? If, for instance, they were manfucaturing both hardware AND software, wouldn't it be sort of necessary to get inside the box to plug something in if needed? Or do they have special boxes for different developers?</strong><hr></blockquote>

I can't say what happens with hardware developers but I know the company I work for recently got to work with an Apple test box that was not only sealed but had practically no information with it (it could have been a new G3 or G4 for all we were told). We were told just that it met a certain requirement that was set down and that's it.

Apparently they then got to test the software, which was developed for current hardware, to show it performed and worked.

The entire event was to serve as encouragement we should be supporting the Mac as they did have hardware suitable.

Don't really know any more than that because I went on holidays the week before so didn't attend *shrug*

I've dealt with prototype hardware (non-Apple) many times, and it is completely normal to not pry into the box. Not only do you not want to risk your position as a test site, but we're also software geeks -- all we really care about the hardware is how to write software for it and how fast it pushes bits. :cool:

[quote]Originally posted by Programmer:
<strong>I've dealt with prototype hardware (non-Apple) many times, and it is completely normal to not pry into the box. Not only do you not want to risk your position as a test site, but we're also software geeks -- all we really care about the hardware is how to write software for it and how fast it pushes bits. :cool: </strong><hr></blockquote>

so, you're saying here and elsewhere that what the original poster said is at least plausible? I thought the g5 was supposed to 100% compatible with the g4. Why would they need to recompile a program in order to run it? Doesn't that defeat the whole point? Does that mean you'd need a whole new version of this hypothetical software in order to run it (as a user?).

Hmmm.... also, about this 64 vs 32 thing. What kind of software would crunch 64 bit integers? 3d rendering perhaps? Some scientific program? Any ideas?

Oh fart. I shouldn't get my hopes up, I know, I know.
<img src="graemlins/hmmm.gif" border="0" alt="[Hmmm]" />

[quote]Originally posted by The Mactivist:
<strong>

so, you're saying here and elsewhere that what the original poster said is at least plausible? I thought the g5 was supposed to 100% compatible with the g4. Why would they need to recompile a program in order to run it? Doesn't that defeat the whole point? Does that mean you'd need a whole new version of this hypothetical software in order to run it (as a user?).

Hmmm.... also, about this 64 vs 32 thing. What kind of software would crunch 64 bit integers? 3d rendering perhaps? Some scientific program? Any ideas?

Oh fart. I shouldn't get my hopes up, I know, I know.
<img src="graemlins/hmmm.gif" border="0" alt="[Hmmm]" /> </strong><hr></blockquote>


The quote just said they rebuilt with the newer compiler and the results were astounding. It did not say that it was necessary to recompile. My guess would be that the old code would run, but only see the 2x-3x speed up that you'd expect from the clock rate bump and improved memory bus.


Pure speculation... clearly Apple thinks it has something big for the 7th. They almost had something big for last summer, but delayed it at what appeared to be a very late stage. I don't think they'd use the word "revolutionary" lightly, so I'm optimistic that Steve is going to wow us with something... whether its a G5 or some new gadget I don't know, but I don't think an assortment of faster busses in yet another G4 machine will be the extent of it. Apollo will arrive as Moto has already announced it, but for a long time now (&gt;1 year) the Apollo has been earmarked as the "consumer machine G4". One possibility I haven't seen mentioned anywhere is that the G5 might arrive but MacOS X will use it only in 32-bit mode until the release of 10.2 which (apparently) is earmarked for next summer.


One more thing that doesn't seem to be given much consideration: Apple has a lot of engineering talent working away feverishly. They are working on something, and Apple has shown in the last few years that they can and will deliver product. The longer we go without them delivering a major step up, the more likely they are to do so at the next event. I think they've made it pretty clear that this time they are going to deliver something of note.

[ 12-29-2001: Message edited by: Programmer ]</p>

[quote]Originally posted by Programmer:
<strong>


&lt;snip&gt;

One more thing that doesn't seem to be given much consideration: Apple has a lot of engineering talent working away feverishly. They are working on something, and Apple has shown in the last few years that they can and will deliver product. The longer we go without them delivering a major step up, the more likely they are to do so at the next event. I think they've made it pretty clear that this time they are going to deliver something of note.

[ 12-29-2001: Message edited by: Programmer ]</strong><hr></blockquote>

Even more significantly, their most recent SEC filings report a 13% increase in R&D. That is a HUGE increase in R&D, especially considering the type of economy we are in.

[quote]Originally posted by Programmer:
<strong>[...]One possibility I haven't seen mentioned anywhere is that the G5 might arrive but MacOS X will use it only in 32-bit mode until the release of 10.2 which (apparently) is earmarked for next summer.[...]</strong><hr></blockquote>

Why does everyone seem to think that a 64b version of OS X can't happen before 10.2? Couldn't Apple just check the "64b box" on whatever compiler they're using and give us a 64b version of 10.1.2?

Ok, I'm sure it's not quite that simple, but I really don't see any reason why they couldn't do it. Am I way off base here?

[quote]Originally posted by Whisper:
<strong>

Why does everyone seem to think that a 64b version of OS X can't happen before 10.2? Couldn't Apple just check the "64b box" on whatever compiler they're using and give us a 64b version of 10.1.2?

Ok, I'm sure it's not quite that simple, but I really don't see any reason why they couldn't do it. Am I way off base here?</strong><hr></blockquote>

I'm afraid you are somewhat off base, yes. A simple recompile will give you a working programme, so long as nothing in the programme is dependent on the size of items in memory, especially pointers. Currently all pointers are 32 bits, and a lot of structures used in the OS assume this, so you need glue code to adjust this in a 64 bit environment.
However, I believe that OSX was written with 64 bitness in mind, so most of the work has already been done, but for certain no one will be sure until after they have actually run a large number of existing programmes on 64 bit hardware and software, as with most development of existing code, the vast majority of the time is spent testing.

Michael

[quote]Originally posted by mmicist:
<strong>

However, I believe that OSX was written with 64 bitness in mind, so most of the work has already been done, but for certain no one will be sure until after they have actually run a large number of existing programmes on 64 bit hardware and software, as with most development of existing code, the vast majority of the time is spent testing.

Michael</strong><hr></blockquote>

Okay, assuming all that's needed is an update along the lines of 10.2, what would a 64 bit processor actually do for a program like, say, after effects - where there is a lot of rendering involved? Does it actually make anything at all faster? What's the point of making a 64bit chip at all?

<img src="confused.gif" border="0">

[quote]Originally posted by The Mactivist:
<strong>

Okay, assuming all that's needed is an update along the lines of 10.2, what would a 64 bit processor actually do for a program like, say, after effects - where there is a lot of rendering involved? Does it actually make anything at all faster? What's the point of making a 64bit chip at all?

:confused: </strong><hr></blockquote>

After Effects and its ilk (image processing) are typically AltiVec optimized and thus operate on 128 bits of data at a time already. Each piece of data is 32 bits or smaller, but they work on 4 or more pieces at a time. A 64-bit processor's ability to do 64-bit integer math would probably not benefit them at all. Having a 64-bit address space might help -- they could work on data sets &gt;4 gigabytes without worrying about fitting it into memory. Virtual memory would handle it all for them, unless of course you really had that much RAM (rumoured to be up to 16 Gb in the new machines!).

What kind of apps need 64-bit math? Very few, that's why we've been using 32-bit processors since the mid-80s and haven't pushed up to 64-bits. Each bit you add doubles the size of the number the processor can work on in a single operation so as the machine's word size increases its capability increases dramatically.

8-bit = 256
16-bit = 65356
32-bit = ~4.5 billion
64-bit = ~18.44 billion billions

As you can imagine it is pretty normal to have to deal with numbers that are beyond what a 16-bit machine can deal with, but well within what a 32-bit machine can handle. And I'm just talking about what a machine can handle in one single native operation -- with more work a processor can operate on larger numbers, it just becomes less efficient and slower. Moving beyond 64-bit is even less likely, instead there will more likely be a more fundamental shift in the processor design paradigm at some point in the future.

Note that all I'm talking about here is the processor's word size. Bus sizes, math register sizes, vector register sizes, etc are all measured in bits as well and these vary independently of the word size. If these are included the G4 can be considered a 32-bit 64-bit 128-bit, and maybe even 256-bit processor for a variety of reasons based on its internal architecture.

[quote]Originally posted by mmicist:
<strong>

I'm afraid you are somewhat off base, yes. A simple recompile will give you a working programme, so long as nothing in the programme is dependent on the size of items in memory, especially pointers. Currently all pointers are 32 bits, and a lot of structures used in the OS assume this, so you need glue code to adjust this in a 64 bit environment.
However, I believe that OSX was written with 64 bitness in mind, so most of the work has already been done, but for certain no one will be sure until after they have actually run a large number of existing programmes on 64 bit hardware and software, as with most development of existing code, the vast majority of the time is spent testing.

Michael</strong><hr></blockquote>

Ah, I'd forgotten about pointer math. I guess I've been spending too much time with Java lately. Thanks for explaining that.

Programmer,

Thanks for the lesson in CPU's... It clears up many falsehoods that keep getting spouted about. But, after reading everything you wrote about 32 vs 64bit CPU's... What I'm not sure I understand is WHY?

Why do we need to move to a 64bit system... It seems from what you've written most things will not see any major pop in performance due to the 64bitness of the CPU. The pop will come from other factors such as Mhz etc (as with any new CPU).

So what real world computer tasks could benefit with a computer running 1 64bit over say 2 (or more) 32bit cpus. Unless building the new CPU as a 64bit isn't a 'big deal' and the chip designers are just doing it 'because it doesn't really matter one way or the other'.

I hope that makes some sence...

Dave

[ 12-29-2001: Message edited by: DaveGee ]</p>

The kernel and base OS design has built-in support for the following processor architectures, even if the machine code for every single cpu might not be included in current compiled versions:

PowerPC (dedicated code setpus for 601, 603, 603e, 603ev, 604, 604e, 750 (using different l2 cache configurations), 750cx, 7400 (using different l2 cache configurations), 7410, 7450 (using different l2/l3 cache combinations). Note the support for the 601. Neither the 7460 nor the 8500 are listet in currently available OS X versions. If the 7460 is more than just a 7450 with better fab process (different l2/l3 cache config for example) we should get an updated OS with the new machines. If the 7460 is very similar to the 7450 Apple probably won't add specific code for this CPU, 10.1.2 doesn't add specific 7440 code either (the 7440 is considered to be a 7450 with 0kb l3 cache, as far as I can see).

Intel x86 (dedicated code setups for i386, i486, i486sx, PentiumPro, PentiumII). Note the lack of support for the original Pentium CPU, this processor probably is considered to behave like a 486, no support for MMX. The P6 design has been separated in PPro and PII because of the different L2 configs, PIII and PIV use the same setup as PII. All this is needed for the Intel port of Darwin, for example, it does NOT mean that Apple will ever offer OS X on the x86 architecture. Athlon is considered to be 100% x86 compatible.

Intel Risc aka i860/i960 (i960 is considered to be 100% compatible with i860).

Motorola 68k (68030 and 68040 only). Note that 68000, 68010 and 68020 would not be able to run the OS X base system because of the lack of hardware support, like MMU and more... 68060 is considered to be 100% compatible with 68040.

Motorola 88k Risc (only one code setup for all CPUs)

HPPA / Hewlett Packard Precision Architecture (optimized for the 7100lc)

Sun SPARC (only one code setup for all CPUs)

Note that the system core has been designed to run on little and big endian systems (you will be able to comile it for Intel and other platforms). I can assure you that at least some parts of the core system have been prepared for 64 bit. The entire system core / UNIX layer (which is based partly on NeXTstep, OpenBSD and NetBSD) has been designed for 32 and 64 bit processors.

Anyway, as already mentioned by others it doesn't make sense for Apple to move to 64 bits, as only very few apps will take real advantage of the 64 bit registers, and I think that a powerful SIMD unit (like Altivec) is much more efficient in most cases than a 64 bit ALU.

BUT - if Apple has learned one thing from Intel, people don't care about the real facts. Look at the mhz myth, Intel needs mhz so much that they even reduce the cpus efficiency for the marketing (-&gt; P4). Apple could use the 64 bit mode for marketing, they would be the first to offer a large number of 64 bit systems. They could say "well, we are still at 1.6 ghz (G5) while Intel is at 2 ghz (P4), but we have a 64 bit cpu instead of only 32 bits. Consumers are stupid, and that's why they'll believe it (why else are people buying Wintel machines?). The G5 will probably be faster than the P4, but not because of 64 bits but because of a better design (enhanced ALU, Ocean crossbar witch, RapidIO,...). But Apple can't use these facts for marketing, as the common consumer has never heard of "ALUs", "crossbar switches" or whatever. Remember the Nintendo64? All the hype they made with their 64 bit CPU, that's just the same...

One nice thing about the PPC architecture definition is a seamless 32-bit mode on 64-bit chips. This means you can run 32-bit software without any kind of an emulation hit on a 64-bit processor. So there isn't a reason to not go 64-bit, and there are a few apps where benefit would be seen in 64-bit mode -- particuarly server apps. A 64-bit G5 w/ OSX would let Apple compete with the big guys in the server market against the 64-bit SPARC, MIPS, IA-64, Alpha, Power3/4 and Precision processors. If (when) the G5 shows up it will be in the high end machines, and it will considerably extend Apple's reach into the workstation market where margins are even wider.

Not having a 64-bit processor, however, means that you are limited in those areas where you really do need one. Apple will go there, its just a matter of when.

Jeez louise. So if Apple is talking like the MHz gap is about to be closed - and the Apollo G4 is supposed to be a whole new kind of G4 with a thinner fabrication and a new bus and all this - what's the point of waiting for a g5? Like, if Jobs goes out and introduces new machines with a 266 bus, 266 ram (or whatever) and a new apollo g4, won't that be a considerable speed increase over the current models - like more than some new-fangled 64 bit processor that won't even effect any speed increases?

And if so then why all the focus on the G5? Is it the number? Is it because it can go to eleven? It's one more than a G4?

(Sorry if I'm mastering the obvious here - I've just been so caught up in the g5 frenzy that I'm starting to think the semantics of the change are more important than the actual change itself.)

Hell, if Apple brings out new powermacs with faster ram and faster buses, and dual processor machines over 1.2 Ghz, I'll take three, thanks very much (for work and home)!!!

[quote]Originally posted by macrumorzz:
<strong>The kernel and base OS design has built-in support for the following processor architectures, even if the machine code for every single cpu might not be included in current compiled versions:</strong><hr></blockquote>

Okay, but correct me if I'm wrong here, but this means Darwin can run on all the processors you mentioned, but mac applications and the aqua interface will not run on anything other than a powerpc? Is that right?

Is it possible to bring out an AMD-based Powermac without having to update all your software? (Don't think it is, but just wondering).

[quote]Originally posted by DaveGee:
<strong>Programmer,

Thanks for the lesson in CPU's... It clears up many falsehoods that keep getting spouted about. But, after reading everything you wrote about 32 vs 64bit CPU's... What I'm not sure I understand is WHY?

Why do we need to move to a 64bit system... It seems from what you've written most things will not see any major pop in performance due to the 64bitness of the CPU. The pop will come from other factors such as Mhz etc (as with any new CPU).

So what real world computer tasks could benefit with a computer running 1 64bit over say 2 (or more) 32bit cpus. Unless building the new CPU as a 64bit isn't a 'big deal' and the chip designers are just doing it 'because it doesn't really matter one way or the other'.
</strong><hr></blockquote>

The cost of adding 64bitness to a processor is relatively small. Firstly it only affects the integer portions, the FPU and the vector unit already work with as wide or wider data paths, and the extensions of the ALUs to handle 64 bits is relatively simple, there is a bit of overhead for controlling the mode (32 or 64 bits).
The big advantage to 64 bits is not in any internal operations but in being able to logically address more than 4GB of memory. This may not seem like much of a limitation at the moment, but people handling large databases, complex rendering projects, some CAD systems, and a lot of scientific modelling, are already using more than that memory, and using 64 bits makes that a lot easier. Soon, however, many other users will be running systems, which, between several programmes running simultaneously, will approach that memory requirement.

Michael

[quote]Originally posted by mmicist:
<strong>
The big advantage to 64 bits is not in any internal operations but in being able to logically address more than 4GB of memory. This may not seem like much of a limitation at the moment, but people handling large databases, complex rendering projects, some CAD systems, and a lot of scientific modelling, are already using more than that memory, and using 64 bits makes that a lot easier. Soon, however, many other users will be running systems, which, between several programmes running simultaneously, will approach that memory requirement.

Michael</strong><hr></blockquote>


BINGO!!!! A HA! Thank you so much for this. Now it makes sense to me why Apple is designing a 64 bit processor.

The image is of an SGI Octane in the middle of a set of Apple-branded crosshairs.

Okay, so that's no big revelation. But I've been writing Apple for ages on why they don't sell real servers and why their top of the line is such a joke. I work with After Effects and I also do digital video editing. There's no end to the amount of power you'd like to have at your disposal. Rendering projects to 'see' what you're doing is just time consuming, wasteful and annoying. I know you can do ram previews, etc.. But it REALLY helps to see a full rez version and it often takes many hours to get one.

Thanks!

I am not a tech person so don't quite understand all these details of 32 bit vs 64 bit processors, but it seems to me that the trend of late has been for the hardware to be way out ahead of the software. It wasn't that long ago that running many Photoshop filters meant it was time for a 15 minute coffee break and people were screaming for more horsepower, but nowadays even my "ancient" Powerbook 250mhz G3 runs most in seconds. Of course games and a few other apps like Maya can use all the power they can get, but for most of us it isn't all that necessary. I think this is the biggest reason, other than the slow economy, that computer sales are down. Many people are just not feeling they need more powerful computers, especially in the Wintel world. Mac users of course, no matter what we read about the Mhz myth, still feel we have fallen behind and I think really significantly more powerful Macs like a G5 will sell like hotcakes, even to those who don't really need them, like me.
But I think to really drive hardware sales there needs to be more software that takes makes those machines absolutely NECESSARY...and not software like Maya that costs many thousands of dollars that only big companies can afford. The point I am trying to make here is that while it is great, at least from a marketing standpoint, to go from 32 to 64 bit processors, it may take awhile for new software to appear that really needs 64 bits. Once software developers know they have that many bits to take advantage of they may come up with programs that do things we can't even imagine yet. Basically, what Apple really needs is a "killer app" that only runs on a 64 bit machine and makes their machines a "must have" to the maximum number of people.

[quote]Originally posted by The Mactivist:
<strong>

Okay, but correct me if I'm wrong here, but this means Darwin can run on all the processors you mentioned, but mac applications and the aqua interface will not run on anything other than a powerpc? Is that right?

Is it possible to bring out an AMD-based Powermac without having to update all your software? (Don't think it is, but just wondering).</strong><hr></blockquote>

Mach and Darwin are already running on the Intel/AMD platform. This means that the entire UNIX layer runs natively on these CPUs. Of course this is not true for Aqua and other OS X frameworks. So MacOS X will NOT run on Intel/AMD, and even recompiling should not work because of the huge differences between PPC and x86.

It would however be possible to use a PPC emulation translating the PPC code into x86 code (like the 68k emulator used in the PMs), today it is even possible to run such an emulation on a very elementar system level or even entirely inside the CPU - think of Transmeta for example. Some weeks ago a company - sorry, forgot the name - demonstrated PPC software (not en entire OS, of course), on an Athlon. Thus the Athlon can emulate a 1 Ghz PowerPC (speaking in terms of G3, I think, and no AltiVec).

But I don't think this would be the right way, an AMD based PowerMac running an emulated OSX would always be slower than the same CPU running a native OS like Win, Linux or any other UNIX.

[quote]Originally posted by The Mactivist:
<strong>...and a new apollo g4, won't that be a considerable speed increase over the current models - like more than some new-fangled 64 bit processor that won't even effect any speed increases?

And if so then why all the focus on the G5? Is it the number? Is it because it can go to eleven? It's one more than a G4?</strong><hr></blockquote>

Be careful now - the fact that 64 bit does not mean a major speed boost does not mean that the G5 is not faster than the G4. 64 bits is only one of many improvements of this architecture, most speed gain is due to the new ALU, the crossbar switch, the new frontside bus, the new memory controller, bigger caches etc. If you look at the G5 specs you can easily imagine that the new design could offer double performance compared to the G4, and the new pipeline/core design allows higher clockrates too - so the G5 should be at least 3 to 5 times faster than the G4 (comparing G5/1.6 to G4/800).

[quote]Originally posted by mmicist:
<strong>
Soon, however, many other users will be running systems, which, between several programmes running simultaneously, will approach that memory requirement.
</strong><hr></blockquote>


It should be noted that running lots of apps is not a reason to require a 64-bit processor! Each application is limited to a 4 gigabyte address space of its own, but the operating system can manage multiple operating systems, and the PPC hardware is setup to address &gt;32 bits worth of physical address space (52-bits worth, I think?). Whether this is brought out to the bus to allow that much RAM to be used, I'm not sure, but the OS could juggle many apps with 4 gigs of virtual memory each.


Regarding the comment about greater performance from the G5 due to non-64bit reasons: absolutely! Have you seen the other thread that purports to have a quote from somebody who has recompiled their app on a G5 and seen a 6-8x performance improvement over an 800 G4x2? [edit: Oh,wait -- that's THIS thread!! Duh.] Whether true or not, whether the machine will arrive in a week or not, it is plausible! Processors are very complex devices and can't be characterized by a couple of simple numbers (i.e. MHz, X-bits, etc) -- there are many many things chip companies can do to make them go much faster. We've been stuck with the G4 for two years now, but one day (soon, I hope) Apple will unveil what comes next and you can bet that it will be a significant step up.

Even if we don't get G5 next week, a &gt;1 GHz Apollo w/ DDR memory, 1394b, and USB2 would be a welcome improvement. They'll need to get more price competitive if that's all it is, however. On the other hand, a G5 machine with a stunning leap in performance could command the traditional Apple pricing margin -- and I'm sure Steve is pushing for it really hard.

[ 12-29-2001: Message edited by: Programmer ]</p>

There is still one point that confuses me - will Apple use RapidIO or HyperTransport in their future products, or maybe both? I did some research in this area, but as already mentioned, very confusing...

Both Motorola and IBM are supporting RapidIO, and both companies have announced that their future CPU generations (like the G5) will support this bus. You will find nothing about HyperTransport on IBMs or Motorolas website.

On the other hand Apple supports HyperTransport, a bus that AMD wants to use with their future CPUs.

RapidIO and HyperTransport are not compatible, they cannot emulate each other and, as far as I know, there is no RapidIO/HyperTransport bridge (even not announced).

Some people say that RapidIO is the memory bus while HyperTransport is used to connect to PCI, but THAT'S NOT TRUE. As far as I know the 8540 offers a RapidIO bus plus an internal DDR Ram controller and a dedicated memory bus. This means that the memory will NOT be connected to the CPU using RapidIO (which makes much more sense to me).

I took a look at both the RapidIO and HyperTransport specs and to me it seems that RapidIO is much more powerful than HyperTransport. And as I already mentioned, the G5 will probably offer a RapidIO bus. You don't need HyperTransport for PCI or Ethernet either, as there are RapidIO/PCI(X) bridges as well as RapidIO/Ethernet ASICs. So it makes no sense at all to use HyperTransport on a G5 motherboard, doesn't it???

If Apple really wants to commit to Hypertransport this can only mean one of the following:

- Apple will use the G5 with a RapidIO/HyperTransport bridge, which is nonsense
- Apple will use the G5 with a RapidIO motherboard, and HyperTransport is meant for something else (but what?)
- Apple will use a version of the G5 that will not use RapidIO but HyperTransport (this would mean they had to develop this themselves, as IBM and Moto only support RapidIO, sounds very unlikely to me)

Has Apple ever said something about HyperTransport or RapidIO in public? Why does everyone expect a HyperTransport MB if the G5 apparently supports only RapidIO???



[ 12-29-2001: Message edited by: macrumorzz ]</p>

[quote]Originally posted by macrumorzz:
<strong>Has Apple ever said something about HyperTransport or RapidIO in public? Why does everyone expect a HyperTransport MB if the G5 apparently supports only RapidIO???
</strong><hr></blockquote>


Good questions. The only thing I know for sure is that Apple is one of the key members of the HyperTransport group. HT seems to be just a point-to-point serial interface between chips on the motherboard, albeit a really fast one. I don't know much about RapidIO, but this quote from their website is illuminating:

"This new high-performance, packet-switched interconnect technology was designed for embedded systems, primarily for the networking and communications markets."

Speculation is fun so I'll indulge a little:
- AMD is the primary force behind HT so if they were designing a G5 for Apple it would be HT.
- Apple's needs are quite different than IBM & Moto (who are obsessed with embedded systems), so perhaps they are doing that part of the G5 themselves? Or the whole design?
- Motorola isn't interested in HT, but if they were doing the G5 just for Apple they might put it in the design on request. They certainly wouldn't jump on the HT bandwagon for anything else they are doing.
- Either of these bus designs is really really fast!!

[ 12-29-2001: Message edited by: Programmer ]</p>

DaveGee, I don't understand why you were so dismayed by my lack of patience with the creator of this thread, which you yourself have dismissed as incredulous.

Thanks for trying to educate me about the purpose of these boards, but I've been a reader/member or these boards for years, and in case you haven't let me tell you there was a time when these boards provided a lot of real insight into the development of new Mac hardware.

Today, Apple has all but extinguished 'insider' information, and in its place has sprung up a flood of posters who are yanking our chains with vague reports and rehashed rumors. Frankly I'm tired of them and I'm tired of the people who justify them as being 'part of the fun' of these boards. There are lots of other BBS out there that cater to the Mac platform and I hit a lot of them. But the AI forums have always been a place where real information was discussed and debated. Today we joke about the 'I met this guy who works for Apple and he got pretty drunk and started telling me...' posts, but sadly they're becoming the norm.

I'd hate to see these boards de-evolve into something like the MacAddict boards, and I think that if we keep encouraging these absurd posts then that's exactly what will happen.

But that's just my opinion, I suppose. So ultimately I guess I'm curious why, if you're so quick to defend fahre451's right to post are you so interested in condeming mine?

[wow...I like it up on this soapbox...I think I can see my house from here...]

[quote]Originally posted by Programmer:
<strong>


It should be noted that running lots of apps is not a reason to require a 64-bit processor! Each application is limited to a 4 gigabyte address space of its own, but the operating system can manage multiple operating systems, and the PPC hardware is setup to address &gt;32 bits worth of physical address space (52-bits worth, I think?). Whether this is brought out to the bus to allow that much RAM to be used, I'm not sure, but the OS could juggle many apps with 4 gigs of virtual memory each.

</strong><hr></blockquote>

True, having a 64 bit chip does make it easier but it is not necessary. My point was that once people put more than 4GB of RAM in their machines, they're going to want each programme to be able to address it, and also programmers will start finding uses for it. This is not far away in time. I have produced a few pieces of software that at times would have benefitted from more than 32 bit pointers.
The current 7450 I believe has a 36 bit physical address bus.

Michael

[quote]Originally posted by mmicist:
<strong>
I have produced a few pieces of software that at times would have benefitted from more than 32 bit pointers.
</strong><hr></blockquote>


Heh, I know what you mean. One of the projects I've got on the back burner is anxiously awaiting a 64-bit machine... I remain hopeful that Apple will pull the rabbit out of the hat in a week and surprise everyone, but I wouldn't put money on it.

[ 12-29-2001: Message edited by: Programmer ]</p>

[quote]Originally posted by Talibabble:
<strong>
I know that NEXTSTEP (before it became Mac OSX) was ported to Sun Solaris SPARC, a 64 bit architecture, so it would make sense that a 64bit G5 would have little problems in porting OSX over to it. And they would reap a lot of benefits in that..
</strong><hr></blockquote>

The NEXTSTEP port never supported the UltraSPARC chip, which was the first 64-bit capable CPU shipped by Sun, so this really has no bearing on reality. The "best" Sun machine supported (shipped from Sun) was the Sun SPARCSTATION 20/71 (that's 71 as in "70MHz and some extra cache memory" IIRC - the code base for OS X have diverged quite a bit in the meantime)

There is also a weird common notion that 64-bit (or should we say more-bit) is inherently good - there is a non-trivial penalty wrt cache/RAM usage when bumping things up in "bitness" - without any real benefit unless you need:

a) The increased address space
b) The increased address space
c) The increased address space
d) support for "large" integers

Oh well.

[quote]Originally posted by DaveGee:
<strong>

This one line tells me this whole post is BS...

First comes human nature... Don't open that box Johnny... What do you think the first thing little Johnny does..

</strong><hr></blockquote>

"Little Johnny" is not a grown-up working at a real job.

I'm not making any statements about the original poster's veracity, but I am saying that if Apple is going to the trouble of sending out secure hardware prototypes, they would certainly do so under strict agreements with their testers stipulating that the testers will make no effort to open the cases or otherwise ascertain what's inside them. Some idiot cracking open such a unit would not only get himself into trouble, he'd probably keep any developmental hardware out of his company's hands for a good while after.

Would I be tempted to peek inside? Absolutely. Would I actually do it? No.