Yonah *book's life ..
how long would the Yonah based (i/power)books last till they become "yesterday's technology" .. because they're use a 32 architecture.. and all the rest use a 64bit ..
not to mention that leopard, the upcoming Mac OSX would be realeased just in time when "merom" would be available..
any ideas? ..
that would help lots of ppl in deciding whether to pay now $2000 for a laptop that "might" not last as a laptop that would be released 6 months later ...
waiting 6 months = getting 3 years minimum o compatibility (or maybe 5 years)
or now = getting less than 2 years of campatibility
not to mention that leopard, the upcoming Mac OSX would be realeased just in time when "merom" would be available..
any ideas? ..
that would help lots of ppl in deciding whether to pay now $2000 for a laptop that "might" not last as a laptop that would be released 6 months later ...
waiting 6 months = getting 3 years minimum o compatibility (or maybe 5 years)
or now = getting less than 2 years of campatibility
Comments
A YonahBook should last a good long time.
Originally posted by wmf
The first G5 shipped what, over two years ago? And today there is one 64-bit application: Mathematica.
That has more to do with the lack of OS support than anything else. (OS X 10.4 is still 98% 32-bit.)
However, it does pose an potentially interesting situation 2-3 years down the road. The Mac userbase will be essentially fractured three ways:
+ A large base of Legacy PowerPC users running 32-bit software.
+ A large base of newer Intel customers with 64-bit processors and OS support
+ A tiny base of 2006 early adoptor Intel laptop customers with 32-bit processors.
So, I suppose there's the slight chance that 32-bit Intel users will get left out in the cold. But most software will ship as 32-bit for the next 5-10 years, so I wouldn't worry about it.
Originally posted by IntlHarvester
That has more to do with the lack of OS support than anything else. (OS X 10.4 is still 98% 32-bit.)
Oh God, not this again. OS X is fully 32/64-bit for console applications. GUI applications in 99% of the cases do not need 64-bit. Period.
Originally posted by 1337_5L4Xx0R
Am I on crack in thinking that SIMDs on G4s and Yonahs could handle 64 bit ops efficiently?
As far as I know, both SSE3 and AltiVec use 128-bit registers, so yeah, they could do the math. Even with 32-bit registers you can do 64-bit math -- you just have store the numbers in 2 registers (I think).
The thing is, the math isn't really the issue. The reason you switch to 64-bits is the increased address space. 32-bit CPUs can only address 4 gigs of memory. That's fine for most home users because very few programs use that much memory. If you're processing large amount of data (like big companies and sciencey people like to do), you will quickly bump your head on that 32-bit ceiling, though.
Originally posted by elron
As far as I know, both SSE3 and AltiVec use 128-bit registers, so yeah, they could do the math. Even with 32-bit registers you can do 64-bit math -- you just have store the numbers in 2 registers (I think).
You can do it but it is manual and laborious. Really the AltiVec and SSE units are intended for 32-bit and smaller math. SSE3 adds paired double precision floating point (i.e. 64-bit), and possibly 64-bit integer support as well (I'd have to go check). That said, your other point is more to the point...
The thing is, the math isn't really the issue. The reason you switch to 64-bits is the increased address space. 32-bit CPUs can only address 4 gigs of memory. That's fine for most home users because very few programs use that much memory. If you're processing large amount of data (like big companies and sciencey people like to do), you will quickly bump your head on that 32-bit ceiling, though.
Very true. And all your pointers get twice as big which hits some programs hard and others hardly at all. The increase in memory size of this isn't really the bad part, either, it is that now a lot of data structures take more space in the cache than they do on a 32-bit machine and that slows the program down.
Originally posted by Chucker
Oh God, not this again. OS X is fully 32/64-bit for console applications. GUI applications in 99% of the cases do not need 64-bit. Period.
Bet you change your tune when 10.5 ships with 64-bit GUI support.
Originally posted by IntlHarvester
Bet you change your tune when 10.5 ships with 64-bit GUI support.
64-bit on x64 (AMD64/EM64T) is a wholly different story. There's two big differences, both of which result from the fact that PowerPC was designed to work "natively" in 32-bit and 64-bit right from the start all the way back in the late 80s / early 90s, whereas x64 was explicitly designed to be an extension on top of x86. We could start a big philosophical discussion on how Intel should have pushed Itanium more (and engineered it better) and wouldn't then have this problem, but let's not go there.
1) 64-bit PowerPC can run perfectly side-by-side to 32-bit PowerPC. For example, a 64-bit-compiled Safari (which would be pointless, but just to illustrate the point) could use 32-bit plug-ins, and a 32-bit Photoshop could use 64-bit plug-ins. Only the directly related frameworks need to be available in 64-bit.
64-bit x64, however, is exclusive. Not only does it require the kernel to be 64-bit; it also requires the related processes to be. Windows x64 64-bit Internet Explorer, for example does not support 32-bit Flash, and 32-bit Photoshop does not support 64-bit plug-ins.
2) PowerPC has the same register count, whether 32-bit or 64-bit.
x86, however, has a limited number of registers that is increased in 64-bit x64 mode. Because of this, applications on x64 compiled to be 64-bit are significantly faster, usually between 10 and 30%, which is why it is desirable to have a 64-bit operating system and 64-bit frameworks and applications.
On PowerPC, because the register count is the same, there is no performance difference.
Originally posted by Chucker
64-bit PowerPC can run perfectly side-by-side to 32-bit PowerPC. For example, a 64-bit-compiled Safari (which would be pointless, but just to illustrate the point) could use 32-bit plug-ins, and a 32-bit Photoshop could use 64-bit plug-ins. Only the directly related frameworks need to be available in 64-bit.
While anything's possible in theory, I've never seen this done. Presumably it would require compiler changes or massive thunking or both.
Anyway, if developers want to take advantage of 64-bit in the future, they can just ship quad-fat binaries (PPC/PPC64/x86/x86-64).