On 12/07/2022 12:21 am, Charles Mills wrote:
+1
And when new hardware comes out, taking advantage of the new architecture is a
simple matter of updating ARCH() in your C/C++ compile and re-building. You
probably don't have the appetite to re-work your carefully hand-tuned assembler.
+1 you can't optimize for hardware that hasn't been invented yet
I know whereof I speak. I wrote a commercial product in C++ that successfully handled
millions of events per second, with CPU utilization that was considered satisfactory by
customers. Non-trivial events: basically taking an SMF record, reformatting a hundred or
more fields using a "report writer"* type architecture, translating it to UTF-8
(non-trivial) and pushing it out the TCP stack.
*By report writer type architecture, I mean it did not work the way you would
write a hard-coded program, working its way through one SMF record section at a
time. It went customer-specified-field by customer-specified-field, so for two
adjacent fields in the same section, it had to decode the relevant triplet
twice.
We can easily push millions of events through our stack which is
written in Metal/C and Java.
https://www.ibm.com/docs/en/om-im/5.6.0?topic=monitor-getting-started
Charles
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Andrew Rowley
Sent: Sunday, July 10, 2022 6:22 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: NOTSP The Latin of Software Code Is Thriving - The New York Times
On 9/07/2022 1:10 am, Colin Paice wrote:
I was told
If it executes
1. a million times a second - write in assembler
2. a thousand times a second write it in cobol or C
3. once a second - write it in Java
4. Else /bash/rexx/
Probably not an accurate picture these days.
It would have to be a very select piece of assembler to have any
significant advantage over C / C++. C and C++ have the advantage that
the compiler doesn't have to produce maintainable or comprehensible
code, so it can do lots of optimizations, inlining, loop unrolling etc.
- whatever the compiler writers found produces the fastest code. Of
course you can do the same in assembler - it is just a question of
whether it is practicable for larger pieces of code.
Java: that is probably reasonable if you are talking about starting a
JVM from scratch every time e.g. like a z/OS batch job. If you are
talking about a routine executed by a running program, I would expect
Java to be close to C. (Certainly not 3 orders of magnitude different.)
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
