Closed
Description
Hi,
I'm trying to perform a simple load of aag file (code below).
The load function never ends and cause massive memory usage (I stopped the run at 12GB).
I've noticed that the code get stuck at the loop in line 262 of parser.py.
I think that the reason is that at lines 273, 274 the parser aggregates boolean expressions from all the nodes parsed so far. It causes a very long boolean expressions and a massive memory usage.
Can you please assist?
Some technical details:
i10.aig is an example database I got from ABC tool.
I translated it to aag using aigtoaig from AIGER package.
Here is the aag header:
aag 2932 257 0 224 2675
Here is my code:
- import aiger
- databasePath = "./"
- fileName = "i10.aag"
- aig1 = aiger.load(databasePath+fileName)
Activity
mvcisback commentedon Mar 2, 2021
Hi @Hemer911
Could you please attach the file so I can reproduce.
Hemer911 commentedon Mar 2, 2021
i10.aag.gz
Thanks
Fixes memory issues pointed out in #122.
mvcisback commentedon Mar 2, 2021
@Hemer911 I just published a patched py-aiger version.
I now build the AIG directly rather than using the
BoolExpr
DSL.In retrospect, its not surprising given that the current composition code is worst case linear is the right circuit (and thus quadratic for repeated composition of a growing circuit).
I plan to eventually fix this, but its a bit subtle to do and keep things immutable.
Anyway, if you could confirm that it works for you, that'd be great!
Hemer911 commentedon Mar 3, 2021
Hi,
I tried the new version with the file above and 2 other examples and it works great.
Thanks a lot
Hemer911 commentedon Mar 3, 2021
One thing tough, what do you think would be the upper limit of the load function (in terms of number of nodes in the loaded graph)? 10K? 100K? more?
mvcisback commentedon Mar 3, 2021
Hard to say. I think, so long as everything fits in ram (load the file as a string - would be fairly straightforward to change), it should work.
The current algorithm does a linear pass through the aag to build the graph and then another topologically ordered pass to build the circuit.
I think it should grow ~linearly, but there's always surprises...
That said, I think the bigger problem with big circuits at the moment is manipulation, which due to immutability copies the circuit.
There's a lazy api I've been working on which helps amortize the cost, but its not fully baked. I've used it to unroll sequential circuits, and there it worked for large (~10-100k) circuits.