Assuming that you can trust Dropbox, there's also the problem of compartmentalisation. My OS provides primitives that allow it to restrict which applications have access to which files. All major mobile operating systems use these primitives to do varying degrees of sandboxing. If I grant an application access to Dropbox, how do I prevent it from accessing every single file I have there? How do I audit the access that each application has? How do I ensure that this corresponds with the global policy that I have for sharing data between applications?
Volatile memory is defined as memory that requires power to preserve its contents. All of the 'cheap' memory that you can buy at the moment is volatile memory (and the non-volatile memory is either really expensive, really slow, or both). If you double the amount of RAM, then you double the number of capacitors that must be refreshed every few nanoseconds and so you double the power consumption. You also double the amount of heat that's generated and must be dissipated.
Now, what's the number one complaint that people have about most smartphones? Is it performance, or is it battery life? If it's performance, then doubling the RAM makes sense. If it's battery life, then doubling the RAM will make people complain more.
I implemented GC for the GNUstep Objective-C runtime using the Boehm collector (which, amusingly, performed better than Apple's 'highly optimised' collector in my tests, but then there's a reason that the AutoZone team doesn't work at Apple anymore...) and didn't notice any problems with pausing in typical applications, and did see a noticeable decrease in total memory usage, largely due to programs not leaving objects in autorelease pools for as long.
GC support was deprecated for two reasons. The first is that lots of Objective-C idioms rely on deterministic destruction. Although people are discouraged from using objects to manage scarce resources, you still have classes like NSFileHandle that own a file descriptor and close it when the object is destroyed. Nondeterminism of destruction made these problems really hard to debug.
The second problem was that the memory model for ObjC in GC mode sucked beyond belief. Or, rather, the lack of a memory model. It allowed mixing GC'd and non-GC'd buffers at will, but didn't expose this information in the type system. Consider this toy example:
void makeSomeObjects(id *buffer, int count) { for (int i=0 ; i<count ; i++) buffer[i] = [SomeClass new]; }
Will this work? Who knows. If the caller passes a buffer created by NSAllocateCollectable() with NSScannedOption, or passes a buffer on the stack, then yes. If they pass the address of a global that's declared in an Objective-C source file, then yes. If they pass the address of a global that's declared in a C/C++/whatever source file, then no. If they pass a buffer created with malloc(), then no. If they pass a buffer created with NSAllocateCollectable() but without NSScannedOption, then no.
In short, the whole idea was a clusterfuck from the start. On the other hand, it may be one that's worth revisiting now that Objective-C (with ARC) has a notion of ownership for memory. Source code that uses ARC could be compiled to use GC without a huge amount of pain (although the ARC memory barrier functions seem to have been created with the express intention of not allowing GC to be added later).
Having worked in HPC, allow me to translate your post for the benefit of everyone else:
Hi, I work on a subset of problems where aliasing is intentionally reduced and where the algorithms that we use are, by design, amenable to shared-nothing parallelism, although we used shared memory for efficiency. The code that I write has very little similarity in structure or requirements to the vast majority of software in the world, but because it runs on very expensive hardware I regard my views base on this code as being valid in any setting. Memory management is easy.
You can leak memory in a garbage collected language quite easily - especially one like JavaScript that doesn't have any kind of weak reference (ECMAScript 5 draft fixes this with WeakMap, by the way), by keeping pointers around longer than you need to.
You started well, but then ended up badly. Garbage collection is an abstract concept, reference counting is a concrete mechanism. GC means deleting objects after they are no longer referenced. It can be implemented manually, using reference counts, using tracing, or using reference counts with automatic cycle detection. The last two are equivalently expressive, but have very different cache interactions. The rest of your post talks about one specific subset of implementations of tracing garbage collectors.
The problem is that there isn't a good interface between the kernel and applications in most desktop operating systems (OS X is the exception, L4 HURD does it the best way but has 2 users) for letting them know that you're getting low on physical memory. The kernel knows when you're low on memory, but doesn't have any knowledge of the application's data structures so can't make very intelligent decisions about what to swap out. The application can easily throw away stuff from caches, but isn't ever told that it needs to. Mobile operating systems provide applications with explicit notifications that now would be a good time to delete some cached data. On a modern desktop, some of the trades are now very weird - it's often cheaper to refetch data from the network than it is to do a few page faults (although only if you're not on an SSD).
FreeBSD and glibc are both around 1.3MB. That's pretty large compared to the 100KB JavaScript libraries that the original poster was complaining about, and that typically doesn't include the library that implements the math.h functions. Try running ldd on a C binary sometime and see what else it depends on.
It's possibly related to the results. Many of the top-tier universities use less industry-friendly languages for teaching undergraduates. At Cambridge we do a lot of ocaml, at MIT they use Scheme (and, apparently, Python), at a number of others they use Haskell. There are several reasons for doing this. The first is that teaching a less common language means that you don't start the course with half the students thinking that they already know the material. The second is that teaching a relatively simple yet expressive language teaches students to think about algorithms first and then about microoptimisation later when they learn their third or forth language.
In many other universities, there has been the growing trend to believe that the language that you should teach with is one that you would use to solve real-world problems. I believe that this is a mistake, because the requirements for a language for teaching and for creating maintainable large-scale applications are nowhere near the same. This would mean, however, that students from universities with this belief would have an advantage in these contests as they'd be using a language that they'd had a few years more practice with.
Looking at the results, however, I suspect that there's also a lot of apathy involved. MIT and Stanford are there, but they tend to encourage a very competitive atmosphere. Several universities that I'd expect to produce students that would do well appear not to have entered at all. Given the wide range of extra curricular activities available to students these days, I wouldn't be surprised if entering a competition is somewhere down the list.
Many of the people working on these things will also have full time jobs as security researchers. The extra financial incentive for a bug just means that they'll be applying their bug-finding technique to your codebase instead of to someone else's.
I'm not a VLC apologist, but does that even happen any more?
The first time I ever saw this message was when updating VLC to the latest version about 2 months ago, so it definitely does still happen, although I've no idea why (or what it's doing that takes so long).
So, you're comparing an unreleased product that doesn't yet exist to shipping products and accusing me of spreading BS? And repeating claims that Intel has made about its last three generations of Atoms, which have never yet been true? Okay then, enjoy your bubble.
Oh, this made me laugh:
All intel CPUs up to "Haswell" were never designed from the ground up with power management in mind
The Pentium 4 was the last Intel chip not to be designed from the ground up with power management in mind, at least according to the chief architect of the P4 project when I spoke to him a little while ago.
I don't know - I saw the prototype over some beers a few weeks ago. I'll let you know when they're past the prototype stage. The version I saw had a small design flaw where the wires to the arm weren't quite robust enough, so after a few weeks of use the indicators started working. They need to fix that before a proper launch...
Citation needed. Anandtech benchmarked Clovertrail against Tegra-3, the least power efficient ARM core currently on the market. The Tegra-3 has a very power-hungry GPU (which is nice if you've got the batteries for it...) and a fairly standard Cortex A9 core, which has lower performance-per-Watt than either the A7 or A15 and lower performance in absolute terms than the A15. Their latest Atom SoCs are in the same ballpark as the A15 in both power consumption and performance, but they're nowhere near the A7 in terms of power consumption, which uses less power under load than Clovertrail uses idle.
That's a different, and much more valid argument. When has anyone ever rolled out a piece of software across a business and not found either a bug or a missing feature that affects them? Unless you're a really huge company, Microsoft or Oracle won't even take your money to fix it in a timely fashion, but if it's open source then there are a lot of small companies (and big ones, like IBM or Red Hat) that will be more than happy to write the code that you need in exchange for some financial incentive.
Pedestrians around here have a habit of stepping out into the road without looking. Most often, I see women with pushchairs push their child out into the road without looking, which is inexcusable - I don't object to people doing things that will get them killed, only when it is likely to injure someone else. The level of stupidity I see from cyclists is generally higher than for car drivers, but most of it is just likely to get them killed, whereas most of the idiocy from car drivers is likely to at least injure someone else.
Last week, I pulled up to a red light and took a photograph of the car that had stopped with three of its wheels in the cycle lane (lights here often have a strip of cycle lane across the front so that bikes that are turning can get out of the way as soon as the lights change). The driver seemed to take exception to this, gesticulated and then drove off. Straight through the red light.
if a bike blows through an intersection, and a cop sees it, I doubt they'd expend the effort to track the bicyclist down.
They won't track anyone down. They will, however, stop the vehicle. A few months ago I cycled up to some lights that changed to red just before I got there. Annoying to stop. So annoying that the cyclist about 10 seconds behind me decided not to. He got less than 50m down the road before being pulled over and fined. Now, perhaps the moral of this story is don't shoot the lights directly in front of the police station...
One of our former students is now starting a company that produces vests with built-in LEDs. They're bright glowing red from the back and white from the front. They, alone, are bright enough that you exceed the minimum legal requirements for bike lights at night even if you don't have any lights on the bike itself. Even better, they have flashing yellow lights in the arms that are activated when you lift the arm to the horizontal position. They're currently circulating some prototypes, but I'm looking forward to seeing them hit the market.
Fact: you're riding on a road designed for cars. If you can't handle that, then don't do it.
Most of the time, I'm riding on a road designed for horses, with some modest concessions made to the fact that they might be pulling a cart. Both cars and bikes post-date the creation of most of the roads around here and they're sufficiently narrow that if you do the kind of idiocy that the grandparent suggests then an oncoming car will have the choice of hitting you or hitting a car that's on the correct side of the road. I wonder which they'd chose...
I ride a bike, and I've seen a lot of my fellow cyclists do stupid and dangerous things. Often, these are also illegal. I've also seen a lot of drivers do stupid and dangerous things, like the guy in the SUV a couple of days ago who decided that the best place to overtake me was on a bend in the road where it's barely wide enough for two cars and there was an oncoming bus - his only way of avoiding a head-on collision was to sharply turn in front of me when half way past, and my only way of avoiding a collision was an emergency stop (and that was only possible in time because I'd noted when he started overtaking on that part of the road that he was probably a dangerous idiot and started slowing down).
The difference is that most of the time a cyclist does something dangerous, the person most likely to suffer injury or death is the cyclist. When someone in a car does something dangerous, the person most likely to suffer injury or death is someone outside the car - like the friend of mine who was killed when someone pulled out of a car park without looking and crushed the side of his car, or a pedestrian or cyclist. When you are in charge of a ton of metal moving at high speed, you should expect to be held to higher standards.
Nothing, except that Intel's most power efficient chips are in the same ballpark as the A15 (the power-hungry, fast 'big' chip) and they currently have nothing comparable to the A7 (the power-efficient, slow 'LITTLE' chip). And in the power envelope of the A7, an x86 decoder is a significant fraction of your total power consumption.
One of the reasons why RISC had an advantage over CISC in the '80s was the large amount of die area (10-20% of the total die size) that the CISC chips had to use to deal with the extra complexity of decoding a complex non-orthogonal variable-length instruction set. This started to be eroded in the '90s for two reasons. The first was that chips got bigger, whereas decoders stayed the same size and so were proportionally smaller. The second was that CISC encodings were often denser, and so used less instruction cache, than RISC.
Intel doesn't have either of these advantages at the low-power end. The decoder is still a significant fraction of a low-power chip and, worse, it is a part that has to be powered all of the time. They also don't win on instruction density, because both x86 and Thumb-2 are approximately as dense.
MIPS might be able to do something similar. They've been somewhat unfocussed in the processor design area for the past decade, but this has meant that a lot of their licensees have produced chips with very different characteristics, so they may be able to license two of these and implement something similar quite easily. Their main problem is that no one cares about MIPS.
The power difference between an A7 and an A15 is huge. There's really nothing that you could do to something like an A15 to get it close to the power consumption of the A7 without killing performance. They're entirely different pipeline structures (in-order, dual-issue-if-you're-luck vs out-of-order multi-issue). The first generation from Samsung had some bugs in cache coherency that made them painful for the OS, but the newer ones are much better: they allow you to have any combination of A7s and A15s powered at the same time, so if you have a single CPU-bound task you can give it an A15 to run on and put everything else on one or more A7s (depending on how many other processes you've got, running multiple A7s at a lower clock speed may be more efficient than running one at full speed). The OS is in a far better place to make these decisions than the CPU, because it can learn a lot about the prior behaviour of a process and about other processes spawned from the same program binary.
This solution _might_ be more power efficient. But it can not be more die and space efficient
Two words: Dark Silicon. As process technologies have improved, the amount of the chip that you can have powered at any given time has decreased. This is why we've seen a recent rise in instruction set extensions that improve the performance of a relatively small set of algorithms. If you add something that needs to be powered all of the time, all you do is push closer to the thermal limit where you need to reduce clock speed. If you add something that is only powered infrequently, then you can get a big performance win when it is used but pay a price when it isn't.
TL;DR version: transistors are cheap. Powered transistors are expensive.
Slashdot Mirror
Assuming that you can trust Dropbox, there's also the problem of compartmentalisation. My OS provides primitives that allow it to restrict which applications have access to which files. All major mobile operating systems use these primitives to do varying degrees of sandboxing. If I grant an application access to Dropbox, how do I prevent it from accessing every single file I have there? How do I audit the access that each application has? How do I ensure that this corresponds with the global policy that I have for sharing data between applications?
Volatile memory is defined as memory that requires power to preserve its contents. All of the 'cheap' memory that you can buy at the moment is volatile memory (and the non-volatile memory is either really expensive, really slow, or both). If you double the amount of RAM, then you double the number of capacitors that must be refreshed every few nanoseconds and so you double the power consumption. You also double the amount of heat that's generated and must be dissipated.
Now, what's the number one complaint that people have about most smartphones? Is it performance, or is it battery life? If it's performance, then doubling the RAM makes sense. If it's battery life, then doubling the RAM will make people complain more.
I implemented GC for the GNUstep Objective-C runtime using the Boehm collector (which, amusingly, performed better than Apple's 'highly optimised' collector in my tests, but then there's a reason that the AutoZone team doesn't work at Apple anymore...) and didn't notice any problems with pausing in typical applications, and did see a noticeable decrease in total memory usage, largely due to programs not leaving objects in autorelease pools for as long.
GC support was deprecated for two reasons. The first is that lots of Objective-C idioms rely on deterministic destruction. Although people are discouraged from using objects to manage scarce resources, you still have classes like NSFileHandle that own a file descriptor and close it when the object is destroyed. Nondeterminism of destruction made these problems really hard to debug.
The second problem was that the memory model for ObjC in GC mode sucked beyond belief. Or, rather, the lack of a memory model. It allowed mixing GC'd and non-GC'd buffers at will, but didn't expose this information in the type system. Consider this toy example:
Will this work? Who knows. If the caller passes a buffer created by NSAllocateCollectable() with NSScannedOption, or passes a buffer on the stack, then yes. If they pass the address of a global that's declared in an Objective-C source file, then yes. If they pass the address of a global that's declared in a C/C++/whatever source file, then no. If they pass a buffer created with malloc(), then no. If they pass a buffer created with NSAllocateCollectable() but without NSScannedOption, then no.
In short, the whole idea was a clusterfuck from the start. On the other hand, it may be one that's worth revisiting now that Objective-C (with ARC) has a notion of ownership for memory. Source code that uses ARC could be compiled to use GC without a huge amount of pain (although the ARC memory barrier functions seem to have been created with the express intention of not allowing GC to be added later).
It's fine, as long as your closures are only passed downwards. If you ever pass a closure up the stack or to another thread, then it becomes painful.
Hi, I work on a subset of problems where aliasing is intentionally reduced and where the algorithms that we use are, by design, amenable to shared-nothing parallelism, although we used shared memory for efficiency. The code that I write has very little similarity in structure or requirements to the vast majority of software in the world, but because it runs on very expensive hardware I regard my views base on this code as being valid in any setting. Memory management is easy.
You can leak memory in a garbage collected language quite easily - especially one like JavaScript that doesn't have any kind of weak reference (ECMAScript 5 draft fixes this with WeakMap, by the way), by keeping pointers around longer than you need to.
No, refcounts and GC are completely different.
You started well, but then ended up badly. Garbage collection is an abstract concept, reference counting is a concrete mechanism. GC means deleting objects after they are no longer referenced. It can be implemented manually, using reference counts, using tracing, or using reference counts with automatic cycle detection. The last two are equivalently expressive, but have very different cache interactions. The rest of your post talks about one specific subset of implementations of tracing garbage collectors.
The problem is that there isn't a good interface between the kernel and applications in most desktop operating systems (OS X is the exception, L4 HURD does it the best way but has 2 users) for letting them know that you're getting low on physical memory. The kernel knows when you're low on memory, but doesn't have any knowledge of the application's data structures so can't make very intelligent decisions about what to swap out. The application can easily throw away stuff from caches, but isn't ever told that it needs to. Mobile operating systems provide applications with explicit notifications that now would be a good time to delete some cached data. On a modern desktop, some of the trades are now very weird - it's often cheaper to refetch data from the network than it is to do a few page faults (although only if you're not on an SSD).
FreeBSD and glibc are both around 1.3MB. That's pretty large compared to the 100KB JavaScript libraries that the original poster was complaining about, and that typically doesn't include the library that implements the math.h functions. Try running ldd on a C binary sometime and see what else it depends on.
It's possibly related to the results. Many of the top-tier universities use less industry-friendly languages for teaching undergraduates. At Cambridge we do a lot of ocaml, at MIT they use Scheme (and, apparently, Python), at a number of others they use Haskell. There are several reasons for doing this. The first is that teaching a less common language means that you don't start the course with half the students thinking that they already know the material. The second is that teaching a relatively simple yet expressive language teaches students to think about algorithms first and then about microoptimisation later when they learn their third or forth language.
In many other universities, there has been the growing trend to believe that the language that you should teach with is one that you would use to solve real-world problems. I believe that this is a mistake, because the requirements for a language for teaching and for creating maintainable large-scale applications are nowhere near the same. This would mean, however, that students from universities with this belief would have an advantage in these contests as they'd be using a language that they'd had a few years more practice with.
Looking at the results, however, I suspect that there's also a lot of apathy involved. MIT and Stanford are there, but they tend to encourage a very competitive atmosphere. Several universities that I'd expect to produce students that would do well appear not to have entered at all. Given the wide range of extra curricular activities available to students these days, I wouldn't be surprised if entering a competition is somewhere down the list.
Many of the people working on these things will also have full time jobs as security researchers. The extra financial incentive for a bug just means that they'll be applying their bug-finding technique to your codebase instead of to someone else's.
I'm not a VLC apologist, but does that even happen any more?
The first time I ever saw this message was when updating VLC to the latest version about 2 months ago, so it definitely does still happen, although I've no idea why (or what it's doing that takes so long).
So, you're comparing an unreleased product that doesn't yet exist to shipping products and accusing me of spreading BS? And repeating claims that Intel has made about its last three generations of Atoms, which have never yet been true? Okay then, enjoy your bubble.
Oh, this made me laugh:
All intel CPUs up to "Haswell" were never designed from the ground up with power management in mind
The Pentium 4 was the last Intel chip not to be designed from the ground up with power management in mind, at least according to the chief architect of the P4 project when I spoke to him a little while ago.
I don't know - I saw the prototype over some beers a few weeks ago. I'll let you know when they're past the prototype stage. The version I saw had a small design flaw where the wires to the arm weren't quite robust enough, so after a few weeks of use the indicators started working. They need to fix that before a proper launch...
Citation needed. Anandtech benchmarked Clovertrail against Tegra-3, the least power efficient ARM core currently on the market. The Tegra-3 has a very power-hungry GPU (which is nice if you've got the batteries for it...) and a fairly standard Cortex A9 core, which has lower performance-per-Watt than either the A7 or A15 and lower performance in absolute terms than the A15. Their latest Atom SoCs are in the same ballpark as the A15 in both power consumption and performance, but they're nowhere near the A7 in terms of power consumption, which uses less power under load than Clovertrail uses idle.
That's a different, and much more valid argument. When has anyone ever rolled out a piece of software across a business and not found either a bug or a missing feature that affects them? Unless you're a really huge company, Microsoft or Oracle won't even take your money to fix it in a timely fashion, but if it's open source then there are a lot of small companies (and big ones, like IBM or Red Hat) that will be more than happy to write the code that you need in exchange for some financial incentive.
Pedestrians around here have a habit of stepping out into the road without looking. Most often, I see women with pushchairs push their child out into the road without looking, which is inexcusable - I don't object to people doing things that will get them killed, only when it is likely to injure someone else. The level of stupidity I see from cyclists is generally higher than for car drivers, but most of it is just likely to get them killed, whereas most of the idiocy from car drivers is likely to at least injure someone else.
Last week, I pulled up to a red light and took a photograph of the car that had stopped with three of its wheels in the cycle lane (lights here often have a strip of cycle lane across the front so that bikes that are turning can get out of the way as soon as the lights change). The driver seemed to take exception to this, gesticulated and then drove off. Straight through the red light.
if a bike blows through an intersection, and a cop sees it, I doubt they'd expend the effort to track the bicyclist down.
They won't track anyone down. They will, however, stop the vehicle. A few months ago I cycled up to some lights that changed to red just before I got there. Annoying to stop. So annoying that the cyclist about 10 seconds behind me decided not to. He got less than 50m down the road before being pulled over and fined. Now, perhaps the moral of this story is don't shoot the lights directly in front of the police station...
One of our former students is now starting a company that produces vests with built-in LEDs. They're bright glowing red from the back and white from the front. They, alone, are bright enough that you exceed the minimum legal requirements for bike lights at night even if you don't have any lights on the bike itself. Even better, they have flashing yellow lights in the arms that are activated when you lift the arm to the horizontal position. They're currently circulating some prototypes, but I'm looking forward to seeing them hit the market.
Fact: you're riding on a road designed for cars. If you can't handle that, then don't do it.
Most of the time, I'm riding on a road designed for horses, with some modest concessions made to the fact that they might be pulling a cart. Both cars and bikes post-date the creation of most of the roads around here and they're sufficiently narrow that if you do the kind of idiocy that the grandparent suggests then an oncoming car will have the choice of hitting you or hitting a car that's on the correct side of the road. I wonder which they'd chose...
I ride a bike, and I've seen a lot of my fellow cyclists do stupid and dangerous things. Often, these are also illegal. I've also seen a lot of drivers do stupid and dangerous things, like the guy in the SUV a couple of days ago who decided that the best place to overtake me was on a bend in the road where it's barely wide enough for two cars and there was an oncoming bus - his only way of avoiding a head-on collision was to sharply turn in front of me when half way past, and my only way of avoiding a collision was an emergency stop (and that was only possible in time because I'd noted when he started overtaking on that part of the road that he was probably a dangerous idiot and started slowing down).
The difference is that most of the time a cyclist does something dangerous, the person most likely to suffer injury or death is the cyclist. When someone in a car does something dangerous, the person most likely to suffer injury or death is someone outside the car - like the friend of mine who was killed when someone pulled out of a car park without looking and crushed the side of his car, or a pedestrian or cyclist. When you are in charge of a ton of metal moving at high speed, you should expect to be held to higher standards.
Nothing, except that Intel's most power efficient chips are in the same ballpark as the A15 (the power-hungry, fast 'big' chip) and they currently have nothing comparable to the A7 (the power-efficient, slow 'LITTLE' chip). And in the power envelope of the A7, an x86 decoder is a significant fraction of your total power consumption.
One of the reasons why RISC had an advantage over CISC in the '80s was the large amount of die area (10-20% of the total die size) that the CISC chips had to use to deal with the extra complexity of decoding a complex non-orthogonal variable-length instruction set. This started to be eroded in the '90s for two reasons. The first was that chips got bigger, whereas decoders stayed the same size and so were proportionally smaller. The second was that CISC encodings were often denser, and so used less instruction cache, than RISC.
Intel doesn't have either of these advantages at the low-power end. The decoder is still a significant fraction of a low-power chip and, worse, it is a part that has to be powered all of the time. They also don't win on instruction density, because both x86 and Thumb-2 are approximately as dense.
MIPS might be able to do something similar. They've been somewhat unfocussed in the processor design area for the past decade, but this has meant that a lot of their licensees have produced chips with very different characteristics, so they may be able to license two of these and implement something similar quite easily. Their main problem is that no one cares about MIPS.
The power difference between an A7 and an A15 is huge. There's really nothing that you could do to something like an A15 to get it close to the power consumption of the A7 without killing performance. They're entirely different pipeline structures (in-order, dual-issue-if-you're-luck vs out-of-order multi-issue). The first generation from Samsung had some bugs in cache coherency that made them painful for the OS, but the newer ones are much better: they allow you to have any combination of A7s and A15s powered at the same time, so if you have a single CPU-bound task you can give it an A15 to run on and put everything else on one or more A7s (depending on how many other processes you've got, running multiple A7s at a lower clock speed may be more efficient than running one at full speed). The OS is in a far better place to make these decisions than the CPU, because it can learn a lot about the prior behaviour of a process and about other processes spawned from the same program binary.
This solution _might_ be more power efficient. But it can not be more die and space efficient
Two words: Dark Silicon. As process technologies have improved, the amount of the chip that you can have powered at any given time has decreased. This is why we've seen a recent rise in instruction set extensions that improve the performance of a relatively small set of algorithms. If you add something that needs to be powered all of the time, all you do is push closer to the thermal limit where you need to reduce clock speed. If you add something that is only powered infrequently, then you can get a big performance win when it is used but pay a price when it isn't.
TL;DR version: transistors are cheap. Powered transistors are expensive.