• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: @property problem
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: @property problem


  • Subject: Re: @property problem
  • From: glenn andreas <email@hidden>
  • Date: Sun, 17 Feb 2008 11:11:34 -0600


On Feb 17, 2008, at 10:59 AM, William Squires wrote:

But it doesn't answer the question. Why even make the change in the 64-bit runtime? This would seem to hide a source of bugs, by taking the responsibility for providing storage away from the programmer. Some storage is still necessary. And besides, in order to take advantage of Leopard features like this one (whether on PPC or Intel), you should still have to link against the 10.5 SDK, so it would seem more reasonable to make the update to both the 32 and 64- bit runtimes, but only in the 10.5 SDK. Then you could update the 10.5 SDK (to 10.5.1) to allow for this "syntactic sugar" under both 32- and 64-bit.
I mean, after all, all it means is that you're changing the default size of an (Integer) register in the CPU chip, and updating the OS to take advantage. How would this make implementing (or not implementing) this change any harder or easier?


One thing to remember is that if you were to do this, you would need another entire copy of all the system frameworks - one for the 32 bit "compatibility" version (for apps linked with 10.4) and another for the new features that you'd get with linked-with-10.5 apps.

This may not seem like much (since disks are cheap, though we are talking a lot of space - and going from 1 to 2 DVDs to install Leopard would be a non-trivial impact) but all of these frameworks get loaded into memory as well. For example, turn on activity monitor and look at memory usage once you launch your first 64 bit app. See the nice big jump in used memory? That's the 64 bit apps, and for now, there aren't a lot of 64 bit apps out there to make this a problem (and they tend to be targeted to markets that have lots of memory installed, etc..).

If this sort of memory usage were to be hit when using "common level" apps, the whole user experience of OS X would go down.

Not to mention that having to QA system updates with yet-another- version of the frameworks makes things uglier as well (right now its 2 CPUs x [32 bit + 64 bit + 64 bit GC] which would become 2 CPUs x [32 bit 10.4 + 32 bit 10.5 + 32 bit 10.5 GC + 64 bit + 64 bit GC] - 6 vs 10 testing configuration). There are more than purely technical decisions involved in shipping products.

Glenn Andreas email@hidden
<http://www.gandreas.com/> wicked fun!
quadrium | prime : build, mutate, evolve, animate : the next generation of fractal art




_______________________________________________

Cocoa-dev mailing list (email@hidden)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


References: 
 >@property problem (From: Randall Meadows <email@hidden>)
 >Re: @property problem (From: Joshua Emmons <email@hidden>)
 >Re: @property problem (From: William Squires <email@hidden>)
 >Re: @property problem (From: Jean-Daniel Dupas <email@hidden>)
 >Re: @property problem (From: William Squires <email@hidden>)

  • Prev by Date: Re: NSTextTab at the rightmost edge of view
  • Next by Date: Re: @property problem
  • Previous by thread: Re: @property problem
  • Next by thread: Re: @property problem
  • Index(es):
    • Date
    • Thread