> Indeed! And the generated code between opt(0) and opt(3) is so different,
> it's hard to believe it's doing the same thing, yet it is. It's impressive as
> hell. In the one compute-intensive case that we measured, unoptimized used
> half again as much CPU.
In fact it convinced me that we should probably not be coding assembler
language by hand as we have to write for comprehension and maintainability, not
efficiency.
Best wishes / Mejores deseos / Meilleurs vœux
Ian ...
On Wednesday, July 19, 2023 at 11:38:51 PM GMT+2, Phil Smith III
<li...@akphs.com> wrote:
Chris Craddock wrote, in part, re:
>>"It's silly to say that C hardware near. I would say less than 5% of the x86
>>or z instructions are used by the language."
>You would be shocked if you looked at a z/OS C++ listing. Spoiler: the
>C/C++ compiler and libraries exploit the living shit out of the z
>architecture instruction set. There are waaaay more new instructions
>in the generated C++ than in the HLASM part (I wrote both parts).
Indeed! And the generated code between opt(0) and opt(3) is so different, it's
hard to believe it's doing the same thing, yet it is. It's impressive as hell.
In the one compute-intensive case that we measured, unoptimized used half again
as much CPU.
>It is true that the C/C++ macro processor is pretty dumb compared to
>the HLASM macro language. And yet that doesn't seem to be much of a
>limitation if any. The programming models are just different.
Well.like all good questions, "it depends". We hit limitations with the macro
preprocessor pretty often, in part because our code is multi-platform, so we
have lots of multipathing for which #if and friends just don't suffice. I'll
admit that it probably doesn't help that I'm an assembler guy and thus
immediately think "Gee, this would be trivial with an assembler macro".
Sometimes there are ways to do it with the macro preprocessor; sometimes I'm
told "You just can't do that". And in those cases, I'm assuming that the folks
telling me that know what they're on about. Which, of course, might be wrong!
...phsiii
