About the "SIIS" instruction.

Products

• Easytrieve Report Generator

Issue/Introduction

IBM reported as follows.

If "SIIS" assembler instruction is used in a program on z13 or upper processers, CPU time can increase. Reference materials are as follows

https://www.ibm.com/support/pages/identifying-%E2%80%9Cstore-instruction-stream%E2%80%9D-siis-inefficiency-using-cpu-mf-counters

Does the Easytrieve use the "SIIS" assembler instruction?

 

Environment

Release : 6.4

Component : CA Easytrieve Plus Report Generator

Resolution

There is no "SIIS" assembler instruction in the Easytrieve and the Easytrieve is not involved in "SIIS" assembler instruction.

We believe they are referring to "Store Into Instruction Stream" which means a coding technique where you modify instructions dynamically and then execute those instructions.  We do not do that.  Any module marked reentrant (RENT) is definitely not doing that.  There was one patch we know of that caused the Japanese version to go from RENT to NORENT because of a patch that added a STORAGE OBTAIN to increase the limit of REPORT statements any one Easytrieve program could use.  That involved storing the address of the gotten main in the program itself once during execution.  That is one isolated case where we stored into the program and possibly disrupted the pipeline. But that only happens once per execution, so not really an issue.

 

Additional Information

We are sure that the customer's concern is that as the newer processors have come out they have become increasingly more sensitive to SIIS.  Storing into the instruction stream wreaks havoc on the instruction pipeline.  Each modification causes the pipeline to be invalidated and rebuilt.  The multicore processors we have today get all of their speed from the pipelined instructions.  The z15 has 12 physical processors per one logical CPU.  Given an undisturbed pipeline, it can be working on 12 different code paths at the same time doing speculative execution and out of order execution.  Storing into that instruction stream totally invalidates all the speculative work done which requires rolling back to an earlier state and then starting it all over again.  

At least, CA 7 had a few places where they were doing that.  The customers were seeing that performance went down when they upgraded to newer processors. CA 7 had to rewrite several code paths to convert that code to RENT in order to get the performance improvements expected by the customers.