Some u-ops can only be sent through a single port, most can be sent through a couple specific ports, and none are suitable for all 6 ports. Most of the integer instructions can only be sent through ports 0, 1, and 5, and these ports also perform some floating point duties. The complexity creates a problem for people tasked with optimizing low level code because they need to be aware of what u-ops are generated by each instruction, and what ports they can be sent to.
This is in contrast to AMD'd setup where most integer instructions break down into u-ops suitable for any of its 3 integer execution units, and that these execution units do not perform any floating point duties.
So optimizing for AMD is a pleasure compared to optimizing for Intel. This doesnt mean that Intel design is stupid or anything, just that its a bitch to hand-optimize for.
I was never a big fan of the 3x symmetric ALU's in the Athlons. When it comes to integer intensive code, having a ton of independent ADDs or MULs that I'd need that kind of parallelism for was rare. And the latency (compared to a sane design like Core at least) were significantly higher due to the units being multi-purpose.
In the Phenom II design the latency of most of the register to register integer instructions is exactly 1 cycle just like the i7. The units being multi-purpose is not a latency sacrifice at all, although maybe the original Athlons had poor latency for another reason and Agner Fog's reference actually indicates that most of the register to register integer instructions on even the early K7's also had 1 cycle latency.
Even in mem,reg operations, the Phenom II beats out the I7 in latency on many operations (ex: xor [ebx], eax.. 6 cycle latency on i7, 4 cycle latency on Phenom II).. where the I7 really shines the most is in reading directly from L1 into registers (2 cycle latency vs 3 cycle latency), with a massive 50% advantage on one of the most common operations..
The only kind of leap second which has occurred is an extra second. It's still monotonic: 23:59:59, 23:59:60, 00:00:00 (+1 day)
You are encoding time as strings here, which is different than having a system of time. The purpose of a system of time is to be able to calculate the difference between two given encodings. Your time encoding does not have the ability to calculate such differences, so it is not a system of time.
Basically you have to choose between interval calculations that are (A) right when a specific number of leap seconds actually fall in the interval and wrong otherwise, or (B) right when no leap seconds actually fall in the interval and wrong otherwise.
What Oracle/etc are doing is using (B) because they want their time calculations to actually be right most of the time, rather than wrong most of the time.
I hope that this sheds some light on the subject for you. Just keep in mind that encoding time is not the same as a system of time, that even leap years are problematic if you only demand encoding (rather than having a system of time that encompasses 4 year, 100 year, and 400 year rules that allow you to subtract dates and get an actual number of days elapsed)
Just to be clear, when you say "integer units" you mean "integer schedulers" and not actual integer execution units, of which even the old Athlon's had 3 per core (and that hasnt changed since then.)
Unlike Intel design, with highly asymmetric execution units, AMD's have had 3 symmetric integer execution units per core since the original Athlons. Its actually a pleasant breeze to write hand-optimized integer code on AMD's.
This new design looks (in the diagram) like it actually has 4 symmetric integer execution units per integer scheduler, with the bulldozer having 2 schedulers per core while the bobcat only having 1 per core (I would guess that the logical cores are alternated on rise-and-fall states of the clock on the bobcat, and the diagram certainly makes it look like that is the case.)
Each seem to have two wide floating point execution units, so the floating point performance of both bulldozers and bobcat's are probably equivalent.
What I think AMD has done here is that with the bulldozer, in integer performance it is going to behave like it has 2x the number of real cores. So an 8 core (16 thread) chip will perform much like an 8 core CPU in floatng point work, but much more like a true 16-core CPU in integer work. This should give it a large advantage over Intel in integer work in equal-core comparisons, but the floating point performance will still lag behind Intel.
That word -- monotonically -- you're using it but I don't think you understand what it means. Adding leap seconds doesn't violate a monotonically increasing property of time. As long as the count of the seconds doesn't go down, the time function is still monotonically increasing.
Leap seconds are not defined as increment only. In fact, all the leap seconds so far (coincidental to the delay of their introduction into UTC) have been decrementing. They have all been extra seconds.
In short, you are wrong. They have violated the monotonic property of time, every time so far.
I'll give a shit about you hating the United States when the U.N. stops asking us to be the international police force.
Only a handful of countries maintain the ability to stop aggression against them. We are one of them. If you live some place where your country does not maintain that ability, that is your loss and you should be very mad about relying on other countries for protection.
It sounds like the problem is due to the fact that the leap second is implemented as a step function and not a slew.
It is because the step function is non-systematic. Leap years are implemented as step functions just fine. You simply cannot write an algorithm to predict when a leap second will be introduced based only on the time, which is the problem.
Leap seconds are ad hoc seat-of-the-pants alterations to the time. They violate the monotonically steadily increasing property of time encoding, so simply cannot be tolerated in any system that benefits from having monotonically steadily increasing time values.
..or its actually difficult to 'handle' leap seconds. I can tell that you've never worked seriously with time values as a programmer.
If you can't answer "When will each of the next 10 leap seconds be?" and "When were the last 10 leap seconds?" then you are pretty much fucked from a programming standpoint of 'handling' it in any sane manner using common time encodings, which use a count of intervals (usually seconds, or milliseconds) since some specific date and time.
Leap seconds make it impossible to incorporate them into intervals because leap seconds are not computationally predictable.
They are simply arbitrary announcements from the time keepers "we are adjusting the clocks by 1 second on such and such a date. We dont know when we will adjust them again.. we'll keep you posted."
Leap seconds are not like leap years, which are easily handled because they are introduced systematically based on only the interval value.
Hell, "Future Generations" arent even real people. They are imaginary people. Real people can use helium now, or we can save it for some imaginary people that may exist in the future.
Prove to me that these mythical future people will exist, and THEN prove to me that THEY wont "waste" this helium in manners equivalent to the way we "waste" it. Only when both of those things can be established can we rationally talk about the value of "saving" it for "future non-wasters."
Why? Perhaps because of the disproportionate spending on defence in USA.
Disproportionate to what?
(2008 figures) It is only 20% (503.4 billion) of the U.S. total tax receipts (2.524 trillion).
..and thats just the tax receipts.. not including the additional money that we borrow every year.
The spending may be higher than it should be, but then so too is everything else the government blows money on. It is not even close to being "disproportionate." The proportions are 4:1 against.
"We the People of the United States, in order to form a more perfect Union, establish Justice, insure domestic Tranquility, provide for the common defence, promote the general Welfare, and secure the Blessings of Liberty to ourselves and our Posterity, do ordain and establish this Constitution for the United States of America"
Defense spending goes towards half of the very things (specifically enumerated above) we decided that the federal government should perform when founding our nation, yet its only 20% of the fucking budget. Its fucking insane, and you sir are not as smart as you think you are.
There are no options for people who want a carrier that doesn't mark up the cost of txt msg's 10000%.
Why not?
The answer is that there is not a large market for people that care enough that they are marked up 10000%. If there was, a company would target that market and snatch up all those users that care enough.
It is your expectations that are messed up. There simply is not a big market of people up-in-arms over text messaging rates. Most people are fine with the rates -> its what the market will bare.
Contrary to the common but ignorant belief that more Linux distro's is a good thing, they aren't.
I've said this before, both here on slashdot and elsewhere. The biggest competitor to Linux is another Linux.
Many Linux users do seem to get this. Some just refuse to accept the fact that its not Linux vs Windows.. its Ubuntu vs Fedora vs SUSE vs Mandriva vs Debian vs Gentoo vs Slack vs... Windows
It isnt so much a bad thing that Linux competes with itself, because this sort of competition definitely has value, but it does really put the screws to commercial game development on top of a Linux flavor. Its like developing a game for multiple consoles, but without the enormous profit potential of consoles.
Besides the obvious evidence of people with MAC's dual booting and running the same games on both OSX and Windows on the same hardware and getting significantly better frame rates on Windows...
The simple fact of the matter is that OpenGL is not the same interface paradigm as modern DirectX. In the early days of Direct3D they were quite similar, but eventually Direct3D evolved to have two different rendering paradigms.. one called Immediate Mode (like OpenGL) and one called Retained Mode.
Now, Immediate Mode is a lower level interface to the hardware than Retained Mode is, and that in fact Retained Mode is implemented as a layer on top of Immediate Mode. OpenGL does immediate mode better than Direct3D's immediate mode, but as it turns out that doesnt actually matter in trms of modern game rendering pipelines.
What Microsoft has done with this Retained Mode is encompassed many optimizations, and its all centered around queuing up many rendering calls that make up a scene frame. It can then issues large batches of rendering commands to the video hardware all it once, grouping similarly textured/shadered polygons together, as well as geometry that uses the same transformation matrix, etc.. so that the state of the GPU (shaders, texture sets, transformation matrices, etc..) needs to be updated less often than a visit-each-object-once Immediate Mode algorithm would have had to do.
These state changes are expensive, often requiring the GPU to completely finish all other operations (flushing its own queue) before the state can be updated, greatly reducing parallelism. That visit-each-object-once algorithm in Immediate Mode could require 30,000 state changes while in retained mode that same visit-each-object-once algorithm only requires 5,000. As it turns out, this is a significant win that more than offsets the less efficient Immediate Mode.
This could be implemented on top of OpenGL too, so OSX could certainly do it.. but the fact is that it hasnt been done all that well yet anywhere but DirectX and a few big-name ($$$) OpenGL-centric game engines that handle it themselves.
How is there enough competition? Is that why text message prices have gone up, despite costs to send them going down? Is that why AT&T has been spending less on their (famously bad) network lately, despite traffic being up at least 40%? Does that sound like something you do when you're in tight competition?
The cost of text messaging is what it is because that is what the market will bare. If AT&T lets its infrastructure go to shit, then you can go with Verizon, Sprint, T-Mobile, etc..
The free market does not guarantee that all competitors are specifically rational about the specific thing you care about, nor is it supposed to.
You have quite a bit of choice right now when it comes to mobile carriers. If none of the services are living up to your expectations, then either your expectations are irrational or there is a big conspiracy. Given how nasty AT&T and Verizon are to each other, I'm pretty sure that they arent in bed together... so it must be your expectations that are irrational.
In the past, there was always some exponentially bigger media file people werent storing yet.
But today not only are we storing movies, we are storing them encoded at state of the art resolutions in the native format that they are available at commercially. We can increment up with twin-stream stereo video (aka 3D), and maybe a few doubling of resolution. There just isnt any orders-of-magnitude storage demand increases on the movie storage front.
Previously, there was always some next exponential thing that wasn't handled. From Text to Images to Audio to Movies. Its always been media driving the storage needs of desktops.
My question to you is simply this.. what is the next exponential demand? There isnt any media left, so I think you are just grasping at the "640K" meme at this point.
FCC analysis shows that the median actual speed consumers experienced in the first half of 2009 was roughly 3 Mbps, while the average (mean) actual speed was approximately 4 Mbps
The real story is that over 50% of the users get less than 50% of the average bandwidth. I'm not sure how to explain it, but the difference between median and mean looks quite significant to me.
You are making a calculation based on the average summary statistics quoted by manufacturers: maximum writes per hardware unit; hardware units written per OS write. In doing so, you're assuming a perfect wear levelling algorithm for any use case and no persistent metadata for that algorithm. (You're also assuming that the quoted limits for erases are close enough to correct.)
No I am not. While I did use maximum writes per hardware unit of 10,000, I showed that you can use 4,000 and still attain 5 years longevity while overwriting the entire drive every single day for the entirety of those 5 years
I did not use any manufacturer figure for the # of hardware units written per OS write. You are making that up. I used my own 200% write amplification figure, which is abysmal. In my reply, I noted that even 500% write amplification still allows the user to attain 5 years of service while overwriting the entire drive every single day for the entirety of those 5 years
I am also not assuming perfect wear leveling, since that actually doesnt play a role in the calculation needed. If a block is fully worn, the drive is simply smaller, even with the most grotesquely bad wear leveling algorithm.
But I am going to humor you, since you didnt do any calculations, and presume that (A) the erase limit is actually only 25% of advertised, (B) the write amplification is actually 500%, and (C) the wear leveling algorithm only attains 25% efficiency over the drive, causing some blocks to wear out 4 times faster than ideal.
So we've got 80,000,000,000 bytes with only 2,500 erase cycles, so thats 200,000,000,000,000 bytes of ideal write capacity, but the 500% write amplification reduces this is 40,000,000,000,000. Then factoring in 25% efficiency on the wear leveling (that some blocks will be used up 4 times faster than with an ideal wear leveling algorithm), we arrive at 10,000,000,000 bytes of write capacity using these absolutely horrific numbers that you must be imagining before any blocks cant be erased. That is still an average of 5.5 gigabytes per day of writes over a 5 year period, equivalent to replacing the entire contents of the drive every 2 weeks.. and at the end of this period, the size of the drive merely begins to shrink because we assumed 25% wear leveling efficiency.
Are these numbers simple enough for you to understand? Here I took extreme pessimism on every single value in the equation. In short, this is the nightmare scenario that you are imagining that requires that the manufacturers are lying their asses off to such an extreme extent that it would already have been witnessed in practice (because much smaller SSD's were being shipped 3 years ago in Dell laptops)
Then you'll please link to some real world reports of usage which describe how the volume is actually being accessed on a daily basis. I appreciate that they have been effective as embedded rust caches and for read-mostly databases, but that's not enough to go on.
Laptops typically do not contain "read-mostly" databases. Fir you assume every nightmare scenario imaginable. Then you even assume that the real word usage of these devices has only been at extremely good conditions. Its amazing the lengths you will go to continue to believe that your nightmare belief stopped adding up years ago. Your view just doesnt add up any longer, and it probably barely added up when you adopted it.
In a lot of countries, large portions of the population dont even have electricity.
Consider that in India alone, there are over 400 million people below the international poverty line (of $1.25 per day.) That more than the entire population of the united states, including illegals.
Except, again, you're just taking the manufacturer's summary performance data based on some unspecified average scenario and making a crude calculation. You're not taking account of paging vs block vs OS sector size, metadata location and updates (do SSDs use associative memory yet?), the nature of the wear levelling algorithm vs the nature of data written, behaviour as blocks gradually fail, etc.
Except that I wasn't? Nowhere will you find a 200% write amplification number in the manufacturers summary. The reality is that things would have to be an order of magnitude different that the numbers I used before that 5 year point isnt realistic.
That write amplification could have easily been 500% (thats 5 bytes erased per byte written!) and the user would STILL have had to overwrite the entire drive every day for 5 years.
Maybe you think the erase cycle limit is only 4,000 instead of 10,000? Thats the same thing. The user would STILL have to overwrite the entire drive every day for 5 years.
How about some citations for how unreliable SSD's are. Its really that simple. Got any? If not, why not?
Are there no usage patterns anywhere that use up the erase cycles in the first few years of ownership?
Dell has been shipping SSD's for more than a few years (much smaller ones in fact), and plenty of servers have been using SSD's for more than a few years. Both Sun and Oracle have been using much smaller SSD's as caches for their storage systems for years as well. Yet over these years, nobody has come out and reported about how they killed a bunch of them. Just the opposite, in fact, as Dell has stated that reliability is equal or better based on their very large numbers.
These things work well, and they are apparently even hard to kill with abusive patterns. They are replacing enterprise 15K drives pretty much everywhere, where they are actually priced well for that market ($2/GB is NORMAL for high end enterprise drives)
I can report to you that we've been buying these in our desktops for over a year now. We have about 200 or so deployed, for a total of about 2000 deployment-months. Zero failures so far.
The naysayers say things like "thats not enough time" etc etc..
But heres the thing. If those were platter drives, 16 of them would have died the first year based on Googles very large sample, with another 16 expected to go the next year.
Even if SSD lifetimes were actually shorter on average (which there doesnt seem to be evidence of) then it still makes sense to buy them. Its much easier to schedule the replacement of 200 drives all at once than it is to deal with surprise downtime.
Slashdot Mirror
What is this about highly asymmetric execution units on Intel? link please ;-)
Intel Core cores have 6 execution "ports", each serve a range of micro-operations (u-ops) and there is some overlap between them.
Some u-ops can only be sent through a single port, most can be sent through a couple specific ports, and none are suitable for all 6 ports. Most of the integer instructions can only be sent through ports 0, 1, and 5, and these ports also perform some floating point duties. The complexity creates a problem for people tasked with optimizing low level code because they need to be aware of what u-ops are generated by each instruction, and what ports they can be sent to.
This is in contrast to AMD'd setup where most integer instructions break down into u-ops suitable for any of its 3 integer execution units, and that these execution units do not perform any floating point duties.
So optimizing for AMD is a pleasure compared to optimizing for Intel. This doesnt mean that Intel design is stupid or anything, just that its a bitch to hand-optimize for.
The most extensive references arent from Intel or AMD tho, they are from a low level hack named Agner Fog.
"ATTENTION PEDESTRIANS! This vehicle is accelerating uncontrollably while an elderly man panics in the drivers seat! Please make way!"
I was never a big fan of the 3x symmetric ALU's in the Athlons. When it comes to integer intensive code, having a ton of independent ADDs or MULs that I'd need that kind of parallelism for was rare. And the latency (compared to a sane design like Core at least) were significantly higher due to the units being multi-purpose.
In the Phenom II design the latency of most of the register to register integer instructions is exactly 1 cycle just like the i7. The units being multi-purpose is not a latency sacrifice at all, although maybe the original Athlons had poor latency for another reason and Agner Fog's reference actually indicates that most of the register to register integer instructions on even the early K7's also had 1 cycle latency.
.. 6 cycle latency on i7, 4 cycle latency on Phenom II) .. where the I7 really shines the most is in reading directly from L1 into registers (2 cycle latency vs 3 cycle latency), with a massive 50% advantage on one of the most common operations..
Even in mem,reg operations, the Phenom II beats out the I7 in latency on many operations (ex: xor [ebx], eax
The only kind of leap second which has occurred is an extra second. It's still monotonic: 23:59:59, 23:59:60, 00:00:00 (+1 day)
You are encoding time as strings here, which is different than having a system of time. The purpose of a system of time is to be able to calculate the difference between two given encodings. Your time encoding does not have the ability to calculate such differences, so it is not a system of time.
Basically you have to choose between interval calculations that are (A) right when a specific number of leap seconds actually fall in the interval and wrong otherwise, or (B) right when no leap seconds actually fall in the interval and wrong otherwise.
What Oracle/etc are doing is using (B) because they want their time calculations to actually be right most of the time, rather than wrong most of the time.
I hope that this sheds some light on the subject for you. Just keep in mind that encoding time is not the same as a system of time, that even leap years are problematic if you only demand encoding (rather than having a system of time that encompasses 4 year, 100 year, and 400 year rules that allow you to subtract dates and get an actual number of days elapsed)
Just to be clear, when you say "integer units" you mean "integer schedulers" and not actual integer execution units, of which even the old Athlon's had 3 per core (and that hasnt changed since then.)
Unlike Intel design, with highly asymmetric execution units, AMD's have had 3 symmetric integer execution units per core since the original Athlons. Its actually a pleasant breeze to write hand-optimized integer code on AMD's.
This new design looks (in the diagram) like it actually has 4 symmetric integer execution units per integer scheduler, with the bulldozer having 2 schedulers per core while the bobcat only having 1 per core (I would guess that the logical cores are alternated on rise-and-fall states of the clock on the bobcat, and the diagram certainly makes it look like that is the case.)
Each seem to have two wide floating point execution units, so the floating point performance of both bulldozers and bobcat's are probably equivalent.
What I think AMD has done here is that with the bulldozer, in integer performance it is going to behave like it has 2x the number of real cores. So an 8 core (16 thread) chip will perform much like an 8 core CPU in floatng point work, but much more like a true 16-core CPU in integer work. This should give it a large advantage over Intel in integer work in equal-core comparisons, but the floating point performance will still lag behind Intel.
That word -- monotonically -- you're using it but I don't think you understand what it means. Adding leap seconds doesn't violate a monotonically increasing property of time. As long as the count of the seconds doesn't go down, the time function is still monotonically increasing.
Leap seconds are not defined as increment only. In fact, all the leap seconds so far (coincidental to the delay of their introduction into UTC) have been decrementing. They have all been extra seconds.
In short, you are wrong. They have violated the monotonic property of time, every time so far.
"After 23:59:59 UTC, a positive leap second at 23:59:60 would be counted, before the clock indicates 00:00:00 of the next day. Negative leap seconds are also possible, should the Earth's rotation become slightly faster -- in which case, 23:59:58 would be followed directly by 00:00:00 -- but they have not yet been used."
Regardless of when they appear, time monotonically increases.
This presumes only one kind of leap second.. the kind that skips a second, rather than introduced an extra second.
Leap seconds are not defined as increment-only, so 'handling' leap seconds based on the 'monotonic' assumption doesnt hold water.
I'll give a shit about you hating the United States when the U.N. stops asking us to be the international police force.
Only a handful of countries maintain the ability to stop aggression against them. We are one of them. If you live some place where your country does not maintain that ability, that is your loss and you should be very mad about relying on other countries for protection.
It sounds like the problem is due to the fact that the leap second is implemented as a step function and not a slew.
It is because the step function is non-systematic. Leap years are implemented as step functions just fine. You simply cannot write an algorithm to predict when a leap second will be introduced based only on the time, which is the problem.
Leap seconds are ad hoc seat-of-the-pants alterations to the time. They violate the monotonically steadily increasing property of time encoding, so simply cannot be tolerated in any system that benefits from having monotonically steadily increasing time values.
..or its actually difficult to 'handle' leap seconds. I can tell that you've never worked seriously with time values as a programmer.
If you can't answer "When will each of the next 10 leap seconds be?" and "When were the last 10 leap seconds?" then you are pretty much fucked from a programming standpoint of 'handling' it in any sane manner using common time encodings, which use a count of intervals (usually seconds, or milliseconds) since some specific date and time.
Leap seconds make it impossible to incorporate them into intervals because leap seconds are not computationally predictable.
They are simply arbitrary announcements from the time keepers "we are adjusting the clocks by 1 second on such and such a date. We dont know when we will adjust them again.. we'll keep you posted."
Leap seconds are not like leap years, which are easily handled because they are introduced systematically based on only the interval value.
I agree 100%.
Hell, "Future Generations" arent even real people. They are imaginary people. Real people can use helium now, or we can save it for some imaginary people that may exist in the future.
Prove to me that these mythical future people will exist, and THEN prove to me that THEY wont "waste" this helium in manners equivalent to the way we "waste" it. Only when both of those things can be established can we rationally talk about the value of "saving" it for "future non-wasters."
Why? Perhaps because of the disproportionate spending on defence in USA.
Disproportionate to what?
..and thats just the tax receipts.. not including the additional money that we borrow every year.
(2008 figures) It is only 20% (503.4 billion) of the U.S. total tax receipts (2.524 trillion).
The spending may be higher than it should be, but then so too is everything else the government blows money on. It is not even close to being "disproportionate." The proportions are 4:1 against.
"We the People of the United States, in order to form a more perfect Union, establish Justice, insure domestic Tranquility, provide for the common defence, promote the general Welfare, and secure the Blessings of Liberty to ourselves and our Posterity, do ordain and establish this Constitution for the United States of America"
Defense spending goes towards half of the very things (specifically enumerated above) we decided that the federal government should perform when founding our nation, yet its only 20% of the fucking budget. Its fucking insane, and you sir are not as smart as you think you are.
There are no options for people who want a carrier that doesn't mark up the cost of txt msg's 10000%.
Why not?
The answer is that there is not a large market for people that care enough that they are marked up 10000%. If there was, a company would target that market and snatch up all those users that care enough.
It is your expectations that are messed up. There simply is not a big market of people up-in-arms over text messaging rates. Most people are fine with the rates -> its what the market will bare.
Contrary to the common but ignorant belief that more Linux distro's is a good thing, they aren't.
I've said this before, both here on slashdot and elsewhere. The biggest competitor to Linux is another Linux.
... Windows
Many Linux users do seem to get this. Some just refuse to accept the fact that its not Linux vs Windows.. its Ubuntu vs Fedora vs SUSE vs Mandriva vs Debian vs Gentoo vs Slack vs
It isnt so much a bad thing that Linux competes with itself, because this sort of competition definitely has value, but it does really put the screws to commercial game development on top of a Linux flavor. Its like developing a game for multiple consoles, but without the enormous profit potential of consoles.
Besides the obvious evidence of people with MAC's dual booting and running the same games on both OSX and Windows on the same hardware and getting significantly better frame rates on Windows...
The simple fact of the matter is that OpenGL is not the same interface paradigm as modern DirectX. In the early days of Direct3D they were quite similar, but eventually Direct3D evolved to have two different rendering paradigms.. one called Immediate Mode (like OpenGL) and one called Retained Mode.
Now, Immediate Mode is a lower level interface to the hardware than Retained Mode is, and that in fact Retained Mode is implemented as a layer on top of Immediate Mode. OpenGL does immediate mode better than Direct3D's immediate mode, but as it turns out that doesnt actually matter in trms of modern game rendering pipelines.
What Microsoft has done with this Retained Mode is encompassed many optimizations, and its all centered around queuing up many rendering calls that make up a scene frame. It can then issues large batches of rendering commands to the video hardware all it once, grouping similarly textured/shadered polygons together, as well as geometry that uses the same transformation matrix, etc.. so that the state of the GPU (shaders, texture sets, transformation matrices, etc..) needs to be updated less often than a visit-each-object-once Immediate Mode algorithm would have had to do.
These state changes are expensive, often requiring the GPU to completely finish all other operations (flushing its own queue) before the state can be updated, greatly reducing parallelism. That visit-each-object-once algorithm in Immediate Mode could require 30,000 state changes while in retained mode that same visit-each-object-once algorithm only requires 5,000. As it turns out, this is a significant win that more than offsets the less efficient Immediate Mode.
This could be implemented on top of OpenGL too, so OSX could certainly do it.. but the fact is that it hasnt been done all that well yet anywhere but DirectX and a few big-name ($$$) OpenGL-centric game engines that handle it themselves.
How is there enough competition? Is that why text message prices have gone up, despite costs to send them going down? Is that why AT&T has been spending less on their (famously bad) network lately, despite traffic being up at least 40%? Does that sound like something you do when you're in tight competition?
The cost of text messaging is what it is because that is what the market will bare. If AT&T lets its infrastructure go to shit, then you can go with Verizon, Sprint, T-Mobile, etc..
The free market does not guarantee that all competitors are specifically rational about the specific thing you care about, nor is it supposed to.
You have quite a bit of choice right now when it comes to mobile carriers. If none of the services are living up to your expectations, then either your expectations are irrational or there is a big conspiracy. Given how nasty AT&T and Verizon are to each other, I'm pretty sure that they arent in bed together... so it must be your expectations that are irrational.
In its current form, native HTML5 browser media players are no solution.
In its current form, it doesnt rule our codecs with DRM built in.
Fine, HTML 5. HTML 5 is great, we can all agree on that. Now which video codec?
Flash provides DRM
Silverlight provides DRM.
HTML5 does not provide DRM.
The codec is the one with DRM, so that rules out H.264, Theora, and WebM. Got any in mind?
In the past, there was always some exponentially bigger media file people werent storing yet.
But today not only are we storing movies, we are storing them encoded at state of the art resolutions in the native format that they are available at commercially. We can increment up with twin-stream stereo video (aka 3D), and maybe a few doubling of resolution. There just isnt any orders-of-magnitude storage demand increases on the movie storage front.
Previously, there was always some next exponential thing that wasn't handled. From Text to Images to Audio to Movies. Its always been media driving the storage needs of desktops.
My question to you is simply this.. what is the next exponential demand? There isnt any media left, so I think you are just grasping at the "640K" meme at this point.
I can still buy Atari 2600 systems, accessories, and games.
Doesn't mean shit.. its still dead tech, just like the fucking floppy that you think isnt dead.
FCC analysis shows that the median actual speed consumers experienced in the first half of 2009 was roughly 3 Mbps, while the average (mean) actual speed was approximately 4 Mbps
The real story is that over 50% of the users get less than 50% of the average bandwidth. I'm not sure how to explain it, but the difference between median and mean looks quite significant to me.
You are making a calculation based on the average summary statistics quoted by manufacturers: maximum writes per hardware unit; hardware units written per OS write. In doing so, you're assuming a perfect wear levelling algorithm for any use case and no persistent metadata for that algorithm. (You're also assuming that the quoted limits for erases are close enough to correct.)
No I am not. While I did use maximum writes per hardware unit of 10,000, I showed that you can use 4,000 and still attain 5 years longevity while overwriting the entire drive every single day for the entirety of those 5 years
I did not use any manufacturer figure for the # of hardware units written per OS write. You are making that up. I used my own 200% write amplification figure, which is abysmal. In my reply, I noted that even 500% write amplification still allows the user to attain 5 years of service while overwriting the entire drive every single day for the entirety of those 5 years
I am also not assuming perfect wear leveling, since that actually doesnt play a role in the calculation needed. If a block is fully worn, the drive is simply smaller, even with the most grotesquely bad wear leveling algorithm.
But I am going to humor you, since you didnt do any calculations, and presume that (A) the erase limit is actually only 25% of advertised, (B) the write amplification is actually 500%, and (C) the wear leveling algorithm only attains 25% efficiency over the drive, causing some blocks to wear out 4 times faster than ideal.
So we've got 80,000,000,000 bytes with only 2,500 erase cycles, so thats 200,000,000,000,000 bytes of ideal write capacity, but the 500% write amplification reduces this is 40,000,000,000,000. Then factoring in 25% efficiency on the wear leveling (that some blocks will be used up 4 times faster than with an ideal wear leveling algorithm), we arrive at 10,000,000,000 bytes of write capacity using these absolutely horrific numbers that you must be imagining before any blocks cant be erased. That is still an average of 5.5 gigabytes per day of writes over a 5 year period, equivalent to replacing the entire contents of the drive every 2 weeks.. and at the end of this period, the size of the drive merely begins to shrink because we assumed 25% wear leveling efficiency.
Are these numbers simple enough for you to understand? Here I took extreme pessimism on every single value in the equation. In short, this is the nightmare scenario that you are imagining that requires that the manufacturers are lying their asses off to such an extreme extent that it would already have been witnessed in practice (because much smaller SSD's were being shipped 3 years ago in Dell laptops)
Then you'll please link to some real world reports of usage which describe how the volume is actually being accessed on a daily basis. I appreciate that they have been effective as embedded rust caches and for read-mostly databases, but that's not enough to go on.
Laptops typically do not contain "read-mostly" databases. Fir you assume every nightmare scenario imaginable. Then you even assume that the real word usage of these devices has only been at extremely good conditions. Its amazing the lengths you will go to continue to believe that your nightmare belief stopped adding up years ago. Your view just doesnt add up any longer, and it probably barely added up when you adopted it.
In a lot of countries, large portions of the population dont even have electricity.
Consider that in India alone, there are over 400 million people below the international poverty line (of $1.25 per day.) That more than the entire population of the united states, including illegals.
Except, again, you're just taking the manufacturer's summary performance data based on some unspecified average scenario and making a crude calculation. You're not taking account of paging vs block vs OS sector size, metadata location and updates (do SSDs use associative memory yet?), the nature of the wear levelling algorithm vs the nature of data written, behaviour as blocks gradually fail, etc.
Except that I wasn't? Nowhere will you find a 200% write amplification number in the manufacturers summary. The reality is that things would have to be an order of magnitude different that the numbers I used before that 5 year point isnt realistic.
That write amplification could have easily been 500% (thats 5 bytes erased per byte written!) and the user would STILL have had to overwrite the entire drive every day for 5 years.
Maybe you think the erase cycle limit is only 4,000 instead of 10,000? Thats the same thing. The user would STILL have to overwrite the entire drive every day for 5 years.
How about some citations for how unreliable SSD's are. Its really that simple. Got any? If not, why not?
Are there no usage patterns anywhere that use up the erase cycles in the first few years of ownership?
Dell has been shipping SSD's for more than a few years (much smaller ones in fact), and plenty of servers have been using SSD's for more than a few years. Both Sun and Oracle have been using much smaller SSD's as caches for their storage systems for years as well. Yet over these years, nobody has come out and reported about how they killed a bunch of them. Just the opposite, in fact, as Dell has stated that reliability is equal or better based on their very large numbers.
These things work well, and they are apparently even hard to kill with abusive patterns. They are replacing enterprise 15K drives pretty much everywhere, where they are actually priced well for that market ($2/GB is NORMAL for high end enterprise drives)
I can report to you that we've been buying these in our desktops for over a year now. We have about 200 or so deployed, for a total of about 2000 deployment-months. Zero failures so far.
The naysayers say things like "thats not enough time" etc etc..
But heres the thing. If those were platter drives, 16 of them would have died the first year based on Googles very large sample, with another 16 expected to go the next year.
Even if SSD lifetimes were actually shorter on average (which there doesnt seem to be evidence of) then it still makes sense to buy them. Its much easier to schedule the replacement of 200 drives all at once than it is to deal with surprise downtime.