Robert Wessel <[email protected]> writes: > Not only is it bad practice in general, self modifying code tends to > be extremely slow on modern processors, usually involving considerable > pipeline stalls and cache flushing. Of course once done it's fast, > but the actual change is usually quite painful. The traditional S/360 > coding practices that often put code and data near together is also > problematic, modifying data within some distance of executed code is > often very painful too, IIRC, it was the z900 first that bit a bunch > of people who had any code and modifiable data in the same 256 byte > block.
mvs & vm/370 had a bunch of kernel rework for (4-way) 3084 to make data areas cache aligned and multiples of cache line size ... claims that it increased overall system throughput 5-6%. vm370 did accurately track time used ... but mvs is quite a bit sloppier ... which gives rise to "capture ratio" ... ratio cpu accounted for compared to total cpu busy. http://publib.boulder.ibm.com/tividd/td/TDS390/SH19-6818-08/en_US/HTML/DRLM9mst48.htm and http://pic.dhe.ibm.com/infocenter/zos/v1r12/index.jsp?topic=%2Fcom.ibm.zos.r12.erba900%2Ferbzpm9030.htm and could even be as low as 40% ... really old email discussing capture ratio http://www.garlic.com/~lynn/2006v.html#email800717 -- virtualization experience starting Jan1968, online at home since Mar1970 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
