and my two cents: 1) don't forget that energy efficiency and hence cost is yet another factor for comparison. Scaled up, Z does rather well in this respect.
2) CICS vs RISC: the distiction is so blurred that to even talk in these terms is difficult. Most Z instructions are implemented in H/W. We moved away from horizontally microcoded instuctions with the advent of s/390. Only very complex instructions are now implemented in firmware called millicode - see the IBM Reseach Journal article by Heller and Farrell when s/390 was announced. There may be many cycles consumed to take an instruction though the entire pipeline but the perceived cycle time will be very much smaller because of out-of-order exection, and the superscaler pipeline. Instructions are gouped dispatched by the h/w according to dependencies. Performance will depend on how optimally the instruction steam is presented to the processor - as with all modern CPUs - and that depends on how well the compiler undertsands the pipeline characteristics and the design intent of the program. When comparisons are made are we comparing simply comparing the CPU or are we confounding this with compaler comparisions? Many architectures have "non-functional" instructions that drop hints to the h/w as to where the dependencies will arise and where the instruction stream is likely to go. Correct use of these can bring benefit and the converse is true. Predictions from benchmarks can only have a limited use. Actual comparisions of the real workload have to be made. Selecting corretly the level of optimization or even the correct compailer is just as important. If you are not using a compiler (ie writing in BAL) then these days it's very difficult to write efficient and maintainable BAL. That's not a z observation - it's becuase of OOO superscaler design of modern processors. Richard J Moore -- Z millicode & zVM development Ext: (M) 37264807/ (L) 37247072; Cell: (+44) (0)7739-875237 Office: (+44) (0)1962-817072 IBM Academy Member - http://www-03.ibm.com/ibm/academy/index.html Linkedin Profile http://uk.linkedin.com/pub/richard-j-moore-fiet-fbcs-ceng-citp/4/4b1/748 Linux on 390 Port <LINUX-390@VM.MARIST.EDU> wrote on 08/11/2017 02:11:23: > From: John Campbell <soup...@gmail.com> > To: LINUX-390@VM.MARIST.EDU > Date: 08/11/2017 02:16 > Subject: Re: How many Intel cores does an IFL emulate > Sent by: Linux on 390 Port <LINUX-390@VM.MARIST.EDU> > > GHz is GHz primarily when comparing CISC vs CISC. While you can try to use > this, a lot depends upon how well the microcode can make a CPU process the > "usual" machine code. > > CISC vs RISC-- zSeries vs pSeries, for instance, the GHz (I remember when > it was 2MHz for mainstream microcomputer CPUs) more closely maps to > instruction issue rates rather then microcode steps. > > All right, I'm going to age myself. > > A long long time ago I wrote microcode for the Sperry UNIVAC Array > Processor supporting geophysical processing; At the time it was > implemented in TTL logic and had an instruction fetch rate of 100ns. > Maximum theoretical compute capability was approximately 120 MFloPS (you > can laugh, now, but this was in 1981) though, in "sustained" rate, could > almost get up to 80MFloPS which, frankly, was pretty cool. We were doing > 3D FFT processes... and, so, I had to doink with I/O subroutines (on the > 1100 CPU end) to allow the I/O system to handle the trace shuffling. Yeah, > there were multiple steps in the instruction processing-- IF, OD, CD, etc, > etc, etc-- and use of graph paper to get them to all be coded in the > "right" order was pretty much de rigeur. > > CISCs are hard to compare. zSeries "SS" instructions don't exist in the > Intel CPUs (all right, so I've written BAL for 360s and 370s as well as > Intel CPUs) so the instruction mix, as executed makes comparisons difficult. > > RISC processors are more comparable w/r/t clock rates; DEC Alpha, PowerPC, > MC88K, etc, etc, etc, because, with the low impact instructions, the > fetch/execute is pretty predictable. > > With CISC CPUs there have been all kinds of efforts to optimize them. Some > CPUs "internally" re-order instruction processing in order to get the best > performance. I've also seen indications that compilers can be a lot more > clever in terms of optimizing the generated code. > > -soup > > On Tue, Nov 7, 2017 at 5:31 PM, Barton <bar...@velocitysoftware.com> wrote: > > > Yes. Gigahertz is gigahertz. If you can measure ghz consumed on x, you > > can guestimate requirements on z. The only way to understand requirements > > is to know current use. > > > > Barton > > > > > > > On Nov 7, 2017, at 8:28 PM, Victor Echavarry Diaz < > > vechava...@evertecinc.com> wrote: > > > > > > We receive a request from a new customer for a z/Linux guest on a BC12. > > The specification that the vendor supplied is for an intel platform. Does > > anyone know is there a formula to convert intel cpu cores to IFL? > > > > > > Regards, > > > > > > Victor Echavarry > > > > > > System Programmer > > > > > > Operating Systems > > > > > > EVERTEC, LLC > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > WARNING: This email and any files transmitted with it are confidential > > and > > > intended solely for the use of the individual or entity to whom they are > > > addressed. If you have received this email in error please delete it > > immediately. > > > Please note that any views or opinions presented in this email are > > solely those > > > of the author and do not necessarily represent those of EVERTEC, Inc. or > > its > > > affiliates. Finally, the integrity and security of this message cannot be > > > guaranteed on the Internet, and as such EVERTEC, Inc. and its affiliates > > accept > > > no liability for any damage caused by any virus transmitted by this > > email. > > > > > > ---------------------------------------------------------------------- > > > For LINUX-390 subscribe / signoff / archive access instructions, > > > send email to lists...@vm.marist.edu with the message: INFO LINUX-390 > > or visit > > > https://urldefense.proofpoint.com/v2/url? > u=http-3A__www.marist.edu_htbin_wlvindex-3FLINUX-2D390&d=DwIBaQ&c=jf_iaSHvJObTbx- > siA1ZOg&r=hsO4Lk6XlJWxPC1OayT7oG3wyw3H8GpACVStAsDQDSM&m=6h8X9oU4b- > Q0m0028lSv9hggZyvd2MAVahBRDGcRqZc&s=hdIWV4mNyDc8rwmzK3GO1ZpEaCDWnOcEDXAgOIu7c1g&e= > > > ---------------------------------------------------------------------- > > > For more information on Linux on System z, visit > > > https://urldefense.proofpoint.com/v2/url? > u=http-3A__wiki.linuxvm.org_&d=DwIBaQ&c=jf_iaSHvJObTbx- > siA1ZOg&r=hsO4Lk6XlJWxPC1OayT7oG3wyw3H8GpACVStAsDQDSM&m=6h8X9oU4b- > Q0m0028lSv9hggZyvd2MAVahBRDGcRqZc&s=vv6NRI9Kt91DGHfx4ZveOT66D2odS4gCVkq603hOuxc&e= > > > > ---------------------------------------------------------------------- > > For LINUX-390 subscribe / signoff / archive access instructions, > > send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or > > visit > > https://urldefense.proofpoint.com/v2/url? > u=http-3A__www.marist.edu_htbin_wlvindex-3FLINUX-2D390&d=DwIBaQ&c=jf_iaSHvJObTbx- > siA1ZOg&r=hsO4Lk6XlJWxPC1OayT7oG3wyw3H8GpACVStAsDQDSM&m=6h8X9oU4b- > Q0m0028lSv9hggZyvd2MAVahBRDGcRqZc&s=hdIWV4mNyDc8rwmzK3GO1ZpEaCDWnOcEDXAgOIu7c1g&e= > > ---------------------------------------------------------------------- > > For more information on Linux on System z, visit > > https://urldefense.proofpoint.com/v2/url? > u=http-3A__wiki.linuxvm.org_&d=DwIBaQ&c=jf_iaSHvJObTbx- > siA1ZOg&r=hsO4Lk6XlJWxPC1OayT7oG3wyw3H8GpACVStAsDQDSM&m=6h8X9oU4b- > Q0m0028lSv9hggZyvd2MAVahBRDGcRqZc&s=vv6NRI9Kt91DGHfx4ZveOT66D2odS4gCVkq603hOuxc&e= > > > > > > -- > John R. Campbell Speaker to Machines souperb at gmail dot > com > MacOS X proved it was easier to make Unix user-friendly than to fix Windows > "It doesn't matter how well-crafted a system is to eliminate errors; > Regardless > of any and all checks and balances in place, all systems will fail because, > somewhere, there is meat in the loop." - me > > ---------------------------------------------------------------------- > For LINUX-390 subscribe / signoff / archive access instructions, > send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit > https://urldefense.proofpoint.com/v2/url? > u=http-3A__www.marist.edu_htbin_wlvindex-3FLINUX-2D390&d=DwIBaQ&c=jf_iaSHvJObTbx- > siA1ZOg&r=hsO4Lk6XlJWxPC1OayT7oG3wyw3H8GpACVStAsDQDSM&m=6h8X9oU4b- > Q0m0028lSv9hggZyvd2MAVahBRDGcRqZc&s=hdIWV4mNyDc8rwmzK3GO1ZpEaCDWnOcEDXAgOIu7c1g&e= > ---------------------------------------------------------------------- > For more information on Linux on System z, visit > https://urldefense.proofpoint.com/v2/url? > u=http-3A__wiki.linuxvm.org_&d=DwIBaQ&c=jf_iaSHvJObTbx- > siA1ZOg&r=hsO4Lk6XlJWxPC1OayT7oG3wyw3H8GpACVStAsDQDSM&m=6h8X9oU4b- > Q0m0028lSv9hggZyvd2MAVahBRDGcRqZc&s=vv6NRI9Kt91DGHfx4ZveOT66D2odS4gCVkq603hOuxc&e= > Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For more information on Linux on System z, visit http://wiki.linuxvm.org/
