SV: generic type support

Thu Feb 20 11:41:00 GMT 2003

=?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.