[Poach Algorithm] Term Cache#61
Conversation
merge main into PTP_TermCache
| function speedup(b) { | ||
| const t = b.train.report.run_program; | ||
| const s = b.serve.wall_time_micros; | ||
| return t === 0 || s === 0 ? null : t / s; |
There was a problem hiding this comment.
Would you mind explaining the logic here? Are we using train.report.run_program as an approximation of vanilla?
There was a problem hiding this comment.
Yeah that's right. I want to measure the time for answering the query using the cache compared to the amount of time to just run the program entirely (as in vanilla egglog)
There was a problem hiding this comment.
Do we know if this is a good approximation?
| Rules: b.report.rule_micros, | ||
| Extraction: b.report.extraction_micros, | ||
| Other: b.report.other_micros, | ||
| "Program Run Time": b.train.report.run_program, |
There was a problem hiding this comment.
Related to the question above, we should clarify what "Program Run Time" means.
| } | ||
| } | ||
|
|
||
| // TODO: Add cost model from the e-graph, this is just the default (term size) |
There was a problem hiding this comment.
Reusing the extractor's output, which includes the cost, would be better. I accept this as a workaround.
| /// Uses `Parser::default()`, which does not know about any user-defined sorts or constructors; | ||
| /// for current cache use this is fine because the cached strings are flat term shapes | ||
| /// (apps + literals). Revisit if user-defined macros start appearing in extracted terms. | ||
| fn parse_cached_term(td: &mut TermDag, s: &str) -> TermId { |
There was a problem hiding this comment.
There is an optimization opportunity here. Potentially clean up the code as well.
In serialization, the code transforms (TermDag, Vec<TermId>) into Vec<String>. This involves expanding each term separately, which means no sharing of common subexpressions.
In deserialization, the code transforms Vec<String> back into (TermDag, Vec<TermId>).
An optimization is to serialize and deserialize (TermDag, Vec<TermId>) directly without going through the Vec<String> representation.
3 participants
No description provided.