Umm, the funding is most likely not from "Virginia Tech". It is most likely a grant for this specific task.
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Virginia Tech Supercomputer?
- Thread starter MacRumors
- Start date
- Sort by reaction score
Umm, the funding is most likely not from "Virginia Tech". It is most likely a grant for this specific task.
Re: Re: Re: G5 Fans
The speed is throttled down by the OS (OS X only). The default speed for the fans is full-bore. This was stated shortly after the announcement.
The speed is throttled down by the OS (OS X only). The default speed for the fans is full-bore. This was stated shortly after the announcement.
I read on the slashdot thread regarding this that VT has been in the market for a cluster for a while, and actually looked into Dell and HP before going G5. So it seems as if the purchase was approved before the G5 was announced.
(tig)
Wait till 64-bit OS
If you think the G5s are going to be fast now, just wait until Apple releases a truly 64-bit version of OSX, saying that VT does use OS X. That plus 64-bit apps, the G5s would be smoking!
As for the $9 Mil+ VT paid for them, don't forget that VT is an EDUCATIONAL INSTITUTION! That means that they'd probably get a discount. They might even have gotten still bigger discount considering they bought 1100!
If you think the G5s are going to be fast now, just wait until Apple releases a truly 64-bit version of OSX, saying that VT does use OS X. That plus 64-bit apps, the G5s would be smoking!
As for the $9 Mil+ VT paid for them, don't forget that VT is an EDUCATIONAL INSTITUTION! That means that they'd probably get a discount. They might even have gotten still bigger discount considering they bought 1100!
Doubt
I sorta doubt that the user experience / GUI will go 64-bit for quite some time.
Doing so would require simultaneous maintenance of OS X 32 & 64-bit builds... this will undoubtedly happen eventually, but I imagine Apple will make a managed effort at limiting the duration that this simultaneous maintenance would have to be endured... perhaps once G5's are in the majority of new sales? .. or when some major clients request such a thing??
of course... Apple has already stated that 64-bit apps will function now... just that the 'Finder' will remain 32-bit... since it's just an app like others you'd run (Graphic Converter, AOHell, Safari, Seti@Home, your Folding selection... and so-on)... I don't think it matters much.
I still want one NOW NOW NOW!! Time will tell
I sorta doubt that the user experience / GUI will go 64-bit for quite some time.
Doing so would require simultaneous maintenance of OS X 32 & 64-bit builds... this will undoubtedly happen eventually, but I imagine Apple will make a managed effort at limiting the duration that this simultaneous maintenance would have to be endured... perhaps once G5's are in the majority of new sales? .. or when some major clients request such a thing??
of course... Apple has already stated that 64-bit apps will function now... just that the 'Finder' will remain 32-bit... since it's just an app like others you'd run (Graphic Converter, AOHell, Safari, Seti@Home, your Folding selection... and so-on)... I don't think it matters much.
I still want one NOW NOW NOW!! Time will tell
Doubt it....
Do you have any reference that says that Apple claims that 64-bit applications are supported (that is, applications that see a 64-bit virtual memory space and deal with 64-bit memory pointers).
I didn't think so.... 10.2.7 (G5) and 10.3 support 32-bit applications, which can be optionally compiled to use a 64-bit integer data type with 32-bit pointers.
That's not a 64-bit application. For proof - AltiVec has been manipulating 128-bit chunks of data, but nobody calls the G4 a 128-bit system. G3/G4 and Pentium chips have 64-bit floating point, but nobody calls them 64-bit computers.
It's the width of the address pointer that matters, not the width of the largest datum.
Do you have any reference that says that Apple claims that 64-bit applications are supported (that is, applications that see a 64-bit virtual memory space and deal with 64-bit memory pointers).
I didn't think so.... 10.2.7 (G5) and 10.3 support 32-bit applications, which can be optionally compiled to use a 64-bit integer data type with 32-bit pointers.
That's not a 64-bit application. For proof - AltiVec has been manipulating 128-bit chunks of data, but nobody calls the G4 a 128-bit system. G3/G4 and Pentium chips have 64-bit floating point, but nobody calls them 64-bit computers.
It's the width of the address pointer that matters, not the width of the largest datum.
Yeah, BUT...
DOPE... you are indeed correct
it'll be a nice upgrade though... once supported fully.. right?
DOPE... you are indeed correct
it'll be a nice upgrade though... once supported fully.. right?
Would be nice though
It would be nice if the G5 & later processors were completely 128-bit, like Altivec & Apple shipped a completely 128-bit OS for it. Saying that everything else hardware-wise (memory paths, system controllers, etc.) were all 128-bit (or whatever the highest one is if it's higher) and operated at the same clock speed, these computers would be ***** fast! Damn! I'm a Computer Science major @ school & we learned about the basic I/O controllers & how the processors work (though still @ a very rudimentary level), if all the hardware ran @ the same bit-rate & clock speed, there'd be little t0 no bottleknecks when different parts of the hardware are communicating. However, there's not very much out there (for consumers anyway) in software to fully take advantage of this. But when there is, that would be a great day. Please correct me if any of my info. is incorrect.
It would be nice if the G5 & later processors were completely 128-bit, like Altivec & Apple shipped a completely 128-bit OS for it. Saying that everything else hardware-wise (memory paths, system controllers, etc.) were all 128-bit (or whatever the highest one is if it's higher) and operated at the same clock speed, these computers would be ***** fast! Damn! I'm a Computer Science major @ school & we learned about the basic I/O controllers & how the processors work (though still @ a very rudimentary level), if all the hardware ran @ the same bit-rate & clock speed, there'd be little t0 no bottleknecks when different parts of the hardware are communicating. However, there's not very much out there (for consumers anyway) in software to fully take advantage of this. But when there is, that would be a great day. Please correct me if any of my info. is incorrect.
Why get top spec ones for a cluster -- as i understand it what theyd need is the processors and some RAM -- plus the mobo and a small HDD to make 'em work. Oh, and a network card; fibrechannel or gigabit. No graphics card, no optical drive, no big hard disk, etc.
And at 1100 units you bet they got a discount. And an advertising requirement in the contract.
A
AhmedFaisal
Guest
Idiotic descision on Virginia Tech's part IMHO.
Completely dumb. The G5 Xserve Upgrade is only 2 months away (max) and price wise the Xserve Cluster node is less expensive than a dual CPU client. That way they would have had easily stackable 1U machines that were designed for exactly that purpose which would save both space and money. Again a sign that government folks same as university people are not capable to reasonably use money.
Cheers,
Ahmed
Completely dumb. The G5 Xserve Upgrade is only 2 months away (max) and price wise the Xserve Cluster node is less expensive than a dual CPU client. That way they would have had easily stackable 1U machines that were designed for exactly that purpose which would save both space and money. Again a sign that government folks same as university people are not capable to reasonably use money.
Cheers,
Ahmed
did you read the article?
They'll be using InfiniBand ... (up to 10 Gbps with low overhead and latency)
They'll be using InfiniBand ... (up to 10 Gbps with low overhead and latency)
keep studying
Keep studying, and you'll realize how silly your statement is.
The "bitness" of a processor almost always refers to the size of an address pointer register. The PPC970 (which Apple puts in the Power Mac G5) has 64-bit addressing, but only supports 42-bits of physical memory. That's 4096 GiB of RAM, though, which is unlikely to ever be reached with this chip.
The G4/P4/PPC970 already have 64-bit, 128-bit, and 256-bit internal datapaths - which is what's important for performance.
A "64-bit" computer lets each process address more than 4 GiB of RAM. Useful, but consider that IBM thinks that 42-bits is way more than will be needed during the lifetime of this processor.
And of course, Apple is shipping the PPC970 with a 32-bit operating system (yes, Panther is also 32-bit) - so the 4 GiB limit per process still exists.
Your wish for 128-bit won't be needed while any of us are alive - but I'm sure that the starships' Enterprise computers are more than 64-bit. It's silly.
Keep studying, and you'll realize how silly your statement is.
The "bitness" of a processor almost always refers to the size of an address pointer register. The PPC970 (which Apple puts in the Power Mac G5) has 64-bit addressing, but only supports 42-bits of physical memory. That's 4096 GiB of RAM, though, which is unlikely to ever be reached with this chip.
The G4/P4/PPC970 already have 64-bit, 128-bit, and 256-bit internal datapaths - which is what's important for performance.
A "64-bit" computer lets each process address more than 4 GiB of RAM. Useful, but consider that IBM thinks that 42-bits is way more than will be needed during the lifetime of this processor.
And of course, Apple is shipping the PPC970 with a 32-bit operating system (yes, Panther is also 32-bit) - so the 4 GiB limit per process still exists.
Your wish for 128-bit won't be needed while any of us are alive - but I'm sure that the starships' Enterprise computers are more than 64-bit. It's silly.
Re: Would be nice though
Actually, 128 bit Altivec and a 128 bit CPU are VERY different from what I understand. Altivec processes 4 separate 32 bit chunks at once (so basically 4 instructions in one clock cycle), while a 128 bit processor would just process one 128 bit piece of data, thus being VERY VERY Accurate, but not any faster.
And 128 bit addressing is useless, because right now we use 32 bits, which is 4 GBs or RAM, and the G5's use 42 bit addressing which is 4096 gigs of RAM, 128 bit addressing would let you have over
100,000,000,000,000,000,000,000,000,000,000,000,000
Bytes of RAM.
Actually, 128 bit Altivec and a 128 bit CPU are VERY different from what I understand. Altivec processes 4 separate 32 bit chunks at once (so basically 4 instructions in one clock cycle), while a 128 bit processor would just process one 128 bit piece of data, thus being VERY VERY Accurate, but not any faster.
And 128 bit addressing is useless, because right now we use 32 bits, which is 4 GBs or RAM, and the G5's use 42 bit addressing which is 4096 gigs of RAM, 128 bit addressing would let you have over
100,000,000,000,000,000,000,000,000,000,000,000,000
Bytes of RAM.
You're right
Regular consumers probably wouldn't need that much RAM. Maybe people doing something like the Earth simulator might, but still. What I was trying to get @ was that data would get to each part of hardware @ the same time (MHz) & could carry the same amount of data (bit-size). But I don't claim to be an expert on computers. Sure, I'm a CS major, but the stuff I learned so far is still REALLY rudimentary. So in you're replies, stay nice. We're all friends here.
Regular consumers probably wouldn't need that much RAM. Maybe people doing something like the Earth simulator might, but still. What I was trying to get @ was that data would get to each part of hardware @ the same time (MHz) & could carry the same amount of data (bit-size). But I don't claim to be an expert on computers. Sure, I'm a CS major, but the stuff I learned so far is still REALLY rudimentary. So in you're replies, stay nice. We're all friends here.
Also, if they waited for the Xserves, well, the Xserves wouldn't necessarily have the same megahertz rating.
So there.
So there.
Re: You're right
That's a good idea - and it's what even 32-bit computers are doing today with wide (64/128/256 bit) datapaths.
Having addresses wider than needed, however, is a liability. Many people think that recompiling a 32-bit program with 64-bit pointer will make it faster. More than likely, however, it will be a little bit slower - those pointers are bigger, and take up more memory, more memory bandwidth, and more of the caches.
If you don't need more than 4 GiB of memory in your application, you're better off with 32-bit addressing.
That's a good idea - and it's what even 32-bit computers are doing today with wide (64/128/256 bit) datapaths.
Having addresses wider than needed, however, is a liability. Many people think that recompiling a 32-bit program with 64-bit pointer will make it faster. More than likely, however, it will be a little bit slower - those pointers are bigger, and take up more memory, more memory bandwidth, and more of the caches.
If you don't need more than 4 GiB of memory in your application, you're better off with 32-bit addressing.
Xserves would be better
I think those who say that xServe clusters would be better are right. I don't think that, when clustering, you need so many hard drives, video cards, etc. Besides, xServes are a lot smaller and can be put in a rack. With a regular desktop like a Power Mac, there's the stylized case, all the PCI card space, CD/DVD & hard drive bays, etc. For clustering, all you really need is a hard drive for each motherboard, a networking device like ethernet or fiber channel for each motherboard, only one CD/DVD drive, preferably a burner for backup, and a case just big enough for all that. And since xServes can be put into racks, the room(s) that they'd be stored in would be more organized. However, I don't know how much heat a G5 & appropriate motherboard would give out so it may have to be put into a 2U chassis, but still, that's pretty good. And w/ an xRAID, I heard that Maxtor is shipping 320GB Serial-ATA drives so there's a lot of room. Also, think of the power requirements! W/ all those Power Macs, the switches/hubs used to connect them, etc., that gets kinda expensive.
I think those who say that xServe clusters would be better are right. I don't think that, when clustering, you need so many hard drives, video cards, etc. Besides, xServes are a lot smaller and can be put in a rack. With a regular desktop like a Power Mac, there's the stylized case, all the PCI card space, CD/DVD & hard drive bays, etc. For clustering, all you really need is a hard drive for each motherboard, a networking device like ethernet or fiber channel for each motherboard, only one CD/DVD drive, preferably a burner for backup, and a case just big enough for all that. And since xServes can be put into racks, the room(s) that they'd be stored in would be more organized. However, I don't know how much heat a G5 & appropriate motherboard would give out so it may have to be put into a 2U chassis, but still, that's pretty good. And w/ an xRAID, I heard that Maxtor is shipping 320GB Serial-ATA drives so there's a lot of room. Also, think of the power requirements! W/ all those Power Macs, the switches/hubs used to connect them, etc., that gets kinda expensive.
And I'm sure if they're ordering that many machines that Apple would've told them that the XServe would be out shortly, if it was a concern.
They're already mounting the G5 towers in customized racks. It would save real estate if they used Xserves, sure, but which of the two exists right now?
Originally posted by trog
If you were to charge that to Discover Card you would get approximately $97,000 cash back. Not bad.
if you have a credit card with a ten million dollar limit... i want to go have a few drinks with you...
pnw
Not always true. The Apple II is usually considered an 8-bit personal computer; but the 6502 CPU uses a 16-bit PC, address bus, and address pointers (zero page indirect). The Nintendo N64 usually configured the MIPS R4300i CPU in 32-bit address, 64-bit data mode.