[Info-vax] Storage is faster than the processor

[already5chosen at yahoo.com]

On Friday, January 8, 2016 at 5:25:14 PM UTC+2, Johnny Billquist wrote:
> On 2016-01-07 22:18, David Froble wrote:
> > Johnny Billquist wrote:
> >> On 2016-01-07 03:54, David Froble wrote:
> >>> Stephen Hoffman wrote:
> >>>>
> >>>> Having storage that is faster than the processors renders more than a
> >>>> few system and application design details obsolete.
> >>>>
> >>>>
> >>>>
> >>>> Non-volatile Storage
> >>>> Implications of the Datacenter's Shifting Center
> >>>>
> >>>> https://queue.acm.org/detail.cfm?id=2874238
> >>>>
> >>>>
> >>>> Ponder what this shift means for OpenVMS and its network and storage
> >>>> I/O stacks, for scheduling, fast path and affinity, the new file
> >>>> system and related.  And for your applications, too.
> >>>>
> >>>> This isn't fiction or future, either.   The HPE 3PAR FC SAN SSD
> >>>> storage arrays are just staggeringly faster than the old MSA gear.
> >>>> And that's before any discussions of PCIe or NVDIMMs.
> >>>>
> >>>>
> >>>
> >>> Well, for sure, it's a faster method for making my head hurt ....
> >>>
> >>> Now, remember, I'm a senile old man, who might have more than a little
> >>> trouble envisioning new methods, regardless ....
> >>>
> >>> I am having a hard time imagining how significantly faster storage I/O
> >>> can affect the things that I do with a computer.  As a simple example, a
> >>> simple operation to get some value, increment it by one, and store it.
> >>> The speed of the I/O has nothing to do with the "work" of adding 1 to
> >>> some value.  This takes a CPU or similar logic.  And the problem only
> >>> gets worse, the more "work" needed done with the data.
> >>
> >> I didn't even read the link, but I'd like to point out that your
> >> current fast CPU is spending most of its life just waiting for
> >> something to happen. SO, obviously, if you want overall perceived
> >> speed to increase, it is not the CPU that needs to get faster. It can
> >> certainly loop more times waiting for anything to happen, but that is
> >> not going to make you happy.
> >> So obviously, it is the things that the CPU is waiting for that needs
> >> to speed up. And that is memory, network and disk.
> >>
> >> "Simple operation to get some value, increment it by one, and store
> >> it" is actually in many cases a typical example of the CPU waiting an
> >> eternity to get something to work on. Getting the value? From where?
> >> If it is of any relevance it will sooner or later end up on some
> >> permanent storage. Values just kept in a CPU register is not going to
> >> be very useful.
> >>
> >>     Johnny
> >>
> >
> > If you would have read the article, what I got from it is that the
> > storage would be faster than the CPU, or CPUs, and now it would be the
> > storage waiting on the CPU(s).  Or possibly I got it wrong ....
> >
> > So, yes, making use of what used to be CPU waiting sure would speed
> > things up, but my point was, not beyond the ultimate capabilities of the
> > CPU(s).  I'm still waiting on someone smarter than me to indicate how
> > performance could go beyond that point.
> 
> Well, a lot of the time, data is just shuffled around, with no actual 
> CPU processing done on the data. So, faster CPUs don't change anything, 
> but faster storage would.
> 
> So I would suspect it would still cause a perceived performance increase.
> 
> Most computing is very little CPU work, and lots of moving bits around.
> 
> Saying that storage is faster than CPU is rather ambiguous, by the way. 
> What would we mean by that? That a full I/O transfer happened in less 
> than one clock cycle? That seems unlikely. That requests get 
> acknowledged in less than one clock cycle? More plausible, but not 
> really that interesting. That transfers starts in less than one clock 
> cycle? Also possible, but not that interesting.
> 
> 	Johnny

Don't take things too literally.
With "vary fast" storage discussed in the article, a latency of reading a single word from storage is still 4 orders of magnitude higher than latency of reading a word from L1D cache.
Emerging technologies, like Intel/Micron 3D-Xpoint have a potential for reducing the difference to 2 orders of magnitude or even a little less (approximately to factor of 50), but it will take cardinal changes in software stack. Besides, price-wise 3D-Xpoint is not exactly "storage". It's expected to be somewhat cheaper (per bit) than DRAM, but significantly more expensive than NAND flash used by SSDs.