> A memory operand reference is literally _orders of magnitude_ slower than an > in-L1-cache operand reference
I have finally come to terms with that concept. When I started out, on a S/360 40, it came with a book (http://bitsavers.informatik.uni-stuttgart.de/pdf/ibm/360/funcChar/A22-6881-2_360-40_funcChar.pdf) that had the exact timing for each opcode. Most RR instructions were 7.5us and most RX instructions were ~12us. My mental model now is "instructions take almost no time at all; storage references take a very long time." Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Ed Jaffe Sent: Friday, January 31, 2014 1:58 PM To: [email protected] Subject: Re: CPU time On 1/31/2014 9:52 AM, Charles Mills wrote: > I don't really know, but my conclusion is that either "getting interrupted" > consumes a fair amount of CPU time, or else that if the program is busy > continuously it tends to "own" the instruction and data caches, which saves a > lot of CPU time. Both. We've measured a so-called "task switch" at ~4000 instructions (we use the "L" instruction as our metric). And, on modern hardware, cache and TLB misses are "killer." A memory operand reference is literally _orders of magnitude_ slower than an in-L1-cache operand reference. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
