[Info-vax] Storage is faster than the processor

[Johnny Billquist]

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