Why are most files 2x as big for a Mac?

[mkrishnan]

The terminal and all the Unix underpinnings of Mac OS X are 64bit. The GUI parts are not. This is due to change in Leopard. It is simple, basically you have a 32bit layer sitting on top of a 64bit core (which is Unix).

Okay, I'm stupid, and it is simple... but I still don't understand.

If you write a program that executes at the command line, my understanding is that it can instigate a thread that invoke 64-bit APIs in Tiger to solve some problem. My understanding, as others have reported it, is that a GUI program cannot create the same thread. That's the part I don't understand.

If you have a program that's manipulating large amounts of data, such as a rendering program or some video format translation, or something, where 64-bit might be usable, the thing that's being done is not a GUI thing, whether or not a GUI program is doing it, right? That is, if you wish to do some kind of data manipulation, like inverting a large matrix or pushing a lot of data through some sort of digital signal process... the API that does this is not a different API for a command line program than it is for a GUI program.

I mean, no one wants 64-bits to make interface widgets or pop-up dialogs better. People want it for complex computations involving large amounts of data.

What I don't get is how the system is set up so that it matters what kind of process initiated the thread as to whether the process can use 64 bits in Tiger or not.

This is all a bit off topic, though, and I do apologize...

 

[savar]

If you write a program that executes at the command line, my understanding is that it can instigate a thread that invoke 64-bit APIs in Tiger to solve some problem. My understanding, as others have reported it, is that a GUI program cannot create the same thread. That's the part I don't understand.

You're correct. The reason is that a process is either 32-bit or 64-bit -- it can't be both. So actually a process can start up in 64 bit mode. It doesn't need to spawn a thread. But then that process can only execute 64 bit code, which means all libraries and kernel calls must be 64 bit. Aqua/Windowserver are not 64 bit yet, so a 64 bit program can't call any code in them.

There is a workaround: invoke 64-bit windowless processes from your 32-bit GUI process and share information between them. This is definite possibly although I don't know if its being done in any mainstream application.

64-bit is still relatively esoteric and not quite necessary for most people. The main advantage I see is for people who are stuck against the 4GB memory barrier, but that's not too common on desktop computers yet. I see the 64 bit transition as a strategic positioning...because 4GB and beyond will become much more common in the next 5 years.

That is, if you wish to do some kind of data manipulation, like inverting a large matrix or pushing a lot of data through some sort of digital signal process... the API that does this is not a different API for a command line program than it is for a GUI program.

It's the same API, but it would need to have been compiled as 64-bit. On a 64-bit system there are usually two copies of many libraries, one is 32-bit for linking 32-bit applications, and the other is 64-bit for linking 64-bit applications.

 

[daneoni]

Yes... but you don't save that much space.
Linkety to a fast Google-found app (I haven't used it, beware!)

I use this and it works well mostly BUT for some reason it refuses to strip Skype. Go figure.

 

[mkrishnan]

There is a workaround: invoke 64-bit windowless processes from your 32-bit GUI process and share information between them. This is definite possibly although I don't know if its being done in any mainstream application.

Ahhh, gotcha, now that's starting to make sense. So the core process of an application running with a GUI can be a 64-bit process in Leopard.

 

[link92]

There is a workaround: invoke 64-bit windowless processes from your 32-bit GUI process and share information between them. This is definite possibly although I don't know if its being done in any mainstream application.

Mathematica is probably the most used one (but it's also the exact sort of application that'll see a gain from being 64-bit).

 

[wrldwzrd89]

Relatedly, I thought that versions of OS X up to and including Tiger did not generally allow Aqua / windowed programs to execute in 64 bits... although I'm not suprah clear on how an Aqua program is prevented and a terminal program is not....

As cromulent said, the underpinnings are 64-bit ready. The libraries that drive the GUI portion of Mac OS X are not, however. This is what stops GUI programs from being 64-bit.

 

[blitzkrieg79]

Universal binaries are one thing, but eversince Apple switched to RISC processors in mid-1990s, the exact same application written for a PPC and Wintel would always be larger in size for a Mac, it had to do with a fact that RISC processors do less work (lesser transistor count) and software hadto do more work hence the need for more code which translates into bigger size of an application. CISC processors are more sophisticated and have larger transistor count hence the software written for it doesn't require as much coding as processor does more work.

 

[wrldwzrd89]

Universal binaries are one thing, but eversince Apple switched to RISC processors in mid-1990s, the exact same application written for a PPC and Wintel would always be larger in size for a Mac, it had to do with a fact that RISC processors do less work (lesser transistor count) and software hadto do more work hence the need for more code which translates into bigger size of an application. CISC processors are more sophisticated and have larger transistor count hence the software written for it doesn't require as much coding as processor does more work.

Actually, this isn't strictly true anymore, at least when you compare PowerPC to Intel. True, PowerPC started out RISC, and Intel started CISC, but both have taken on each other's features over the years, and have become a LOT more similar than they used to be.

 

[Cromulent]

Universal binaries are one thing, but eversince Apple switched to RISC processors in mid-1990s, the exact same application written for a PPC and Wintel would always be larger in size for a Mac, it had to do with a fact that RISC processors do less work (lesser transistor count) and software hadto do more work hence the need for more code which translates into bigger size of an application. CISC processors are more sophisticated and have larger transistor count hence the software written for it doesn't require as much coding as processor does more work.

That is not entirely true. A RISC processor is designed to take lots of small instructions and execute them very quickly, where as a CISC processor is designed to take larger more complex instructions and execute them at a slower speed.

Both processors still do exactly the same amount of work, they just achieve the results using a different work methodology. Neither is more advanced than the other (in pure theoretical terms).

Edit : You state that the software has to do more work when running on a RISC processor. That is not true at all, software never does any work at all on a computer. The hardware always does everything. The CPU is the primary means of executing all the code that resides on your computer is hardly ever bypassed (except with things like graphics which are offloaded onto a separate card and then fed back to the CPU).

The software is mearly a way of instructing the hardware what to do. Much like a shopping list (very simplified) the shopping list does not go and buy the shopping it needs someone (the hardware) to execute the instructions contained within it in order for the shopping to be bought.