Well yes - that is really apples and oranges, and thanks for proving my point.
Numpy leverages hand tuned assembly (BLAS) with hinting for different chip levels and architectures, and the difference with plain python is shown here: https://en.algorithmica.org/hpc/complexity/languages/ You can of course integrate OpenBLAS into everything. It is not my problem that IBM chooses to starve the support of the assets that brought in money, or fails to innovate them. I would have expected all language products to be able to use Decimal Floating Point (DFP) instructions on the mainframe by now - but apparently the Rexx compiler does not know about those yet. The interpreter probably even less, as that is mostly 24 bit when the compiler still manages 31 and still has mode technical debt to clear. All modern editing features (folding, syntax coloring) come from STET, LEXX, Xedit and ISPF/PDF. IBM choose with OS/2 to throw out the baby with the bath water, and did not develop wonderfull technology- LPEX, son of LEXX, was given to Eclipse and did not get significantly better. Meanwhile, everybody intergrated these ideas. The same goes for Python and Ruby, both done by people knowing Rexx. The 1970’s did not have ISPF, that was only later, >1985, with SPF being around 1984. These could have been developed into proper PC/Internet type editing/paneling systems which would have made building apps and webpages a lot easier and more fun than the current flock of js tools, which all more or less try to imitate the 3270 attribute byte model, but rather poorly. But don’t take my word for it, watch the market and see what people do. I am not stating that Rexx (on the mainframe) has not been neglected, I am just worried that you need skewed benchmarks (and years of hand-tuned Fortran and Assembler) to present a false impression about a product that is not there yet. best regards, René. > On 1 Mar 2023, at 14:16, David Crayford <[email protected]> wrote: > > Have you heard of Dave Plummer's Primes benchmark project, which is widely > regarded as a reliable way to test the speed of programming languages? In > this test, ooRexx only managed to complete 13 passes in 5 seconds, while > Python with numpy completed 6969 passes, thanks to its ability to leverage > GPU processing power. Given that Python has a large community of developers > backed by big tech, it's not surprising that more investment is being made to > improve its performance compared to REXX. Similarly, TSO/ISPF is only > supported by one person, so IBM may not prioritize investing in it as they > focus on other strategic areas to keep the mainframe technology relevant. > While this news may not be welcomed by some, it's important to consider the > bigger picture of ensuring the longevity of mainframe technology. We need to > attract young talent to the platform not handcuff them with tools for the > 1970's no matter how comforting they may be for old timers like us. > > ❯ rexx PrimeRexx.rex > joss_REXX;13;5.084288;1;algorithm=base,bits=8,faithful=no > > > 8:59 > ❯ python3 PrimePy.py > Passes: 6769, Time: 5.000584452878684, Avg: 0.0007387478878532551, Limit: > 1000000, Count: 78498, Valid: True > emillynge_numpy; 6769;5.000584452878684;1;algorithm=base,faithful=no,bits=8 > > [1] https://github.com/PlummersSoftwareLLC/Primes > > On 1/3/23 20:52, René Jansen wrote: >> I agree with Rony. I think your ‘benchmarks’ are a bit synthetic but I >> understand your goal. I think calling ISPF ‘a relic’ and constantly >> badgering Rexx does not serve any purpose in front of this audience, most of >> which see ISPF as something shiny and worthwhile (e.g. to have on OS VS2 >> r3.8 (clones of Rexx and ISPF have even been built there recently)). >> >> We know IBM has divested some of its software maintenance. It is important >> to remember that ’the new mainframe’ *if casted in the image of Windows or >> Linux* always would be a hampered version of something. The mainframe is a >> high-end market and not everybody needs one anymore. It could be >> competitive, but it would need competition, a sane pricing scheme and less >> RACF admins reared in the 80’s ‘lock her down’ mindset. That last thing, not >> the toolset, is why it is hard to get new staff in. >> >> If good tools were enabled young people would choose them and use them. >> There is no need for any badmouthing or skewed benchmarks. If one needs fast >> I/O, one writes assembler or COBOL. It is important to not let new tools >> loose before their time, and seen the difference in the number of interfaces >> to the OS compared to Rexx, the time of Python has not come yet. I remember >> IBM or Rational people demoing the new GUI way of working to grumpy old >> COBOL programmers, and always having to open a 3270 TSO session to do >> something or other before the demo could go on. It was a laugh. In the end, >> it meant that the quality of people’s 3270 emulators went down the drain and >> they were grumpier than ever. >> >> I am sure Visual Studio Code is a nice editor (I sometimes use it on the Mac >> for markdown, mermaid plugins etc) but it is not going to sell mainframes - >> there will be VBS to confront, and maybe VSAM. And obj modules. And probably >> Cool:gen or RPG. What adaptation to modern dinky machines does, is more >> dynamic memory usage, more senseless multithreading and worse algorithms - >> just read in that 88MB XML file and shove it into a Db2 column. Where you >> used to be able to run an LPAR flat out at 100%, you cannot do that anymore >> because websphere and service oriented architecture. >> >> With IBM’s current approach and its horrible handling of its intellectual >> property (sealing it off from a legal perspective, and neglecting it from a >> development point of view) the mainframe is going to be a niche market. That >> is not bad in itself: look at Tandem, long dead but still non-stop running a >> very large part of cards transactions. >> >> If IBM had been serious about the cloud, it would have been forced to >> acknowledge that it would have been best and cheapest to run it on mainframe >> lpars in sysplexes and on COBOL, but alas, they were not serious at all and >> told us mainframe ‘always were the cloud’ but forgot to build one doing what >> they did best. >> >> We like Xedit, we like ISPF. We like Rexx, and we are very fortunate that >> IBM open sourced Object Rexx and NetRexx before that window closed and the >> open sourcing was locked down with ‘business cases’. It also meant, of >> course, they are never going to maintain it again. We now see important >> parts in the hands of private companies, and we see everything we know built >> anew, but worse. And, old problems, once solved, are coming back (memory >> fragmentation anyone?). Transactions? We now have No-SQL but please don’t >> run my bank accounts on it. My suggestion would be to keep working on new >> things, but we don’t need the negative propaganda. On the other hand, now >> would be a good time for IBM to open source and publish everything they >> reaped the benefits from over and over, instead of allowing it to wither and >> waste. And IBM should invent some good new stuff. >> >> best regards, >> >> René. >> >> >> >> >>> On 1 Mar 2023, at 12:15, Rony G. Flatscher <[email protected]> wrote: >>> >>> On 28.02.2023 20:55, David Crayford wrote: >>>> I respectfully express my opinion without intending to badmouth anyone. I >>>> believe that benchmarking the performance of reading a large file is not >>>> an artificial test but rather a real-world use case that we encounter >>>> regularly. It is no secret that REXX on z/OS can be slow. In fact, one of >>>> my colleagues who worked on the IBM File Manager product, which >>>> incorporates REXX scripting, developed their own subset of REXX because >>>> the performance of the TSO REXX interpreter did not meet their objectives. >>> If that is the case then it shows that IBM needs to maintain their >>> mainframe REXX by replacing it with an up-to-date version of REXX (finally). >> ---------------------------------------------------------------------- >> 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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
