[Info-vax] The Machine - Dows Jones newswire report

[Stephen Hoffman]

On 2016-11-29 04:46:00 +0000, David Froble said:

>> Engineers have booted up an early version of the hardware in a lab in 
>> Fort Collins, Colorado, a test of the design the company says will 
>> allow programmers to begin working on new software that will be needed 
>> to exploit the system.
> 
> Where have we heard that before, new software for the HW?  Can you say itanic?

TM is a much bigger shift than was the EPIC / VLIW Itanium design, too. 
  Itanium processors and the instruction set are very different from 
other common architectures and designs, but the basic processing 
interconnects and memory and caching system designs aren't different, 
and even the application programming isn't particularly different.   
BASIC source code from OpenVMS VAX can still be gotten to work on 
OpenVMS I64, and — modulo the differences in cache and memory and 
remote processor access times due to NUMA — SMP still works more or 
less the same.

http://labs.hoffmanlabs.com/node/431

> It's interesting that HP feels that they need something new to take 
> advantage of advances in memory technology.

They're looking to use a server design that's not based on the Von 
Neumann architecture.   TM is much more than the RRAM memory technology 
that HPE has been advertising, and — based on their previous 
presentations — much different from the sorts of Von Neumann boxes that 
run OpenVMS, Microsoft Windows, Linux, BSD, macOS, iOS, Android/ASOS 
and otherwise.

https://en.wikipedia.org/wiki/Von_Neumann_architecture

HPE hasn't explained what sort of design changes are going to be 
recommended or required of application software, and what sorts of APIs 
and language extensions or alternate programming languages are going to 
be involved, either.  If the developers are going to be looking to use 
more or all of what TM servers might provide, and not just cobble 
together something that can compile and run on the box...   Current 
computers are already increasingly complex networks of processors and 
embedded software and firmware and embedded volatile and non-volatile 
storage and SGX enclaves and the rest — all parts of that network 
entirely within the same server "box" — and TM looks to take that 
approach much, much further.  Much further away from how the boxes and 
the caches and the rest of the innards of the server are presently 
organized.

> Or, is it they want to charge more for their products?

They'd like to find products with more profit than their existing ones, 
whether that means more expensive products or designs and 
configurations with patent or technical impediments or other sorts of 
pricing (profit) protections.   Who wouldn't?

> Just as AMD added 64 bit stuff to x86, when the new memory technology 
> is available, you'll see people using it with x86 and such existing 
> technologies.

And just like happens now, you'll see folks force-fitting the newer 
technology into the older hardware designs.   SSDs, for instance, were 
how flash was force-fit into older bus-based designs prior to the 
availability of DIMM socket flash and M.2 NGFF slots and such.   Also 
how folks are force-fitting existing software, too.   The existing I/O 
stack on OpenVMS is positively baroque, compared with what 
byte-addressable non-volatile storage provides.

> Now, I'm sure there are jobs for computers where data is read and acted 
> upon. But in my world the data is also updated by multiple entities at 
> the same time.   That requires some form of locking.  Or something I 
> haven't yet imagined. That means that those large number of processors 
> working on the same memory at the same time aren't going to be able to 
> go as fast as some would have you believe.

One step below locking is cache coherence; where different processors 
either have a consistent view of what's in local cache and shared cache 
and in whatever is being used for main memory, or however the 
particular system is designed.   At this level, you're working with 
memory barriers and cache hardware.   An architecture that is not Von 
Neumann works very differently here, and it's not something that 
OpenVMS itself will support.

http://labs.hoffmanlabs.com/node/407

> We had that discussion here recently, directly reading and writing 
> memory, not moving to and from I/O buffers.  I'm buying the concept.  I 
> think I can also see it happening with today's systems.

It's already happened.  Something very similar already happened with 
OpenVMS and some forty years ago too, though that hardware and that 
software support was discontinued.   With the newer hardware such as 
RRAM, the associated morass of batteries isn't needed, though some 
operating system code and some application software is likely going to 
require a little rework around properly initializing and reinitializing 
storage that can already contain (possibly corrupted, possibly entirely 
valid) code and data.  That's before discussing how to protect the 
storage from stray overwrites and a host of other topics — more than a 
few memory paging designs and implementations will be or are now being 
significantly reworked, and much more directly integrated with the 
operating system I/O stacks.



-- 
Pure Personal Opinion | HoffmanLabs LLC