Well, they don't make that distinction yet.</strong><hr></blockquote>
I don't see any reason to think this would change. It seemed to me that most of the "low-end tower" theories came about through people trying to reconcile rumors of an upcoming super-fast chip (G5) with Mot's insistence that the G4 has a long life and many revs ahead of it. Answer: Apple is going to use both at the same time. Kind of a nice idea -- I'd happily buy a cheap G4 tower -- but I don't see that it's likely.
Ok, I read the first 15, or so posts, and these last two. So if I'm way out of it thats why. AS the thread started out I noticed a lot of G5 worshiping, and I the thing that no one said (as far as I read) was that the G5 has no Altavec/Velocity Engine yet everybody thinks it's the next big thing, and motorola's roadmap as of two weeks ago (the last time I looked) didn't have any G5 specs that blew me away.
I was happy with what was said about the G4 ugrades by the register. With those improvements (although I'm no processor expert) If you take into consideration the Velocity Engine the G4 seemed to be a much more powerfull processor.
Of course I think we should petition Apple/Motorola, and IBM to include the velocity engine on the G5.
Altivec is probably the most underappreciated technological advancment in microprocessor technolgy today. It's what makes a 2x 1GHz G4 encode a DVD 300% faster than a 2x 2GHz P4. That statistic, and plenty of others just like it get overlooked everyday, and I can't believe no one is concerned about loosing this advancment to a measly MHz race when we could have both.
<strong>Ok, I read the first 15, or so posts, and these last two. So if I'm way out of it thats why. AS the thread started out I noticed a lot of G5 worshiping, and I the thing that no one said (as far as I read) was that the G5 has no Altavec/Velocity Engine</strong><hr></blockquote>
RazzFazz: the current G4 processors can address 36-bits of physical space, but a single application's address space can only be 32-bits worth (due to pointer size). This means Apple could build machines which hold up to 16 GBytes, but no single process could use all of that directly.</strong><hr></blockquote>
The MPC7450 processor contains separate memory management units for instructions and data, supporting 4 Petabytes (2^52) of virtual memory and up to 64 Gigabytes (2^36) of physical memory. </strong><hr></blockquote>
Of course, you're right, a single pointer can only be 32 bits wide on a G4, but from the above text, and from descriptions like <a href="http://www.usenix.org/publications/library/proceedings/osdi99/full_papers/dougan/dougan_html/node3.html"; target="_blank">this one</a> (which also includes the diagram shown below), I was getting the impression that you could still get around the 4GB barrier by using multiple segments:
Of course, it wouldn't be quite as straightforward as having 64 bit pointers in the first place, but it seems like it could be done if really necessary, and the fact that it hasn't been done by Apple yet leads me to believe that the demand for huge address spaces isn't quite as high as some people seem to expect.
The "G5" according to what Moto has publicly said is not the "G5" that is discussed in Mac circles. The "G5" that Apple would use (if it exists) most certainly does have an AltiVec unit, and I agree that it is a terrific piece of technology. This processor would also be designed as a desktop powerhouse, and not the embedded processor that Moto discusses (the 8540). "G5" just standards for "5th Generation PowerPC", after all, and presumably there will be a next generation PowerPC desktop processor. If Moto doesn't build it I'm sure Apple will or will find somebody else who will... and they will ensure that it includes a VelocityEngine equivalent unit.
... correct info about PowerPC segment support omitted for brevity ...
</strong><hr></blockquote>
Damn! I was hoping nobody would mention that. Segments are evil and will hopefully never again rear their ugly heads. The WIntel world struggled under the burden of segmentation for years before coming out into the light, and I pray that Apple never goes this way. Darn you for even mentioning it in (reasonably) polite company!
Damn! I was hoping nobody would mention that.</strong><hr></blockquote>
Ooops...
[quote]<strong>Segments are evil and will hopefully never again rear their ugly heads. The WIntel world struggled under the burden of segmentation for years before coming out into the light, and I pray that Apple never goes this way.</strong><hr></blockquote>
Well, at least to me, the PPC segmentation model seems to make a hell of a lot more sense than the x86 segmentation model, especially the real mode one - overlapping 64k segments scattered throughout the address space in 16 byte steps anyone?
[quote]<strong>Darn you for even mentioning it in (reasonably) polite company!</strong><hr></blockquote>
<strong>Well, at least to me, the PPC segmentation model seems to make a hell of a lot more sense than the x86 segmentation model, especially the real mode one - overlapping 64k segments scattered throughout the address space in 16 byte steps anyone?</strong><hr></blockquote>
It is definitely more reasonable than the 286 segmentation model, but it is fairly close to the 386 (and onward) segmentation model. Using any segmentation model these days, however, is just going to break a lot of code. Developers would have to code specifically to support it in the same way that they have to code for AltiVec... but the payoff is quite a bit less.
4 gigabytes of addressable space ought to be enough for the vast majority (>99.99%) of software run on the Mac. Having a 64-bit address space lets you use some interesting techniques (usually in combination with virtual memory) to write algorithms in interesting new ways. The biggest reason to go to a 64-bit PowerPC is that then people who have programs that require 64-bit addressing can then port them to the Mac... right now there aren't many of them, but if the Hammer takes off in a big way then there will be a lot more. Apple should probably get a 64-bit PowerPC on deck within a year of AMD or Intel. If they happen to get there first then its a PR win, but little else.
It is definitely more reasonable than the 286 segmentation model, but it is fairly close to the 386 (and onward) segmentation model.
</strong><hr></blockquote>
Still different, though. A PPC segments marks a private address space, whereas the 386 ones are just mark an area inside the 386's 4GB virtual address space.
Then again, the differences don't really matter at all, given that everyone just seems to be using flat memory models these days anyway...
[quote]<strong>Using any segmentation model these days, however, is just going to break a lot of code. Developers would have to code specifically to support it in the same way that they have to code for AltiVec... but the payoff is quite a bit less.
</strong><hr></blockquote>
Well, as stated above, I was just thinking that if there really was strong a demand for larger address spaces as some believe, this might have been a way to go without having to go to a 64 bit chip, and obviously the demand wasn't quite high enough to justify it...
[quote]<strong>4 gigabytes of addressable space ought to be enough for the vast majority (>99.99%) of software run on the Mac.</strong><hr></blockquote>
Agreed. Whereas 16 bits have been immediately limiting for most users, and going to 32 bits was a necessity, the same isn't (well, at least not currently and in the near future) true for 32 vs. 64 bit.
[quote]<strong>The biggest reason to go to a 64-bit PowerPC is that then people who have programs that require 64-bit addressing can then port them to the Mac...</strong><hr></blockquote>
Yes, but I don't see why people would port to a hypothetical 64 bit Mac at all - those who can't live without 64 bits already use SPARCs, Alphas or Itaniums right now, and I see little incentive for them to abandon those in favor of the Mac.
[quote]<strong>Apple should probably get a 64-bit PowerPC on deck within a year of AMD or Intel. If they happen to get there first then its a PR win, but little else.</strong><hr></blockquote>
Agreed, again. That's why I guess it's not exactly on top of their priority list right now. Then again, I don't work there, so what do I know
<strong>Actually the motivation is putting the SAME box on the desk for basic day-to-day life, with all it's nicities, as is sitting in the Lab running straight Darwin releases and doing the real crunching. I know more than a couple prof's who kind of like the idea of being coddled with a warm and fuzzy GUI in the office that they can also do the dev work on. Saves plenty of space for more falling over piles of journals and last quarters papers! </strong><hr></blockquote>
Can save money too but yeah I know lots of people who want this for very similar reasons.
It is just less hassle to use 1 comp for both.Currently I have one comp on top of the desk and another under it. It's a little annoying <img src="graemlins/oyvey.gif" border="0" alt="[No]" /> I also have two downstairs in the study for when I don't want to work in my bedroom <img src="graemlins/lol.gif" border="0" alt="[Laughing]" />
[quote] Yes, but I don't see why people would port to a hypothetical 64 bit Mac at all - those who can't live without 64 bits already use SPARCs, Alphas or Itaniums right now, and I see little incentive for them to abandon those in favor of the Mac.<hr></blockquote>
Well certainly the GUI makes a difference. I don't know what using the Sun and SGI OS's are like (aside from the fact that they are UNIX variants) but I would guess depending on your preference (I know some like a more raw enviroment) OSX would be much better. Macs are attractive because of the whole package (hardware and software).
I noticed that the clock speed of alot of the processors in these machines are pretty low but of course there more of them. Kind of funny when you think about it. We wage endless battles with Wintel users over Mhz and Sun and SGI users are using much lower clock speeds per processor. They're machines just have more processors and more of the important technologies we have been talking about (faster bus, memory etc.).
Comments
<strong>
Well, they don't make that distinction yet.</strong><hr></blockquote>
I don't see any reason to think this would change. It seemed to me that most of the "low-end tower" theories came about through people trying to reconcile rumors of an upcoming super-fast chip (G5) with Mot's insistence that the G4 has a long life and many revs ahead of it. Answer: Apple is going to use both at the same time. Kind of a nice idea -- I'd happily buy a cheap G4 tower -- but I don't see that it's likely.
I was happy with what was said about the G4 ugrades by the register. With those improvements (although I'm no processor expert) If you take into consideration the Velocity Engine the G4 seemed to be a much more powerfull processor.
Of course I think we should petition Apple/Motorola, and IBM to include the velocity engine on the G5.
Altivec is probably the most underappreciated technological advancment in microprocessor technolgy today. It's what makes a 2x 1GHz G4 encode a DVD 300% faster than a 2x 2GHz P4. That statistic, and plenty of others just like it get overlooked everyday, and I can't believe no one is concerned about loosing this advancment to a measly MHz race when we could have both.
<strong>Ok, I read the first 15, or so posts, and these last two. So if I'm way out of it thats why. AS the thread started out I noticed a lot of G5 worshiping, and I the thing that no one said (as far as I read) was that the G5 has no Altavec/Velocity Engine</strong><hr></blockquote>
Says who?
<strong>
RazzFazz: the current G4 processors can address 36-bits of physical space, but a single application's address space can only be 32-bits worth (due to pointer size). This means Apple could build machines which hold up to 16 GBytes, but no single process could use all of that directly.</strong><hr></blockquote>
Actually, I got this from <a href="http://e-www.motorola.com/webapp/sps/site/prod_summary.jsp?code=MPC7450&nodeId=03M9430304504 67M98653" target="_blank">here</a>:
[quote]<strong>
The MPC7450 processor contains separate memory management units for instructions and data, supporting 4 Petabytes (2^52) of virtual memory and up to 64 Gigabytes (2^36) of physical memory. </strong><hr></blockquote>
Of course, you're right, a single pointer can only be 32 bits wide on a G4, but from the above text, and from descriptions like <a href="http://www.usenix.org/publications/library/proceedings/osdi99/full_papers/dougan/dougan_html/node3.html"; target="_blank">this one</a> (which also includes the diagram shown below), I was getting the impression that you could still get around the 4GB barrier by using multiple segments:
Of course, it wouldn't be quite as straightforward as having 64 bit pointers in the first place, but it seems like it could be done if really necessary, and the fact that it hasn't been done by Apple yet leads me to believe that the demand for huge address spaces isn't quite as high as some people seem to expect.
Feel free to correct me, though.
Bye,
RazzFazz
[ 02-13-2002: Message edited by: RazzFazz ]</p>
<strong>
... correct info about PowerPC segment support omitted for brevity ...
</strong><hr></blockquote>
Damn! I was hoping nobody would mention that. Segments are evil and will hopefully never again rear their ugly heads. The WIntel world struggled under the burden of segmentation for years before coming out into the light, and I pray that Apple never goes this way. Darn you for even mentioning it in (reasonably) polite company!
<strong>
Damn! I was hoping nobody would mention that.</strong><hr></blockquote>
Ooops...
[quote]<strong>Segments are evil and will hopefully never again rear their ugly heads. The WIntel world struggled under the burden of segmentation for years before coming out into the light, and I pray that Apple never goes this way.</strong><hr></blockquote>
Well, at least to me, the PPC segmentation model seems to make a hell of a lot more sense than the x86 segmentation model, especially the real mode one - overlapping 64k segments scattered throughout the address space in 16 byte steps anyone?
[quote]<strong>Darn you for even mentioning it in (reasonably) polite company!</strong><hr></blockquote>
Oh, I'm sooo sorry. No really.
Bye,
RazzFazz
[ 02-13-2002: Message edited by: RazzFazz ]</p>
<strong>Well, at least to me, the PPC segmentation model seems to make a hell of a lot more sense than the x86 segmentation model, especially the real mode one - overlapping 64k segments scattered throughout the address space in 16 byte steps anyone?</strong><hr></blockquote>
It is definitely more reasonable than the 286 segmentation model, but it is fairly close to the 386 (and onward) segmentation model. Using any segmentation model these days, however, is just going to break a lot of code. Developers would have to code specifically to support it in the same way that they have to code for AltiVec... but the payoff is quite a bit less.
4 gigabytes of addressable space ought to be enough for the vast majority (>99.99%) of software run on the Mac. Having a 64-bit address space lets you use some interesting techniques (usually in combination with virtual memory) to write algorithms in interesting new ways. The biggest reason to go to a 64-bit PowerPC is that then people who have programs that require 64-bit addressing can then port them to the Mac... right now there aren't many of them, but if the Hammer takes off in a big way then there will be a lot more. Apple should probably get a 64-bit PowerPC on deck within a year of AMD or Intel. If they happen to get there first then its a PR win, but little else.
<strong>
I hope your right, where did you get 60-70%?</strong><hr></blockquote>
1.5Ghz vs 1Ghz
0.13nm vs 0.18nm
Faster mobo
It's quite reasonable to expect that much of increase in performance
<strong>
It is definitely more reasonable than the 286 segmentation model, but it is fairly close to the 386 (and onward) segmentation model.
</strong><hr></blockquote>
Still different, though. A PPC segments marks a private address space, whereas the 386 ones are just mark an area inside the 386's 4GB virtual address space.
Then again, the differences don't really matter at all, given that everyone just seems to be using flat memory models these days anyway...
[quote]<strong>Using any segmentation model these days, however, is just going to break a lot of code. Developers would have to code specifically to support it in the same way that they have to code for AltiVec... but the payoff is quite a bit less.
</strong><hr></blockquote>
Well, as stated above, I was just thinking that if there really was strong a demand for larger address spaces as some believe, this might have been a way to go without having to go to a 64 bit chip, and obviously the demand wasn't quite high enough to justify it...
[quote]<strong>4 gigabytes of addressable space ought to be enough for the vast majority (>99.99%) of software run on the Mac.</strong><hr></blockquote>
Agreed. Whereas 16 bits have been immediately limiting for most users, and going to 32 bits was a necessity, the same isn't (well, at least not currently and in the near future) true for 32 vs. 64 bit.
[quote]<strong>The biggest reason to go to a 64-bit PowerPC is that then people who have programs that require 64-bit addressing can then port them to the Mac...</strong><hr></blockquote>
Yes, but I don't see why people would port to a hypothetical 64 bit Mac at all - those who can't live without 64 bits already use SPARCs, Alphas or Itaniums right now, and I see little incentive for them to abandon those in favor of the Mac.
[quote]<strong>Apple should probably get a 64-bit PowerPC on deck within a year of AMD or Intel. If they happen to get there first then its a PR win, but little else.</strong><hr></blockquote>
Agreed, again. That's why I guess it's not exactly on top of their priority list right now. Then again, I don't work there, so what do I know
Bye,
RazzFazz
<strong>Actually the motivation is putting the SAME box on the desk for basic day-to-day life, with all it's nicities, as is sitting in the Lab running straight Darwin releases and doing the real crunching. I know more than a couple prof's who kind of like the idea of being coddled with a warm and fuzzy GUI in the office that they can also do the dev work on. Saves plenty of space for more falling over piles of journals and last quarters papers!
Can save money too but yeah I know lots of people who want this for very similar reasons.
It is just less hassle to use 1 comp for both.Currently I have one comp on top of the desk and another under it. It's a little annoying <img src="graemlins/oyvey.gif" border="0" alt="[No]" /> I also have two downstairs in the study for when I don't want to work in my bedroom <img src="graemlins/lol.gif" border="0" alt="[Laughing]" />
[ 02-14-2002: Message edited by: Telomar ]</p>
Well certainly the GUI makes a difference. I don't know what using the Sun and SGI OS's are like (aside from the fact that they are UNIX variants) but I would guess depending on your preference (I know some like a more raw enviroment) OSX would be much better. Macs are attractive because of the whole package (hardware and software).
I noticed that the clock speed of alot of the processors in these machines are pretty low but of course there more of them. Kind of funny when you think about it. We wage endless battles with Wintel users over Mhz and Sun and SGI users are using much lower clock speeds per processor. They're machines just have more processors and more of the important technologies we have been talking about (faster bus, memory etc.).