[Info-vax] Current VMS Usage Survey

[John Reagan]

On Thursday, December 5, 2013 11:21:00 AM UTC-5, Bill Gunshannon wrote:
> In article <36bcad1f-a91d-48fa-8eaa-bcec922da3ae at googlegroups.com>,
> 
> 	John Reagan <xyzzy1959 at gmail.com> writes: 


>  The HP-UX Itanium compiler provides PBO (Profile Based Optimization).  The NSK Itanium compiler provides PGO (Profile Guided Optimization).  Same concept, different TLA.  Compiler instruments the code, you run it to count various things, a data file written out, you compile again using that data file.
 
> 
> > On Alpha, the Tru64 compilers had some PGO-like tools.  GEM has the support to use profiling data.  It was never enabled/ported to OpenVMS.
> 
> Why?  Because no one saw any real value in it in the real world?
> 
The decision that HPTC would be a Tru64 solution.  Enabling it for OpenVMS would have been trivial.  Plus, Alpha SPECmark numbers were never reported from OpenVMS, only from Tru64.  You wanted PGO there to help get the best numbers.

 
> > GCC provides PGO for x86 targets (-fprofile-generate and -fprofile-use) and so does Open64.  I've seen discussions to add PGO to LLVM in the future.
> 
> How many commercial application developers collect these profiles from 
> their customers and provide customized binaries afterwards?
>  

Probably not that approach, but many certainly run "test loads" against their code to help detect the various branch likely/unlikely paths.  Without any source syntax to indicate branch ratios, the compiler guesses.  With any "test load", you can easily detect which branches are rare (ie, error paths and such) vs the common ones.  The NSK kernel itself is built with PGO profiling data based on a "test load".  Same with HPUX if I remember correctly.