Welcome to the MacNN Forums.

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

You are here: MacNN Forums > Software - Troubleshooting and Discussion > Mac OS X > Questions about G5 memory management in X.2.7 and Panther

Questions about G5 memory management in X.2.7 and Panther
Thread Tools
Eug
Clinically Insane
Join Date: Dec 2000
Location: Caught in a web of deceit.
Status: Offline
Reply With Quote
Sep 11, 2003, 11:25 AM
 
OK we all know that the G5 can take 8 GB (or 16 GB) physically, but how does this translate in real-world usage? I've seen several explanations, but they seem to contradict each other.

ie.

How much of the memory does the OS take for itself?

What apps can make use of more than 2-4 GB memory? Are all 32-bit apps still limited in terms of the max memory they can access?

What is the largest file size directly accessible in memory? IOW, how many GB per process for 32-bit and 64-bit apps (or updated 32-bit apps)?

How much of memory allocated to an app must be reserved for the app itself?
     
Forum Regular
Join Date: Jan 2001
Location: Boston, MA
Status: Offline
Reply With Quote
Sep 11, 2003, 11:47 AM
 
How much of the memory does the OS take for itself?
That's actually pretty hard to determine at any given time. Mac OS X is a very dynamic OS in that it loads and unloads system components as they're needed. Since UNIX-based OSes are a collection of small programs and daemons, the lines get blurry about whether you're allocating memory for system purposes or for user purposes.

What apps can make use of more than 2-4 GB memory? Are all 32-bit apps still limited in terms of the max memory they can access?
32-bit apps are limited to a theoretical 4GB limit due to the 32-bit pointer size. In order to access more memory, you have to recompile the app to be a 64-bit binary, then you can handle the larger pointer sizes and thus a larger memory address space. The nice part about Apple's implementation (unlike 64-bit Windows XP for instance) is that 32- and 64-but apps can live as peers together and each will execute natively -- there's no emulation involved at all.

What is the largest file size directly accessible in memory? IOW, how many GB per process for 32-bit and 64-bit apps (or updated 32-bit apps)?
I don't think I understand the question. Since Mac OS X features virtual memory and protected memory spaces, each app gets its own virtual address space and can address as much of its own 32-bit memory space as possible. That's not to say that in reality if you have 10 apps that each request 4GB of RAM that they're going to get it. VM and protected memory provide the illusion of isolation while managing the shared bits.

How much of memory allocated to an app must be reserved for the app itself?
Remember, one of he nice things about the Mac OS X memory model is that applications no longer have to worry about setting a memory partition as in Mac OS 9. By default, each app gets a private memory space to work with that has a virtual 32-bit address space to provide memory. Apps can divy up that space anyway they want, but Apple's VM system won't let it stomp on other process's address space nor let the system run out of memory.

Does this help?
     
Eug  (op)
Clinically Insane
Join Date: Dec 2000
Location: Caught in a web of deceit.
Status: Offline
Reply With Quote
Sep 11, 2003, 12:02 PM
 
Thanks, I think I understand. Let me see if I get this straight.

1) 32-bit apps still have a 4 GB limit, but some 32-bit apps can be updated to make use of more (up to 42-bit memory addressing). (ie. They do not suffer a 2 GB per process limitation as previous iterations of Windows.)

2) 64-bit apps can work in Panther alongside 32-bit apps, and access tons of memory.

So are we saying that in terms of memory addressing specifically, Panther is a true 64-bit/42-bit OS? (I'm ignoring all the lacking other 64-bitness features at the moment.)

Question though. I thought the Opteron beta of Win XP 64 was such that 32-bit apps CAN run along side of 64-bit apps. Not true? (I'm not talking about the Itanium 2 Win XP 64.)
     
Forum Regular
Join Date: Jan 2001
Location: Boston, MA
Status: Offline
Reply With Quote
Sep 11, 2003, 01:58 PM
 
Originally posted by Eug:
1) 32-bit apps still have a 4 GB limit, but some 32-bit apps can be updated to make use of more (up to 42-bit memory addressing). (ie. They do not suffer a 2 GB per process limitation as previous iterations of Windows.)
Right. The 42-bit addressing is really the physical addressing the chip performs. Your app will see a full 64-bit memory address space. If you do the math, an real 64-bit address is such a mind-boggling big number that it's not surprising that the actual hardware limit is 42-bits

2) 64-bit apps can work in Panther alongside 32-bit apps, and access tons of memory.

So are we saying that in terms of memory addressing specifically, Panther is a true 64-bit/42-bit OS? (I'm ignoring all the lacking other 64-bitness features at the moment.)
From all that I've seen, it supports a full 64-bit memory address space. Whether or not the entire OS has been recompiled as 64-bit code is doubtful. I'm sure Apple will focus on the places that matter the most like the filesystem, memory management, process communication, etc.

Question though. I thought the Opteron beta of Win XP 64 was such that 32-bit apps CAN run along side of 64-bit apps. Not true? (I'm not talking about the Itanium 2 Win XP 64.)
Hmmm...front what I've heard, WinXP64 works very similar to how WinNT and Win2000 handled 16-bit app binaries: they execute in the Windows-on-Windows environment (WOW.EXE) to provide compatibility. This may change in the future though
     
Eug  (op)
Clinically Insane
Join Date: Dec 2000
Location: Caught in a web of deceit.
Status: Offline
Reply With Quote
Sep 11, 2003, 02:16 PM
 
Hmmm...front what I've heard, WinXP64 works very similar to how WinNT and Win2000 handled 16-bit app binaries: they execute in the Windows-on-Windows environment (WOW.EXE) to provide compatibility. This may change in the future though
OK you're right according to the review below. At least it's better than Itanium 2 though, although not as good as with the G5. From here.

3) Will all my programs work?
Here's the beauty of the AMD64 architecture. Everything just works. No fuss, no hassle, no nothing. Just as the Opteron/Athlon 64 architecture can execute 32-bit and 64-bit code side by side, so can Windows XP 64-bit Edition for AMD64. You can be running a 32-bit applications right alongside a new 64-bit application, both running at full speed with no slowdowns. Everything, such as games, graphics applications, programming utilities, will run as seamlessly in XP 64-bit edition as they do in today's 32-bit editions of XP.
As many of you know, the Intel's 64-bit Itanium and Itanium2 processors can run 64-bit and 32-bit programs simultaneously, but Itanium handles 32-bit software through emulation. While I have not personally tested 32-bit software on Itanium, I'm not qualified to venture the performance hit this takes on the software. From all indications, 32-bit performance is not anywhere near "full speed" on the Itanium.

With simultaneous 32-bit and 64-bit program execution abilities, software compatability really becomes a non-issue. All of our 32-bit applications installed and ran perfectly fine without any special installation instructions. This allows you to use all of your current software which is working today, and as AMD64 variants are released over time, you can upgrade and see better performance. Pretty simple, we think.

It’s not as simple as it may seem though. There's an interesting concept going on which allows Windows XP 64-bit edition to run 32-bit programs, which sounds worse than it actually is, Windows On Windows 64. (WoW64 for short)

WoW64 is implemented in both Windows XP and Windows Server for AMD64, and basically translates 32-bit function calls to 64-bit for the OS to understand it. While the nomenclature of WoW64 makes it appear that there is another 32-bit version of Windows running on top of the 64-bit variant, this is certainly not the case. WoW64 is completely seamless to the end user, and if I hadn't read about it in the AMD technical documentation, I would have had no idea that it was active and running on our test system.

From what we've seen, Windows-On-Windows 64 is absolutely seamless, and all 32-bit applications worked fine without ANY hassle. Keep in mind, the need for a layer between the application and the OS is an issue with Microsoft, not AMD's Opteron implementation. WoW64 is also used for 32-bit application use for Intel's Itanium processor as well.

4) Does WoW64 (Windows-On-Windows 64) decrease performance?
WoW64 does not have the performance penalties that full-scale 32-bit emulation incurs. But, as the CPU is translating 32-bit calls into 64-bit calls, there is always a bit of performance overhead, which takes away speed from the application. While we have not run any full-scale performance benchmarks on the operating system yet, from our early time with the OS it does not appear that WoW64 will take a noticeable performance hit for running 32-bit applications under Windows XP 64-bit Edition. If we were to estimate numbers, we would likely say under the 1-2% percentage point for performance loss in comparison to a 32-bit operating system.

Our folks at AMD say any performance loss associated with WoW64 will likely be overshot by the performance gains one will see with the efficiency of 64-bit drivers and 64-bit memory management. In short, 32-bit games and applications should run just as fast on current Windows XP 64-bit Edition as they do on today's 32-bit Windows XP Professional.
     
Mac Enthusiast
Join Date: Jan 2002
Location: Trondhjem, Norway
Status: Offline
Reply With Quote
Sep 11, 2003, 06:43 PM
 
There have been tons of posts about this issue at Apple's SciTech list the latest days. You could go to lists.apple.com and look for a couple of posts from Ian Ollman and Ernest Prabhakar.

The way I've understood it, is that each app will be limited to 4GB, as this is limited by the OS at the present time. There may be some non-standard way of dealing with more than 4GB, but not by just compiling with a 64 bit option.

This is an excerpt from one of these posts:

Hi all,

There seems to be a bit of confusion on this topic. The short answer is
* The PowerPC G5 processor is fully 64-bit
* Mac OS X supports many, but not all, services using 64-bit integers
* Currently, sizeof(void *) == 4

I realize that some people take a rigid position that 64-bit computing -> 64-bit OS -> sizeof(void *) == 8. Which may be understandable given their problem space, but reality - especially when dealing with mass-market personal computers, not speciality workstations - is a bit more complicated, and different people benefit from Mac OS X's level of 64-bit support in different ways.

A more official explanation is below. Please let me know if there's any confusion about this.
Sincerely,
Ernest Prabhakar
Product Manager, UNIX & Open Source
Apple
     
Eug  (op)
Clinically Insane
Join Date: Dec 2000
Location: Caught in a web of deceit.
Status: Offline
Reply With Quote
Sep 11, 2003, 06:57 PM
 
Hmmm... That 4 GB per app limitation is disappointing (for the science/database types).

Is the limitation with X.2 only, or both X.2 and X.3? Can you post the more detailed explanation he mentioned? I'm not a member of the mailing lists.

I don't know what this means either: sizeof(void *) == 4
     
Dedicated MacNNer
Join Date: Mar 2001
Location: Iowa City, IA
Status: Offline
Reply With Quote
Sep 11, 2003, 09:11 PM
 
sizeof (void *) == 4 translates:

The size of a generic pointer (a variable capable of containing the address of anything in memory) is equal to four characters (a character, in C, traditionally takes up 1 byte).

Essentially, he's saying that the pointer size, and therefore the size of the memory available to any given process, is 4 bytes, or 32 bits.
James

"I grew up. Then I got better." - Sea Wasp
     
Grizzled Veteran
Join Date: Apr 2001
Status: Offline
Reply With Quote
Sep 12, 2003, 01:45 AM
 
AMD 64 bit chips will run 32 and 64 bit x86 code because it is a 54 bit x86 processor, same as how the G5 is a 64 bit Power PC.

The Itanium on the other hand is an IA64 chip. It's a new type of processor, similar to how an Alpha, PA-RiSC and PowerPC are all non x86 chips. This is why "32 bit" peformance on an Itanium is slow. It's not because the program is 32 bit, it is because it is an X86 program and has to be emulated. Any 64 bit processor can, and does quite frequently run 32 bit code with little to no peformance hit.
     
Eug  (op)
Clinically Insane
Join Date: Dec 2000
Location: Caught in a web of deceit.
Status: Offline
Reply With Quote
Sep 12, 2003, 11:31 AM
 
So X.3 Panther still has a 4 GB per app limitation too? Disappointing.
     
Mac Enthusiast
Join Date: Jan 2002
Location: Trondhjem, Norway
Status: Offline
Reply With Quote
Sep 12, 2003, 11:59 AM
 
Even if we're still limited to 32bit virtual memory addressing, this shouldn't be too surprising nor disappointing. Apple must see to that the 32 to 64 bit transition is smooth for most users. That's most important. I'm sure they have their reasons for not having done everything already.

There are a lot of scitech stuff that should work well with 4GB. It's better to think of all the doors that have been opened with the G5, than to focus on those that are still closed.

Before the G5, most people looked away from Macs for scitech work simply because of performance (floating point math and memory bandwidth). I've seen many scitech benchmarks the recent days, from various fields, and things look GOOD for the G5.

There was a post from one developer of PYMOL, a molecular modeling app: Here's an excerpt:

In my own hands, a dual 2.0 Ghz G5
effectively competes with a dual 3.0 Ghz Pentium 4 Xeon for generating
PyMOL ray-traced movies in head-to-head comparisons. OpenGL speed is
also top notch.
He's also got some very nice remarks about Apple's profiling tools (like Shark), saying that they helped him increase performance on not only the Mac, but the PC too.

BTW, Eug, if you want to browse the scitech list, it's possible to use the archives, without actually being on the mailing list.
     
Addicted to MacNN
Join Date: Apr 2001
Location: The bottom of Cloud City
Status: Offline
Reply With Quote
Sep 12, 2003, 12:36 PM
 
Heck, I want to see who in the "real world" needs 8 Gigs of RAM.

Damn that Photoshop twirl filter

"Ahhhhhhhhhhhhhhhh"
     
Eug  (op)
Clinically Insane
Join Date: Dec 2000
Location: Caught in a web of deceit.
Status: Offline
Reply With Quote
Sep 12, 2003, 01:37 PM
 
Originally posted by Severed Hand of Skywalker:
Heck, I want to see who in the "real world" needs 8 Gigs of RAM.

Damn that Photoshop twirl filter
A lot of the scientific types are anxiously awaiting mainstream machines truly capable of 6-8 GB per app.

Hell, even 4 years ago, one of the biochemistry labs next to the one I was working in was using 2 GB databases on individual workstations. People these days are talking about single databases of well over 4 GB.

Before the G5, most people looked away from Macs for scitech work simply because of performance (floating point math and memory bandwidth). I've seen many scitech benchmarks the recent days, from various fields, and things look GOOD for the G5.

There was a post from one developer of PYMOL, a molecular modeling app: Here's an excerpt:
Speaking of PyMol, here are some AMBER numbers:

Speed comparisons (higher is better)
Code:
g77 (G4 400) : xlf (G4 400) 1 : 1.337 g77 (G4 400) : ifc (P4 1.7G) 1 : 3.213 g77 (G4 400) : ifc (Opteron 1.4G) 1 : 4.473 g77 (G4 400) : ifc (Xeon 2G) 1 : 4.562 g77 (G4 400) : g77 (G5 2G) 1 : 4.808 g77 (G4 400) : ifc (P4 2.4G) 1 : 5.810 g77 (G4 400) : xlf (G5 2G) 1 : 7.118
It would seem a G5 2.0 with IBM's xlf is about 50% faster than g77 with the same Fortran code.
(Last edited by Eug; Sep 12, 2003 at 01:55 PM. )
     
Junior Member
Join Date: Jan 2001
Location: California, USA
Status: Offline
Reply With Quote
Sep 12, 2003, 03:54 PM
 
Originally posted by Eug:
Hell, even 4 years ago, one of the biochemistry labs next to the one I was working in was using 2 GB databases on individual workstations. People these days are talking about single databases of well over 4 GB.
It isn't for scientific usage, but my university has a database that contains nearly 35 GBs of raw data. One could see how having a database app that could access 8 GBs of RAM would be useful when doing searches, etc. with that much data. My university isn't even that large--around 5000 students at any given time. I imagine that a much larger university would have even larger databases that could benefit. Sadly, I don't think they will ever put their database on an Apple computer. Campus politics, you know.

-Joel
     
Mac Enthusiast
Join Date: Jan 2002
Location: Trondhjem, Norway
Status: Offline
Reply With Quote
Sep 12, 2003, 06:51 PM
 
Originally posted by Severed Hand of Skywalker:
Heck, I want to see who in the "real world" needs 8 Gigs of RAM.

Damn that Photoshop twirl filter
Photoshop, what's that????

Numerical solving of partial differential equations...that's where the action is.
     
Addicted to MacNN
Join Date: Apr 2001
Location: The bottom of Cloud City
Status: Offline
Reply With Quote
Sep 12, 2003, 10:15 PM
 
Originally posted by alien:
Photoshop, what's that????

Numerical solving of partial differential equations...that's where the action is.
I gotta wonder in the end what percentage of G5's actually have more then 4 gigs of RAM put in em. 0.01%?

"Ahhhhhhhhhhhhhhhh"
     
Giv
Fresh-Faced Recruit
Join Date: Mar 2003
Status: Offline
Reply With Quote
Sep 12, 2003, 11:27 PM
 
Originally posted by Drakino:
AMD 64 bit chips will run 32 and 64 bit x86 code because it is a 54 bit x86 processor, same as how the G5 is a 64 bit Power PC.

The Itanium on the other hand is an IA64 chip. It's a new type of processor, similar to how an Alpha, PA-RiSC and PowerPC are all non x86 chips. This is why "32 bit" peformance on an Itanium is slow. It's not because the program is 32 bit, it is because it is an X86 program and has to be emulated. Any 64 bit processor can, and does quite frequently run 32 bit code with little to no peformance hit.
Itanium2 processors run 32bits programs quite fast, if they are compiled for the Itanium instruction set. The processor still runs in "pure" 64bits, the 32bits memory model is simply a software convention. As of today this mode is only offered by HP-UX, neither Linux nor Windows64 offer a native 32bits mode today (a big mistake IMO).

Obviously you are thinking about x86 (IA32) 32bits binaries, but I am getting tired of seeing this claim that Itanium is slow on 32bits apps. Note also that Itanium's x86 "emulation" is quite adequate for office applications. I'm sure an Itanium2 1.5Ghz workstation would run all my office applications a good deal faster than the Windows box I use at work (4 years old), and would scream on native code.
     
Fresh-Faced Recruit
Join Date: Jan 2002
Status: Offline
Reply With Quote
Sep 13, 2003, 01:48 AM
 
Originally posted by Giv:
Itanium2 processors run 32bits programs quite fast, if they are compiled for the Itanium instruction set. The processor still runs in "pure" 64bits, the 32bits memory model is simply a software convention. As of today this mode is only offered by HP-UX, neither Linux nor Windows64 offer a native 32bits mode today (a big mistake IMO).

Obviously you are thinking about x86 (IA32) 32bits binaries, but I am getting tired of seeing this claim that Itanium is slow on 32bits apps. Note also that Itanium's x86 "emulation" is quite adequate for office applications. I'm sure an Itanium2 1.5Ghz workstation would run all my office applications a good deal faster than the Windows box I use at work (4 years old), and would scream on native code.
As I recall, an 800MHz Itanic ran X86 code at 75MHz Pentium speed ( Pentium 1 w/ new MMX!) This is a hardware implementation built into the Itanic - which was a funny thing to the Corueso Transmeta chip -including Linus Torvalds - since software is ALWAYS slower.....yet they had 500KB on a RISC CPU running about 70%+ )
*** A 300MHz 603e emulated a 90MHz x86 PC***
Now, as for the New Itanic, now at blazing speeds of 1.5GHz, which one are you referring to?? ( Why can't Intel even keep up with IBM???) There is the $4,000+ Model with 6 MB of cache - since after 1MB, each MB obly returns a 2% or less gain, at extreme cost, why the need for this expensive hack on such an advanced CPU???
Then we have a 1.5GHz Itanic, with only 1.5MB cache for a steal of only $1100, which compares poorly to P4's 3GHz @ $599, or a dual Xeon System for only $4100 -system with better performance - for less than JUST the CPU - on Itanic!

Besides, since the Itanic has no software, and the hardware for 64 bit use is ridiculously expensive.......most former SGI, SUN, IBM workstation customers are not spending 60 grand on a workstation.......rather racks of mass produced, cheap, PC parts.....and using clusters to simulate massively parallel workstations....or exceed them by far............besides the cheapest dual processor system is a Dual G5 - 1100 of them make a top 5 Supercomputer on earth.....at a VERY low price on Teraflops....
( You should see how fast it rips MP3's!)

According to SPEC, IBM Power 4+ (Mother of ALL CPU's), kills all CPU's, of course ALL are 64 bit RISC; Alpha, MIPS, Sparc, HP-RISC, etc. Power 4+ slaughters all of them in just Integer & Floating Point - now throw a 1/2 clock system bus ( so 8GB RAM run as fast as a L2 Cache 8GB/sec from RAM to CPU! ) not to mention, AltiVec has been held back by bandwidth - serious gigaflopaage when we have bandwidth for 128 bit Vectors + 2 Complex 64 bit Floats + 2 complex Integers/ per clock cycle - the Power4+ has no Vector unit.... Now the 970 uses Apple's bus, at 1/2 CPU clock, and Apples AltiVec, which I don't know if Apple will license IBM to sell for Linux....we'll see....

Itanic is a horrid brain dead design! Only surpassed by the brain dead x86 - which takes CISC coverts to RISC -excecutes code faster - then converts back into CISC for a complete intruction.......why not use RISC, and emulate DOS & old code in software!!! Morons! See Apple 68k on PPC, etc.
BUY AAPL STOCK! It will be going WAYYY UP!
     
Eug  (op)
Clinically Insane
Join Date: Dec 2000
Location: Caught in a web of deceit.
Status: Offline
Reply With Quote
Sep 13, 2003, 04:10 AM
 
As much as I like the G5, the above post seems like meaningless and unjustified pro-G5 anti-Intel rambling.

I gotta wonder in the end what percentage of G5's actually have more then 4 gigs of RAM put in em. 0.01%?
Yeah, probably <1%. But that will likely change in the next little while as needs expand and memory gets cheaper.

Hell, I started off with 64 MB with my CURRENT motherboard, which was in a PC running with a 366 MHz CPU. I'm running now with 512 MB. (Running a 1.4 GHz CPU now. The motherboard doesn't support more than 768 MB RAM.)
     
Senior User
Join Date: Dec 2002
Location: Portland, OR
Status: Offline
Reply With Quote
Sep 13, 2003, 05:18 AM
 
Originally posted by Eug:
As much as I like the G5, the above post seems like meaningless and unjustified pro-G5 anti-Intel rambling.
Agreed that it is maybe a little harsh. On the other hand, the market hasn't exactly jumped all over itself to buy Itaniums. And it's not like they haven't been available, or that Intel hasn't been marketing them to enterprise customers.

On the other hand, most admins that I talk with feel like the Power4 is a great CPU, but that being stuck with AIX is too big of a liability (outside of government and healthcare anyway.) It is tough to keep updated with your apps as vendors tend to support AIX dead-last of all the major Unixes.

Full disclosure: I admin Solaris on SPARC for a living but my companies product only runs on Oracle on top of AIX or HPUX (don't ask me why.. I don't know..) So I might be a biased against AIX..
     
Mac Elite
Join Date: Mar 2001
Status: Offline
Reply With Quote
Sep 13, 2003, 11:34 AM
 
From Dr. Ernie Prabhakar:

Apple on 64-bit-ness

Subject: Apple on 64-bit-ness
To: scitech@lists.apple.com
From: Ernest Prabhakar <prabhaka@apple.com>
Date: Wed, 10 Sep 2003 12:10:08 -0700

Hi all,

There seems to be a bit of confusion on this topic. The short answer is
* The PowerPC G5 processor is fully 64-bit
* Mac OS X supports many, but not all, services using 64-bit integers
* Currently, sizeof(void *) == 4

I realize that some people take a rigid position that 64-bit computing -> 64-bit OS -> sizeof(void *) == 8. Which may be understandable given their problem space, but reality - especially when dealing with mass-market personal computers, not speciality workstations - is a bit more complicated, and different people benefit from Mac OS X's level of 64-bit support in different ways.

A more official explanation is below. Please let me know if there's any confusion about this.
Sincerely,
Ernest Prabhakar
Product Manager, UNIX & Open Source
Apple
----------------------------------------
Mac OS X Jaguar (10.2.7 and later) features a redesigned kernel and updated system software math libraries specifically for the 64-bit PowerPC G5 processor. The updated kernel delivers the most substantial benefits of 64-bit computing by breaking through the 4GB physical memory barrier enabling the kernel to use all the RAM that can be added to the new Power Mac G5 (currently 8GB).

The key functions of the system math and vector libraries have been hand tuned to make maximum advantage of new and faster math functions that the 64-bit G5 is capable of. This is a great because unmodified applications that use the system math functions will get an automatic speed up when run on the G5. For example, the square root function is implemented as a software algorithm when run on a G3 or G4 but on a G5 when a square root calculation is requested the math library uses the super-fast hardware instruction that the G5 has.

This approach brings the maximum benefit of 64-bit processing to the desktop personal computer market and does so with full native-speed compatibility with existing 32-bit applications. Because the PowerPC instruction set was designed initially with 64-bit instructions in mind, this transition is a smooth and simple one for our developers and customers.

Apple has also supplied a new compiler, GCC version 3.3 which generates optimal code for the new G5 machine model. Importantly, this compiler produces code that executes efficiently on G5, G4 and G3 systems so a single Mac OS X application runs on each of our support processor architectures. This allows developers to build and qualify a single version of their applications for the 32-bit and 64-bit Mac systems.

Mac OS X Panther takes the same approach to the G5 as Jaguar but will be able to optimized additional math functions based on feedback from the developer community.

== References ===
Optimizing for the Power Mac G5
<http://developer.apple.com/performan...imization.html> ):
Technical Note TN2086: Tuning for the G5: A Practical Guide
<http://developer.apple.com/technotes/tn/tn2086.html>
Technical Note TN2087: PowerPC G5 Performance Primer
<http://developer.apple.com/technotes/tn/tn2087.html>
Technical Note TN2090: Driver Tuning on Panther or G5 (Of interest only if you have written a device driver)
<http://developer.apple.com/technotes/tn/tn2090.html>
Power Mac G5 Performance White Paper (PDF)
http://www.apple.com/powermac/pdf/Po..._WP_071503.pdf


== Default Sizes ===
sizeof (char) == 1
sizeof (short) == 2
sizeof (int) == 4
sizeof (long) == 4
sizeof (long long) == 8
sizeof (void *) == 4
sizeof (void (*)(void)) == 4
sizeof (float) == 4
sizeof (double) == 8
sizeof (long double) == 8* [may change in the future]
sizeof (size_t) == 4
sizeof (off_t) == 8

== G5-Related Flags for GCC ===
-mcpu=970
This allows the compiler to use instructions only available on the G5 (also known as 970) processor.

-mtune=970
This tells the compiler to tune code as optimally as it can for the G5. This flag can be safely used by itself on code that may run on processors other than the G5, because code compatibility is not changed.

-mpowerpc64
In combination with the above flags, this flag tells the compiler to enable the G5's native 64-bit long long support for greatly enhanced performance when working with long longs. At times, the -force_cpusubtype_ALL flag may also be needed.
_______________________________________________
scitech mailing list | scitech@lists.apple.com
Help/Unsubscribe/Archives:http://www.lists.apple.com/mailman/listinfo/scitech
Do not post admin requests to the list. They will be ignored.
     
Giv
Fresh-Faced Recruit
Join Date: Mar 2003
Status: Offline
Reply With Quote
Sep 13, 2003, 12:46 PM
 
Originally posted by Armas:
As I recall, an 800MHz Itanic ran X86 code at 75MHz Pentium speed ( Pentium 1 w/ new MMX!)
You recall incorrectly, and the first Itanium was a complete failure, only used as a development vehicle. IIRC an Itanium2 1GHz was about equivalent to a 300Mhz P3 when emulating x86. That's plenty enough for migration purposes. Moreover Intel is now fielding their software emulator, which can give up to 2x performance boost on x86 emulation (whether this boost will be seen in real life I do not know, it looks good on benchmarks so far). Still not competitive with a P4, but that's not the goal.

Now, as for the New Itanic, now at blazing speeds of 1.5GHz, which one are you referring to?? ( Why can't Intel even keep up with IBM???) There is the $4,000+ Model with 6 MB of cache - since after 1MB, each MB obly returns a 2% or less gain, at extreme cost, why the need for this expensive hack on such an advanced CPU???
Why can't IBM keep up with the 3Ghz Pentium IV ? Your question is stupid, and you probably know it. As far as $4k for the topline processor, let's see, how much does a Power4 costs ? Oh, you can't buy one on the chip market, so you have no idea.


Then we have a 1.5GHz Itanic, with only 1.5MB cache for a steal of only $1100, which compares poorly to P4's 3GHz @ $599, or a dual Xeon System for only $4100 -system with better performance - for less than JUST the CPU - on Itanic!
Besides, since the Itanic has no software, and the hardware for 64 bit use is ridiculously expensive...
Let me help you. Go see the HP Itanium workstations, and remember to compare against workstations, not PCs. Also remember that those sell at a significant discount to enterprises, only use the listed prices as a maximum.


....most former SGI, SUN, IBM workstation customers are not spending 60 grand on a workstation....
Good thing because I do not find a $60K workstation listed.


( You should see how fast it rips MP3's!)
Let me guess, you have no idea how enterprises use computers, do you ? Itanium is not currently targeted at pimple-faced teenagers ripping MP3's and debating which processor company is the most 3l337. Thankfully the target market for Itanium is starting to realize that it is indeed a very good processor, ahead of the RISC competition on performance and with a significant lead on price. The real danger for Itanium is not Power (a worthy competitor but not a killer), it is the price/performance of x86 processors.


According to SPEC, IBM Power 4+ (Mother of ALL CPU's), kills all CPU's.
Uh, no. Unfortunately for you Itanium2 processors currently hold most of the speed records, often with a non-trivial margin. Go get a clue.

I don't mind seeing Itanium criticized, it certainly deserves some. However you are only spewing anti-Intel FUD and seem to be in denial and feeling insecure. Would Itanium be the product of AMD it would be praised as the solution to the world problems.

I've talked to people who saw an Itanium2 1Ghz provide 2x the performance of a Power4 1.3GHz _on the first compilation_ of their well-tuned scientific application. After this all the "Itanic" attacks look a bit juvenile. Itanium is not so easily dismissed anymore, to the chagrin of Intel competitors. Take everything with a grain of salt, whether it comes from Intel or its competitors.
     
Giv
Fresh-Faced Recruit
Join Date: Mar 2003
Status: Offline
Reply With Quote
Sep 13, 2003, 01:06 PM
 
Originally posted by geekwagon:
Agreed that it is maybe a little harsh. On the other hand, the market hasn't exactly jumped all over itself to buy Itaniums. And it's not like they haven't been available, or that Intel hasn't been marketing them to enterprise customers.
The market couldn't jump on them, even if it wanted, due to lack of applications and the immaturity of the platform. All those good reasons to avoid Itanium are slowly being addressed by Intel and its partners.
The first Itanium was a joke and Itanium2 hit the market in the mist of a recession. It will take a while longer (5 years?) to judge whether Itanium is a success in the marketplace.

... my companies product only runs on Oracle on top of AIX or HPUX (don't ask me why.. I don't know..) So I might be a biased against AIX..
Because Power/AIX and HP-UX (both PA an Itanum) are the fastest, most rock-solid (Unix) platforms for enterprise computing ? Solaris was the preferred platform for Unix developers (that is changing with Linux), but Sun enterprise systems are a good deal slower than offerings from IBM and HP. Application availability is a problem for AIX, since AIX never gained enough marketshare to make it worthwile for ISVs. HP-UX is one of the best-kept secret of the industry. Many like to dislike it (because it is slightly different from what they are used to, Solaris or Linux), yet it keeps being rated as the best enterprise-class Unix by companies and independent labs.

Sun is in a world of hurt right now. What kept them afloat, the familiarity with Solaris that came from their marketshare in the low-end, is disappearing. Developers are migrating off of Solaris and toward Linux. Suddenly Solaris will stop enjoying this advantage and will become a porting platform like AIX and HP-UX have always been.
     
Senior User
Join Date: Dec 2002
Location: Portland, OR
Status: Offline
Reply With Quote
Sep 13, 2003, 04:03 PM
 
Originally posted by Giv:
The market couldn't jump on them, even if it wanted, due to lack of applications and the immaturity of the platform. All those good reasons to avoid Itanium are slowly being addressed by Intel and its partners.
The first Itanium was a joke and Itanium2 hit the market in the mist of a recession. It will take a while longer (5 years?) to judge whether Itanium is a success in the marketplace.
I dunno. I have been hearing this same argument for a few years now and the pace of application development for Itanium doesn't really seem to be picking up. Why should developers port their apps if their customers aren't demanding it? And the customers don't care because the value isn't there yet. The only other reason would be if the chip opened up new possibilites for capabilities in their software, and apparently that hasn't been enough to get developers to specify that customers need to buy Itanium systems. Plus, the only hardware vendor they have really managed to get behind them is HP.



Because Power/AIX and HP-UX (both PA an Itanum) are the fastest, most rock-solid (Unix) platforms for enterprise computing ? Solaris was the preferred platform for Unix developers (that is changing with Linux), but Sun enterprise systems are a good deal slower than offerings from IBM and HP. Application availability is a problem for AIX, since AIX never gained enough marketshare to make it worthwile for ISVs. HP-UX is one of the best-kept secret of the industry. Many like to dislike it (because it is slightly different from what they are used to, Solaris or Linux), yet it keeps being rated as the best enterprise-class Unix by companies and independent labs.

I can't agree that HP/UX is that great. Some of their hardware is pretty nice (Superdome, etc) and is a great value price/performance compared to Sun, especially. However, the OS is such a pain in the a** to admin in so many ways. Any Unix where you still have to relink the kernel to add a tape drive is not modern and enterprise ready in my book. Even Linux and Darwin have dynamic kernel modules.


Sun is in a world of hurt right now. What kept them afloat, the familiarity with Solaris that came from their marketshare in the low-end, is disappearing. Developers are migrating off of Solaris and toward Linux. Suddenly Solaris will stop enjoying this advantage and will become a porting platform like AIX and HP-UX have always been.
Agreed. In fact, in the datacenter I administer, we are moving towards Linux for everything but our higher-end database servers (which will still be Solaris-SPARC.) I love Linux for it's great userland, but it is still no match for Solaris in scalability. Also, to get decent performance out of Linux you have to use x86 processors (so far) because that is the platform that most developers have on their desks. Unfortunately x86 architecture with it's archaic BIOSes and slow quad-pumped busses are not really in the same league as say Sun Enterprise hardware. Sure, you can buy more hosts for the same price, but not every application is easily clusterable.

Not to say that Sun is perfect, their CPUs are too slow for the price (especially in the low- and mid-range) and their OS could certainly use some modernization. I really wish they would port glibc to Solaris since no-one else seems able or willing to do it. And the way they manage patches is pretty hard to deal with (although it is getting better, and is miles better than HP last time I used them..) A more modern package manager would be nice too.

To attempt to bring this back on topic, I hope that G5 xServes come out soon. We have budget to replace just about every machine in my datacenter next year and I would like to evaluate Apple for a few of our applications. Now that Panther is based on FreeBSD 5.x and comes with a modern xterm things are getting very nice in the OS X world for Unix admins.
     
Giv
Fresh-Faced Recruit
Join Date: Mar 2003
Status: Offline
Reply With Quote
Sep 13, 2003, 09:08 PM
 
Originally posted by geekwagon:
I dunno. I have been hearing this same argument for a few years now and the pace of application development for Itanium doesn't really seem to be picking up.
I have contacts at multiple ISVs and they seem to be waking up. Alpha is going away, PA-RISC is going away, MIPS is going away (in the enterprise space). Intel and HP have been spending a good deal of money helping ISVs port to Itanium, and this is starting to pay off for them. Microsoft had record TPC-C numbers on an Itanium-based superdome, they are pushing Itanium and Windows Server 2003 for high-end enterprise solutions.

Remember also that the companies betting on Itanium are also big customers. Intel is moving its R&D to Itanium systems, that will force a bunch of suppliers to be available. I don't know what HP is doing.


I can't agree that HP/UX is that great. Some of their hardware is pretty nice (Superdome, etc) and is a great value price/performance compared to Sun, especially. However, the OS is such a pain in the a** to admin in so many ways. Any Unix where you still have to relink the kernel to add a tape drive is not modern and enterprise ready in my book. Even Linux and Darwin have dynamic kernel modules.
You are probably refering to HP-UX 10.20, which is, what, 6 years old now and unsupported since June ? It is similar to criticizing Linux because the 1.x kernel sucked, or complaining about the slowness of OS X based on Rhapsody previews.

HP-UX has had DLKMs since 11.00. It could be that developers have been slow in converting their drivers to DLKMs though. The latest release (11i V2 / 11.23) has removed almost all needs to relink and most kernel tunables are dynamic, so rebooting is also minimized. On that respect Linux and Darwin are way behind.

HP has also cleaned-up its act a good deal wrt. patches. HP-UX was the bane of sysadmins due to the constant stream of patches, but things have improved tremendously.


To attempt to bring this back on topic, I hope that G5 xServes come out soon. We have budget to replace just about every machine in my datacenter next year and I would like to evaluate Apple for a few of our applications. Now that Panther is based on FreeBSD 5.x and comes with a modern xterm things are getting very nice in the OS X world for Unix admins.
Indeed I am quite happy to see Apple push itself slowly (as they should) in the enterprise space. It did cost them too much to be absent from the enterprise server rooms. I believe that's a perfect trojan horse to reappear on business desktops. They seem to know what they are doing, I hope they won't make one of the moronic decisions they used to make that burned bridges in the enterprises.
     
Senior User
Join Date: Dec 2002
Location: Portland, OR
Status: Offline
Reply With Quote
Sep 13, 2003, 10:55 PM
 
Originally posted by Giv:
I have contacts at multiple ISVs and they seem to be waking up. Alpha is going away, PA-RISC is going away, MIPS is going away (in the enterprise space). Intel and HP have been spending a good deal of money helping ISVs port to Itanium, and this is starting to pay off for them. Microsoft had record TPC-C numbers on an Itanium-based superdome, they are pushing Itanium and Windows Server 2003 for high-end enterprise solutions.

Remember also that the companies betting on Itanium are also big customers. Intel is moving its R&D to Itanium systems, that will force a bunch of suppliers to be available. I don't know what HP is doing.
You might be right. Due to where I live (Hillsboro, OR) I have many friends/aquantances who are Intel employees. One of them is even a designer that designs the MB layouts and chassis that are used by most vendors of commodity Intel-based servers (almost none of these "systems vendors" actually design their own servers/pc's HPAQ seems to be an exception. I really like Proliants, too.) I probably get my pessimism from them as when you are a pawn for any largish company of course you are only going to whine about the not-so-good stuff that you have to put up with day to day. (I just think it's funny that all of Intel's names for their chips since the Coppermine are taken from local placenames. Tualatin, Willamette, etc.) And yes, they do give me a lot of crap for being a Mac user A few of them have verbally wished they had my Powerbook rather than their crappy old P3 Thinkpads though.


You are probably refering to HP-UX 10.20, which is, what, 6 years old now and unsupported since June ? It is similar to criticizing Linux because the 1.x kernel sucked, or complaining about the slowness of OS X based on Rhapsody previews.

HP-UX has had DLKMs since 11.00. It could be that developers have been slow in converting their drivers to DLKMs though. The latest release (11i V2 / 11.23) has removed almost all needs to relink and most kernel tunables are dynamic, so rebooting is also minimized. On that respect Linux and Darwin are way behind.
The last version I used was 11.00. 11i had *just* come out and I never had any machines that came with it. So, this was probably 2 years or so ago. The comment I had was a real one, I hooked up an HP tape drive and watched SAM relink the kernel and prompt for a reboot. It could be better now, but Solaris has had kernel modules, since what, 2.4? I don't know when exactly that they were first supported, but I know that 2.51 (which was the first version I ever worked with..) had them. Agreed on the kernel tunables. You've got to remember too that a LOT of customers were still using 10.2 until just recently as the transition to the more SysV'ish system in 11 borked a LOT of stuff. I know this was the case 2 years ago.


HP has also cleaned-up its act a good deal wrt. patches. HP-UX was the bane of sysadmins due to the constant stream of patches, but things have improved tremendously.

That is good to hear. Solaris still has a way to goes in this respect but they were better than HP last I used them. I still think they make it such a pain so you will buy the more expensive support contracts where they will send you customized patch clusters.



Indeed I am quite happy to see Apple push itself slowly (as they should) in the enterprise space. It did cost them too much to be absent from the enterprise server rooms. I believe that's a perfect trojan horse to reappear on business desktops. They seem to know what they are doing, I hope they won't make one of the moronic decisions they used to make that burned bridges in the enterprises.
One area in particular that concerns me about Apple is support. I can buy a support contract from any other major Unix vendor that would have someone onsite with a part in hand within a few hours of my opening a call. I even have local tech reps assigned to my account that I can call for whatever reason. And I'm not even a very big fish (well, I work for a Fortune 5 now but my site's datacenter is just not THAT large.) I just don't think that Apple has a service like that, and that is going to bar them from entry into a lot of datacenters. Sure, you can self-insure and keep spare boxes on hand for a farm of webservers, but you sure aren't going to do that for your bigger iron (which, admitedly Apple doesn't sell *yet*. I just hope when they make their actual push to be taken seriously in the enterprise they realize this. Obviously they can contract out the on-site stuff until they get large enough to employ their own staff like Sun does.
     
Eug  (op)
Clinically Insane
Join Date: Dec 2000
Location: Caught in a web of deceit.
Status: Offline
Reply With Quote
Sep 13, 2003, 11:27 PM
 
Maybe it's precisely because of that that Apple has been pushing slowly. Enterprise is new to them, and not only do they not quite have the hardware yet, they don't have quite the experience or expertise to compete at that level yet so they don't want to push too hard or they'll end up biting off more than they can chew...

Anyways back to memory...

What are the options in OS X to access more than 4 GB? "Partitioned" memory? Special modded OS components for the scientific types (eg. X.3 scientific version)? Wait for X.4?
     
Senior User
Join Date: Dec 2002
Location: Portland, OR
Status: Offline
Reply With Quote
Sep 14, 2003, 12:04 AM
 
Originally posted by Eug:
Maybe it's precisely because of that that Apple has been pushing slowly. Enterprise is new to them, and not only do they not quite have the hardware yet, they don't have quite the experience or expertise to compete at that level yet so they don't want to push too hard or they'll end up biting off more than they can chew...

Anyways back to memory...

What are the options in OS X to access more than 4 GB? "Partitioned" memory? Special modded OS components for the scientific types (eg. X.3 scientific version)? Wait for X.4?
When Sun went through the 64 bit conversion (well, they still are in a lot of ways..) They did it like this. At first, you could boot a 32 bit or 64 bit kernel, but the 32 bit was default. The 64 bit kernel allows you to run both 32 bit and 64 bit programs, but the true 32 bit kernel was there for people who had compatibility problems with their older software on the new kernel. Eventually, they changed the 64 bit kernel to default and left the 32 bit kernel as an option for people who need it (I hear it is going away in the next release though.)

All the system libraries are compiled into both 32 and 64 bit versions. Whenever an application runs, the linker is smart enough to link them with either the normal "32 bit" library, or to link them to special sparcv9 "64 bit" versions of the same libraries.

What this allows is for 32 bit applications and 64 bit applications to run at the same time, and 32 bit applications have all the same limitations they always have (pointer size, etc.) While 64 bit applications are able to take advantage of all the advantages of the 64 bit hardware.

Obviously this requires some tricky kernel stuff that I am sure Darwin doesn't currently know how to do. I am not a systems programmer, nor have I closely followed Darwin's design, but it seems like this would be the best way to handle the transition (it's already been proven to work..) It shouldn't cause any extra hassles for home-users or anything.

The only hassle would be difficulties in linking libraries to applications and whether both have a 32 or 64 bit version. Since it seems like almost nothing co-depends on each other in OS X (after all, Apple recommends you put all your libraries into your application bundle) unlike, say, Linux, this shouldn't be a problem. I haven't got a G5 (yet ) but it would be interesting to see exactly how they changed the kernel to handle the G5. I just checked and they don't have the kernel source posted for anything new than 10.2.6 so no help there.
     
Mac Elite
Join Date: Aug 2001
Status: Offline
Reply With Quote
Sep 14, 2003, 12:42 AM
 
To the people insulting the Itanium: Yes, it has its problems, but you don't insult the performance of anything that can hit 2000+ SPECfp. That's FAST. That said, it's still got quite a ways to go before it'll be able to emulate x86 fast enough to beat a native x86 proc on price/performance (Intel's new emulator should help a lot though).
     
Eug  (op)
Clinically Insane
Join Date: Dec 2000
Location: Caught in a web of deceit.
Status: Offline
Reply With Quote
Sep 14, 2003, 01:37 AM
 
sizeof (void *) == 4
Hmmm... This seems to be PO'ing a lot of people.

Not quite the same level of complaints as with Apple's GCC SPEC bakeoff, but nonetheless there is some pretty vocal Apple-bashing on various forums, about Apple's 64-bitness claims.

What's internet life without constant flaming...?
     
Senior User
Join Date: Dec 2002
Location: Atlanta, GA
Status: Offline
Reply With Quote
Sep 14, 2003, 01:59 AM
 
The nice part about Apple's implementation (unlike 64-bit Windows XP for instance) is that 32- and 64-but apps can live as peers together and each will execute natively -- there's no emulation involved at all.
I've never been sure why Microsoft designed Windows this way. They already use the same kind of method to run 16-bit programs under NT, although, there's virtually no performance hit -- everything runs fairly seamlessly. Reports I've seen on the new 64-bit XP say the same thing about running 32-bit programs.
     
   
Thread Tools
Forum Links
Forum Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On
Top
Privacy Policy
All times are GMT -5. The time now is 08:26 AM.
All contents of these forums © 1995-2011 MacNN. All rights reserved.
Branding + Design: www.gesamtbild.com
vBulletin v.3.8.7 © 2000-2011, Jelsoft Enterprises Ltd., Content Relevant URLs by vBSEO 3.3.2