sampsyo
commented
10 years ago More notes for this eventual documentation page (this time more on the technical side, but still necessary to document).
Quoth @joshuay (with my response):
The definition of a struct specifies which elements the struct contains. It is my understanding that a struct itself should not be specified as approximate, but whatever elements of a primitive data type it contains may be specified as approximate.
Yes. Only primitive types can be approximate.
Again answering an eminently reasonable question, all credit due to @joshuay:
Would it be better to just ENDORSE the entire boolean condition once as a whole, or rather ENDORSE each APPROX variable in the boolean condition individually?
In my opinion, this is actually a matter of taste—either one is appropriate. I generally like to use the latter when there are also precise variables in the condition, like this:
if (x && ENDORSE(y)) { … }but sometimes use the former when both x and y are approximate:
if (ENDORSE(x && y)) { … }In general, optimizations will treat these more or less the same way—it’s just a matter of making the code clear to read.
We should write a guide for the docs that's more accessible than the papers (EnerJ and ACCEPT) to annotating programs. This should capture the softer, more philosophical ideas behind the annotation language: stuff that we tend to take for granted these days but are critical to communicate to someone new to approximation.
As a starting point, here's some background I sent to @joshuay earlier today in an email.
Here’s the basic idea: you should mark things as APPROX only when you think that code should be treated as approximate. In contrast, use an endorsement when two pieces of code need to interact where one is approximate and the other should be treated precisely.
As an example, say you have a program that does some kind of complicated physical simulation, like our fluidanimate. The particular positions of each particle may not be too important, and computations involving those positions probably make up the bulk of the computation time. So it makes sense to mark those positions as approximate:
You might have a function that updates the position of some particle. Since this again seems approximable, you should probably use an APPROX parameter to pass in the coordinates:
On the other hand, maybe you have a bookkeeping function that prints some coordinates to a file or does some sort of counting into an array. Bookkeeping and output is (a) unlikely to be approximatable, since even small errors can cause large problems, and (b) probably isn’t very “expensive” in terms of execution time. So you should probably mark this function with precise arguments and use an endorsement:
Another strategy that can be useful during this process is to use a profiler, such as
gprofto find the most time-consuming parts of the execution and target your efforts there.