|Compiler-generated file access hints firstname.lastname@example.org (Nor Jaidi) (1997-04-02)|
|Re: Compiler-generated file access hints email@example.com (Stefan Monnier) (1997-04-03)|
|Re: Compiler-generated file access hints firstname.lastname@example.org (Nor Jaidi) (1997-04-06)|
|From:||Nor Jaidi <email@example.com>|
|Date:||2 Apr 1997 16:02:19 -0500|
|Organization:||Curtin University of Technology|
|Keywords:||optimize, question, comment|
From literature I gather that giving hints on future file access is a
worthwhile form of optimisation to look into. For example, a file can
be fetched (assumed non-blocking) from the disk (slow) into memory
(fast) before it is actually opened and read. This would give the
impression of zero disk transfer latency.
Some papers suggested that the compiler should give the hints. But I
haven't read any compiler-related issues regarding this. The compiler
writers may not like this idea because of the following problems:
1. File semantics must be built to the compiler in addition
to/instead of the library.
2. String semantics must be explicit (good bye C/C++) because
file names are specified using strings.
I know that file and string semantics are built into translators such
as pascal to C, etc. But has anyone ever exposed library stuff to the
compiler for optimisation sake (rule out embedded application please,
they would do ANYTHING for optimisation). I thought that would make
the compiler more monolithic in nature.
I am interested in this and related issues.
Nor Jaidi Tuah
[I suppose profiling with feedback might help. -John]
Return to the
Search the comp.compilers archives again.