Memristor is an a pseudo-object with a set of meta properties. A lot of things could be technically be a memristor. Human skin can technically be one, but making use of it would be rather difficult. XPoint may be similar to a memristor in a layman's sense, but Intel may realize that XPoint only has the property of storage, which is not the only meta property required. It is also not phase-change because nothing physical changes. Not much information to go on.
Intel said they're unifying memory and storage with this. No more distinction between DRAM and HDs, they're one and the same. Of course other stuff needs to happen first, but that obviously indicates that they expect it to replace DRAM. Actually, the explicitly stated they will make DRAM with it.
"Memristors" are anything with certain meta properties. Assume XPoint fits the theoretical definition of memristor perfectly, you can process and store data at the same time.
Unofficial sources are starting to say that XPoint does not exhibit wear from write cycles and the "1000x more endurance" is normalized to some other metric. If it was normalized against time, then you may expect NAND to last 3-5 years which would put XPoint around 3,000-5,000 years life time. We won't know until more official data or hands-on reviews happen.
DDR3 is about 10ns. If XPoint is 1000x faster than 5us NAND, then it has 1/2 the latency of DRAM. I doubt it, but you can see how it can easily be within a a factor or two.
When you restart your computer without a power down, you still have all that data in memory. Same difference. As for a power down, the only real benefit is it also resets the CPU and other hardware. When the BIOS starts up and copies data from the HD into memory, it already over-writes what was ever there. No changes required. If you want to take advantage of having persistent memory, then you'll need new protocols, but old protocols should continue to work as expected.
As the "new" blocks were written out for the rest of the file, the filesystem would see that they were identical to existing blocks on disk and just point to them instead.
That only works if the newly resulting blocks are the same. If you cause all of the data to shift, then all of the data in the blocks could also shift creating blocks are that not the same. Flipping bits is one thing, but changing length is another.
TLC VNAND has upwards of 60k cycles, but as low as 5k. Depends on how fast you want it. It's a speed-endurance tradeoff. 60k cycles is about 1/3rd the speed of the 5k cycles. With a non-linear tradeoff that causes diminishing returns on gained speed, there's bound to be a happy medium.
This is where a good manager comes into play. My current and past manager would tell the other departments that if they could not do a good job in a timely fashion, we would do the job.
A programmer's productivity is relatively static. What's important is the quality of the code that allows the programmer to multiply the productivity of others. Code quality becomes very important as each layer of dependencies compounds the complexity of the system. 80/20 rules great until you're 3 dependency layers deep and 0.8^3 is only 0.5.
If a project is to take less than a month of uninterrupted dedicated work, I can usually get the time within 80%, siding on caution, so typically early. The further a project is expected to take, the more buffer I need to add in case things take longer.
As a programmer, it is my job to get into the head of the end user and figure out what they're trying to do. Requires seeing what they do, unrderstanding why they do it, and the end result.
"Union" is a dirty word because of cases like this. Someone at a local union shop was coming into work 2 hours late, strait from the bar and pissed up, then would leave 2 hours early, handled heavy equipment which resulted in some near accidents. No one told on him because he was high in the Union, but the company looked into the near accidents that got reported. Once finding out this guy was coming in late and drunk and leaving early, they fired him. A month later, the Union successfully sued the employer for firing the employee without first consulting the Union for permission. The person was rehired at his original wage and pretty much given a job to do nothing because he was always drunk. The employer finally got him to leave by offering him money to leave.
Crap like this is why people around here hate Unions.
Finding good programmers is not like walking into an empty room and looking to see who is in it. Its more like going to a packed stadium and trying to find where your friends are and they didn't tell you in advance.
Learning how to code is one thing but becoming programmers is another. More bad programmers gives me more headaches and makes it harder for me to design correct solutions because of legacy issues. Ever try to design a system that can emulate bugs of the old system until the dependencies can also get fixed? It's really annoying.
I don't want to have a job, I want to have fun and be proud of my work while getting paid to do what I enjoy. I enjoy programming, the last thing I want is to lose that, it is a large part of who I am.
The switching would be done in blocks and could be ware levelled
With all of the issues wear leveling has created with SSDs, I would be very skeptical about wear leveling in system memory. And memory has much different write characteristics than HDs. Memory is typically written bytes at a time, not large blocks. This would cause massive write amplification for any block based wear leveling.
Of course this memory is bit addressable, so the wear leveling blocks could be made very small, but as your blocks get smaller, the meta-data overhead to manage the blocks approaches the size of your actual data.
It would be interesting to have more research as into what is actually gained from the exposure so that information can be focused on. Whenever I have to work with someone new that acts as the in-between person between me and the customer, I bring up questions for corner and edge cases during my talks. I'm pretty quick to recognize edge and corner cases as someone is giving me the specs. I quickly look over the specs and start rattling off questions, then I hypothetically make answers for those questions which creates even more questions. The person can quickly see how what they thought were "good specs" quickly turns into a hundred questions of things they did not think about.
Some people with whom I have worked long are now very good at thinking ahead or recognizing when something feels off and come to me during the discussions with the customer instead of waiting for after.
Slashdot Mirror
Memristor is an a pseudo-object with a set of meta properties. A lot of things could be technically be a memristor. Human skin can technically be one, but making use of it would be rather difficult. XPoint may be similar to a memristor in a layman's sense, but Intel may realize that XPoint only has the property of storage, which is not the only meta property required. It is also not phase-change because nothing physical changes. Not much information to go on.
The only thing for sure is it is a form of ReRAM.
Wiki
the fact that phase-change is a thermally driven process
10ghz is what they predicted, XPoint already exists.
Intel said they're unifying memory and storage with this. No more distinction between DRAM and HDs, they're one and the same. Of course other stuff needs to happen first, but that obviously indicates that they expect it to replace DRAM. Actually, the explicitly stated they will make DRAM with it.
"Memristors" are anything with certain meta properties. Assume XPoint fits the theoretical definition of memristor perfectly, you can process and store data at the same time.
Unofficial sources are starting to say that XPoint does not exhibit wear from write cycles and the "1000x more endurance" is normalized to some other metric. If it was normalized against time, then you may expect NAND to last 3-5 years which would put XPoint around 3,000-5,000 years life time. We won't know until more official data or hands-on reviews happen.
DDR3 is about 10ns. If XPoint is 1000x faster than 5us NAND, then it has 1/2 the latency of DRAM. I doubt it, but you can see how it can easily be within a a factor or two.
When you restart your computer without a power down, you still have all that data in memory. Same difference. As for a power down, the only real benefit is it also resets the CPU and other hardware. When the BIOS starts up and copies data from the HD into memory, it already over-writes what was ever there. No changes required. If you want to take advantage of having persistent memory, then you'll need new protocols, but old protocols should continue to work as expected.
shark bait hoo haha - Finding Nemo
2ms is a few magnitudes too high for NAND. Google is returning back latencies of 5us-25us for NAND.
As the "new" blocks were written out for the rest of the file, the filesystem would see that they were identical to existing blocks on disk and just point to them instead.
That only works if the newly resulting blocks are the same. If you cause all of the data to shift, then all of the data in the blocks could also shift creating blocks are that not the same. Flipping bits is one thing, but changing length is another.
if you just write to the same memory location over and over with DDR4 you can write every 5 cycles @ 1.25ns/cycle = 160,000,000 writes/second
And you'd both burn our your CPU's SRAM and DRAM in under a year. They're only rated for around 10^16 writes.
TLC VNAND has upwards of 60k cycles, but as low as 5k. Depends on how fast you want it. It's a speed-endurance tradeoff. 60k cycles is about 1/3rd the speed of the 5k cycles. With a non-linear tradeoff that causes diminishing returns on gained speed, there's bound to be a happy medium.
My LCD monitor takes longer than 1sec to turn on. I'm not too concerned. 1sec is "instant" for this class of interactions.
Flipping at bit at 100mhz would burn out your L1 cache's SRAM in one year.
This is where a good manager comes into play. My current and past manager would tell the other departments that if they could not do a good job in a timely fashion, we would do the job.
A programmer's productivity is relatively static. What's important is the quality of the code that allows the programmer to multiply the productivity of others. Code quality becomes very important as each layer of dependencies compounds the complexity of the system. 80/20 rules great until you're 3 dependency layers deep and 0.8^3 is only 0.5.
Sometimes the only way to fix cancer is to destroy it.
If a project is to take less than a month of uninterrupted dedicated work, I can usually get the time within 80%, siding on caution, so typically early. The further a project is expected to take, the more buffer I need to add in case things take longer.
As a programmer, it is my job to get into the head of the end user and figure out what they're trying to do. Requires seeing what they do, unrderstanding why they do it, and the end result.
"Union" is a dirty word because of cases like this. Someone at a local union shop was coming into work 2 hours late, strait from the bar and pissed up, then would leave 2 hours early, handled heavy equipment which resulted in some near accidents. No one told on him because he was high in the Union, but the company looked into the near accidents that got reported. Once finding out this guy was coming in late and drunk and leaving early, they fired him. A month later, the Union successfully sued the employer for firing the employee without first consulting the Union for permission. The person was rehired at his original wage and pretty much given a job to do nothing because he was always drunk. The employer finally got him to leave by offering him money to leave.
Crap like this is why people around here hate Unions.
Finding good programmers is not like walking into an empty room and looking to see who is in it. Its more like going to a packed stadium and trying to find where your friends are and they didn't tell you in advance.
Learning how to code is one thing but becoming programmers is another. More bad programmers gives me more headaches and makes it harder for me to design correct solutions because of legacy issues. Ever try to design a system that can emulate bugs of the old system until the dependencies can also get fixed? It's really annoying.
I don't want to have a job, I want to have fun and be proud of my work while getting paid to do what I enjoy. I enjoy programming, the last thing I want is to lose that, it is a large part of who I am.
The switching would be done in blocks and could be ware levelled
With all of the issues wear leveling has created with SSDs, I would be very skeptical about wear leveling in system memory. And memory has much different write characteristics than HDs. Memory is typically written bytes at a time, not large blocks. This would cause massive write amplification for any block based wear leveling.
Of course this memory is bit addressable, so the wear leveling blocks could be made very small, but as your blocks get smaller, the meta-data overhead to manage the blocks approaches the size of your actual data.
It would be interesting to have more research as into what is actually gained from the exposure so that information can be focused on. Whenever I have to work with someone new that acts as the in-between person between me and the customer, I bring up questions for corner and edge cases during my talks. I'm pretty quick to recognize edge and corner cases as someone is giving me the specs. I quickly look over the specs and start rattling off questions, then I hypothetically make answers for those questions which creates even more questions. The person can quickly see how what they thought were "good specs" quickly turns into a hundred questions of things they did not think about.
Some people with whom I have worked long are now very good at thinking ahead or recognizing when something feels off and come to me during the discussions with the customer instead of waiting for after.
Only a transitional pain. Once everyone had immature dirt, no one person will stand out more than another.