Apple pushes devs to deliver 64-bit support with new Snow Leopard beta

24567

Comments

  • Reply 21 of 127
    melgrossmelgross Posts: 33,095member
    Quote:
    Originally Posted by uni View Post


    You need the $500 Developer package to get access to the seeds, right?



    Why would you want them unless you are going to develop something?



    You surely wouldn't want to run with them.
  • Reply 22 of 127
    10.6 betas see to be coming so often, yet, 10.5.7 has taken over a month of betas... must have tons of issues... and Apple released Safari 4 Beta 1 over a month ago. Come on Apple, start focusing on these two current platforms. It seems they are rushing out 10.6 to run head to head with Microsoft Windows 7. Windows 7 is fierce. Probably Microsoft's best OS to date. I love it and can't wait for release.



    Apple has a lot to do to win customers over or to keep afloat.
  • Reply 23 of 127
    solipsismsolipsism Posts: 25,726member
    Quote:
    Originally Posted by italiankid View Post


    10.6 betas see to be coming so often, yet, 10.5.7 has taken over a month of betas... must have tons of issues... and Apple released Safari 4 Beta 1 over a month ago. Come on Apple, start focusing on these two current platforms. It seems they are rushing out 10.6 to run head to head with Microsoft Windows 7. Windows 7 is fierce. Probably Microsoft's best OS to date. I love it and can't wait for release.



    Apple has a lot to do to win customers over or to keep afloat.



    You logic doesn't make sense. You state that the more frequent SL betas mean that Apple is focusing more on their beta SW than their current SW, but then you mention the 10.5.7 which has had many more betas seeded is a shorter time frame which blows away your previous statement.



    You also state that Apple should focus on current platforms and seem to imply that Apple shoudl focus more on Safari 4 beta. Which is a beta regardless of it being public or not. That Beta 1 was in development for at least 6 months as Safari 4. Granted, they changed up the front end in many ways, but the back end is the nearly similar to the previous Safari 4 beta.



    Finally, Apple is in absolutely no risk or going under as you suggest. They will not be closing their doors or declaring bankruptcy.
  • Reply 24 of 127
    Quote:
    Originally Posted by solipsism View Post


    Actually, that is what it means. Right now, only the XServe will boot into the 64-bit kernel by default because very few drivers are needed for it. Most other 64-bit machines are capable of using the 64-bit kernel of SL but use the 32-bit kernel by default, for now. To switch between kernels at startup you simply boot the Mac while holding down the '3' and '2' keys or '6' and '4' keys, for 32-bit and 64-bit, respectively.



    Really? That's pretty impressive.



    Will Apple be requiring all 64-bit drivers, plugins and extensions be compiled as Universal Binaries with a 32-bit code path as well for backwards compatibility? I think that would be wise otherwise you could have disappearing devices and preference planes when you switch between booting the 32-bit and 64-bit kernel which could be confusing and unintuitive.



    On a side note, I wonder if Apple is going to enable compiling to SSSE3 as the default for all 64-bit apps? I believe SSE2 is the compiling target for all Intel applications right now, but since all Core 2 Duo and up chips that support x64 already also support SSSE3, Apple might as well enable it. Intel's compiler for Mac already does this. I'd think there would be some performance improvements to be had from autovectorization and SSSE3 since it's a superset that includes SSE3 which contains instructions meant to help optimize code for Hyperthreading processors, which with Nehalem, are the future. Even Atom's that are 64-bit capable have SSSE3 and so do AMD's latest processors so it's not like it'll limit Apple's processor selection. If Apple is going to enable SSSE3 as the default target for 64-bit apps, they might as well do it now before 64-bit apps become common since there would no doubt be more complaints if they changed it later forcing retesting.
  • Reply 25 of 127
    kim kap solkim kap sol Posts: 2,987member
    Quote:
    Originally Posted by italiankid View Post


    apple has a lot to do to win customers over or to keep afloat.



    o rly!?
  • Reply 26 of 127
    melgrossmelgross Posts: 33,095member
    Quote:
    Originally Posted by ltcommander.data View Post


    Really? That's pretty impressive.



    Will Apple be requiring all 64-bit drivers, plugins and extensions be compiled as Universal Binaries with a 32-bit code path as well for backwards compatibility? I think that would be wise otherwise you could have disappearing devices and preference planes when you switch between booting the 32-bit and 64-bit kernel which could be confusing and unintuitive.



    As you know, Universal Binaries refers to Intel/PPC code. For the sake of clarity, I suggest that you not use that term for this. Just say 32/64 code.



    Quote:

    On a side note, I wonder if Apple is going to enable compiling to SSSE3 as the default for all 64-bit apps? I believe SSE2 is the compiling target for all Intel applications right now, but since all Core 2 Duo and up chips that support x64 already also support SSSE3, Apple might as well enable it. Intel's compiler for Mac already does this. I'd think there would be some performance improvements to be had from autovectorization and SSSE3 since it's a superset that includes SSE3 which contains instructions meant to help optimize code for Hyperthreading processors, which with Nehalem, are the future. Even Atom's that are 64-bit capable have SSSE3 and so do AMD's latest processors so it's not like it'll limit Apple's processor selection. If Apple is going to enable SSSE3 as the default target for 64-bit apps, they might as well do it now before 64-bit apps become common since there would no doubt be more complaints if they changed it later forcing retesting.



    Good question. Of course, the new chips use SSE4, or even 4.2.
  • Reply 27 of 127
    Quote:
    Originally Posted by melgross View Post


    As you know, Universal Binaries refers to Intel/PPC code. For the sake of clarity, I suggest that you not use that term for this. Just say 32/64 code.



    I guess I was drawn in by Apple's talk of UB's supporting 4 architectures: 32-bit PPC, 64-bit PPC, x86, and x64.



    Quote:
    Originally Posted by melgross View Post


    Good question. Of course, the new chips use SSE4, or even 4.2.



    Well SSE4.1 or SSE4.2 of course couldn't be used as the default compilation option in 64-bit without by default excluding the many Merom based Macs.



    It's actually interesting that Apple's latest compiler for XCode is based on GCC4.2 which if I'm not mistaken doesn't support SSE4. It might not even support SSSE3. I believe Apple's version of GCC4.2 recognize SSSE3 and SSE4, but seeing GCC4.3 specifically mentioned adding SSE4 support, GCC4.2 probably doesn't really optimize for it. Seeing GCC4.2 for XCode was recently released, it doesn't seem likely that Apple will release yet another compiler so soon, so I guess some performance benefits of the new chips will be left on the table for now.
  • Reply 28 of 127
    iansilviansilv Posts: 283member
    Quote:
    Originally Posted by mcarling View Post


    I just want Resolution Independence.



    Yes! I could not agree more!
  • Reply 29 of 127
    melgrossmelgross Posts: 33,095member
    Quote:
    Originally Posted by ltcommander.data View Post


    I guess I was drawn in by Apple's talk of UB's supporting 4 architectures: 32-bit PPC, 64-bit PPC, x86, and x64.





    Well SSE4.1 or SSE4.2 of course couldn't be used as the default compilation option in 64-bit without by default excluding the many Merom based Macs.



    It's actually interesting that Apple's latest compiler for XCode is based on GCC4.2 which if I'm not mistaken doesn't support SSE4. It might not even support SSSE3. I believe Apple's version of GCC4.2 recognize SSSE3 and SSE4, but seeing GCC4.3 specifically mentioned adding SSE4 support, GCC4.2 probably doesn't really optimize for it. Seeing GCC4.2 for XCode was recently released, it doesn't seem likely that Apple will release yet another compiler so soon, so I guess some performance benefits of the new chips will be left on the table for now.



    I'm not suggesting that it be used as a default compilation. But support is up to the software developers anyway. If they want to support 4 and above, they can.
  • Reply 30 of 127
    Quote:
    Originally Posted by melgross View Post


    As you know, Universal Binaries refers to Intel/PPC code. For the sake of clarity, I suggest that you not use that term for this. Just say 32/64 code.



    Universal Binary is just a marketing term for fat Mach-O binaries. It doesn't matter if its Intel/PPC, 32/64, ARM/ia32/x86-64/ppc32/ppc64/Hobbit/68k. NeXTSTEP supported this, and there are currently 4 architectures Xcode will allow you to build and package binaries for (PPC32/PPC64/ia32/x86-64).



    Since a Universal Binary can contain any subset of PPC/x86 32/64 bit binaries (and maybe more in the future, and a few more in the past), it seems silly to place artificial limit on the term.
  • Reply 31 of 127
    arteckxarteckx Posts: 39member
    Quote:
    Originally Posted by AppleInsider View Post


    Other software faces less urgency in moving to 64-bit, as the Snow Leopard 64-bit kernel has no problem running 32-bit software outside of the kernel; it just can't run 32-bit kernel drivers. Other 64-bit processes similarly can't run 32-bit plugins or extensions, so developers of "pref pane" modules that get installed in System Preferences will need to release 64-bit versions of those items to allow users to run the 64-bit version of System Preferences.



    I'm surprised this is still an issue. Those super-geniuses are supposed to laugh and tell us it's only normal for us to conclude that this would be a problem. Then they'll write a few lines of code which send the kernel to any-bit land and everything will just work.
  • Reply 32 of 127
    Quote:
    Originally Posted by scottkitts View Post


    With all the arguments in favor of dropping PPC support with Snow Leopard, why bother with the 32bit version at all? Seems like a lot of effort just to support some old Mac minis. Why not just do a clean break with the past and go 64bit only?



    Quote:
    Originally Posted by solipsism View Post


    3) If you do need a driver that is only 32-bit, unlike with Windows, you'll be able to still use it by running the entire system in 32-bit. This is more than just the CPU.



    I think that makes a LOT of sense.



    ie: All things being equal, they might well have abandoned 32bit Intel. But they know that some people will need to run Snow Leopard in 32bit mode anyway to handle their devices... so if they're going to allow that then they may as well allow 32bit Intel hardware at the same time.
  • Reply 33 of 127
    wessanwessan Posts: 37member
    I personally hope there are some more languages coming in SL. Czech localization is available for years from third party, but it disables software updates and you have to uninstall it, update and then reinstall, which is not really a mac-like experience. I'm thinking about getting a Mac for my parents, but missing localization is a huge obstacle.
  • Reply 34 of 127
    melgrossmelgross Posts: 33,095member
    Quote:
    Originally Posted by hohlecow View Post


    Universal Binary is just a marketing term for fat Mach-O binaries. It doesn't matter if its Intel/PPC, 32/64, ARM/ia32/x86-64/ppc32/ppc64/Hobbit/68k. NeXTSTEP supported this, and there are currently 4 architectures Xcode will allow you to build and package binaries for (PPC32/PPC64/ia32/x86-64).



    Since a Universal Binary can contain any subset of PPC/x86 32/64 bit binaries (and maybe more in the future, and a few more in the past), it seems silly to place artificial limit on the term.



    Don't be too technical. We all refer to it as Intel/PPC code, and that's how people understand it.



    I'm willing to bet that 99% of the people here don't care about that explanation, and would just like to have a simpler usage for it.



    Once the PPC OS is gone, no one will be referring to 32/64 Intel code as a universal binary.
  • Reply 35 of 127
    palegolaspalegolas Posts: 1,330member
    I must say, I don't REEAALLY get this 32/64 bit thing. The way it's described it sounds like if OS X is booted in 64 bit mode it will still be able to run 32 bit code, albeit probably a little slower in a sort of "virtual 32 bit mode"?



    Will users have to know anything about this? Are there gonna be stories where software suddenly is running much slower when upgraded to 10.6 running in 64 bit? Say, for instance CS4, I bet most CS4 apps are 32 bit. Would the user be adviced to boot the whole OS in 32 bit mode for optimal use?



    I guess my question is: What does all this mean to the end user?
  • Reply 36 of 127
    lfmorrisonlfmorrison Posts: 698member
    Quote:
    Originally Posted by palegolas View Post


    I must say, I don't REEAALLY get this 32/64 bit thing. The way it's described it sounds like if OS X is booted in 64 bit mode it will still be able to run 32 bit code, albeit probably a little slower in a sort of "virtual 32 bit mode"?



    Will users have to know anything about this? Are there gonna be stories where software suddenly is running much slower when upgraded to 10.6 running in 64 bit? Say, for instance CS4, I bet most CS4 apps are 32 bit. Would the user be adviced to boot the whole OS in 32 bit mode for optimal use?



    No, 32-bit code will still run at virtually the same speed as they would have on a native 32-bit processor. That is because the CPU's complete 32-bit environment exists as a subset of its 64-bit operation mode.



    Also, keep in mind that Leopard already has a mixture of 32-bit applications and 64-bit applications in its userspace, even though Leopard's kernel is 32-bit. When it's running on 64-bit hardware, user applications that have been compiled to operate in 64-bit mode already do so.
  • Reply 37 of 127
    As a professional photographer, all I want is for Apple, Epson, and Adobe to get together and make a path for using more than 3 GB of RAM in Photoshop - and then printing prints that are more than 90 inches long on wide-format Epson printers.



    Is that too much to ask? Snow Leopard and PS CS5 - with new Epson drivers.



    Dick
  • Reply 38 of 127
    shadowshadow Posts: 373member
    Quote:
    Originally Posted by melgross View Post


    Once the PPC OS is gone, no one will be referring to 32/64 Intel code as a universal binary.



    Everyone will be referring to 32/64 Intel code as a universal binary. That's what it is: a binary which contains executable code for more than one architecture.



    Even if SL is not supported on PPC, even the new 10.5 compatible applications will use PPC code as well

    Quote:
    Originally Posted by palegolas


    I must say, I don't REEAALLY get this 32/64 bit thing. The way it's described it sounds like if OS X is booted in 64 bit mode it will still be able to run 32 bit code, albeit probably a little slower in a sort of "virtual 32 bit mode"?



    There are several issues here.

    First, the jump to 64 bit kernel should be made at some point, and now seems to be a right time.

    Second, specific to Intel architecture, the 64-bit applications will benefit from the additional registers available when running in this mode, which translates to some performance improvement.

    Third, with the move to 64-bit kernel and OS many low-level components should be re-compiled/re-written, which makes it possible for some modernization on the way, e.g. improvement in the Cocoa run-time architecture.

    Forth, the additional address space available allows the implementation of some modern security-related concepts, which benefits the end-user as well.



    There is no "virtual 32 bit mode", it is native. But the process is either 32-bit or 64-bit. Plug-ins are loaded by the parent process, thus the issue with the plugins and preference panes. The preference panes are loaded as plugins. If a particular pane is 32-but only, the system Preferences application first restarts itself in 32-bit mode.



    Regarding the drivers discussion above:

    I think that the 32/64 bit problem does not apply to the printer drivers, more specifically, to the CUPS printer driver architecture, introduced alongside 10.2. It won't hurt if the drivers are 64 bit, of course.



    Some clarifications, to avoid misconception:

    Even if the kernel is booted in 32-bit mode it is perfectly OK to run 64-bit apps and vice-versa. As far as I remember, there were leaks suggesting that you can select a certain app to load in 32-bit mode, much like the "Launch using Rosetta" option. BTW, I expect the 64-bit mode to be the default for all 64-bit hardware.
  • Reply 39 of 127
    m2002brianm2002brian Posts: 258member
    Quote:
    Originally Posted by melgross View Post


    Don't be too technical. We all refer to it as Intel/PPC code, and that's how people understand it.



    I'm willing to bet that 99% of the people here don't care about that explanation, and would just like to have a simpler usage for it.



    Once the PPC OS is gone, no one will be referring to 32/64 Intel code as a universal binary.



    Because you think something means something to you, that's what it should mean to everyone? Right! I had a girlfriend who liked to make her own definitions of real words. Kind of frustrating when somebody says "that's not what it means to me" and then you go read the word right out the dictionary to her. So whatever you think Universal Binary means is probably wrong. Don't tell somebody they're wrong because "people here don't care." In fact I do care, and was happy to know I had learned something I didn't know earlier. I will forever remember now, that, Universal Binary is exactly what the name implies. I'm sure with a little work you'll someday learn to enjoy others ways of thinking instead of wanting them to think like you.
  • Reply 40 of 127
    kim kap solkim kap sol Posts: 2,987member
    I'm gonna have to side with melgross here. Calling 32/64 binaries Universal Binaries would bring too much confusion.



    People will download the Universal Binary thinking they can run it on their PPC Mac.



    Sorry but m2002brian and shadow but calling 32/64 binaries UB simply won't work unless it also contains the PPC binary considering people have grown to associate the UB meaning to a PPC/x86 fat binary. You guys can keep calling 32/64 binaries UB but you'd be doing yourself and everyone around you a great disfavor. And if developed apps and called your 32/64 app a Universal Binary, you'd be getting sued by customers still on PPC Macs that bought the app on the premise that it would work on their PPC Mac.



    UB means PPC/x86 fat binary. Period. Any other definition given to UBs would be misleading.



    http://www.apple.com/universal/

    Quote:

    When you see the Universal symbol on Mac applications, that means they’re made to run on both Intel- and PowerPC-based Mac computers.



    Of course, this doesn't mean you can't have UBs that contain 32/64 x86 support...but it must also contain the PPC binary for it to be called a UB.
Sign In or Register to comment.