Open XL C/C++ is being delivered in stages with incremental enhancements. Open 
XL C/C++ 1.1 was bringing the Clang/LLVM infrastructure to the z/OS platform to 
support more recent C++ standards needed by many open-source applications 
coming onto the platform. Open XL C/C++ 2.1 added 32-bit code generation and 
z/OS batch support. 
We intend to keep improving the usability and features supported in the Open XL 
C/C++ compiler. You can expect usability improvement with debugging and 
additional key features from XL C/C++ in the next release of Open XL C/C++.

On Mon, 17 Mar 2025 08:21:48 +0800, David Crayford <[email protected]> wrote:

>Apologies, I fat fingered the previous email on my iPad.
>
>All our tests have been conducted from a z/OS UNIX shell, which has a maximum 
>region size. Using precompiled headers won’t make much difference since most 
>of the header files being read are part of the runtime and are not 
>precompiled. The XLC compiler used to include precompiled header files, but 
>IBM dropped them, stating they intended to improve compiler performance, 
>making them unnecessary.
>
>It gets worse. The new compiler does not generate compiler listings. Neither 
>does Clang, but at least it provides the llvm-objdump utility, which, when 
>used with debug files, can produce something useful for debugging. 
>Unfortunately, that tool isn’t included in the z/OS toolchain, so god knows 
>how a customer is supposed to support their code in the field.
>
>
>
>> On 17 Mar 2025, at 7:11 am, David Crayford <[email protected]> wrote:
>> 
>> T sting region size is pointless. All our tests have been conducted in the 
>> shell which has a maximum regi
>> 
>>> On 17 Mar 2025, at 06:53, Charles Mills <[email protected]> wrote:
>>> 
>>> Both tests specified REGION=0M. Here are the stats from the two compiles:
>>> 
>>> Open:
>>> CPU:     0 HR  00 MIN  01.29 SEC    SRB:     0 HR  00 MIN  00.03 SEC      
>>> VIRT:    20K  SYS:   244K  EXT:   243432K  SYS:    25660K                 
>>> ATB- REAL:                 68856K  SLOTS:                     0K          
>>>    VIRT- ALLOC:      88M SHRD:       0M                                     
>>>                  
>>> 
>>> Legacy:
>>> CPU:     0 HR  00 MIN  00.36 SEC    SRB:     0 HR  00 MIN  00.00 SEC  
>>> VIRT:    80K  SYS:   252K  EXT:   108328K  SYS:    16728K             
>>> ATB- REAL:                   232K  SLOTS:                     0K      
>>>    VIRT- ALLOC:      13M SHRD:       0M                             
>>> 
>>> Charles
>>> 
>>>> On Sun, 16 Mar 2025 15:48:18 -0500, Charles Mills <[email protected]> wrote:
>>>> 
>>>> Trying to hold down the noise by doing one reply for all of your great 
>>>> suggestions.
>>>> 
>>>> @Peter, no, did not know about .pch. The documentation is sorely lacking. 
>>>> Would like to give that a try but no idea how.
>>>>> Did you run both of those tests using the same REGION value on the same 
>>>>> LPAR?
>>>> Same exact virtual machine on both but I am not certain about the REGION 
>>>> size. Suspect it was the same. I will look when I get back online and 
>>>> possibly re-test.
>>>> 
>>>> @David Crayford, agree, this product does not seem quite yet ready for 
>>>> prime time. Sadly. I had hoped to move forward with the new compiler.
>>>> 
>>>> @David Cole, well, both compile and run times are important. If you pay 
>>>> for compile cycles, as we do, then compile CPU time is important. If you 
>>>> value developer time, then compile elapsed time is important. Of course 
>>>> run time is important, but harder to measure: what inputs, on what machine?
>>>> 
>>>> @Allen: noted. I will re-run the tests with larger and consistent region 
>>>> sizes. I suspect they were the same, but I am not online at the moment.
>>>> 
>>>> Also not sure what the OPT value was for the Open compiler test. I did not 
>>>> specify, and the default does not seem to be documented :-( OPT value was 
>>>> 0 for the legacy test. When I retest I will specify OPT 0.
>>> 
>>> ----------------------------------------------------------------------
>>> 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

Reply via email to