HN user

jimaway123

3 karma
Posts0
Comments6
View on HN
No posts found.

Yes I can see it would be pretty fast, but the computation is defined at run time and its evaluation uses pointers to the various nodes of the computation graph. This limits what optimizations be applied (ie inlining, vectorization, reordering, etc). I'm just curious if anyone has taken this a step further and written something like PSAC except with a code-generation step that creates an optimized implementation of psac_propagate() for the specific computation graph.

How do you consistently update a DAG, like you describe in your medium article, if the functions corresponding to the nodes in the graph are free to create new dependencies willy-nilly? It seems like this would have to be pretty restricted and/or performance killing, because you'd have to evaluate the graph under the assumption that any node could depend on any other node (unless that dependency creates a cycle, presumably). This overhead may not matter if the node functions are expensive relative to the cost of managing the graph, though.

Can anyone comment on the suitability of databases of any kind as the data source for running a "high frequency trading" backtest? The fact that the market data ticks are in a database doesn't seem that helpful, given that the order book state needs to be built up by processing all previous ticks since market open anyway.

  block
    statement (assignment)
      expression
        operator (post-increment)
          operator (dereference)
            variable
      expression
        variable
I don't think this could possibly be a valid AST for '*lwr++ = x' because the increment is not an operation on the dereferenced value, its an operation on the pointer. So in this case I don't see how it could help but be transformed into a form similar to the "beginner friendly" case.

Or perhaps I am wrong and it would generate an AST like you describe and rely on later passes to actually create a proper dependency graph. My mental model of how these kinds of postfix operators work always assumed it must very early on turn it into two separate statements. Thank you for the suggestions.

Does anyone know exactly what is going on here to cause this difference? I am extremely puzzled that the "beginner friendly" code is not at some point in the compilation pipeline in EXACTLY the same representation as the non-"beginner friendly" code. I would imagine they'd be in the same form very early on, perhaps even at the point of generating an initial syntax tree. And once they take on the same form in the compilation pipeline, the resulting compiler output should be identical. So what is really going on here?