[Info-vax] Chiphead News: Intel announces new Kaby Lake processors

[johnwallace4 at yahoo.co.uk]

On Friday, 2 September 2016 14:10:05 UTC+1, Kerry Main  wrote:
> > -----Original Message-----
> > From: Info-vax [mailto:info-vax-bounces at rbnsn.com] On
> > Behalf Of IanD via Info-vax
> > Sent: 01-Sep-16 7:32 PM
> > To: info-vax at rbnsn.com
> > Cc: IanD <iloveopenvms at gmail.com>
> > Subject: Re: [Info-vax] Chiphead News: Intel announces
> > new Kaby Lake processors
> > 
> > On Thursday, September 1, 2016 at 8:53:51 PM UTC+10,
> > Neil Rieck wrote:
> > > Intel announces new Kaby Lake: Built on 14nm+, with
> > improved video decode and better top-end frequencies
> > >
> > > http://www.extremetech.com/computing/234733-intel-
> > announces-new-kaby-lake-built-on-14nm-with-improved-
> > video-decode-and-better-top-end-frequencies
> > >
> > > Today, Intel announced its upcoming Kaby Lake
> > hardware refresh. This launch is the first iteration of Intel’s
> > new Process – Architecture – Optimization strategy
> > (dubbed PAO) that replaced Tick-Tock earlier this year. It’s
> > a change driven by the realities of lithography. As die
> > shrinks have become more difficult, it now takes longer to
> > move from one node to the next. This difficulty is
> > somewhat exacerbated for Intel because it continues to
> > perform full node shrinks rather than relying on hybrid
> > process nodes like TSMC and Samsung.
> > >
> > > Neil Rieck
> > > Waterloo, Ontario, Canada.
> > >
> > http://www3.sympatico.ca/n.rieck/docs/openvms_notes
> > _itanium_diary.html
> > 
> > Interesting
> > 
> > I wonder how much of this technology is going to make it's
> > way to the server cpu's?
> > 
> > Speedshift is going to require some rather interesting
> > code. I believe it requires the OS to hand over control to
> > the CPU for certain burst cycles?
> > 
> > Clock speeds are diminishing, and Intel is looking internally
> > within the cpu to extract every speed aspect it can from
> > the cpu and how it can optimise even tiny compute
> > changes. The announced cpu has more video decoding
> > goodness built in
> > 
> > Linux has always been fast because it is lean and
> > OpenVMS the slow beast except for a brief time when
> > Alpha ruled the world
> > 
> 
> Well, I would argue that it depends, but it's kind of moot comparing OpenVMS of the past with the future until OpenVMS gets its new engine (file system) and new set of wheels (new TCPIP stack) added in.
> 
> > I'm really looking forward to seeing how OpenVMS
> > behaves against linux when the two OS are running on the
> > same bit of silicone.
> > 
> > I know to start with, OpenVMS will be pretty much a
> > straight port (at what specific processor I wonder?) and
> > will not be optimised to take advantage of the latest and
> > greatest offerings from Intel / AMD but in the years
> > ahead, it will be interesting to see if any of the OpenVMS
> > internal design enables OpenVMS to pull ahead of linux in
> > certain areas? (speaking from a total lack of linux internal
> > knowledge of course!)
> > 
> 
> Misc. points for consideration:
> 
> - ALL X86-64 architectures are now NUMA based 
> - OpenVMS has been optimizing its OS scheduler code to accommodate NUMA and RADS since the Alpha GS160 days
> - Huge non-volatile memory (TB) and large core NUMA systems (32/64+) are going to mean that server and App deployment strategies are going to become much more centralized
> - Due to global IT SLA's becoming more common, multi-site DR/DT is becoming even more critical than the past
> - IF galaxy style shared memory, dynamic cpu reallocation between OS instances (based on rules or workloads) features makes it to OpenVMS/X86-64, remember that Linux and Windows does not yet have this capability.
> 
> Re: NUMA on OpenVMS
> http://h41379.www4.hpe.com/openvms/journal/v16/rad.html 
> "With RAD soft-affinity, the OpenVMS Scheduler attempts to schedule a process on a CPU from the Home RAD of that process. This is a complementary mechanism to ensure that when a process is scheduled on a CPU, the memory references for that process become more local. Any CPU hard-affinity set for a particular process to particular CPU(s) takes precedence over the RAD soft-affinity."
> 
> "When a process is ready to be scheduled, if the scheduler does not find an idle CPU from the Home RAD of that process, it skips the scheduling of that process for skip count iterations; beyond that the Scheduler chooses a CPU from a remote RAD."
> 
> As you indicated .. the plot thickens ..
> 
> :-)
> 
> 
> Regards,
> 
> Kerry Main
> Kerry dot main at starkgaming dot com

Mostly agreed, but reallocation of "hardware" resources (memory,
processors, IO) isn't relevant to commodity OSes - it's not
relevant that they can't do it, because the IT department rely
on the HYPErvisor to provide that functionality (generally).

How do you tune a VAX? Give it more memory.

How do you tune an x86 system? Buy a newer one.

Neither are entirely fair, but...