VMS x86 performance ?

[IanD]

It's been a while since this topic was first aired and the response at the time was "it is too early to tell"

This was quite some time ago now

I don't expect benchmarks as such but I would have thought we have a general idea as to how it performs compared to Itanium or Alpha by now?

Ballpark figures?

10%, 20%, 50%, Rabbit on crack? Still too early to tell?

*Yes, I'm talking about a VM environment since that will probably be the normal deployment environment

[[e-mail]]

Post by IanD
It's been a while since this topic was first aired and the response at the time was "it is too early to tell"
This was quite some time ago now
I don't expect benchmarks as such but I would have thought we have a general idea as to how it performs compared to Itanium or Alpha by now?
Ballpark figures?
10%, 20%, 50%, Rabbit on crack? Still too early to tell?
*Yes, I'm talking about a VM environment since that will probably be the normal deployment environment

IanD,

Working with preliminary cross compilers? Early field test software?

I would think that it is far too early to make any comments that would have any validity.

Bootstrap speed of the pre=configured appliance is reasonable.

- Bob Gezelter, http://www.rlgsc.com

[Simon Clubley]

Post by ***@rlgsc.com

Post by IanD
It's been a while since this topic was first aired and the response at the time was "it is too early to tell"
This was quite some time ago now
I don't expect benchmarks as such but I would have thought we have a general idea as to how it performs compared to Itanium or Alpha by now?
Ballpark figures?
10%, 20%, 50%, Rabbit on crack? Still too early to tell?
*Yes, I'm talking about a VM environment since that will probably be the normal deployment environment

IanD,
Working with preliminary cross compilers? Early field test software?

The compilers are only one part of this.

Ian is very, very correct. We should be getting some initial indications
by now, especially for I/O bound workloads, where the compilers are far
less important.

For example, tests from RMS could compare Alpha/Itanium performance
with x86-64 (and associated I/O hardware) performance.

Tests using RMS could also show if there are any noticable overheads
from mapping 4 VMS modes (KESU) into 2 hardware modes (KU).

Those same tests repeated on AMD hardware would show what additional
overheads are imposed by not having PCID available.

Initial I/O performance testing would show how much faster than Itanium
(or Alpha) VMS on x86-64 is (assuming that x86-64 VMS is indeed faster
than Alpha or Itanium VMS) for I/O based workloads and would make good
publicity within the VMS community for VSI.

So yes, it makes perfect sense in VSI-land that VSI wouldn't bother
doing such tests. :-(

Post by ***@rlgsc.com
I would think that it is far too early to make any comments that would have any validity.

We are _6_ _years_ into the port! How much longer are people going to
have to wait ?

Simon.

[Craig A. Berry]

Post by Simon Clubley

Post by ***@rlgsc.com
Working with preliminary cross compilers? Early field test software?

The compilers are only one part of this.
Ian is very, very correct. We should be getting some initial indications
by now, especially for I/O bound workloads, where the compilers are far
less important.
For example, tests from RMS could compare Alpha/Itanium performance
with x86-64 (and associated I/O hardware) performance.

Which would be meaningless because RMS is software that is getting
compiled with non-optimized cross compilers, and other parts of the I/O
path are also compiled software. Disk I/O and network I/O have
traditionally been much slower on VMS than on other OSs running on the
same hardware, especially with default settings, so the difference
pretty much has to be in software, which is currently getting compiled
with rough-and-ready cross compilers. Your impatience has no impact on
how the technology actually works.

Post by Simon Clubley
We are _6_ _years_ into the port! How much longer are people going to
have to wait ?

At least until v9.1, but don't get your hopes up even then. v9.1 is
scheduled for the first half of next year. While the compilers will be
native, I don't know if optimizations will be available in compilers
provided with the initial EAK (and the compiler engineers may not know
yet either). There may very well be an agreement that comes with
downloading the EAK that forbids public posting of benchmarks.

It is certainly frustrating that the port is taking a long time. But the
original projection of a two-year port beginning in 2015 was predicated
on having a team of 70 doing the port, on not doing Alpha releases, and
probably not doing a bunch of other things they have ended up having to
do but weren't initially planning on doing before the port. I don't
know how many people are working on the port, but I'm guessing it isn't 70.

The sharply narrowed focus of the latest roadmap suggests that they are
doubling down on the port and making it a top priority. There will
certainly be some opportunities lost by the fact that the first
production release on x86_64 is still a year away (if all goes according
to the current plan). But I have a hard time believing that anyone is
more eager to have it done than the people doing it. So complaining in
the newsgroup about how long it's taking is probably not going to make
it happen faster (though I admit I have certainly done some complaining
myself).

[Arne Vajhøj]

Post by Craig A. Berry

Post by Simon Clubley
We are _6_ _years_ into the port! How much longer are people going to
have to wait ?

It is certainly frustrating that the port is taking a long time. But the
original projection of a two-year port beginning in 2015 was predicated
on having a team of 70 doing the port, on not doing Alpha releases, and
probably not doing a bunch of other things they have ended up having to
do but weren't initially planning on doing before the port.  I don't
know how many people are working on the port, but I'm guessing it isn't 70.

Yes.

And any comparison to previous ports are not particular relevant.

When VAX to Alpha was done then DEC was one of the worlds largest IT
companies.

When Alpha to Itanium was done then HP was one the worlds largest IT
companies.

I don't think VSI will feel insulted if I say they are not one of the
worlds largest IT companies.

Reality.

Arne

[Simon Clubley]

Post by Arne Vajhøj
I don't think VSI will feel insulted if I say they are not one of the
worlds largest IT companies.

They might. :-)

VSI claim that out of all the operating systems produced in the world,
theirs is the most secure.

They might not appreciate you bringing them back down to Earth. :-)

Post by Arne Vajhøj
Reality.

VSI marketing could do with a dose of that. Their current approach
is storing up potential trouble for VMS customers if researchers
notice and then go "Oh really ??? Are you sure about that ?".

Simon.

[Phillip Helbig (undress to reply)]

Post by Simon Clubley

Post by Arne Vajhøj
I don't think VSI will feel insulted if I say they are not one of the
worlds largest IT companies.

They might. :-)
VSI claim that out of all the operating systems produced in the world,
theirs is the most secure.
They might not appreciate you bringing them back down to Earth. :-)

So which one is the most secure?

[Bill Gunshannon]

Post by Phillip Helbig (undress to reply)

Post by Simon Clubley

Post by Arne Vajhøj
I don't think VSI will feel insulted if I say they are not one of the
worlds largest IT companies.

They might. :-)
VSI claim that out of all the operating systems produced in the world,
theirs is the most secure.
They might not appreciate you bringing them back down to Earth. :-)

So which one is the most secure?

My money is on RSTS or Primos.

bill

[Dennis Boone]

Post by Bill Gunshannon
My money is on RSTS or Primos.

Haha!

De

[Bill Gunshannon]

Post by Bill Gunshannon
My money is on RSTS or Primos.

Haha!
De

What's so funny? When was the last time you saw a CVE for either OS?

bill

(OK, you win. Here it is :-)

[Simon Clubley]

Post by Bill Gunshannon

Post by Bill Gunshannon
My money is on RSTS or Primos.

Haha!
De

What's so funny? When was the last time you saw a CVE for either OS?
bill
(OK, you win. Here it is :-)

By that definition, MP/M is the most secure OS around. :-)

Simon.

[Scott Dorsey]

Post by Bill Gunshannon

Post by Phillip Helbig (undress to reply)
So which one is the most secure?

My money is on RSTS or Primos.

It's definitely not Pr1mos. When I was in grad school, the college I was at
was running Pr1mos 19, and I knew at least ten different ways to get system
access from a user account. Not all of them were timing issues either!

Pr1mos had so many different layers of compatibility stuff, so many different
operating modes, that there were all kinds of little places for security holes
to hide. Complexity is the enemy of security.
--scott

[Bill Gunshannon]

Post by Scott Dorsey

Post by Bill Gunshannon

Post by Phillip Helbig (undress to reply)
So which one is the most secure?

My money is on RSTS or Primos.

It's definitely not Pr1mos. When I was in grad school, the college I was at
was running Pr1mos 19, and I knew at least ten different ways to get system
access from a user account. Not all of them were timing issues either!
Pr1mos had so many different layers of compatibility stuff, so many different
operating modes, that there were all kinds of little places for security holes
to hide. Complexity is the enemy of security.

Try them on Rev 24. Rev 19 was old even before I faded from the
Primos world (well, kinda faded, I still have it running on
emulators here and now!)
Still, I expect Primos has had about as much hacking attacks
pointed at it as VMS.

Still leaves RSTS, my favorite OS. :-)

bill

[Dave Froble]

Post by Bill Gunshannon

Post by Scott Dorsey

Post by Bill Gunshannon

Post by Phillip Helbig (undress to reply)
So which one is the most secure?

My money is on RSTS or Primos.

It's definitely not Pr1mos. When I was in grad school, the college I was at
was running Pr1mos 19, and I knew at least ten different ways to get system
access from a user account. Not all of them were timing issues either!
Pr1mos had so many different layers of compatibility stuff, so many different
operating modes, that there were all kinds of little places for security holes
to hide. Complexity is the enemy of security.

Try them on Rev 24. Rev 19 was old even before I faded from the
Primos world (well, kinda faded, I still have it running on
emulators here and now!)
Still, I expect Primos has had about as much hacking attacks
pointed at it as VMS.
Still leaves RSTS, my favorite OS. :-)
bill

I confess to curiosity. What is there about RSTS that you like so much?

RSTS was my first serious OS, and I liked it. But there were so many
restrictions. 16 bit being the most significant. There was the dreaded
TKB. (Yes, TKB taught one to be precise and know a bit about what one
was doing.)

About 2 months after I started on VMS, RSTS was forgotten ....

[Bill Gunshannon]

Post by Bill Gunshannon

Post by Bill Gunshannon

Post by Phillip Helbig (undress to reply)
So which one is the most secure?

My money is on RSTS or Primos.

It's definitely not Pr1mos.  When I was in grad school, the college I
was at
was running Pr1mos 19, and I knew at least ten different ways to get system
access from a user account.  Not all of them were timing issues either!
Pr1mos had so many different layers of compatibility stuff, so many different
operating modes, that there were all kinds of little places for security holes
to hide.  Complexity is the enemy of security.

Try them on Rev 24. Rev 19 was old even before I faded from the
Primos world (well, kinda faded, I still have it running on
emulators here and now!)
Still, I expect Primos has had about as much hacking attacks
pointed at it as VMS.
Still leaves RSTS, my favorite OS.  :-)
bill

I confess to curiosity.  What is there about RSTS that you like so much?

I don't really kow. Why do people like VMS? Why do people like
Unix? It was not my first nor my last OS but I always found it
easy, if not fun, to both administer and use.

RSTS was my first serious OS, and I liked it.  But there were so many
restrictions.  16 bit being the most significant.

Hardly significant when most of it's competitors were still 8bit or
also 16bit.

  There was the dreaded
TKB.  (Yes, TKB taught one to be precise and know a bit about what one
was doing.)

Never had much problem with TKB. But then, I was real good at doing
overlays in Ultrix-11, too. Probably a brain tumor or something.

About 2 months after I started on VMS, RSTS was forgotten ....

I had used VMS before I first worked with RSTS. In those early days
I definitely preferred Unix to VMS. And while I spent the majority
of my time on Unix, I still enjoy playing with RSTS while Unix is
just a tool to get a job done, to me. (Except Ultrix-11 which is still
fun!!)

Guess there is no real explanation.

I also still like Primos and Exec-8.

bill

[allen rueter]

We had vms driving front end terminals to access in-house RSTS/E DB
Allen Rueter

On Sat, Oct 31, 2020 at 13:50 Dave Froble via Info-vax <

Post by Dave Froble

Post by Bill Gunshannon

Post by Scott Dorsey

Post by Bill Gunshannon

Post by Phillip Helbig (undress to reply)
So which one is the most secure?

My money is on RSTS or Primos.

It's definitely not Pr1mos. When I was in grad school, the college I was at
was running Pr1mos 19, and I knew at least ten different ways to get system
access from a user account. Not all of them were timing issues either!
Pr1mos had so many different layers of compatibility stuff, so many different
operating modes, that there were all kinds of little places for security holes
to hide. Complexity is the enemy of security.

Try them on Rev 24. Rev 19 was old even before I faded from the
Primos world (well, kinda faded, I still have it running on
emulators here and now!)
Still, I expect Primos has had about as much hacking attacks
pointed at it as VMS.
Still leaves RSTS, my favorite OS. :-)
bill

I confess to curiosity. What is there about RSTS that you like so much?
RSTS was my first serious OS, and I liked it. But there were so many
restrictions. 16 bit being the most significant. There was the dreaded
TKB. (Yes, TKB taught one to be precise and know a bit about what one
was doing.)
About 2 months after I started on VMS, RSTS was forgotten ....
--
David Froble Tel: [phone]
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
_______________________________________________
Info-vax mailing list
http://info-vax.com/mailman/listinfo/info-vax_info-vax.com

[Simon Clubley]

Post by Dave Froble
About 2 months after I started on VMS, RSTS was forgotten ....

This times a million. The only thing I missed from RSTS/E was the
ability to detach an interactive job and there were ways around
that problem.

Simon.

[Phillip Helbig (undress to reply)]

Post by Simon Clubley

Post by Dave Froble
About 2 months after I started on VMS, RSTS was forgotten ....

This times a million. The only thing I missed from RSTS/E was the
ability to detach an interactive job and there were ways around
that problem.

That and command completion are the only two things on unix which I
don't have on VMS, though there are various workarounds. Having said
that, these two things aren't as important on VMS as on unix.

[Simon Clubley]

Post by Phillip Helbig (undress to reply)
That and command completion are the only two things on unix which I
don't have on VMS, though there are various workarounds. Having said
that, these two things aren't as important on VMS as on unix.

Filename completion is needed as much on VMS as it is on Unix.

Work with it for a while and you will _really_ miss it when using DCL.

Editing long command lines is really needed as well, but thanks to all
the technical debt that has been built up in the VMS terminal driver
that isn't going to happen anytime soon.

Simon.

[Arne Vajhøj]

Post by Simon Clubley

Post by Phillip Helbig (undress to reply)
That and command completion are the only two things on unix which I
don't have on VMS, though there are various workarounds. Having said
that, these two things aren't as important on VMS as on unix.

Filename completion is needed as much on VMS as it is on Unix.
Work with it for a while and you will _really_ miss it when using DCL.

Time to port DCLCOMPLETE to Alpha and Itanium?

:-)

Arne

[Dave Froble]

Post by Simon Clubley

Post by Phillip Helbig (undress to reply)
That and command completion are the only two things on unix which I
don't have on VMS, though there are various workarounds. Having said
that, these two things aren't as important on VMS as on unix.

Filename completion is needed as much on VMS as it is on Unix.

Every time this topic comes up I remember JF's idea of completion for
passwords.

:-)

[Stephen Hoffman]

Post by Dave Froble

Post by Simon Clubley
...
Filename completion is needed as much on VMS as it is on Unix.

Every time this topic comes up I remember JF's idea of completion for
passwords.

That's another feature missing from OpenVMS, yes; there's no password
manager and no support for that.

Post by Dave Froble
:-)

Yes, I saw that.

[V***@SendSpamHere.ORG]

Post by Dave Froble

Post by Simon Clubley

Post by Phillip Helbig (undress to reply)
That and command completion are the only two things on unix which I
don't have on VMS, though there are various workarounds. Having said
that, these two things aren't as important on VMS as on unix.

Filename completion is needed as much on VMS as it is on Unix.

Every time this topic comes up I remember JF's idea of completion for
passwords.
:-)

ROTFLMFAO!

I sure do miss JF being here.

[Phillip Helbig (undress to reply)]

Post by V***@SendSpamHere.ORG

Post by Dave Froble

Post by Simon Clubley
Filename completion is needed as much on VMS as it is on Unix.

Every time this topic comes up I remember JF's idea of completion for
passwords.
:-)

ROTFLMFAO!
I sure do miss JF being here.

Whatever happened to him?

[V***@SendSpamHere.ORG]

Post by Phillip Helbig (undress to reply)

Post by V***@SendSpamHere.ORG

Post by Dave Froble

Post by Simon Clubley
Filename completion is needed as much on VMS as it is on Unix.

Every time this topic comes up I remember JF's idea of completion for
passwords.
:-)

ROTFLMFAO!
I sure do miss JF being here.

Whatever happened to him?

No idea. Maybe he was run over somewhere while biking.

[Arne Vajhøj]

Post by V***@SendSpamHere.ORG

Post by Phillip Helbig (undress to reply)

Post by V***@SendSpamHere.ORG

Post by Dave Froble

Post by Simon Clubley
Filename completion is needed as much on VMS as it is on Unix.

Every time this topic comes up I remember JF's idea of completion for
passwords.
:-)

ROTFLMFAO!
I sure do miss JF being here.

Whatever happened to him?

No idea. Maybe he was run over somewhere while biking.

If I remember correctly then he switched from VMS to
MacOS X server and then Apple ditched MacOS X server.

Arne

[Jan-Erik Söderholm]

Post by Arne Vajhøj

Post by Phillip Helbig (undress to reply)

Post by V***@SendSpamHere.ORG

Post by Dave Froble

Post by Simon Clubley
Filename completion is needed as much on VMS as it is on Unix.

Every time this topic comes up I remember JF's idea of completion for
passwords.
:-)

ROTFLMFAO!
I sure do miss JF being here.

Whatever happened to him?

No idea.  Maybe he was run over somewhere while biking.

If I remember correctly then he switched from VMS to
MacOS X server and then Apple ditched MacOS X server.
Arne

Right, more or less what VAXman just wrote, not?

[Arne Vajhøj]

Post by Jan-Erik Söderholm

Post by Arne Vajhøj

Post by Phillip Helbig (undress to reply)

Post by V***@SendSpamHere.ORG

Post by Dave Froble

Post by Simon Clubley
Filename completion is needed as much on VMS as it is on Unix.

Every time this topic comes up I remember JF's idea of completion for
passwords.
:-)

ROTFLMFAO!
I sure do miss JF being here.

Whatever happened to him?

No idea.  Maybe he was run over somewhere while biking.

If I remember correctly then he switched from VMS to
MacOS X server and then Apple ditched MacOS X server.

Right, more or less what VAXman just wrote, not?

Maybe.

He is still alive, He has been pretty active on Twitter
last 24 hours.

Arne

[John H. Reinhardt]

Post by Arne Vajhøj

Post by Jan-Erik Söderholm

Post by Arne Vajhøj

Post by Phillip Helbig (undress to reply)

Post by V***@SendSpamHere.ORG

Post by Dave Froble

Post by Simon Clubley
Filename completion is needed as much on VMS as it is on Unix.

Every time this topic comes up I remember JF's idea of completion for
passwords.
:-)

ROTFLMFAO!
I sure do miss JF being here.

Whatever happened to him?

No idea.  Maybe he was run over somewhere while biking.

If I remember correctly then he switched from VMS to
MacOS X server and then Apple ditched MacOS X server.

Right, more or less what VAXman just wrote, not?

Maybe.
He is still alive, He has been pretty active on Twitter
last 24 hours.
Arne

He posts in the Apple X11-users mail list occasionally. Most recently on 7-JUL-2020

[V***@SendSpamHere.ORG]

Post by Jan-Erik Söderholm

Post by Arne Vajhøj

Post by Phillip Helbig (undress to reply)

Post by V***@SendSpamHere.ORG

Post by Dave Froble

Post by Simon Clubley
Filename completion is needed as much on VMS as it is on Unix.

Every time this topic comes up I remember JF's idea of completion for
passwords.
:-)

ROTFLMFAO!
I sure do miss JF being here.

Whatever happened to him?

No idea.  Maybe he was run over somewhere while biking.

If I remember correctly then he switched from VMS to
MacOS X server and then Apple ditched MacOS X server.
Arne

Right, more or less what VAXman just wrote, not?

Lighten up McGraw!

It was a flippant comment. If you knew JF, you'd know that he was an
avid bicycler. I remember he was once bicycling south through the US
and he passed by where I reside.

[Jan-Erik Söderholm]

Post by V***@SendSpamHere.ORG

Post by Jan-Erik Söderholm

Post by Arne Vajhøj

Post by Phillip Helbig (undress to reply)

Post by V***@SendSpamHere.ORG

Post by Dave Froble

Post by Simon Clubley
Filename completion is needed as much on VMS as it is on Unix.

Every time this topic comes up I remember JF's idea of completion for
passwords.
:-)

ROTFLMFAO!
I sure do miss JF being here.

Whatever happened to him?

No idea.  Maybe he was run over somewhere while biking.

If I remember correctly then he switched from VMS to
MacOS X server and then Apple ditched MacOS X server.
Arne

Right, more or less what VAXman just wrote, not?

Lighten up McGraw!
It was a flippant comment. If you knew JF, you'd know that he was an
avid bicycler. I remember he was once bicycling south through the US
and he passed by where I reside.

Of course. I know very well JF's biking habits... :-)

The joke I tried was that "run over while biking" was like
"switching from VMS to MacOS X and then Apple ditching MacOS X"...

I did missed to attach the :-), though... :-)

[Bill Gunshannon]

Post by V***@SendSpamHere.ORG

Post by Phillip Helbig (undress to reply)

Post by V***@SendSpamHere.ORG

Post by Dave Froble

Post by Simon Clubley
Filename completion is needed as much on VMS as it is on Unix.

Every time this topic comes up I remember JF's idea of completion for
passwords.
:-)

ROTFLMFAO!
I sure do miss JF being here.

Whatever happened to him?

No idea. Maybe he was run over somewhere while biking.

I think like many other of us, he retired. In his case he had
stuff other than computers to fill his free time.

bill

[Henry Crun]

Post by Phillip Helbig (undress to reply)

Post by Simon Clubley

Post by Dave Froble
About 2 months after I started on VMS, RSTS was forgotten ....

This times a million. The only thing I missed from RSTS/E was the
ability to detach an interactive job and there were ways around
that problem.

That and command completion are the only two things on unix which I
don't have on VMS, though there are various workarounds. Having said
that, these two things aren't as important on VMS as on unix.

Things I miss on VMS that I remember from RSTS/E

1. The SYSTAT cusp, which showed details of running jobs
(Took a while, but I have a VMS equivalent. Linux has top and htop)
2. The UTILTY program which had an option to force input to another process
(Useful for saving stuck users, or changing batch jobs mid-stream)
3.An undocumented, unsupported SYS call (IIRC SYS(chr(10...) ) which allowed
a suitably privileged System Manager to see anaother process' or user's input buffers.
(Not used often, but an occasional lifesaver!)

OTOH what I don't miss:
ACCT.SYS -- all the passwords readable, and using the KED editor (pre-EDT) left it readable on disk.
Having to jump through hoops to use the equivalent of a batch queue
TKB runs taking hours (The first time I ran LINK on VMS it completed so fast I was sure something was wrong!)

[Bill Gunshannon]

Post by Henry Crun

Post by Phillip Helbig (undress to reply)

Post by Simon Clubley

Post by Dave Froble
About 2 months after I started on VMS, RSTS was forgotten ....

This times a million. The only thing I missed from RSTS/E was the
ability to detach an interactive job and there were ways around
that problem.

That and command completion are the only two things on unix which I
don't have on VMS, though there are various workarounds.  Having said
that, these two things aren't as important on VMS as on unix.

Things I miss on VMS that I remember from RSTS/E
1. The SYSTAT cusp, which showed details of running jobs
(Took a while, but I have a VMS equivalent. Linux has top and htop)
2. The UTILTY program which had an option to force input to another process
(Useful for saving stuck users, or changing batch jobs mid-stream)
3.An undocumented, unsupported SYS call (IIRC SYS(chr(10...) ) which allowed
a suitably privileged System Manager to see anaother process' or user's input buffers.
(Not used often, but an occasional lifesaver!)
ACCT.SYS -- all the passwords readable, and using the KED editor
(pre-EDT) left it readable on disk.

A lot of systems (maybe most or all?) if they even had passwords
stored them unencrypted in those days.

Post by Henry Crun
Having to jump through hoops to use the equivalent of a batch queue

Guess I don't know what "hoops" there were. Running batch jobs on RSTS
was pretty much the same as on other OSes. Some even required operator
intervention to run a batch job at all.

Post by Henry Crun
TKB runs taking hours (The first time I ran LINK on VMS it completed so
fast I was sure something was wrong!)

That probably had more to do with the power of the system than the
commands used. How long do you think TKB would take if RSTS still
ran today and the CPU's were all clocked in Ghz.

It seems anytime people compare "the good ole days" they compare
1970's systems to 2020 systems without allowing for differences like
changes in hardware technology. If RSTS had been handled like VMS
it would be running on X86-64, using GB's of memory and modified to
take advantage of the new hardware without abandoning the underlying
philosophy of the OS.

bill

[Dave Froble]

Post by Bill Gunshannon

Post by Henry Crun

Post by Phillip Helbig (undress to reply)

Post by Simon Clubley

Post by Dave Froble
About 2 months after I started on VMS, RSTS was forgotten ....

This times a million. The only thing I missed from RSTS/E was the
ability to detach an interactive job and there were ways around
that problem.

That and command completion are the only two things on unix which I
don't have on VMS, though there are various workarounds. Having said
that, these two things aren't as important on VMS as on unix.

Things I miss on VMS that I remember from RSTS/E
1. The SYSTAT cusp, which showed details of running jobs
(Took a while, but I have a VMS equivalent. Linux has top and htop)
2. The UTILTY program which had an option to force input to another process
(Useful for saving stuck users, or changing batch jobs mid-stream)
3.An undocumented, unsupported SYS call (IIRC SYS(chr(10...) ) which allowed
a suitably privileged System Manager to see anaother process' or user's input buffers.
(Not used often, but an occasional lifesaver!)
ACCT.SYS -- all the passwords readable, and using the KED editor
(pre-EDT) left it readable on disk.

A lot of systems (maybe most or all?) if they even had passwords
stored them unencrypted in those days.

Post by Henry Crun
Having to jump through hoops to use the equivalent of a batch queue

Guess I don't know what "hoops" there were. Running batch jobs on RSTS
was pretty much the same as on other OSes. Some even required operator
intervention to run a batch job at all.

I've totally forgotten the RSTS batch capabilities.

I do seem to recall writing a line based text editor and printing stuff.

Post by Bill Gunshannon

Post by Henry Crun
TKB runs taking hours (The first time I ran LINK on VMS it completed
so fast I was sure something was wrong!)

That probably had more to do with the power of the system than the
commands used. How long do you think TKB would take if RSTS still
ran today and the CPU's were all clocked in Ghz.

I like modular programming. Perhaps it is because TKB so warped my
mind. To this day I really don't like huge programs. Always liked KISS.

Post by Bill Gunshannon
It seems anytime people compare "the good ole days" they compare
1970's systems to 2020 systems without allowing for differences like
changes in hardware technology. If RSTS had been handled like VMS
it would be running on X86-64, using GB's of memory and modified to
take advantage of the new hardware without abandoning the underlying
philosophy of the OS.

Only if it had expanded the addressing ....

[Bill Gunshannon]

Post by Dave Froble

Post by Bill Gunshannon

Post by Henry Crun

Post by Phillip Helbig (undress to reply)

Post by Simon Clubley

Post by Dave Froble
About 2 months after I started on VMS, RSTS was forgotten ....

This times a million. The only thing I missed from RSTS/E was the
ability to detach an interactive job and there were ways around
that problem.

That and command completion are the only two things on unix which I
don't have on VMS, though there are various workarounds.  Having said
that, these two things aren't as important on VMS as on unix.

Things I miss on VMS that I remember from RSTS/E
1. The SYSTAT cusp, which showed details of running jobs
(Took a while, but I have a VMS equivalent. Linux has top and htop)
2. The UTILTY program which had an option to force input to another process
(Useful for saving stuck users, or changing batch jobs mid-stream)
3.An undocumented, unsupported SYS call (IIRC SYS(chr(10...) ) which allowed
a suitably privileged System Manager to see anaother process' or user's input buffers.
(Not used often, but an occasional lifesaver!)
ACCT.SYS -- all the passwords readable, and using the KED editor
(pre-EDT) left it readable on disk.

A lot of systems (maybe most or all?) if they even had passwords
stored them unencrypted in those days.

Post by Henry Crun
Having to jump through hoops to use the equivalent of a batch queue

Guess I don't know what "hoops" there were.  Running batch jobs on RSTS
was pretty much the same as on other OSes.  Some even required operator
intervention to run a batch job at all.

I've totally forgotten the RSTS batch capabilities.
I do seem to recall writing a line based text editor and printing stuff.

It was. Like JCL on the IBM mainframes and ECL on the Unisys
Mainframes and Primos and pretty much everything else. Unix
didn't have batch queues like the others but shell scripts and
the "at" command pretty much did the same.

Post by Dave Froble

Post by Bill Gunshannon

Post by Henry Crun
TKB runs taking hours (The first time I ran LINK on VMS it completed
so fast I was sure something was wrong!)

That probably had more to do with the power of the system than the
commands used.  How long do you think TKB would take if RSTS still
ran today and the CPU's were all clocked in Ghz.

I like modular programming.  Perhaps it is because TKB so warped my
mind.  To this day I really don't like huge programs.  Always liked KISS.

Two different things entirely. Good modular programming makes
building overlayed Programs easier but it isn't always necessary.
But good modular programming is just a good practice.

Post by Dave Froble

Post by Bill Gunshannon
It seems anytime people compare "the good ole days" they compare
1970's systems to 2020 systems without allowing for differences like
changes in hardware technology.  If RSTS had been handled like VMS
it would be running on X86-64, using GB's of memory and modified to
take advantage of the new hardware without abandoning the underlying
philosophy of the OS.

Only if it had expanded the addressing ....

Every OS I have ever worked with that moved forward to a hardware
platform with larger address space took advantage of it. Didn't
VMS when it went from VAX to Alpha and Itanium? BSD certainly did.
And Linux. And OS-9.

bill

[Simon Clubley]

Post by Bill Gunshannon

Post by Dave Froble

Post by Bill Gunshannon
It seems anytime people compare "the good ole days" they compare
1970's systems to 2020 systems without allowing for differences like
changes in hardware technology.  If RSTS had been handled like VMS
it would be running on X86-64, using GB's of memory and modified to
take advantage of the new hardware without abandoning the underlying
philosophy of the OS.

Only if it had expanded the addressing ....

Every OS I have ever worked with that moved forward to a hardware
platform with larger address space took advantage of it. Didn't
VMS when it went from VAX to Alpha and Itanium? BSD certainly did.
And Linux. And OS-9.
bill

I don't know about OS-9, but it was a lot easier to expand the usable
address space on the BSDs and Linux than it was on VMS. We've discussed
the reasons for this in detail in the past, so I am not going to resurrect
_that_ discussion again. :-)

Simon.

[Dave Froble]

Post by Bill Gunshannon

Post by Dave Froble

Post by Bill Gunshannon

Post by Henry Crun

Post by Phillip Helbig (undress to reply)

Post by Simon Clubley

Post by Dave Froble
About 2 months after I started on VMS, RSTS was forgotten ....

This times a million. The only thing I missed from RSTS/E was the
ability to detach an interactive job and there were ways around
that problem.

That and command completion are the only two things on unix which I
don't have on VMS, though there are various workarounds. Having said
that, these two things aren't as important on VMS as on unix.

Things I miss on VMS that I remember from RSTS/E
1. The SYSTAT cusp, which showed details of running jobs
(Took a while, but I have a VMS equivalent. Linux has top and htop)
2. The UTILTY program which had an option to force input to another process
(Useful for saving stuck users, or changing batch jobs mid-stream)
3.An undocumented, unsupported SYS call (IIRC SYS(chr(10...) ) which allowed
a suitably privileged System Manager to see anaother process' or
user's input buffers.
(Not used often, but an occasional lifesaver!)
ACCT.SYS -- all the passwords readable, and using the KED editor
(pre-EDT) left it readable on disk.

A lot of systems (maybe most or all?) if they even had passwords
stored them unencrypted in those days.

Post by Henry Crun
Having to jump through hoops to use the equivalent of a batch queue

Guess I don't know what "hoops" there were. Running batch jobs on RSTS
was pretty much the same as on other OSes. Some even required operator
intervention to run a batch job at all.

I've totally forgotten the RSTS batch capabilities.
I do seem to recall writing a line based text editor and printing stuff.

It was. Like JCL on the IBM mainframes and ECL on the Unisys
Mainframes and Primos and pretty much everything else. Unix
didn't have batch queues like the others but shell scripts and
the "at" command pretty much did the same.

Post by Dave Froble

Post by Bill Gunshannon

Post by Henry Crun
TKB runs taking hours (The first time I ran LINK on VMS it completed
so fast I was sure something was wrong!)

That probably had more to do with the power of the system than the
commands used. How long do you think TKB would take if RSTS still
ran today and the CPU's were all clocked in Ghz.

I like modular programming. Perhaps it is because TKB so warped my
mind. To this day I really don't like huge programs. Always liked KISS.

Two different things entirely. Good modular programming makes
building overlayed Programs easier but it isn't always necessary.
But good modular programming is just a good practice.

Post by Dave Froble

Post by Bill Gunshannon
It seems anytime people compare "the good ole days" they compare
1970's systems to 2020 systems without allowing for differences like
changes in hardware technology. If RSTS had been handled like VMS
it would be running on X86-64, using GB's of memory and modified to
take advantage of the new hardware without abandoning the underlying
philosophy of the OS.

Only if it had expanded the addressing ....

Every OS I have ever worked with that moved forward to a hardware
platform with larger address space took advantage of it. Didn't
VMS when it went from VAX to Alpha and Itanium? BSD certainly did.
And Linux. And OS-9.

Well, Ok, but then you'd have basically VMS with a few exceptions.

Way back in the day I was one of a half dozen to a dozen people from DEC
customers, ISVs, production shops, timesharing shops, and such, that had
a number of meetings with the DEC VMS developers telling them what we
RSTS users needed in VMS for us to be able to use it. Batch
capabilities, print capabilities, stuff like that. Print re-starts in
the middle of a large file. Batch checkpoints and re-start.

Didn't always get what we wanted. One time the issue was user
interface. One of the DEC guys, instead of giving us what we asked for
instead suggested DCL on RSTS. And that's what happened.

VMS got a lot of work done to implement things RSTS users wanted/needed.

I'm pretty sure I remember Clair being in those meetings. That sort of
"dates" both of us. Long time ago.

[Dave Froble]

Post by Henry Crun
Things I miss on VMS that I remember from RSTS/E
1. The SYSTAT cusp, which showed details of running jobs

That brings back a partial memory. I remember the utility, but, I
cannot remember what the output looked like. I wrote a utility on VMS
that did similar things. Mostly for practice. Could be a lot better.

Also wrote some code that pretty much duplicated the RSTS messaging stuff.

Both in Macro-32. Don't hit me John ...

[John H. Reinhardt]

Post by Henry Crun
Things I miss on VMS that I remember from RSTS/E
1. The SYSTAT cusp, which showed details of running jobs

That brings back a partial memory.  I remember the utility, but, I cannot remember what the output looked like.  I wrote a utility on VMS that did similar things.  Mostly for practice.  Could be a lot better.
Also wrote some code that pretty much duplicated the RSTS messaging stuff.
Both in Macro-32.  Don't hit me John ...

When I was a student at Rose-Hulman, we had a utility called AOF - An Operator's Friend. It was a VT friendly utility that kept a SYSTAT screen running and allowed you to do certain things with the jobs showing up by moving the cursor to the intended job and pressing various keys that started the operation. I wonder if it was based on this cusp. This was around 1978-1981 running on RSTS/E V7 and possibly V6C. I may have gotten a copy of it when I left, but all my tapes were erased by accident by an operator at job I had later on.

[Henry Crun]

Post by Henry Crun
Things I miss on VMS that I remember from RSTS/E
1. The SYSTAT cusp, which showed details of running jobs

a utility on VMS that did similar things.  Mostly for practice.  Could be a lot better.
Also wrote some code that pretty much duplicated the RSTS messaging stuff.
Both in Macro-32.  Don't hit me John ...

I left an Alpha equivalent installation kit for SYSTAT on Eisner
Its world readable, so anyone with sufficient nostalgia is welcome:
DSA3:[DECUSERVE_USER.RECHTMAN]SYSTAT.*
Guaranteed to have bugs, lots of imperfections.

[Simon Clubley]

Post by Henry Crun
Things I miss on VMS that I remember from RSTS/E
1. The SYSTAT cusp, which showed details of running jobs
(Took a while, but I have a VMS equivalent. Linux has top and htop)
2. The UTILTY program which had an option to force input to another process
(Useful for saving stuck users, or changing batch jobs mid-stream)

Good luck getting that past an auditor these days. :-)

Post by Henry Crun
3.An undocumented, unsupported SYS call (IIRC SYS(chr(10...) ) which allowed
a suitably privileged System Manager to see anaother process' or user's input buffers.
(Not used often, but an occasional lifesaver!)

Likewise. :-)

Post by Henry Crun
ACCT.SYS -- all the passwords readable, and using the KED editor (pre-EDT) left it readable on disk.
Having to jump through hoops to use the equivalent of a batch queue

Is this RSTS/E V8 and earlier or RSTS/E V9 and above ?

I'm not familiar with the OPSER stuff that was in V8 and earlier as it
was before my time, but I remember PBS in V9 and above as being very
VMS-like in how you interacted with it.

Simon.

[Henry Crun]

Post by Simon Clubley

Post by Henry Crun
Things I miss on VMS that I remember from RSTS/E
1. The SYSTAT cusp, which showed details of running jobs
(Took a while, but I have a VMS equivalent. Linux has top and htop)
2. The UTILTY program which had an option to force input to another process
(Useful for saving stuck users, or changing batch jobs mid-stream)

Good luck getting that past an auditor these days. :-)

Post by Henry Crun
3.An undocumented, unsupported SYS call (IIRC SYS(chr(10...) ) which allowed
a suitably privileged System Manager to see anaother process' or user's input buffers.
(Not used often, but an occasional lifesaver!)

Likewise. :-)

Post by Henry Crun
ACCT.SYS -- all the passwords readable, and using the KED editor (pre-EDT) left it readable on disk.
Having to jump through hoops to use the equivalent of a batch queue

Is this RSTS/E V8 and earlier or RSTS/E V9 and above ?
I'm not familiar with the OPSER stuff that was in V8 and earlier as it
was before my time, but I remember PBS in V9 and above as being very
VMS-like in how you interacted with it.
Simon.

I was introduced to RSTS watching a SYSGEN (which ran under RT11, IIRC)
circa V5. Lots of PIP, no queues, no DCL, line editor on a LA120 at 1200 baud if you were lucky,
300 on a LA34 if you were unlucky. Later there was DECnet on synchronous RS232 lines.
When I started my main job was maintaining (mostly soldering) RS232 terminal connections...
Took a while till I was allowed to touch software

[Phillip Helbig (undress to reply)]

Post by Simon Clubley

Post by Phillip Helbig (undress to reply)
That and command completion are the only two things on unix which I
don't have on VMS, though there are various workarounds. Having said
that, these two things aren't as important on VMS as on unix.

Filename completion is needed as much on VMS as it is on Unix.

On VMS, I can abbreviate commands and qualifiers if they are unique, so
in that sense there is less need for it. But it would be nice since I
can get a list if it is not unique, and also expansion for file names.
Of course, in things like CD.COM I allow for (all sorts of)
abbreviations, but it would be nice to have it generally.

Post by Simon Clubley
Work with it for a while and you will _really_ miss it when using DCL.

Right.

Also the ability to send an interative process to the background is
nice. A workaround on VMS is to start with a subprocess then attach to
the main process and so on, but that is not as nice.

[Marc Van Dyck]

Post by Phillip Helbig (undress to reply)
Also the ability to send an interative process to the background is
nice. A workaround on VMS is to start with a subprocess then attach to
the main process and so on, but that is not as nice.

When I was working for DEC, I always had 3 sub-processes running
lsedit,
mail, and notes. Even had keypad keys defined to spawn them and attach
to them. Now of course notes is gone, and mail rarely used, but for
the editor I still do it...

[Robert A. Brooks]

Post by Marc Van Dyck
When I was working for DEC, I always had 3 sub-processes running
lsedit, mail, and notes. Even had keypad keys defined to spawn them
and attach to them. Now of course notes is gone, and mail rarely
used, but for the editor I still do it...

Notes is being ported to X86 as we speak . . .

[Simon Clubley]

Post by Robert A. Brooks

Post by Marc Van Dyck
When I was working for DEC, I always had 3 sub-processes running
lsedit, mail, and notes. Even had keypad keys defined to spawn them
and attach to them. Now of course notes is gone, and mail rarely
used, but for the editor I still do it...

Notes is being ported to X86 as we speak . . .

How's the port of TECO coming along ? :-)

Simon.

[Arne Vajhøj]

Post by Phillip Helbig (undress to reply)
Also the ability to send an interative process to the background is
nice.  A workaround on VMS is to start with a subprocess then attach
to the main process and so on, but that is not as nice.

When I was working for DEC, I always had 3 sub-processes running lsedit,
mail, and notes. Even had keypad keys defined to spawn them and attach
to them. Now of course notes is gone, and mail rarely used, but for
the editor I still do it...

Once upon a time I had EVE running in a subprocess and
EVE command defined to attach and EXE EXIT doing
an attach back.

It worked.

I stopped using it when moving from VAX to Alpha. If there
is no wait time starting up the editor then no need for
anything fancy.

Arne

[seasoned_geek]

Post by Bill Gunshannon

Post by Phillip Helbig (undress to reply)

Post by Simon Clubley

Post by Arne Vajhøj
I don't think VSI will feel insulted if I say they are not one of the
worlds largest IT companies.

They might. :-)
VSI claim that out of all the operating systems produced in the world,
theirs is the most secure.
They might not appreciate you bringing them back down to Earth. :-)

So which one is the most secure?

My money is on RSTS or Primos.
bill

RSTS/E is sexy!

[Scott Dorsey]

Post by Phillip Helbig (undress to reply)

Post by Simon Clubley

Post by Arne Vajhøj
I don't think VSI will feel insulted if I say they are not one of the
worlds largest IT companies.

They might. :-)
VSI claim that out of all the operating systems produced in the world,
theirs is the most secure.
They might not appreciate you bringing them back down to Earth. :-)

So which one is the most secure?

The one that is not running.
--scott

[Dave Froble]

Post by Scott Dorsey

Post by Phillip Helbig (undress to reply)

Post by Simon Clubley

Post by Arne Vajhøj
I don't think VSI will feel insulted if I say they are not one of the
worlds largest IT companies.

They might. :-)
VSI claim that out of all the operating systems produced in the world,
theirs is the most secure.
They might not appreciate you bringing them back down to Earth. :-)

So which one is the most secure?

The one that is not running.
--scott

And locked up behind secure walls, doors, locks, and such.

[Simon Clubley]

Post by Phillip Helbig (undress to reply)

Post by Simon Clubley

Post by Arne Vajhøj
I don't think VSI will feel insulted if I say they are not one of the
worlds largest IT companies.

They might. :-)
VSI claim that out of all the operating systems produced in the world,
theirs is the most secure.
They might not appreciate you bringing them back down to Earth. :-)

So which one is the most secure?

First off, it most certainly is not VMS.

However, the above is a good question. We can't talk about the "most secure"
because it's impossible to know that, but we can talk about "more secure
than VMS".

I would consider z/OS to be way more secure that VMS.

Linux suffers from having a monolithic and fully privileged kernel address
space in the same way as VMS but it also has features that VMS doesn't
which make it more secure. At one level, it has KASLR, and at the other
end of the scale it has full mandatory access control capabilities in the
form of SELinux. It also has other security and isolation features that
VMS does not.

Microkernel based operating systems are by design more secure because much
of the kernel/privileged attack surface is pushed into normal user-level
processes. This goes even further with formally verified microkernel designs
such as SeL4.

I would also argue that a system which is heavily probed by security
researchers is more secure than one which is not, because the researchers
find, and hence force to be fixed, issues that would otherwise remain
undiscovered.

Simon.

[[e-mail]]

Post by Simon Clubley

Post by Phillip Helbig (undress to reply)

Post by Simon Clubley

Post by Arne Vajhøj
I don't think VSI will feel insulted if I say they are not one of the
worlds largest IT companies.

They might. :-)
VSI claim that out of all the operating systems produced in the world,
theirs is the most secure.
They might not appreciate you bringing them back down to Earth. :-)

So which one is the most secure?

First off, it most certainly is not VMS.
However, the above is a good question. We can't talk about the "most secure"
because it's impossible to know that, but we can talk about "more secure
than VMS".
I would consider z/OS to be way more secure that VMS.
Linux suffers from having a monolithic and fully privileged kernel address
space in the same way as VMS but it also has features that VMS doesn't
which make it more secure. At one level, it has KASLR, and at the other
end of the scale it has full mandatory access control capabilities in the
form of SELinux. It also has other security and isolation features that
VMS does not.
Microkernel based operating systems are by design more secure because much
of the kernel/privileged attack surface is pushed into normal user-level
processes. This goes even further with formally verified microkernel designs
such as SeL4.
I would also argue that a system which is heavily probed by security
researchers is more secure than one which is not, because the researchers
find, and hence force to be fixed, issues that would otherwise remain
undiscovered.
Simon.
--
Walking destinations on a map are further away than they appear.

Simon,

The real efficacy of ASLR depends upon the entropy of the randomization. Brute force script attacks are prevented effectively, but if the entropy is not high, one can simply keep trying by brute force.

With regards to Linux, some of the approaches used by Linux are due to other factors, such as the prevalence of superuser processes.

How effective a security regime is depends upon the totality of the security measures, not an individual measure. Some measures are more necessary than others due to one choice or another.

- Bob Gezelter, http://www.rlgsc.com

[Stephen Hoffman]

Post by ***@rlgsc.com

...Linux suffers from having a monolithic and fully privileged kernel
address space in the same way as VMS but it also has features that VMS
doesn't which make it more secure. At one level, it has KASLR, and at
the other end of the scale it has full mandatory access control
capabilities in the form of SELinux. It also has other security and
isolation features that VMS does not...

The real efficacy of ASLR depends upon the entropy of the
randomization. Brute force script attacks are prevented effectively,
but if the entropy is not high, one can simply keep trying by brute
force.

Ayup. If the apps are stuck in 32-bit (P0/P1) space, there's less
entropy available as the apps and dependencies increase in size.

With code in 64-bit (P2) space (compile 64-bit, and then LINK
/SEGMENT_ATTRIBUTE=mumblefratz), the available address space
randomization is larger.

Reordering the dependent image activation can be an option for
increasing the available entropy even within 32-bit (P0/P1) space,
among other discussions.

An alternative to ASLR and KASLR is pointer authentication, and that
mechanism is starting to see production deployments:
https://www.qualcomm.com/media/documents/files/whitepaper-pointer-authentication-on-armv8-3.pdf

https://support.apple.com/guide/security/pointer-authentication-codes-seca5759bf02/1/web/1

https://pointer-authentication.github.io

There's also the somewhat simpler approach of pointer tagging, too:
https://www.microsoft.com/en-us/research/uploads/prod/2019/07/Pointer-Tagging-for-Memory-Safety.pdf


The goal here of ASLR/KASLR or pointer authentication or pointer
tagging being to get the attacker to expose their efforts with app or
system crashes, as part of efforts to reduce the risks around assuming
developers writing perfect code.

But before I'd expect to see pointer authentication or pointer tagging
or ASLR/KASLR, there is likely other security-related work pending at
VSI. This work might well include work on sandboxes, app signing,
telemetry, logging (including system and app crashes, and attempted
security exploits leading to run-time errors), integration of SSL and
certificates, modern password hashes, wider use of encryption, fuzzing,
dragging more apps and tooling and APIs forward into 64-bit addressing,
etc. This as most attackers will bypass the most robust defenses, if
there exist easier alternative exploits. And there's the work on the
x86-64 port, which has priority over most.

[John Dallman]

In article <rnpp29$bld$***@dont-email.me>, ***@hoffmanlabs.invalid
(Stephen Hoffman) wrote:

Some comments from doing this sort of stuff on VMS' mutant stepchild,

Post by Stephen Hoffman
With code in 64-bit (P2) space (compile 64-bit, and then LINK
/SEGMENT_ATTRIBUTE=mumblefratz), the available address space
randomization is larger.

The greater entropy is really valuable. This is one of the things that
will get easier if putting code in 64-bit space gets simpler.

Post by Stephen Hoffman
An alternative to ASLR and KASLR is pointer authentication, and
https://www.qualcomm.com/media/documents/files/whitepaper-pointer-au
thentication-on-armv8-3.pdf

ARMv8.3 has hardware support for this, but x86-64 does not AFAIK.

Post by Stephen Hoffman
This work might well include work on ... app signing

One needs to distinguish between app signing and individual image signing.
Apple uses whole-app signing, but their model is very much built around
apps as the only form of distributed software. That makes good sense for
consumer software markets, but that's not what VMS is for. Microsoft lets
you sign individual EXEs and DLLs, which is more flexible.

John

[Stephen Hoffman]

Post by John Dallman
Some comments from doing this sort of stuff on VMS' mutant stepchild,

MICA was a nice design in various ways, and fixed various of the flaws
and limitations present within the OpenVMS design.

Post by John Dallman

Post by Stephen Hoffman
With code in 64-bit (P2) space (compile 64-bit, and then LINK
/SEGMENT_ATTRIBUTE=mumblefratz), the available address space
randomization is larger.

The greater entropy is really valuable. This is one of the things that
will get easier if putting code in 64-bit space gets simpler.

I've come to appreciate the decade-long migration and associated API
deprecation that Apple did with macOS.

A migration to 32-bit-APIs-and-tools-deprecated addressing is
inherently a long-term effort.

VSI is in a different situation in many ways.

Post by John Dallman

Post by Stephen Hoffman
An alternative to ASLR and KASLR is pointer authentication, and that
mechanism is starting to see production deployments...

ARMv8.3 has hardware support for this, but x86-64 does not AFAIK.

Ayup. That's part of what that Microsoft link (re-posted below) was
discussing, too. Intel Control Flow Enforcement CET and Microsoft
Control Flow Guard CFG...

https://www.microsoft.com/en-us/research/uploads/prod/2019/07/Pointer-Tagging-for-Memory-Safety.pdf

Post by John Dallman

Post by Stephen Hoffman
This work might well include work on ... app signing

One needs to distinguish between app signing and individual image
signing. Apple uses whole-app signing, but their model is very much
built around apps as the only form of distributed software. That makes
good sense for consumer software markets, but that's not what VMS is
for. Microsoft lets you sign individual EXEs and DLLs, which is more
flexible.

Going to bundle-based app distributions provides other advantages, even
for servers. Installing apps with system-wide access is just a Bad
Idea, and in so many different ways.

Locally-developed and locally-deployed apps that aren't ever going to
be bundled, yes, a different approach for determining app and
environment integrity (and indirectly, user integrity) is necessary.

Sites with locally-developed deployments have either checksummed their
own installations, or have decided or have defaulted to not
implementing that verification. I'd wager most folks are in the latter
group. The latter gets ugly too, as you're trying to run more than one
server, or have multiple folks administering some or all of the servers.

Work that was intended to checksum the OpenVMS components (think
DECdetect-like) was targeting MD5 checksums, which shows how far back
that work was. A migration to SHA-3 checksums would be typical, now.

[Dave Froble]

Post by Craig A. Berry

Post by Simon Clubley

Post by ***@rlgsc.com
Working with preliminary cross compilers? Early field test software?

The compilers are only one part of this.
Ian is very, very correct. We should be getting some initial indications
by now, especially for I/O bound workloads, where the compilers are far
less important.
For example, tests from RMS could compare Alpha/Itanium performance
with x86-64 (and associated I/O hardware) performance.

Which would be meaningless because RMS is software that is getting
compiled with non-optimized cross compilers, and other parts of the I/O
path are also compiled software. Disk I/O and network I/O have
traditionally been much slower on VMS than on other OSs running on the
same hardware, especially with default settings, so the difference
pretty much has to be in software, which is currently getting compiled
with rough-and-ready cross compilers. Your impatience has no impact on
how the technology actually works.

Post by Simon Clubley
We are _6_ _years_ into the port! How much longer are people going to
have to wait ?

Until it is ready? What else is there to do?

Post by Craig A. Berry
At least until v9.1, but don't get your hopes up even then. v9.1 is
scheduled for the first half of next year. While the compilers will be
native, I don't know if optimizations will be available in compilers
provided with the initial EAK (and the compiler engineers may not know
yet either). There may very well be an agreement that comes with
downloading the EAK that forbids public posting of benchmarks.

I would not bother. Why? It really does not matter.

Post by Craig A. Berry
It is certainly frustrating that the port is taking a long time. But the
original projection of a two-year port beginning in 2015 was predicated
on having a team of 70 doing the port, on not doing Alpha releases, and
probably not doing a bunch of other things they have ended up having to
do but weren't initially planning on doing before the port. I don't
know how many people are working on the port, but I'm guessing it isn't 70.

Well, yes, an Alpha release, as you mention. And why, because it was
what the paying customers wanted. Apparently they are a bit happier
than the loose lips on c.o.v.

Then there was taking over all VMS support. A big job, and quite
possibly a good source of revenue.

Post by Craig A. Berry
The sharply narrowed focus of the latest roadmap suggests that they are
doubling down on the port and making it a top priority. There will
certainly be some opportunities lost by the fact that the first
production release on x86_64 is still a year away (if all goes according
to the current plan). But I have a hard time believing that anyone is
more eager to have it done than the people doing it. So complaining in
the newsgroup about how long it's taking is probably not going to make
it happen faster (though I admit I have certainly done some complaining
myself).

I really haven't seen much complaining by paying customers. Then again,
perhaps it isn't so easy to see, if it happens.

If VSI is going to succeed, it will be because of sufficient revenue,
not by catering to those non-paying customers complaining on c.o.v.

The people at VSI are the same people who have successfully provided
what I have needed for the last 42 years. Why would I now doubt them?

[Michael Moroney]

Post by IanD
It's been a while since this topic was first aired and the response at the time was "it
is too early to tell"
This was quite some time ago now
I don't expect benchmarks as such but I would have thought we have a general idea as to
how it performs compared to Itanium or Alpha by now?
Ballpark figures?
10%, 20%, 50%, Rabbit on crack? Still too early to tell?
*Yes, I'm talking about a VM environment since that will probably be the normal
deployment environment

Still too early to tell. The compilers have optimization off and frankly, the
generated code is hideous.

Despite that, boots are wicked fast.

[IanD]

On Saturday, October 31, 2020 at 12:19:06 AM UTC+11, Michael Moroney wrote:

<snip>

Post by Michael Moroney
Still too early to tell. The compilers have optimization off and frankly, the
generated code is hideous.
Despite that, boots are wicked fast.

Fair enough in one aspect but I wasn't interested in how optimised or not things are but more interested in a ballpark approximate indication of how things look so far

The fact that it boots wickedly fast is also an indication is it not?

VSI have stated they are constantly running automated tests, more than ever before apparently, these will have metrics associated, I highly doubt detailed performance data is not part of this capture and I suspect that they would also have actual workloads being pushed onto those test systems to thrash out issues that crop up over larger and longer running workloads

Data is being collected, ideas formed and inferences made, they are not running blind here, not at this later stage of the port

It's in EAK form already, shipping it to people to kick the tyres and what I indirectly hearing is that they could be doing so with zero idea of how it will perform? I find that rather hard to believe

VSI engineering is great but their marketing leaves a lot to be desired and I think a fair chunk of the success or failure of VMS in the future will be tied to marketing. History is littered with examples of the superior product failing against the more marketed. VMS has captive customers but only for so long

If there is any perform gains known about, no matter how rough, I think VSI would be smart to use this especially in places like this, as a form of indirect marketing/advertising teaser to VMS customers that the 6+ year wait is worth it

The converse to this would of course be if performance is bad or pathetic...

[John Reagan]

Post by IanD
<snip>

Still too early to tell. The compilers have optimization off and frankly, the
generated code is hideous.
Despite that, boots are wicked fast.

Fair enough in one aspect but I wasn't interested in how optimised or not things are but more interested in a ballpark approximate indication of how things look so far
The fact that it boots wickedly fast is also an indication is it not?
VSI have stated they are constantly running automated tests, more than ever before apparently, these will have metrics associated, I highly doubt detailed performance data is not part of this capture and I suspect that they would also have actual workloads being pushed onto those test systems to thrash out issues that crop up over larger and longer running workloads
Data is being collected, ideas formed and inferences made, they are not running blind here, not at this later stage of the port
It's in EAK form already, shipping it to people to kick the tyres and what I indirectly hearing is that they could be doing so with zero idea of how it will perform? I find that rather hard to believe
VSI engineering is great but their marketing leaves a lot to be desired and I think a fair chunk of the success or failure of VMS in the future will be tied to marketing. History is littered with examples of the superior product failing against the more marketed. VMS has captive customers but only for so long
If there is any perform gains known about, no matter how rough, I think VSI would be smart to use this especially in places like this, as a form of indirect marketing/advertising teaser to VMS customers that the 6+ year wait is worth it
The converse to this would of course be if performance is bad or pathetic...

To recap from the question when asked before:

- Most of us at VSI are doing our work on virtual machines. I run VirtualBox on my W10 machine here at home with a Skylake, 16GB of memory, and an SSD system disk. It is homebuilt system with a GIGABYTE system board, etc. It is busy doing other things (browsers, email, podcasts, etc.) What should I compare that with?

- Virtual I/O to the container files adds yet another level of unknown overhead besides RMS/XQP. How does VBox do I/O? Beats me. But then again, most of my tests (so far) are not I/O intensive.

- If you want to take a SWAG at how much the LLVM optimizer will give you, hop over to your Linux box, find your favorite program, get a recent clang compiler, and do a -O0 benchmark and then an -Ofast benchmark. Get that difference, spin around in circles, touch your nose, and then guess from that. As Michael mentioned, the code (especially from the Macro compiler dealing with Alpha registers, condition codes which aren't exactly the same as x86) can be quite ugly. Everything are stack temporaries. Very little has been hoisted into registers (you don't have that many preserved registers anyway with x86).

- The reason we didn't put the optimizer into the cross-compilers is three fold.
-- I literally couldn't get the LLVM 3.4.2 optimizer to compile with the Itanium C++ compiler. LLVM 3.4.2 claims to be buildable with a C++03 compiler. My gut says that the while the Itanium C++ compiler claims C++03, it has bugs. The LLVM code base LOVES templates and template specialization. That's where all my errors were. [The same reason I couldn't build clang 3.4.2]
-- Since everybody is single stepping through code with XDELTA and DELTA, working from MAP files, machine code output from ANALYZE/OBJECT/DISA, and doing hex arithmetic, optimizing it would have made the debugging experience even worse than it is. Eh?
-- The LLVM optimizer relies on metadata attached to the LLVM IR. It is how a language frontend conveys things like pointer aliasing, parameter aliasing, to the optimizer. The mechanism used by GEM is radically different and actually requires real effort to map the concepts. The LLVM metadata has changed formats between LLVM 3.4.2 and recent LLVMs (currently at 10.0.1). With the above issues, didn't seem to make much sense to write the code to convert the GEM model to the LLVM 3.4.2 model just for us to recycle it for LLVM 10. It might have been good practice, but we had other things to pound on. I only have so many rocks. I keep one for me to pound my head against from time to time.

- The optimizer will show up with the native compilers but probably not even with the first native compilers as we have to work on the metadata converter as I mentioned above. The goal will be to match the level of detail as the clang frontend. Anything less and you limit the LLVM optimizer.

[Craig A. Berry]

Post by IanD

Post by Michael Moroney
Still too early to tell. The compilers have optimization off and frankly, the
generated code is hideous.
Despite that, boots are wicked fast.

Fair enough in one aspect but I wasn't interested in how optimised or
not things are but more interested in a ballpark approximate
indication of how things look so far

Why would you think that how fast non-optimized code runs would give you
a meaningful ballpark figure? And it's not just the code generation that
would not be optimized at this point. They probably have debug
statements all over the place that will eventually be removed or
compiled out. If I remember right from the Itanium port, things like
stack unwinding during an exception and alignment faults all over the
place were quite a mess in the initial builds and took quite a few
iterations to get into decent shape.

The particular rough edges on x86 may be different, but there will be
some, and some of them will have a performance impact. It doesn't make
much sense to spend resources on making things crash faster. After the
the native compilers have gone through a few iterations and
architecture-specific parts of the kernel have gotten to the point where
they aren't hanging or blowing up too often, then of course everyone
will want to know how fast it runs. But at the moment it's not so much
comparing apples and oranges as meat and vegetables.

Post by IanD
The fact that it boots wickedly fast is also an indication is it not?

It's good news, but it may not mean what you think it means. I believe
they have done a lot of work on the boot path, so it's not necessarily
the same code that is running on other architectures.

[Phillip Helbig (undress to reply)]

Post by Michael Moroney
Despite that, boots are wicked fast.

Must be those seven-league boots!

[Michael Moroney]

Post by Craig A. Berry

Post by IanD
The fact that it boots wickedly fast is also an indication is it not?

It's good news, but it may not mean what you think it means. I believe
they have done a lot of work on the boot path, so it's not necessarily
the same code that is running on other architectures.

One big reason for the fast boot is the memory disk used, so that (other) boot drivers
won't be needed. Load a chunk of memory once very early and run the rest of the early
boot stuff from it.

[[e-mail]]

Post by Michael Moroney

Post by Craig A. Berry

Post by IanD
The fact that it boots wickedly fast is also an indication is it not?

It's good news, but it may not mean what you think it means. I believe
they have done a lot of work on the boot path, so it's not necessarily
the same code that is running on other architectures.

One big reason for the fast boot is the memory disk used, so that (other) boot drivers
won't be needed. Load a chunk of memory once very early and run the rest of the early
boot stuff from it.

We understand the importance of performance comparisons but such testing is not even on our radar yet. We have many, many more important things to do in the next few months. As has been stated previously, it would be a complete waste of time anyway until we can turn on optimizing in the compilers.

The plan has always been - keep adding more functions as we progress through our V9.0 EAKs and eventually we will have V9.1, the complete operating environment for an expanded Field Test. Moving from 9.1 to 9.2 will be mostly performance and stability work. We now have 31 external users with access to the CrossTools Kit and the appliances with V9.0-A, B, C, D, E, so we are making good progress.

We had some nice breakthroughs in E. My KVM guest has now been up for 31 days running a series of tests, usually 60 jobs on a single CPU. Another more recent change regarding SMP now allows large batteries of tests to run in 2P and 4P without issues. Coming in F will be full SMP support, clustering and MSCP serving as well as other additions.

[Arne Vajhøj]

Post by ***@vmssoftware.com

Post by Michael Moroney

Post by Craig A. Berry

Post by IanD
The fact that it boots wickedly fast is also an indication is it not?

It's good news, but it may not mean what you think it means. I believe
they have done a lot of work on the boot path, so it's not necessarily
the same code that is running on other architectures.

One big reason for the fast boot is the memory disk used, so that (other) boot drivers
won't be needed. Load a chunk of memory once very early and run the rest of the early
boot stuff from it.

We understand the importance of performance comparisons but such
testing is not even on our radar yet. We have many, many more
important things to do in the next few months. As has been stated
previously, it would be a complete waste of time anyway until we can
turn on optimizing in the compilers.
The plan has always been - keep adding more functions as we progress
through our V9.0 EAKs and eventually we will have V9.1, the complete
operating environment for an expanded Field Test. Moving from 9.1 to
9.2 will be mostly performance and stability work. We now have 31
external users with access to the CrossTools Kit and the appliances
with V9.0-A, B, C, D, E, so we are making good progress.
We had some nice breakthroughs in E. My KVM guest has now been up for
31 days running a series of tests, usually 60 jobs on a single CPU.
Another more recent change regarding SMP now allows large batteries
of tests to run in 2P and 4P without issues. Coming in F will be full
SMP support, clustering and MSCP serving as well as other additions.

"Make It Work, Make It Right, Make It Fast"

:-)

Arne

[[e-mail]]

Post by Arne Vajhøj

Post by ***@vmssoftware.com

Post by Michael Moroney

Post by IanD
The fact that it boots wickedly fast is also an indication is it not?

It's good news, but it may not mean what you think it means. I believe
they have done a lot of work on the boot path, so it's not necessarily
the same code that is running on other architectures.

One big reason for the fast boot is the memory disk used, so that (other) boot drivers
won't be needed. Load a chunk of memory once very early and run the rest of the early
boot stuff from it.

We understand the importance of performance comparisons but such
testing is not even on our radar yet. We have many, many more
important things to do in the next few months. As has been stated
previously, it would be a complete waste of time anyway until we can
turn on optimizing in the compilers.
The plan has always been - keep adding more functions as we progress
through our V9.0 EAKs and eventually we will have V9.1, the complete
operating environment for an expanded Field Test. Moving from 9.1 to
9.2 will be mostly performance and stability work. We now have 31
external users with access to the CrossTools Kit and the appliances
with V9.0-A, B, C, D, E, so we are making good progress.
We had some nice breakthroughs in E. My KVM guest has now been up for
31 days running a series of tests, usually 60 jobs on a single CPU.
Another more recent change regarding SMP now allows large batteries
of tests to run in 2P and 4P without issues. Coming in F will be full
SMP support, clustering and MSCP serving as well as other additions.

"Make It Work, Make It Right, Make It Fast"
:-)
Arne

Arne,

I more or less agree with Clair.

Generally speaking, benchmarking is hard. Computational benchmarks (e.e., non-privileged computations such as those used for MIPS and VUPS ratings) are one of the simplest species in that genus.

Benchmarking systems-level elements (e.g., context switches, system services, page faults) is complex and often difficult. I spent a good amount of time during my PhD research digging into these mechanisms in terms of the I/O system, and to say the problem is "non-trivial" is an understatement. Determining precisely what one is benchmarking is only the first small step. Separating the real performance information from the surrounding noise is a significant challenge.

As Clair mentioned in his posting, the goal of these early versions is a working system. Accuracy first, performance later.

- Bob Gezelter, http://www.rlgsc.com

[abrsvc]

Post by ***@rlgsc.com

Post by Arne Vajhøj

Post by ***@vmssoftware.com

Post by Michael Moroney

Post by IanD
The fact that it boots wickedly fast is also an indication is it not?

It's good news, but it may not mean what you think it means. I believe
they have done a lot of work on the boot path, so it's not necessarily
the same code that is running on other architectures.

One big reason for the fast boot is the memory disk used, so that (other) boot drivers
won't be needed. Load a chunk of memory once very early and run the rest of the early
boot stuff from it.

We understand the importance of performance comparisons but such
testing is not even on our radar yet. We have many, many more
important things to do in the next few months. As has been stated
previously, it would be a complete waste of time anyway until we can
turn on optimizing in the compilers.
The plan has always been - keep adding more functions as we progress
through our V9.0 EAKs and eventually we will have V9.1, the complete
operating environment for an expanded Field Test. Moving from 9.1 to
9.2 will be mostly performance and stability work. We now have 31
external users with access to the CrossTools Kit and the appliances
with V9.0-A, B, C, D, E, so we are making good progress.
We had some nice breakthroughs in E. My KVM guest has now been up for
31 days running a series of tests, usually 60 jobs on a single CPU.
Another more recent change regarding SMP now allows large batteries
of tests to run in 2P and 4P without issues. Coming in F will be full
SMP support, clustering and MSCP serving as well as other additions.

"Make It Work, Make It Right, Make It Fast"
:-)
Arne

Arne,
I more or less agree with Clair.
Generally speaking, benchmarking is hard. Computational benchmarks (e.e., non-privileged computations such as those used for MIPS and VUPS ratings) are one of the simplest species in that genus.
Benchmarking systems-level elements (e.g., context switches, system services, page faults) is complex and often difficult. I spent a good amount of time during my PhD research digging into these mechanisms in terms of the I/O system, and to say the problem is "non-trivial" is an understatement. Determining precisely what one is benchmarking is only the first small step. Separating the real performance information from the surrounding noise is a significant challenge.
As Clair mentioned in his posting, the goal of these early versions is a working system. Accuracy first, performance later.
- Bob Gezelter, http://www.rlgsc.com

I would agree, all to much focus is on hardware specifics or operating system function specifics. I spent many years providing actual system performance benchmarks to customers using their own applications on real hardware being driven by "real" users (RTE testing actually) and the results were often eye opening. Many clients thought that the "new" machine would improve throughput significantly only to realize that the limiting factor was not the system but the users themselves.

Testing system components has its place as long as the whole forest is examined and not just the trees.

[Arne Vajhøj]

Post by IanD
It's been a while since this topic was first aired and the response at the time was "it is too early to tell"
This was quite some time ago now
I don't expect benchmarks as such but I would have thought we have a general idea as to how it performs compared to Itanium or Alpha by now?
Ballpark figures?
10%, 20%, 50%, Rabbit on crack? Still too early to tell?
*Yes, I'm talking about a VM environment since that will probably be the normal deployment environment

When talking performance for VMS x86-64 I think we need to define what
we are talking about.

absolute performance on VMS x86-64 vs Linux x86-64 same HW or VM

absolute performance on VMS x86-64 some VM expected to be typical vs VMS
Alpha some typical 15-20 year old box

absolute performance on VMS x86-64 some VM expected to be typical vs VMS
Itanium some typical 5-10 year old box

relative performance per cost on VMS x86-64 standard HW vs VMS Itanium
on latest HP box

The first is relevant for those interested in level of optimization in
the compilers.

The second and third are relevant for those interested in how their
existing system will run when/if upgraded.

The fourth is relevant in the sales pitch to the bean counters.

You seem interested in the second and third.

I have no idea how 9.0 performs. But given the advances in HW, then
it seems given that VMS 9.2 x86-64 will be much faster than
older VMS Alpha and VMS Itanium. If the underlying HW is 3-5-10 times
faster then it does not matter if the compilers are 25% slower
than the best.

Arne

[Grant Taylor]

Post by Arne Vajhøj
When talking performance for VMS x86-64 I think we need to define what
we are talking about.

Isn't this where a VUP comes into play?

Post by Arne Vajhøj
absolute performance on VMS x86-64 vs Linux x86-64 same HW or VM

Why would you want to cross operating systems at this stage? I'd think
it would be better to stick with OpenVMS.

Post by Arne Vajhøj
absolute performance on VMS x86-64 some VM expected to be typical vs VMS
Alpha some typical 15-20 year old box
absolute performance on VMS x86-64 some VM expected to be typical vs VMS
Itanium some typical 5-10 year old box

These two tests seem to fall back to VUPs to me.

Post by Arne Vajhøj
relative performance per cost on VMS x86-64 standard HW vs VMS Itanium
on latest HP box

"x86-64 standard HW" seems like a misnomer to me. A LOT of different
things can fall into that broad description, anything from a low end
college student notebook from 10 years ago to the contemporary
virtualization power house system.

[John Dallman]

Post by Grant Taylor
"x86-64 standard HW" seems like a misnomer to me. A LOT of
different things can fall into that broad description, anything
from a low end college student notebook from 10 years ago to the
contemporary virtualization power house system.

The sensible interpretation is the kind of systems that enterprises run
the bulk of their virtual machines on: 1-2U rack-mount systems, using
current Intel processors with 8-20 cores per package. The top-end
processors are stupidly expensive in such systems, but ones a few speed
bins below that are very cost-effective per core, cheaper than good
deskside PCs.

You still need to describe such a system along with any benchmarks done
on it, but the general class of system is well-understood in corporate IT.
They're hugely faster than Alphas and a fair bit faster than Itaniums,
when all of those systems are running native code, and IT departments who
need to keep running VMS will be very happy if they can use this kind of
hardware for it.

John

[Arne Vajhøj]

Post by Grant Taylor

Post by Arne Vajhøj
When talking performance for VMS x86-64 I think we need to define what
we are talking about.

Isn't this where a VUP comes into play?

As explained below not necessarily.

Post by Grant Taylor

Post by Arne Vajhøj
absolute performance on VMS x86-64 vs Linux x86-64 same HW or VM

Why would you want to cross operating systems at this stage?  I'd think
it would be better to stick with OpenVMS.

Nobody is talking about switching OS.

But if one is interested in comparing the performance of VMS and
its compilers with other platforms then comparing them on the
same HW would be a relevant metric.

Post by Grant Taylor

Post by Arne Vajhøj
absolute performance on VMS x86-64 some VM expected to be typical vs
VMS Alpha some typical 15-20 year old box
absolute performance on VMS x86-64 some VM expected to be typical vs
VMS Itanium some typical 5-10 year old box

These two tests seem to fall back to VUPs to me.

Somewhat yes.

Post by Grant Taylor

Post by Arne Vajhøj
relative performance per cost on VMS x86-64 standard HW vs VMS Itanium
on latest HP box

"x86-64 standard HW" seems like a misnomer to me.  A LOT of different
things can fall into that broad description, anything from a low end
college student notebook from 10 years ago to the contemporary
virtualization power house system.

Notesbooks are obviously not relevant. This is about servers.

The type of HW that IT departments buy from HPE/Dell/Lenovo
to run ESXi and a bunch of VM's on.

I believe it is a rather competitive market. Which means
that the price difference between vendors will be relative small.

Arne

[Simon Clubley]

Post by Grant Taylor

Post by Arne Vajhøj
absolute performance on VMS x86-64 some VM expected to be typical vs VMS
Alpha some typical 15-20 year old box
absolute performance on VMS x86-64 some VM expected to be typical vs VMS
Itanium some typical 5-10 year old box

These two tests seem to fall back to VUPs to me.

Compute performance is one part of it. I/O performance is another
thing to consider.

Simon.

[Dave Froble]

Post by Simon Clubley

Post by Grant Taylor

Post by Arne Vajhøj
absolute performance on VMS x86-64 some VM expected to be typical vs VMS
Alpha some typical 15-20 year old box
absolute performance on VMS x86-64 some VM expected to be typical vs VMS
Itanium some typical 5-10 year old box

These two tests seem to fall back to VUPs to me.

Compute performance is one part of it. I/O performance is another
thing to consider.
Simon.

This concern about performance seems unreasonable to me.

Yes, faster HW will be faster.

But the port to x86 was never about performance. It was to keep VMS
usable in the future. Why? Because everything on which VMS ran, with
the exception of emulators, is either dead, or in one case sinking.

People still using VMS are doing so for a reason, and x86 VMS offers
them a way forward.

[IanD]

Post by Dave Froble

Post by Simon Clubley

Post by Grant Taylor

Post by Arne Vajhøj
absolute performance on VMS x86-64 some VM expected to be typical vs VMS
Alpha some typical 15-20 year old box
absolute performance on VMS x86-64 some VM expected to be typical vs VMS
Itanium some typical 5-10 year old box

These two tests seem to fall back to VUPs to me.

Compute performance is one part of it. I/O performance is another
thing to consider.
Simon.

This concern about performance seems unreasonable to me.
Yes, faster HW will be faster.
But the port to x86 was never about performance. It was to keep VMS
usable in the future. Why? Because everything on which VMS ran, with
the exception of emulators, is either dead, or in one case sinking.
People still using VMS are doing so for a reason, and x86 VMS offers
them a way forward.
--
David Froble Tel: [phone]
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

Itanium was about performance and marketed as such along with the latest i6 offerings

x86 is as much about performance as it is getting onto modern hardware mainly for all the updated and much improved performance aspects it gives one access to. Faster controllers, network adapters, better caching etc.
I would say a huge aspect of why companies move to newer hardware is for the performance component

I work in a place with 10's of thousands of servers, performance is most certainly a requirement to moving forward for any offering, doing more with less is the name of the game, reducing even the number of cpu's and hence cost is constantly under review

When the whole world around you is moving forward in terms of performance, you don't want to be the slowest in the race or you'll show up as the bottleneck and then next thing you know, your system is earmarked for decommissioning!

Performance is important as is risk mitigation, even for VMS

[Phillip Helbig (undress to reply)]

Post by Simon Clubley
Compute performance is one part of it. I/O performance is another
thing to consider.

A supercomputer is a machine which turns a CPU-bound problem into an
I/O-bound problem.