Google and Twitter workloads quite likely do not have the same integrity expectations/requirements as workloads running on z systems. This may be part of the explanation. In addition, my observations are limited to IBM Z systems which are 'mainframe' systems, and the subject of this discussion list. The benchmark cited appeared to be running on a high-end Dell system.
Another possibility might be the true object-oriented nature of the language that may not mesh well with a non-OO workload. For example, I have seen several implementations which had to incorporate an OO-relational layer to bridge the differences between OO processing and relationally conforming data. There was substantial overhead associated with the care maintenance of that data layer. Based on my experience and personal observations, I would not recommend replacing a high volume performance critical system written in an extremely low overhead 2nd generation language with system largely written in JAVA, certainly not without doing a serious pilot project first. I would feel far more comfortable recommending C/C++ as a replacement. This is appears to be an older IBM document (https://www-01.ibm.com/support/docview.wss?uid=swg27013550&aid=7 I could not find a date), but it contains the following statement... " Will a TPF Java program be as efficient as an assembler program or even C? Of course not, but consider..." Hope the above helps explain my perspective. -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of David Crayford Sent: Thursday, April 19, 2018 10:28 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: The IRS Really Needs Some New Computers On 20/04/2018 4:54 AM, Mike Hochee wrote: > I have yet to see JAVA successfully handle the data and transaction volumes > processed by the largest credit card processors, banks, insurance companies, > or the stock market. Some of the biggest companies in the world use the JVM in their stack. Google, Amazon, eBay, Uber not to mention Twitter, all at enormous scale. There are several high frequency trading applications written in Java some claiming to do 6M tps on a single thread [1]. [1] https://martinfowler.com/articles/lmax.html > I witnessed an attempt at processing appx. 15% of IRS volume using JAVA as a > core technology. I don't know the final outcome, but when I left they were > about 400% beyond proposed SLA performance targets. C/C++ seems like a good > (maybe only) bet if they want to keep the workload on zTPF. That's interesting! Is there a fundamental flaw in the JVM implementation on zTPF or was it down to poor design? > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Eric Chevalier > Sent: Thursday, April 19, 2018 4:07 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: The IRS Really Needs Some New Computers > > On 4/18/18 1:50 PM, Steve Beaver wrote: > >> IBM ALCS became zTFP. That is generally all in Assembler, unless you >> use JAVA. But JAVA is way too slow > TPF has had C/C++ since 1997. > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
