Road to Mac OS X Snow Leopard: 64-bits, Santa Rosa, and the great PC swindle - Page 2

To be honest, I'd rather see a cogent rebuttal than a fake concession. Tell me what is wrong with my explanation and I'll either admit that indeed it takes 152.1x more memory to get reasonable performance on a 64-bit machine or expand upon my earlier points (depending on whether manage to convince me that I'm wrong).

I already told you what's wrong. longs, doubles, and pointers, and structs are double the size. The address space for an Objective-C object class is double the size, and the alignment of all these things are along 8-byte boundaries.

I didn't say the app would take up EXACTLY 2x the memory, I said ROUGHLY 2x. *ALL* 64-bit applications *WILL* take up at least moderately more memory, and in my experience, MOST 64-bit applications that a power user will use take up almost 2x the memory. There is no getting around it, and it's not Apple's fault.

http://developer.apple.com/documenta...1064-CH206-SW5

http://developer.apple.com/documenta...nkElementID_25

And by the way, yes, I do think you'll need 4x the memory in 64-bit than you will in 32-bit. Apple usually offers 1GB of memory in their current line of computers. This is woefully inadequate even for the 32-bit architecture. Apple should be offering their base systems with 2GB of memory. Anyone that sticks with the default 1GB quickly realizes they are swapping to disk like mad. Therefore, Apple is going to need to bump their default memory on new machines to 4GB when 10.6 comes out, in my opinion. If they are cheap and bump to 2GB people will be very unhappy with performance.

4GB == 1GB x 4, hence the 4x factor I used in my original post.

again, it really depends on the app. if you're something like microsoft word, where most of your memory is the huge chunk of code that does everything you could ever imagine, and the rest is text data in a pretty simple data structure, your memory requirements are unlikely to get much larger. If you're doing huge (sparse or not) integer matrix calculations, then I can see your point. However, in most consumer apps (i.e., not scientific ones), I'd say that most of the heap is filled with loaded user data files, UI graphics, and a few longs/pointers (doubles don't change in size). The alignment issue only becomes one when most of your memory is taken up by structs, which again I don't think is really the case.

Even in Objective C, if you allocate a bajillion NSStrings, do you really think the overhead of having larger pointers/coarser alignment in the structure offsets the rather large fixed cost of the actual string data you're putting in the strings, which is the same across architectures?

I'm not saying it isn't, but the situations in which your memory usage actually doubles are the exception, not the rule, in my opinion/experience. If I were to write a 100-line c program that reads in a large file and constructs a huge directed graph (with no significant data at the nodes) on the heap, then I'm pretty sure my memory usage would approximately double (assuming I used pointers to represent edges), but I still think this isn't the average case, and certainly does not warrant a "2x memory needed, 4x to get better performance".

As others have said already this article is full of misinformation, but they missed a major point. What 64 bit buys is more addressing more space. By using virtual memory every application is given the ENTIRE addressing space, 32 bit operating systems are thus limited to something like 3 gigs of memory use PER application. So you still benefit from having 4 or 8 gigs of ram, it just can't all be allocated to a single application. This is different of course from being completely useless as the article states. I don't know why I am posting this, no one is going to read it anyway....

That makes no sense. Because they included half the memory that they needed on 32-bit machines, and chose to fix that times the contested 2x figure in 64-bit machines, 64-bit needs 4x the memory?

You portrayed it as an inherent 64-bit property. If they were providing underpowered machines earlier, then that's just a marketing issue, and has nothing to do with 64-bit "needing" 4x the memory.

I apologize for that bit of confusion. My bottom line -- Apple's currently shipping baseline 1GB 32-bit machines will need to be 4GB 64-bit machines when 10.6 comes out in order to satisfy users and make them happy.

You can try this simple experiment yourself with Java. Find yourself a 64-bit capable machine. Install the 32-bit JVM and the 64-bit JVM. Run an app like Star Office. You will see that the 64-bit app takes up almost 2x the memory that the 32-bit version does. I tried this myself on both Java, and OSX, with my own source code. I saw the same result. I'm not trying to poo-poo Apple or 64-bit. I'm just saying, watch out, people don't realize that 64-bit has a relatively unknown downside.

The problems described affect the majority of Windows PC users, and have existed for five years. It's great that you have an 8GB PC with x64 Windows, but your setup represents a tiny fraction of the installed base that is far less significant than the Mac platform, as will be pointed out in the following segment.

You might as well say that hurricanes, tornadoes, earthquakes, and winter storms are "not a problem" because you live in Las Vegas.

I think you have provided some misinformation here. Only 32 bit windows which is the defacto OS sold by oems is limited to 3 gb. OS X does not have to overcome this limitation with an upgrade to the os.

The main point of the article is stating that many consumers are being duped into believing that more ram is beneficial on a standard 32 bit system.

Honking your horn doesn't mean you have the right of way.



Boggle: where did the article state virtual memory was "completely useless"? Having an architecture that limits the vast majority of PCs from using more than 2-3GB of RAM has a major impact on virtual memory performance, because it has to resort to using the disk more.

All current and a large proportion of Apple's installed base of Macs now support 4GB of RAM, and its Pro and Xserve support 32GB of RAM. The fraction of PCs that can do this are very small, and artificially limited because Microsoft couldn't get PAE to work in the 32-bit Windows that the vast majority of PC users run. Only a minority of new PCs can even run x64 Windows.

Baseline Macs are 64-bit. There are no new Macs being sold that are 32-bit. But you are correct about 1GB RAM for baseline models.

In x64 Windows you can still use your 32-bit legacy (existing or new) applications. I would assume OS X 10.6 would do likewise.

Applications that have to have 64-bit memory, e. g. double precision code (like ALL the 32-bit FORTRAN code I've written for the past 30 years), already use two 32-bit real memory locations.

Moving a 32-bit application, that requires mostly double precision 32-bit addresses. once written as 64-bit single precision code, will run ~2X faster, as was the case between 16-bit Windoes and 32-bit Windows, or any OS for that matter. Since what once took two memory read/write operations, or the overhead in doing a 32-bit double precision calculation versus doing a 64-bit single precision calculation, is now done with approximately half the total number of machine instructions.

If you application doesn't need 64-bit code don't write 64-bit code.

It's really just as simple as that.

BTW, the article is a POS. \

you have this backwards. Microsoft is pretty soundly criticized for not taking advantage of the transition to 64 bits as an opportunity to modernize their APIs, something Apple has clearly done with Cocoa and Objective-C 2.0. There is a reason Apple's market share has been growing larger quarter by quarter, growth which is only accelerating.

Question: If you hate Mac so much, why the hell are you replying to a Mac forum?

PS. Owning an iPod doesn't make you an Apple user btw.

I'm running 64-bit Vista on one partition and 32-bit Vista on another partition. Both were the same in terms of instillation. In other words, easy and painless.

I now just use the 64-bit Vista because I get all 4 GB of RAM on my laptop.

Now, most Windows and OS X users don't need a 64-bit OS.

BTW, there are way more 64-bit Windows applications now than there ever will be for 64-bit OS X.

The Santa Rosa chipset opened up the same 4 GB address space for all 64-bit OS'es.

OS X has no advantage over Windows in that regard, as both use the same Intel chipsets. D'oh!

Your last statement is incorrect, unless you are referring to the market of sub $500 boxen, which OS X doesn't compete with because there is no 30% margin at this price point for Apple.

And has nothing to do with the OS'es bitness.

Where do you get your numbers from? Considering that 64-bit OS X is backwards compatible with 32-bit apps and will run pretty much any Unix app it's hard to see how Windows can have that many apps running on 64-bits.

The main advantage of 64-bit computing on x86-64 platforms, increased
memory capability, is dependent upon several factors, including hardware
implementation (including CPU's virtual address size, page table entry size,
and chipset's addressibility) and operating system's design. This article,
while informative, is somewhat misleading in many places.



This is misleading in a way that conventionally chipsets are not described in any
lingo of bitwidth, such as "32-bit chipset". In terms of addressible memory,
simply the amount is used. For example, Intel P35 chipset is capable of
handling 8 GB, while P45 is capable of 16 GB, contingent upon the availability
of suitable memory module. There is no such thing as "33-bit chipset" (equal
to 8GB) or "34-bit chipset" (equal to 16 GB).

Intel's Santa Rosa (965 express) platforms, as used in many recent Macs,
are capable of handling 8 GB of RAM ** on paper **, but in reality most
if not all laptops can only handle 4 GB. By using the integrated GMA X3100,
some memory has to be allocated for graphics use, regardless what version
of OS (32 vs. 64 bit) is being used. Even a discrete graphic solution is used
along with 64-bit OS, PCI configuration still eats up some memory from
the 4GB space, although the amount may be miniscule.


When x86-64 processors run at legacy mode (100% compatible/mimicking x86),
they are incapable of running long mode (or in Intel's term, IA-32e mode) specific
instructions. So the description above is a moot point. Also, current implementations
from either AMD or Intel do not allow 64-bit virtual memory; that will be the future
expansion and currently it stays at 48-bit.

Business, science, and engineering. No contest, OS X has like ~zero wrt Windows.

All the high priced Windows applications offer x86 and x64 versions.

I've been able to find an x64 application for just about anything I've used or have looked at so far.

The Mac GUI is still 32-bit, only under the hood are applications 64-bit native.

SolidWorks. AutoCAD. Pro Engineer. Abacus.

That isn't what you said. YOu said there are more 64-bit Windows applcations now than their ever will be for 64-bit OS X. High-priced apps account for a small part of all apps and your knowledge seems to stem from a limited, anecdotal accounting of 64-bit apps. SInce all 32-bit apps work on 64-bit Leopard but the same can't be said for Windows shouldn't we also count all of them since the original issue stemmed from 64-bit Windows having a very limited app numbers compared to 32-bit Windows?

Yes, you're correct DOS and 16-bit applications won't run under Vista x64.

And no, you are incorrect wrt 32-bit applications running under Vista x64.

So let's count all 32-bit and 64-bit applications on both platforms, shall we?

I don't mind being incorrect, but I do like to have some verifiable facts that will help educate me. Call me a cynic, but I actually require proof before changing my mind.

x86-64 instructions range in size from 1-15 bytes. When AMD designed the
architecture, several considerations were made to minimize the overhead associated
with the increase in register/address space. By default, pointers are 64-bit
in width, but as pointed out by other people while pointers are prevalent, they
are by no means the only determinants of program size. Most if not all
x86-64 long mode instructions actually use 32-bit operands, unless overridden by
REX prefix, which effectively limit the overall instruction size to equal to legacy
or compatibility mode instructions. AMD figured 32-bit fixed point integer arithmetics
would suffice for most applications. Also, 64-bit applications by default use
RIP relative addressing. A side effect/benefit of this is that the instruction size
is limited, since the relative pointer is often 32-bit.

The architecture designs like above allow implementation of modes such as
LLP64 used by Microsoft Visual C++, where only pointers and long long
are 64-bit. It is of course compiler/application dependent issue,
and any program has the freedom to bloat as allowed by the architecture.
However, a properly optimized program should not do this. The 2x bloating
certainly does not happen to Linux 32 vs 64, or Windows Vista 32 vs 64.

I don't have hard numbers to give you at this time.

All I can say is that Vista x64 SP1 has been able to run 100% of the x86 applications that I've thrown at it to date.

That is in fact one of Vista's x64 selling points, better x86 compatibility than XP SP2 x64.

In fact, I convinced one engineer at work to switch over to XP SP2 x64 (the government doesn't support Vista yet), basically because of the 32-bit OS memory and speed limitations of XP SP3 x86. He has the Windows/Intel equivalent of the top end Mac Pro (8-cores of 3GHz Xeon goodness for a 12 month old PC workstation) and was running a 2D wave overtopping RANS model.

A lot of horsepower was going to waste there with only 3GB of memory and running a 64-bit application as a 32-bit application. VM thrashing the HD with a typical 40 hour runtime for a single run. He typically did eight runs at a time (one run for each core). He also needed to get the latest Intel FORTRAN x86/x64 compiler.

Most 64-bit apps should not see a doubling in the memory used. I think I remember reading that 33% larger was typical. While 'long' may double in size, apps that have currently been using 'long' as a 32-bit value should instead specify 'int', which continues to be 32-bits even on 64-bit systems. If an app needs a 64-bit value, it would already be using 'long long' on 32-bit systems. Pointers, of course, do double and there is nothing you can do about that.

But it is NOT TRUE that a 64-bit version of an app needs to take twice as much RAM. Carelessness could certainly cause that, but it is not a requirement.

The article is very clear that 64-bit windows does exist, but if it lacks 64-bit chipsets... Also, the point was made that earlier Mac's had 32bit chipsets, which would encounter similar issues.

"No version of 32-bit Windows supports this..." is in no way including 64-bit versions...

Other articles that I have read this year, have discussed the same issue, though with much less technical detail really

Cheers !

Wow! When was Santa Rosa added to the C2D Mac Mini? I've been waiting for Apple to upgrade the Mini to Santa Rosa since May 2007. I thought all Mac Minis were still using Napa chips. Although at this point, I am expecting the Mac Mini to leapfrog Santa Rosa and just go straight Montevina chips. Won't that be fun to jump from GMA 950 graphics to GMA X4500 graphics.

The article isn't talking about onboard graphics. The video memory on a separate graphics card is still part of the 32-bit address space, as the CPU needs to keep track of it somehow.

What do you mean by "keep track of it?" The GPU needs to be able to address the bytes of video ram individually, but the CPU just needs to be able to push data to it through the expansion bus. The only main memory address space required is for the control/data lines of the bus.

No, that's not true, it was true for Tiger, but not Leopard. Cocoa is 64 bit, its perfectly possible using Cocoa to make fully 64 bit native apps, including the GUI. Only Carbon lacks 64 bit support. Of course most of the "major" apps on Mac (Photoshop, Office) use Carbon.

The use of the word "most" in this paragraph is the killer, yes, most stuff works, but for mission critical machines it *all* has to work. Installing 32bit Debian made it all work, 64 bit wasn't worth the hassle for us. As an aside, the hassle that linux gives us in general is why we've almost exclusively moved to Macs in the space of 4 years at work.

Will Apple rewrite Final Cut Studio 2 so all apps are 64 bit? Seems like this suite would greatly benefit from 64 bit addressing. I've already read that Quicktime will finally be 64.

Can anyone explain what the advantage of a 64 bit kernel is? I feel like Leopard's 32/64 bit hybrid approach is the best of both worlds- you get access to large amounts of memory, you can run 64 bit apps natively, and you have good backward compatibility. Once Snow Leopard comes out, a lot of hardware won't be usable on it because of a lack of 64 bit drivers. I tried using Vista x64 but ran into this issue.

What were you guys running that you couldnt get to port easily to a 64bit install? I haven't had issues with 64bit linux (and yes, I'm a debian guy) in a *very* long time. hell, even most precompiled 32bit binaries will prolly run with the 32bit compat libs installed (apt-get install ia32-libs).

Also, as far as separate vers go... debian uses a more "pure" approach than many distros in their 64bit release, hence why it's possible the 32bit libs may not work, then you get the *fun* of creating a 32bit chroot, which may be what your coworker needed (though on lenny it'll be even less of a problem than it is now, which honestly isnt usually much of a problem for most things). You dont need to do that with all distros though, and debians approach makes very good sense for most of *it's* direct users (rock solid on servers, where we've been solidly 64bit for quite a while, and in most large-scale server-side apps)

Warning: computer science geekery!

zmonster:

There are a couple mistakes in your math there. The only data types that automatically double in size are pointers, which must by definition be 64 bits large to reference 64 bits of memory. While modern apps do use a lot of pointers, pointers are by far a tiny part of a program's total memory usage. 'long' also doubles in size, but to be fair, it's rarely used precisely because its size is a big "it depends".

For everything else, programmers are free to continue with the same sized types as before. 'int' and 'float' were 32-bit types before, and they still are now. 'long long' and 'double' were 64-bit types before, and they still are now. Really, nothing changed other than 'long long' now calculating just as fast as 'int' -- on 32-bit systems, they were slower.

Programmers choose types based on just how big their numbers can get, and if a range of zero to four billion is big enough for their needs, they'll keep using 32-bit math as long as they like. The jump to 32-bit systems didn't stop 8-bit 'char' and 16-bit 'short' from working either.

Objective-C objects also do not completely double in size. They definitely get bigger; every object stores a pointer to its class definition, and when you work with objects in your code you store pointers to the objects. But that's just the overhead. When it comes to the actual *data* contained within each object, programmers are free to use whatever types they want. And to be fair, many "power-user" apps only use Objective-C for the interface; the meat of the app is often done in a language with less RAM overhead.

Lastly, about Photoshop: this part killed your argument. 64-bit Photoshop does not exist yet, so you're stating facts about something that's fiction outside of Adobe. But if it did, I doubt that it would be that much bigger than the current Photoshop. The vast majority of Photoshop's memory usage is with image data, and 8-bit images eat up one byte per color channel, per pixel, per layer, regardless of what kind of computer you're running it on.

Rich

(Ultimately, I think that, as smooth as the transition to 64bitness has been for the OS, narrowing the upgrade from Carbon+Cocoa to Cocoa UI-able apps-only results into a developmental bottleneck which could exclude a lot of heavyweights for years or forever. The results are there for all to see: Photoshop 64 delayed for another year or year and a half, no Maya64 on the horizon, etc. Perhaps the only major creative apps to transtion to 64 bits are Lightroom (Cocoa-based from the start) and Cinema4D. In that sense, Windows, for all its accidents, is progressing far more solidly)

When Apple does make the switch to a 64-bit kernel, we'll see. Until then, we don't know how Apple's 64-bit transition is going to go-- it hasn't fully happened yet. Unlike Windows, in which the fully 64-bit version (something that doesn't exist on MacOS) is rapidly overtaking the 32-bit version in popularity and driver support.

@thor79

I am not a gamer, but reading some of their posts-- gamers seem to favor PCs... they build their own boxes, [supposedly] selecting higher-quality/higher-performance matched components, use the latest/greatest graphics cards, yadda, yadda, yadda. One of the things they all seem to do is max out the RAM to get the best performance.

Have these "gamers" found a way to exploit the RAM address space? Or, do they upgrade from 2G to 4G, knowing that they really can only use .3G of the additional RAM?

If the above is true, wouldn't gamers put a lot of pressure on MS to fix the OS and/or put pressure on the game mfgrs. to port to a 64-bit OS, like the Mac.

but has a lot to do with one system using modern APIs while the other system is still constrained by API decisions made for 16 bit that have been carried over all the way to 64 bit windows.