SV: generic type support

[Andrew Haley <aph at redhat dot com>]

=?utf-8?B?w5h5dmluZCBIYXJib2U=
?= writes:
 > > > The problem is that the profiling pattern is not known before the
 > > > application is deployed. The profiling pattern changes with data
 > > > processed.
 > >
 > >In which case profile directed optimization is invalid, because the
 > >profile might equally well be wrong for the next run of data.  Profile
 > >directed optimization pretty much assumes that the pattern of usage is
 > >consistent between runs.
 >  
 > The idea is that the profiling/JIT process is an iterative adaptive process. 

Fair enough.  It is possible that a profile on a user's machine will
be more accurate than one generated by a developer.

 > >With regard to getting the best performance from a specific chip,
 > >there seems to be a choice here:
 > >
 > >  a) Compile from bytecode during installation.
 > >  b) Compile from source during installation.
 > >
 > >  ... and then perhaps recompile with profile directed optimization.
 > >  Alternatively, a profile could be delivered with the application.
 > >
 > >Why will a) necessarily be better than b)?
 > 
 > The best possible performance could be had if source compilation
 > happened AOT with profiling information specific to deployment
 > hardware and data to be processed.

Yes, probably.

 > I suppose bytecode gives a bit better IP protection than handing
 > out source code, and more actual work has been done in bytecode to
 > native on deployment machine than source to native. Unix has done
 > source on deployment machines since forever though.

Indeed.  Bytecode doesn't seem to be smaller than source code, and in
any case it can easily be decompiled.  [Yes, I know about bytecode
obfuscators.  But you can obfuscate source too.]

And you would not expect a writer of Free Software to be even slightly
sympathetic to issues of "IP protection"!

Andrew.