3 ms·

I enjoyed the article, but am maybe too dense to understand the repercussions. My understanding of the summary is that a goal is to be able to develop these gra

I enjoyed the article, but am maybe too dense to understand the repercussions. My understanding of the summary is that a goal is to be able to develop these graphs and then convert them back to ruby so that developers who know ruby can see how the compiler is optimizing. My honest question is, why does this matter? If the developers then start writing code more in line with what a compiler would do, then it seems compilation would be faster - is it significant, and is this a reason why? What else could it be? Thanks for the article and any thoughts!

pubby 6y ago
My apologies if you know this, but by graph it means the mathematics definition (a type of data structure) and not the actual visualization image: https://en.wikipedia.org/wiki/Graph_(discrete_mathematics) https://en.wikipedia.org/wiki/Graph_(discrete_mathematics) Compilers convert source code into graphs and then perform optimizations on these graphs. They never work directly on the source code itself. Once the graphs have been optimized, they're then converted into the target format, which is typically assembly language or bytecode. So mostly this is about techniques compilers use to optimize and transform code.
- Woberto 6y ago
  I didn't know that, thank you for kindly enlightening me! So from the blogpost, the "compiler debug dumps" are the optimized graph data struct, and instead of converting to assembly or byte code, they want to "decompile" or convert back to ruby. Do you think they're doing this to better understand and improve the compiler? Or to write code that is more easily compiled?
  - jimsmart 6y ago
    I suspect this may have originally developed as a debugging aid, your “to better understand and improve the compiler”, but also to better understand how Ruby programs execute. With non-trivial data structures and algorithms (such as sea-of-nodes here), being able to visually introspect statically, and/or visualise its operation dynamically, can often provide informative insights. Instead of, or perhaps as well as, converting to assembly or byte code, here the author is producing a visualisation of the internal graph structure contained within the compiler. The graph isn’t necessarily a one-to-one match with the AST derived from the source, due to graph transformations that take place during the optimising phase of the compiler/runtime. This makes it even more important/interesting to see what is going on under the hood. Usually, in high-level programming languages one rarely has concerns regarding how easily the compiler might deal with the code - one just codes, and uses language features appropriately, as needed. With the only caveat here being the extreme performance crew, e.g. games programmers might use a restricted subset of C++, and also might disassemble compiler output, and use that information to help try and optimise their source somewhat.

pubby 6y ago

My apologies if you know this, but by graph it means the mathematics definition (a type of data structure) and not the actual visualization image: https://en.wikipedia.org/wiki/Graph_(discrete_mathematics) https://en.wikipedia.org/wiki/Graph_(discrete_mathematics) Compilers convert source code into graphs and then perform optimizations on these graphs. They never work directly on the source code itself. Once the graphs have been optimized, they're then converted into the target format, which is typically assembly language or bytecode. So mostly this is about techniques compilers use to optimize and transform code.

Woberto 6y ago
I didn't know that, thank you for kindly enlightening me! So from the blogpost, the "compiler debug dumps" are the optimized graph data struct, and instead of converting to assembly or byte code, they want to "decompile" or convert back to ruby. Do you think they're doing this to better understand and improve the compiler? Or to write code that is more easily compiled?
- jimsmart 6y ago
  I suspect this may have originally developed as a debugging aid, your “to better understand and improve the compiler”, but also to better understand how Ruby programs execute. With non-trivial data structures and algorithms (such as sea-of-nodes here), being able to visually introspect statically, and/or visualise its operation dynamically, can often provide informative insights. Instead of, or perhaps as well as, converting to assembly or byte code, here the author is producing a visualisation of the internal graph structure contained within the compiler. The graph isn’t necessarily a one-to-one match with the AST derived from the source, due to graph transformations that take place during the optimising phase of the compiler/runtime. This makes it even more important/interesting to see what is going on under the hood. Usually, in high-level programming languages one rarely has concerns regarding how easily the compiler might deal with the code - one just codes, and uses language features appropriately, as needed. With the only caveat here being the extreme performance crew, e.g. games programmers might use a restricted subset of C++, and also might disassemble compiler output, and use that information to help try and optimise their source somewhat.