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.
iLife '11 Still 32-Bit
- Thread starter MacRumors
- Start date
- Sort by reaction score
That was true a number of years ago when Apples had PowerPC chips from IBM and Motorola.
Now that Apples have x64 CPUs from Intel, it is no longer true.
And what did your ISP say when you entered the support desk ticket about unacceptable service?
Um, sorta. 64-bit mode doesn't necessarily use more memory, as good coders can use 32-bits for datastructures that don't need 64-bits.
And 64-bit has other advantages, including the fact that AMD64 provides more registers in 64-bit mode, and can operate the datapaths on 64-bit operands.
I worked at AMD on K8, and actually wrote the first RTL for the 64-bit execution units (before we had an architect for that unit). We frequently found that recompiling 32-bit software in 64-bit mode, while keeping all datastructures 32-bit, had a 20% improvement in speed on K8 (opterons).
Ha! Complaints.
Telecom sucks major arse and most exchanges in the country still have 80s technology in them. (Think AT&T monopoly a couple of years ago, thats what its like) We have one company thats actively investing into getting a better network around New Zealand and they're starting from the major cities and working their way down.
it sounds like you think you can wait and just get Lion and the apps will be updated. This is not the case. You will only get iLife 11 if you (A) buy a new Mac or (B) buy it outright. Whatever iLife you have right now is what you will always have unless you fork over the money.
Well, I gather there will be certain exclusive features in Lion, just because of the way Steve talked about it.
Either way, maybe he buys a new Mac with every new OS release?
I didn't say that it came in Tiger, another user did, they said specifically that qtkit "was introduced" in Tiger.
I might be ignorant on video issues largely but I am also aware of the difference between the framework and the player.
Actually you got it wrong how things work around here with the bitching.
64 bit comes in a year, and people whine that it's not a priority, and that they should have focused on something else more important. "Who cares about 64 bits apple, give us ...this, that, the other".
Then Bupa Satori (what's his name - the guy with the avatar of a sock on a puppet... wait a minute, now I get it!!!!!! sockpupet!!!! this guy has been making it so obvious all this time and I wasn't getting it.) comes and laments the plebes who think 64 bit is even required - contradicting of course shamelessly what he said today.
Then Aiden Shaw comes around from his pc with a highly pompous and insubstantial diatribe on why 128bit should have been standard by now if apple want to call themselves so advanced, and what a great innovative company adobe is versus apple because they have flash 10.2 working flawlessly on his windows 7 mini tower.
You left out (C) you will be able to upgrade just the individual iLife components that you care about.
Just to be clear what we're talking about here: The full version of iLife 11 costs, what, $49?
Why make applications faster, when you can just buy a new Mac? I can't wait for Lion, so that I can purchase MORE movies, songs, and applications from Apple!
Seriously, I'm ready to de-program out of this cult... either with Ubuntu or Win7, but no more Koolaid for me, thanks.
It might be neither x64 nor Cocoa
It's also quite possible that it was rewritten with better, more efficient, and more scalable algorithms - and that neither x64 code nor Cocoa is significant.
Files today are often bigger than disks were not too long ago, and directories with thousands to tens of thousands of files (and directory trees with hundreds of thousands to millions of files) aren't uncommon.
Code that's evolved from the days when disks were tens to hundreds of megabytes in size probably wasn't written with an eye towards millions of files in a filesystem - and after a while various "improvements" muddy up the code. A clean start can do wonders.
It's also quite possible that it was rewritten with better, more efficient, and more scalable algorithms - and that neither x64 code nor Cocoa is significant.
Files today are often bigger than disks were not too long ago, and directories with thousands to tens of thousands of files (and directory trees with hundreds of thousands to millions of files) aren't uncommon.
Code that's evolved from the days when disks were tens to hundreds of megabytes in size probably wasn't written with an eye towards millions of files in a filesystem - and after a while various "improvements" muddy up the code. A clean start can do wonders.
There's also the possible benefit that could come from 64-bit-aware binaries in the x64 architecture having approximately double the number of CPU registers available to work with than pure 32-bit binaries in the same architecture, and each register being able to handle numbers with double the number of bits.
In the (admittedly possibly unusual) situation where an application has a long, tight loop of number-crunching code that it needs to run in the CPU, rather than offloading it to the GPU, then it stands a better chance of being able to store most or all of that loop's local variables in CPU registers, thus reducing the frequency at which it needs to fetch data from the relatively slower cache and system memory, and consequently eliminating some of the performance hit that would have been associated with those fetches.
To be honest, the only reason anyone really cares is because Apple has been wanting to go 64bit for a while now. So, it's kinda out of the norm for iLife not to make transition already.
Wow, that's so "Revolutionary"
That doesn't matter because Apple can easily include the 32-bit version as universal binary like the rest of the OS has so that it will still run in 32-bit when you don't have a 64-bit capable chip.
