1) I don't have to prove it, because I'm not making any absolute claims the way you are. You are the one saying it's not possible for any desktop system from Apple to run ARM and still be fast enough for the user's needs. Hence, the onus is on you.
No, I said it's not there yet WRT being on part with Intel performance-wise, and it probably won't be for quite some time. Put both your brain cells together and think really hard, and you may be able to discern the difference between that and "it's not possible for any desktop system from Apple to run ARM and still be fast enough for the user's needs."
Besides that, insisting on proving a negative is a logical fallacy. You prove to me that the 680x0 isn't secretly about to make a comeback.
Anyway, here's some benchmarks showing that the Intel-based Macs are much more powerful than the ARM, as if we really needed to be shown that.
Is it possible that they could double the single-core performance and triple the multi-core performance in just one generation? Technically, sure. Is it probable? Not really.
2) You're clearly in over your head as you moved the argument from Mac OS X running on ARM to now exclusively referring to "same or better performance as the 2.7GHz Xeon in the currently shipping top-end Mac Pro."
He was talking about Apple completely moving away from Intel, which means they have to replace the entire Intel-based lineup, and that goes all the way up to the Mac Pro. Apple will not replace their workstation machines with something with iPad-level performance, unless they have lost their minds.
Could they make a low-end Chromebook type thing that ran ARM? Sure. However, since Apple has not rolled out any kind of VM-based ABI similar to Java or .NET, it would have absolutely zero third-party software support, and would cause the same confusion as the MS Surface did regarding why your existing apps won't run. So it would, IMO, be a pretty terrible idea.
No, I said it's not there yet WRT being on part with Intel performance-wise, and it probably won't be for quite some time.
What you said was bullshit because it had nothing to do with what was being stated… but you restart it again in this post so I'll get to it in a minute.
Put both your brain cells together and think really hard, and you may be able to discern the difference between that and "it's not possible for any desktop system from Apple to run ARM and still be fast enough for the user's needs."
Yeah, I'm the one not getting it when you can only compare a currently shipping iDevice with the fast Mac Pro Apple sells… but more on that in a moment.
Besides that, insisting on proving a negative is a logical fallacy. You prove to me that the 680x0 isn't secretly about to make a comeback.
Shameful. :no:
Anyway, here's some benchmarks showing that the Intel-based Macs are much more powerful than the ARM, as if we really needed to be shown that.
1) So now you're doing what you are claiming you didn't do: comparing the iPad, which has an SoC designed for a specific use case instead of considering what the ARM design is capable of when moving the power envelope to something that matches their entry-level desktop and enrty-level notebook, what Apple would be capable of with their entry-level desktop and entry-level notebook, and what ARM and Apple could be capable of in the future with with these performance considerations.
You then, again, compare it to a 3.7GHz Quad-Core Xeon E5/12GBRAM/256GBSSD/Dual FirePro D300 w/ 2GiB VRAM x2. Makes perfect sense because that's exactly what people think of when they think about OS X running on a budget "PC" from Apple¡ :roll eyes:
No way the iPad Air could ever reach those numbers¡ :rolleyes:
Is it possible that they could double the single-core performance and triple the multi-core performance in just one generation?
So the A8X used in the iPad Air is now the highest possible performance they were able to get out of that chip, instead of the performance the settled on as being the most ideal YoY growth and power efficiency. Good one¡
Technically, sure. Is it probable? Not really.
Yes, it's inconceivable that the speed of the A8X in the iPad Air 2 the maximum achievable by Apple without absolutely no way they could have designed and built chips with a more cores, faster cores, more RAM, etc. It's simply mpossible¡
He was talking about Apple completely moving away from Intel, which means they have to replace the entire Intel-based lineup, and that goes all the way up to the Mac Pro. Apple will not replace their workstation machines with something with iPad-level performance, unless they have lost their minds.
And the odds are they will, but you're comments are idiotic to assume that will happen tomorrow or from the top down.
Could they make a low-end Chromebook type thing that ran ARM? Sure. However, since Apple has not rolled out any kind of VM-based ABI similar to Java or .NET, it would have absolutely zero third-party software support, and would cause the same confusion as the MS Surface did regarding why your existing apps won't run. So it would, IMO, be a pretty terrible idea.
Right, if they ran it on ARM it would have to be a browser-based OS with no way for developers to make their Mac App Store apps work just as it was impossible for developers to adjust for Apple's other architecture transitions¡ :rolleyes:
Yeah, I'm the one not getting it when you can only compare a currently shipping iDevice with the fast Mac Pro Apple sells… but more on that in a moment.
If you're proposing to replace the entire lineup with ARM, you'd better be pretty damn sure that it can actually do that. That means being able to take on the high end, not just the low end.
Shameful. :no:
It sure is.
So now you're doing what you are claiming you didn't do: comparing the iPad, which has an SoC designed for a specific use case instead of considering what the ARM design is capable of when moving the power envelope to something that matches their entry-level desktop and enrty-level notebook, what Apple would be capable of with their entry-level desktop and entry-level notebook, and what ARM and Apple could be capable of in the future with with these performance considerations.
Very well, you show me an application of ARM that is able to take on pro-level Intel processors performance-wise.
You then, again, compare it to a 3.7GHz Quad-Core Xeon E5/12GBRAM/256GBSSD/Dual FirePro D300 w/ 2GiB VRAM x2. Makes perfect sense because that's exactly what people think of when they think about OS X running on a budget "PC" from Apple¡ :rolleyes:
So the A8X used in the iPad Air is now the highest possible performance they were able to get out of that chip, instead of the performance the settled on as being the most ideal YoY growth and power efficiency. Good one¡
Is there a higher-performance ARM processor out there? If so, show me.
Yes, it's inconceivable that the speed of the A8X in the iPad Air 2 the maximum achievable by Apple without absolutely no way they could have designed and built chips with a more cores, faster cores, more RAM, etc. It's simply mpossible¡
Again with the straw men. It's getting really irritating. Did I say that it is the "maximum achievable"? No, of course not. What I said that increasing ARM's performance by multiple times, as would be required to catch up with Intel, is not likely in the short term.
And the odds are they will, but you're comments are idiotic to assume that will happen tomorrow or from the top down.
Tomorrow? No, I said the opposite of that. I said it's not happening any time soon. I know that my comment was hard to comprehend. This may help.
Top down? Every processor switch Apple has done to date has been from the top down. You need to be confident about these things before you bet the company on them. Otherwise, you will hamstring yourself later on. If you don't know for sure that a new processor can replace your entire lineup (and at present, there's no reason to think that it can, given that ARM is not designed for performance: it's designed for low power consumption), then you'd better wait until you do before you bite that bullet.
Right, if they ran it on ARM it would have to be a browser-based OS with no way for developers to make their Mac App Store apps work just as it was impossible for developers to adjust for Apple's other architecture transitions¡ :rolleyes:
You really need to learn to read. Did I say any of that? Did I say it was "impossible" for developers to recompile for it? No, no, no, of course I did not. What I did say is that Apple would have to have some sort of VM-based ABI or some other solution to allow binaries to run on both architectures first, and give developers time to transition to it. Since ARM is not powerful enough to emulate Intel with anything approaching decent performance, they cannot rely on emulation as they have with past transitions. And these things take time, so you'd have to release everything first and wait until devs have had time to both port and test everything before releasing any Mac with an ARM processor on it. This is self-evident. If Apple were to just go release an ARM machine tomorrow, as everyone seems to be expecting, it would have, literally, zero third-party software support. Look how well that worked for Microsoft with the Surface RT, and even that thing was able to run Office. Can you imagine selling an end-user a machine that they couldn't even run Office on? And it's not like the Mac BU at Microsoft is nimble about things like this. It would take them at least a year to port, and probably more. And all that time you'd have users who were missing what they consider to be basic functionality.
Basically: if Apple ever decides to switch the Mac line over to ARM, we will almost certainly hear about it well in advance. There will be new ABIs, new compilers, plenty of porting guides, and probably devboxes for developers to test their software on ahead of the rollout to consumers, as we saw with the Intel transition. And yet, with all the recent updates to Xcode and the developer toolchain that we've seen lately, there's been not a peep. This indicates that unless Apple is planning to make something Chromebook-like, in the sense that it is not a Mac and that you shouldn't expect to be able to run Mac software on it, you shouldn't expect this anytime soon.
You really need to learn to read. Did I say any of that?
You damn well did. You showed a foolish benchmark of an iPad and Mac Pro and then claimed it was not possible for Apple to ever do in any regard. You didn't say anything that suggests you don't think they'd ever consider it you flat out said it wouldnt happen because the iPad was not as powerful as Mac Pro, which you then deemed made ARM too inferior to ever be used in any notebook or desktop by Apple, which you then tried to associate with Chrome OS to further make a stupid point.
So is there any "functionality" an app might lose the ability to be able to do with the enforcement of this code? I'm thinking for example when Apple enforced Sandboxing for Mac App Store apps, there became a whole class of Applications that were no longer possible to have on the MAS.
I'm not saying that either was a bad thing, I'm just wondering if there will be such an affect with this change and result in another exclusion of a group of unique Applications that "require" to be able to handle garbage collection on their own and thus would be forever prevented from being updated or posted to the MAS because the implementation of ARC would effectively break the Application or some cool function of it. (Sorry for the run-on sentence.)
So is there any "functionality" an app might lose the ability to be able to do with the enforcement of this code? I'm thinking for example when Apple enforced Sandboxing for Mac App Store apps, there became a whole class of Applications that were no longer possible to have on the MAS.
I'm not saying that either was a bad thing, I'm just wondering if there will be such an affect with this change and result in another exclusion of a group of unique Applications that "require" to be able to handle garbage collection on their own and thus would be forever prevented from being updated or posted to the MAS because the implementation of ARC would effectively break the Application or some cool function of it. (Sorry for the run-on sentence.)
With the right compiler, it probably is for 80% of developers. That last 20% are going to be pissed though.
The right compiler? How's my do you think there are. Xcode has one default compiler.
If people have been using some 3rd party framework to generate native code that might be a problem; hiweber Unity et al can handle cross platform already.
I'm in general agreement. However porting to arm is hardly the chore you claim. Theoretically it's a recompile.
That's because Apple historically has made it easy to support fat binaries, which is a result of excellent plannig. That's another reason why Apple could offer a low-end Mac-like product that was both more than enough performance for the average user and faster than the current low-end Mac options today, despite what [@]durandal1707[/@] says is impossible with his ridiculous Mac Pro comparison.
That's because Apple historically has made it easy to support fat binaries, which is a result of excellent plannig. That's another reason why Apple could offer a low-end Mac-like product that was both more than enough performance for the average user and faster than the current low-end Mac options today, despite what @durandal1707 says is impossible with his ridiculous Mac Pro comparison.
Exactly - Given that there is good evidence that Apple has been working on this for at least 5 years (if not longer), I dare say most, if not all of the framework is already in place to be able to support ARM based Macs. I would not be in the least surprised if we started to see the fruits of their labours in the next 18months - Intel X86 isn't going to last forever, and ARM probably has the better chance of supplanting Intel than anyone else.
Don't forget that intel's current core micro-architecture started from a low-power experimental branch and scaled up to the current dominant design.
From another point of view, my current (admittedly rather old now) late 2008 Macbook pro, gets thoroughly trounced by the iPad Air 2 in geekbench, but it's still perfectly usable in pretty much everything I care to throw at it other than 3d rendering and gaming (I don't game on it).
The iPad Air 2 also matches the current low end iMac geekbench scores, so I doubt that performance would be much of an issue with a desktop focused design.
I suspect that the real answer is more political than anything else, give it time though, and I'm sure we'll start to see the landscape change.
I would not be in the least surprised if we started to see the fruits of their labours in the next 18months - Intel X86 isn't going to last forever, and ARM probably has the better chance of supplanting Intel than anyone else.
I wouldn't be surprised either way. It's certainly feasible for Apple to do on a technological level, but there are plenty of other hurdles that may make it less than ideal to release. Even some "political" reasons, like not wanting to weaken their partnership with Intel.
One of the anti-ARM reasons is the lack of Thunderbolt. That may be true, or perhaps Apple can work a deal with Intel that limits the price of the ARMac* where Intel can get a little something on the side in a special deal which would help boost Thunderbolt ubiquity which may help Intel in other ways. Regardless, we're talking about a low-end, budget "PC" where Thunderbolt isn't likely used so just having an mDP port for an external display or even USB 3.0 would be enough for the price points Apple could now drop into as they build out their traditional "PC" market out.
The iPad Air 2 also matches the current low end iMac geekbench scores, so I doubt that performance would be much of an issue with a desktop focused design.
If you look at all the Macs that currently support Yosemite today you will Geekbench results that are slower than the most recent iDevices. And that's before we consider 1) Apple making an bespoke SoC that is designed to make their OS X-based code more efficient for a traditional "PC" OS (which is a one-way street when it comes to Intel's chipsets), 2) that the iPad Air 2 is surely not the maximum clock-rate that used in an ARM-based chip (consider if Apple designed a quad-core 2.x GHz ARM processor with 4–8GiB RAM), 3) that they not only already made the move to 64-bit ARM, but also did it much sooner than anyone expected (Sure, the AArch64 instruction code is better, but I can' help but wonder if their speedy move on this was for something besides an iDevice), and 4) the market opportunity to create a profitable traditional "PC' that doesn't have 1/3–1/4 of the retail price going to Intel's per-1000 retail price for just the CPU.
Again, no idea if it will happen, but it certainly could happen.
* I'm using ARMac to reference these ARM-based traditional "PCs" by Apple. I don't want to call them Macs because I can see how such a machine might get a different branding.
Let's define things in CS terms: "Automatic" was garbage collection (perhaps elswhere than Apple). "Manual" is scope programming known from '90 (and earlier) from langiuuages like C (sdestructor of object was called when object was goingf out of scope automatically).
In fact both of them automatic, but one requires proper programming technique and paying attention to detail (if objects use heap rather than stack).
Nothiong new... perhaps to those who did not program in '90 it may be new.
It's only painful if you don't know how to do it. After I learned exactly what to do, it's just a pattern and one that I liked, and still like to have control over. I can choose when things are stored in memory and when to remove them. Maybe I'm just a little sick in the head, but I sort of like that level of control.
Ha ha, true, but in all honestly, autorelease pools are typically when you need such tight control, and ARC allows for that.
Quote:
Originally Posted by foggyhill
Well, unless someone is programming an embedded system, a driver, or an OS, I think a programmer shouldbMt have this kind of control. The OS should take care of that. I come from a time were we really had to take care of everything.. Believe these days are better.
Nitpick: ARC doesn't hand control over to the OS, it hands control over to the compiler. And there are instances where you want tight control over memory, especially when dealing with large, or secure objects.
It this related to the issue of self installed non Apple SSDs used on older Macs not supporting TRIM? OS X 10.2 removed the ability of third party TRIM utilities I seem to recall without a hack.
SSD garbage collection is different from this and is built into a driver. It was Apple's kernel extension signing process that affected this because 3rd party TRIM apps change the binary code in Apple's bundled drivers to support non-Apple SSDs. Their signing process detects this change and prevents the driver loading at all. The garbage collection in SSDs is a similar principle in that it frees up unused memory so that it can be used again but this memory management is for RAM. SSD garbage collection is overwriting blocks marked as unused so they can be written to without an overwrite step at the same time, which slows it down.
Comments
Besides that, insisting on proving a negative is a logical fallacy. You prove to me that the 680x0 isn't secretly about to make a comeback.
Anyway, here's some benchmarks showing that the Intel-based Macs are much more powerful than the ARM, as if we really needed to be shown that.
iPad Air: 1822 single core, 4527 multi-core.
Mac Pro: 3618 single core, 14572 multi-core.
Is it possible that they could double the single-core performance and triple the multi-core performance in just one generation? Technically, sure. Is it probable? Not really.
He was talking about Apple completely moving away from Intel, which means they have to replace the entire Intel-based lineup, and that goes all the way up to the Mac Pro. Apple will not replace their workstation machines with something with iPad-level performance, unless they have lost their minds.
Could they make a low-end Chromebook type thing that ran ARM? Sure. However, since Apple has not rolled out any kind of VM-based ABI similar to Java or .NET, it would have absolutely zero third-party software support, and would cause the same confusion as the MS Surface did regarding why your existing apps won't run. So it would, IMO, be a pretty terrible idea.
What you said was bullshit because it had nothing to do with what was being stated… but you restart it again in this post so I'll get to it in a minute.
Yeah, I'm the one not getting it when you can only compare a currently shipping iDevice with the fast Mac Pro Apple sells… but more on that in a moment.
Shameful. :no:
1) So now you're doing what you are claiming you didn't do: comparing the iPad, which has an SoC designed for a specific use case instead of considering what the ARM design is capable of when moving the power envelope to something that matches their entry-level desktop and enrty-level notebook, what Apple would be capable of with their entry-level desktop and entry-level notebook, and what ARM and Apple could be capable of in the future with with these performance considerations.
You then, again, compare it to a 3.7GHz Quad-Core Xeon E5/12GBRAM/256GBSSD/Dual FirePro D300 w/ 2GiB VRAM x2. Makes perfect sense because that's exactly what people think of when they think about OS X running on a budget "PC" from Apple¡ :roll eyes:
2) Mac mini (Late-2014): 2545 single core, 4718 multi-core
No way the iPad Air could ever reach those numbers¡ :rolleyes:
So the A8X used in the iPad Air is now the highest possible performance they were able to get out of that chip, instead of the performance the settled on as being the most ideal YoY growth and power efficiency. Good one¡
Yes, it's inconceivable that the speed of the A8X in the iPad Air 2 the maximum achievable by Apple without absolutely no way they could have designed and built chips with a more cores, faster cores, more RAM, etc. It's simply mpossible¡
And the odds are they will, but you're comments are idiotic to assume that will happen tomorrow or from the top down.
Right, if they ran it on ARM it would have to be a browser-based OS with no way for developers to make their Mac App Store apps work just as it was impossible for developers to adjust for Apple's other architecture transitions¡ :rolleyes:
It sure is.
Very well, you show me an application of ARM that is able to take on pro-level Intel processors performance-wise.
Is there a higher-performance ARM processor out there? If so, show me.
Again with the straw men. It's getting really irritating. Did I say that it is the "maximum achievable"? No, of course not. What I said that increasing ARM's performance by multiple times, as would be required to catch up with Intel, is not likely in the short term.
Tomorrow? No, I said the opposite of that. I said it's not happening any time soon. I know that my comment was hard to comprehend. This may help.
Top down? Every processor switch Apple has done to date has been from the top down. You need to be confident about these things before you bet the company on them. Otherwise, you will hamstring yourself later on. If you don't know for sure that a new processor can replace your entire lineup (and at present, there's no reason to think that it can, given that ARM is not designed for performance: it's designed for low power consumption), then you'd better wait until you do before you bite that bullet. You really need to learn to read. Did I say any of that? Did I say it was "impossible" for developers to recompile for it? No, no, no, of course I did not. What I did say is that Apple would have to have some sort of VM-based ABI or some other solution to allow binaries to run on both architectures first, and give developers time to transition to it. Since ARM is not powerful enough to emulate Intel with anything approaching decent performance, they cannot rely on emulation as they have with past transitions. And these things take time, so you'd have to release everything first and wait until devs have had time to both port and test everything before releasing any Mac with an ARM processor on it. This is self-evident. If Apple were to just go release an ARM machine tomorrow, as everyone seems to be expecting, it would have, literally, zero third-party software support. Look how well that worked for Microsoft with the Surface RT, and even that thing was able to run Office. Can you imagine selling an end-user a machine that they couldn't even run Office on? And it's not like the Mac BU at Microsoft is nimble about things like this. It would take them at least a year to port, and probably more. And all that time you'd have users who were missing what they consider to be basic functionality.
Basically: if Apple ever decides to switch the Mac line over to ARM, we will almost certainly hear about it well in advance. There will be new ABIs, new compilers, plenty of porting guides, and probably devboxes for developers to test their software on ahead of the rollout to consumers, as we saw with the Intel transition. And yet, with all the recent updates to Xcode and the developer toolchain that we've seen lately, there's been not a peep. This indicates that unless Apple is planning to make something Chromebook-like, in the sense that it is not a Mac and that you shouldn't expect to be able to run Mac software on it, you shouldn't expect this anytime soon.
You damn well did. You showed a foolish benchmark of an iPad and Mac Pro and then claimed it was not possible for Apple to ever do in any regard. You didn't say anything that suggests you don't think they'd ever consider it you flat out said it wouldnt happen because the iPad was not as powerful as Mac Pro, which you then deemed made ARM too inferior to ever be used in any notebook or desktop by Apple, which you then tried to associate with Chrome OS to further make a stupid point.
I'm in general agreement. However porting to arm is hardly the chore you claim. Theoretically it's a recompile.
I'm not saying that either was a bad thing, I'm just wondering if there will be such an affect with this change and result in another exclusion of a group of unique Applications that "require" to be able to handle garbage collection on their own and thus would be forever prevented from being updated or posted to the MAS because the implementation of ARC would effectively break the Application or some cool function of it. (Sorry for the run-on sentence.)
Cheers.
No
It's just how memory is managed.
I'm in general agreement. However porting to arm is hardly the chore you claim. Theoretically it's a recompile.
With the right compiler, it probably is for 80% of developers. That last 20% are going to be pissed though.
The right compiler? How's my do you think there are. Xcode has one default compiler.
If people have been using some 3rd party framework to generate native code that might be a problem; hiweber Unity et al can handle cross platform already.
That's because Apple historically has made it easy to support fat binaries, which is a result of excellent plannig. That's another reason why Apple could offer a low-end Mac-like product that was both more than enough performance for the average user and faster than the current low-end Mac options today, despite what [@]durandal1707[/@] says is impossible with his ridiculous Mac Pro comparison.
That's because Apple historically has made it easy to support fat binaries, which is a result of excellent plannig. That's another reason why Apple could offer a low-end Mac-like product that was both more than enough performance for the average user and faster than the current low-end Mac options today, despite what @durandal1707 says is impossible with his ridiculous Mac Pro comparison.
Exactly - Given that there is good evidence that Apple has been working on this for at least 5 years (if not longer), I dare say most, if not all of the framework is already in place to be able to support ARM based Macs. I would not be in the least surprised if we started to see the fruits of their labours in the next 18months - Intel X86 isn't going to last forever, and ARM probably has the better chance of supplanting Intel than anyone else.
Don't forget that intel's current core micro-architecture started from a low-power experimental branch and scaled up to the current dominant design.
From another point of view, my current (admittedly rather old now) late 2008 Macbook pro, gets thoroughly trounced by the iPad Air 2 in geekbench, but it's still perfectly usable in pretty much everything I care to throw at it other than 3d rendering and gaming (I don't game on it).
The iPad Air 2 also matches the current low end iMac geekbench scores, so I doubt that performance would be much of an issue with a desktop focused design.
I suspect that the real answer is more political than anything else, give it time though, and I'm sure we'll start to see the landscape change.
I wouldn't be surprised either way. It's certainly feasible for Apple to do on a technological level, but there are plenty of other hurdles that may make it less than ideal to release. Even some "political" reasons, like not wanting to weaken their partnership with Intel.
One of the anti-ARM reasons is the lack of Thunderbolt. That may be true, or perhaps Apple can work a deal with Intel that limits the price of the ARMac* where Intel can get a little something on the side in a special deal which would help boost Thunderbolt ubiquity which may help Intel in other ways. Regardless, we're talking about a low-end, budget "PC" where Thunderbolt isn't likely used so just having an mDP port for an external display or even USB 3.0 would be enough for the price points Apple could now drop into as they build out their traditional "PC" market out.
If you look at all the Macs that currently support Yosemite today you will Geekbench results that are slower than the most recent iDevices. And that's before we consider 1) Apple making an bespoke SoC that is designed to make their OS X-based code more efficient for a traditional "PC" OS (which is a one-way street when it comes to Intel's chipsets), 2) that the iPad Air 2 is surely not the maximum clock-rate that used in an ARM-based chip (consider if Apple designed a quad-core 2.x GHz ARM processor with 4–8GiB RAM), 3) that they not only already made the move to 64-bit ARM, but also did it much sooner than anyone expected (Sure, the AArch64 instruction code is better, but I can' help but wonder if their speedy move on this was for something besides an iDevice), and 4) the market opportunity to create a profitable traditional "PC' that doesn't have 1/3–1/4 of the retail price going to Intel's per-1000 retail price for just the CPU.
Again, no idea if it will happen, but it certainly could happen.
* I'm using ARMac to reference these ARM-based traditional "PCs" by Apple. I don't want to call them Macs because I can see how such a machine might get a different branding.
In fact both of them automatic, but one requires proper programming technique and paying attention to detail (if objects use heap rather than stack).
Nothiong new... perhaps to those who did not program in '90 it may be new.
It's only painful if you don't know how to do it. After I learned exactly what to do, it's just a pattern and one that I liked, and still like to have control over. I can choose when things are stored in memory and when to remove them. Maybe I'm just a little sick in the head, but I sort of like that level of control.
Ha ha, true, but in all honestly, autorelease pools are typically when you need such tight control, and ARC allows for that.
Well, unless someone is programming an embedded system, a driver, or an OS, I think a programmer shouldbMt have this kind of control. The OS should take care of that. I come from a time were we really had to take care of everything.. Believe these days are better.
Nitpick: ARC doesn't hand control over to the OS, it hands control over to the compiler. And there are instances where you want tight control over memory, especially when dealing with large, or secure objects.
SSD garbage collection is different from this and is built into a driver. It was Apple's kernel extension signing process that affected this because 3rd party TRIM apps change the binary code in Apple's bundled drivers to support non-Apple SSDs. Their signing process detects this change and prevents the driver loading at all. The garbage collection in SSDs is a similar principle in that it frees up unused memory so that it can be used again but this memory management is for RAM. SSD garbage collection is overwriting blocks marked as unused so they can be written to without an overwrite step at the same time, which slows it down.