[m-rev.] for post-commit review: getting OISU information to the feedback tool

[Paul Bone]

On Wed, Oct 24, 2012 at 04:16:37PM +1100, Zoltan Somogyi wrote:
> On 24-Oct-2012, Paul Bone <pbone at csse.unimelb.edu.au> wrote:
> > On Wed, Oct 24, 2012 at 02:59:26PM +1100, Zoltan Somogyi wrote:
> > > Note that this diff is BREAKS binary compatibility for debug and deep
> > > profiling grades.
> > > 
> > > For review by anyone.
> > > 
> > 
> > I'm happy to review this.  But before I begin in earnest I would like to confirm
> > my understanding of what you want to implement in the future.
> > 
> > As it stands this and your previous patches add a pragma that the programmer
> > can use to indicate that making the updates to a value of a certain type out of
> > order is okay, and implicitly desirable for performance.  This patch makes
> > this information available to the deep profiler and feedback tool.  My
> > questions are.  Do you want the feedback too to check the global uniqueness of
> > the value of this type?  Also, should the feedback tool attempt to parallelise
> > the program as if uses of this variable cannot form a dependency?  Thereby
> > requiring the compiler to generate code that makes a global store for a
> > variable of this type and provide synchronisation?
> > 
> > These questions may be harder to answer.  How can the compiler be sure that the
> > variable of this type is globally unique?  In particular, the compiler cannot
> > completely trust the feedback, but only the feedback tool can analyse the whole
> > program?  This may also get complicated when linking to 3rd party libraries, a
> > library may create a second instance of such a variable.  It will be possible
> > to use runtime checks, but I would rather detect any problems at compile time.
> 
> These issues are discussed in the OISU design document, which I have now
> added to the compiler/notes directory.
> 
> > > deep_profiler/query.m:
> > > 	Recognize a query asking for the new report type.
> > 
> > Can I execute the query from the UI?
> 
> Yes. There is now a link for it on the module summary page.
> 
> > You can add 'developer only' options using the appropriate constructors in the
> > display structure.  I suggest on each module page adding a developer only
> > link to this report.
> 
> Why would you want to make it developer only?

I assumed that the report would be more like a dump of raw data rather than
information that users might find useful.

Thanks.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: Digital signature
URL: <http://lists.mercurylang.org/archives/reviews/attachments/20121024/b0870d63/attachment.sig>