Re: SRST Performance (was: converting character to packed

[Paul Gilmartin]

On 2016-10-18, at 13:45, Tony Harminc wrote:
> 
> There is also the long-known performance problem with TRT (and TR)
> that its definition requires that "Access exceptions are recognized
> only for those bytes in the second operand which are actually
> required. Access exceptions are not recognized for those bytes in the
> first operand which are to the right of the first byte for which a
> nonzero function byte is obtained."
>  
Isn't the purpose of the "trial execution" to avoid page faults,
at least on the destination operand?  But woe be unto you if
channel activity or other unserialized updates occur concurrently.
(Or is that detected causing the trial execution to restart?)

-- gil

Re: SRST Performance (was: converting character to packed

[Tony Harminc]

On 18 October 2016 at 12:11, Martin Truebner  wrote:
> I have no figures - but consider the following:
>
> TRT does a lockup for each and every char until terminating char is
> found or the maximum length is reached- the lockup is done against a
> table of 256 char.
>
> SRST does a check of each char against a single char (plus the
> termination char).
>
> I would expect SRST to be faster - but have no data to prove it.

There is also the long-known performance problem with TRT (and TR)
that its definition requires that "Access exceptions are recognized
only for those bytes in the second operand which are actually
required. Access exceptions are not recognized for those bytes in the
first operand which are to the right of the first byte for which a
nonzero function byte is obtained."

So if the table (second operand) is near the edge of a page, the
machine cannot decide in advance if there will be a program check for
access (storage key, DAT, etc.); rather, this is data dependent
(actually for both operands). This worked well on S/360, but not so
well on a modern machine. They have changed these rules for TRTE to be
more hardware architect friendly.

Tony H.

Re: SRST Performance (was: converting character to packed

[Gary Gregory]

You're right - there has to be a predetermined breakpoint but in my case I use 
it for testing X'40' or X'00' in strings and then do what I need to do after 
that.  Recently I have used a mix of SRST and TRT in the same program but they 
were used to perform a lot of different parsing.

-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On 
Behalf Of Paul Gilmartin
Sent: Tuesday, October 18, 2016 11:30 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: SRST Performance (was: converting character to packed

On 2016-10-18, at 10:11, Martin Truebner wrote:
> 
> TRT does a lockup for each and every char until terminating char is 
> found or the maximum length is reached- the lockup is done against a 
> table of 256 char.
>  
Caching helps a lot.  How can the programmer insure that the table occupies the 
minimum number of cache lines?

Does modern hardware optimize this further?

> SRST does a check of each char against a single char (plus the 
> termination char).
>  
Testing for multiple characters (e.g. non-numeric) requires multiple executions 
of of SRST.  Is there a break-even point with TRT?
Again, caching the subject string helps.

And the next hardware model will change the rules.

-- gil

Re: SRST Performance (was: converting character to packed

[Paul Gilmartin]

On 2016-10-18, at 10:11, Martin Truebner wrote:
> 
> TRT does a lockup for each and every char until terminating char is
> found or the maximum length is reached- the lockup is done against a
> table of 256 char.
>  
Caching helps a lot.  How can the programmer insure that the table occupies
the minimum number of cache lines?

Does modern hardware optimize this further?

> SRST does a check of each char against a single char (plus the
> termination char).
>  
Testing for multiple characters (e.g. non-numeric) requires multiple
executions of of SRST.  Is there a break-even point with TRT?
Again, caching the subject string helps.

And the next hardware model will change the rules.

-- gil