tag:blogger.com,1999:blog-2572826743364240863.post7559660877956497024..comments2020-05-04T08:05:03.791-07:00Comments on The nerdiest of the nerds: Productivity language for performance-oriented programmersHilbertAstronauthttp://www.blogger.com/profile/11443786031975040593noreply@blogger.comBlogger7125tag:blogger.com,1999:blog-2572826743364240863.post-34196530444068352532009-06-29T21:32:32.426-07:002009-06-29T21:32:32.426-07:00John said: "The 'might as well go all the...John said: "The 'might as well go all the way' argument seems like a reasonable one at first, but I don't know. Many languages have started by compiling down into another."<br /><br />I'm all about source-to-source translation. It's perfectly OK for C or Fortran (probably C _and_ Fortran; each has its strengths) to be a target. <br /><br />The thing is, I don't want to write a general-purpose programming language. It's not so hard to write computational kernels in low-level languages, even efficient ones. (We know how to do autotuning; that's just source-to-source translation.) It's the glue code, the resource allocation, input and output, etc. that are hard for programmers, and that take real time. <br /><br />Of course it would be awesome if units and other kinds of metadata would propagate nicely through the entire computation, but I'm OK with some of that computation living in opaque or low-level libraries -- tagging inputs and outputs of those libraries would be a great start, though.<br /><br />I think if that wonderful "somebody else" were to come along, I'd say to him or her that it's much more general and helpful to translate code from a simple language into C, than to translate annotated C into C (for example).HilbertAstronauthttps://www.blogger.com/profile/11443786031975040593noreply@blogger.comtag:blogger.com,1999:blog-2572826743364240863.post-32528118523306153432009-06-29T18:22:21.122-07:002009-06-29T18:22:21.122-07:00The "might as well go all the way" argum...The "might as well go all the way" argument seems like a reasonable one at first, but I don't know. Many languages have started by compiling down into another. It isn't at all clear to me that the person who would begin such a project wouldn't find it easier to start with additional checks, and then compile down into another language, then to incorporate that compiler, working from there. To frame it a different way, since we both note that this is work for "somebody else", suppose that person were just to come along and offer to listen to your requirements. I don't suppose you would preclude them from working this way, were that their preference?Johnhttps://www.blogger.com/profile/12896413955408148961noreply@blogger.comtag:blogger.com,1999:blog-2572826743364240863.post-57136130512666485632009-06-29T08:47:52.863-07:002009-06-29T08:47:52.863-07:00btw here's a pastebin for that source code sni...btw here's a pastebin for that source code snippet I posted:<br /><br />http://pastebin.com/m65546f66HilbertAstronauthttps://www.blogger.com/profile/11443786031975040593noreply@blogger.comtag:blogger.com,1999:blog-2572826743364240863.post-46539092044344035152009-06-29T08:46:50.166-07:002009-06-29T08:46:50.166-07:00I see what you mean now -- the combination of prag...I see what you mean now -- the combination of pragmas / annotations embedded in comments and source-to-source translation is a common thing in the HPC world. Vectorizing compilers and OpenMP compilers use this technique extensively. It seems to work best when it's a hook for experienced programmers to give the compiler semantic information for optimizations -- for example, that a variable is private to a loop body, or that a function has no side effects. (Why am I lecturing you -- you know all this stuff! ;-P )<br /><br />For correctness issues, though, I don't think this technique scales. For example, it doesn't solve resource management and scoping problems, because coders still have to remember to close resources in a block and annotate the block. For example:<br /><br />#pragma scope(FILE* f, fopen(filename, "w"), (void) fclose(f))<br />{<br /> /* ... do stuff to f ... */<br />}<br /><br />/* would be equivalent to */<br /><br />{<br /> FILE* f = fopen(filename, "w");<br /> /* ... do stuff to f ... */<br /> (void) fclose (f);<br />}<br /><br />If the annotations offer much more syntax than that, then it's an entirely different language; might as well go all the way. Same with units -- the effort of building a system for annotating variables, functions, etc. with units could be saved by using a language that can tag objects with metadata.<br /><br />"Might as well go all the way" is a strong argument for me. It takes a lot of effort to build a robust source-to-source translator (imagine trying to guess what's a variable declaration in the full C++ grammar, for example). One might as well start with a cleaner language that has a tight link to the implementation language (so you don't have to reimplement existing libraries). If you pick the right language features then it's a much more general solution -- metadata is a good example, because it can solve not just the units problem, but any kind of semantic information propagation problem (constantness, function purity, thread-local vs. globally visible).<br /><br />It's fun to discuss these things, even though I definitely won't be doing any real work with this any time soon ;-)HilbertAstronauthttps://www.blogger.com/profile/11443786031975040593noreply@blogger.comtag:blogger.com,1999:blog-2572826743364240863.post-56219055736848410782009-06-29T05:44:26.850-07:002009-06-29T05:44:26.850-07:00Sorry, I don't mean "conventions for pass...Sorry, I don't mean "conventions for passing", but instead I mean that the conventions within a name are passed through the compilation phases. For example, if you were to say _meters and if a tool could trace a direct chain of assignments to something with _foot, you would have an error, or a warning if there could be a path, but it can't tell. <br /><br />The idea overall is that you could embed a declarative language inside the usage of an imperative language, using variable naming conventions and specialized syntax within comments. This would then be co-compiled, annotating the intermediate form.<br /><br />As another example, from your next post, you could add a "start constant" and "end constant" as both a hint to the hardware and compiler, and as an assertion.<br /><br />I'm sure this idea is really as old as the hills, with some compilers having a rich ecology of these kinds of pragmas and whatnot, but maybe not.Johnhttps://www.blogger.com/profile/12896413955408148961noreply@blogger.comtag:blogger.com,1999:blog-2572826743364240863.post-48452529138428472142009-06-22T13:02:11.479-07:002009-06-22T13:02:11.479-07:00Sorry about the late reply -- I've been very v...Sorry about the late reply -- I've been very very busy lately (I usually write these blog posts as memory dumps for later reference).<br /><br />I'm not fond of tool-based approaches because I think it's hard to analyze the kinds of codes that people like me write. Data gets shared in weird ways, for example, and pointers pass in and out of libraries. But maybe I'm just not so familiar with existing tools.<br /><br />Could you clarify that question on passing conventions? What would be an example of such a convention? Would it be something like whether indices are zero-based or one-based?HilbertAstronauthttps://www.blogger.com/profile/11443786031975040593noreply@blogger.comtag:blogger.com,1999:blog-2572826743364240863.post-74005544799427563902009-06-17T04:49:55.453-07:002009-06-17T04:49:55.453-07:00I wonder if there is low-level support of the kind...I wonder if there is low-level support of the kind you are talking about, but most of those who do implement such checks do so as a set of tool-enforced conventions on existing languages, that are then separately held. <br /><br />Also, what do you see of the role of richer intermediate languages in passing along the information that certain conventions are held?Johnhttps://www.blogger.com/profile/12896413955408148961noreply@blogger.com